IDS Platform Ops Docs main roadmap.md

平台运营文档路线图

本文档用于规划 platform-ops-docs 的后续建设节奏，面向系统管理员、平台运维、平台运营和实施支持等读者。它只回答“平台运营文档下一步先补什么、为什么先补这些、补到什么程度算完成”，不替代产品功能 roadmap，也不替代 backlog 的需求真源。

功能能力的真实优先级、增强价值和未决项，仍以产品 backlog 的维护结果为准；本路线图只负责把这些事实映射成 platform-ops-docs 的文档建设排期。

当前基线

当前 platform-ops-docs 已具备一套可用 v1，共包含 20 份公开文档：

  • 1 份总导航：README.md
  • 7 份核心专题页：平台初始化、租户治理、认证接入治理、安全运营、可观测性与健康检查、变更管理、常见问题与排障
  • 2 份承接参考页：平台接入与联调参考、平台 MCP 运维参考
  • 9 份 SOP：新环境初始化、日常巡检、租户生命周期治理、认证接入基线检查、审计排查、变更前检查、变更后验收、跨租户排障、安全事件处置
  • 1 份路线图：本文档本身

当前文档已经能够支撑以下平台高频路径：

  • 平台初始化与基础环境复核
  • 平台日常巡检与发布后可用性确认
  • 租户生命周期治理与禁用租户语义判断
  • 平台认证、联邦、SAML、SCIM 的边界说明
  • 审计、安全、跨租户和高风险异常的第一轮分流
  • 平台侧 MCP 只读排障入口的公开说明

当前文档也有明确边界：

  • 不展开单租户用户、应用、角色、品牌、联邦、SCIM 的日常维护步骤
  • 不承诺未落地平台能力，不把企业化增强项写成现有正式能力
  • 不替代产品 backlog，也不回退成对仓库内部目录的相对依赖

规划原则

  • 只写已落地能力、现有入口和已有产品边界，不发明第二套能力口径。
  • 优先补强平台高频使用路径，而不是平均铺开所有专题。
  • 优先服务系统管理员、平台运维、平台运营和实施支持四类读者。
  • 平台文档与租户文档严格分边界；只要问题转入单租户内日常维护，就跳转到租户公开文档。
  • 路线图采用 Now / Next / Later 三阶段，而不是季度时间表；阶段变化由文档成熟度和产品 backlog 真源驱动。

Now

为什么现在做

当前 platform-ops-docs 已经从骨架升级为可用 v1，下一步最有价值的工作不是继续加更多新主题，而是把现有高频路径补到“稳定可交付”。平台管理员现在最常走的仍然是巡检、变更前后检查、跨租户排障和安全初判四条链路，这些链路如果文档表达再不够顺，就会直接影响交付和排障效率。

重点补强文档

本阶段要补什么

  • 统一 README、专题页和 SOP 之间的互链和阅读顺序，减少“知道入口但不知道下一篇去哪”的跳转断层。
  • 为高频专题增加更稳定的交叉引用口径，例如健康专题到安全专题、安全专题到审计 SOP、租户治理到跨租户排障。
  • 为 9 份 SOP 进一步补清晰的结果记录模板、异常分流规则和平台/租户边界提示。
  • 把高频路径沉淀成更显式的“先看哪里、再去哪里、何时升级”的表达，而不是只散落在单篇正文中。
  • 补齐平台接入与 MCP 两类承接页，减少对外部文档的依赖。

完成标准

  • 平台管理员能仅靠现有文档走通“巡检、变更前后检查、跨租户排障、安全初判”四条主路径。
  • README 到专题页、专题页到 SOP、SOP 到租户公开文档的导航闭环清晰。
  • 9 份 SOP 的结果记录、异常分流和升级判断风格一致。
  • 文档不再因为表达差异造成“平台级 vs 租户级”的判断摇摆。

当前依赖事实

  • 当前 platform-ops-docs 全量公开文档
  • 平台健康与运维视图已形成平台内主链路
  • 租户侧已有独立公开文档入口可承接单租户 handoff

Next

为什么现在做

当现有平台文档的主路径已经稳定后，最值得补的不是泛化的“更多说明”，而是与 post-MVP 高优先级能力增强对齐的文档深化。当前最值得增强的方向集中在审计追踪、安全编排、联邦、SAML、SCIM 和可观测性；platform-ops-docs 需要同步成为这些增强项的文档落点，否则产品能力进化后，平台侧文档会再次滞后。

重点补强文档

本阶段要补什么

  • 审计方向：补更清晰的长期留存、归档、导出和高风险事件追踪口径。
  • 安全方向：补更多安全信号解释、会话异常诊断、统一排障串联和平台级安全初判路径。
  • 联邦方向：补更深的外部 OIDC 联邦诊断、模板化治理说明和身份源边界判断。
  • SAML 方向：补兼容矩阵、典型 SP 模板知识和高级诊断的文档落点。
  • SCIM 方向：补更大规模同步治理、手动 replay 可观测性和失败分类的运营表达。
  • 可观测性方向：补部署侧复用健康端点和平台诊断结果接入外部监控的 SOP 或附录说明。
  • 在相关专题里增加更多“当前版本限制与建议做法”小节，避免读者把企业化增强项误读为已经正式交付。

完成标准

  • 与 feat-0002、feat-0005、feat-0006、feat-0007、feat-0009、feat-0003 对应的文档增强点，都能在 platform-ops-docs 中找到明确落点。
  • 平台文档能解释这些能力“现在支持什么、下一阶段增强什么、当前建议怎么做”。
  • 高级诊断、模板化治理、失败分类和外部监控接入建议，不再只散落在内部 backlog 或外部旧文档中。
  • 文档仍然保持平台视角，不把租户内参数维护回灌到平台专题里。

当前依赖事实

  • feat-0002：审计与操作追踪增强
  • feat-0005：外部身份源联邦与 JIT
  • feat-0006：租户隔离与请求安全
  • feat-0007：SAML IdP 与联邦治理
  • feat-0009：供给与 SCIM
  • feat-0003：运维、可观测性与健康能力

Later

为什么现在做

当高频路径稳定、并且 post-MVP 高优先级能力的文档落点已经建立后，platform-ops-docs 的价值就不应只停留在“当前怎么查”。更长期的目标是把它升级成平台运营知识库，让平台团队可以持续沉淀兼容矩阵、交付模板、值守手册和排障经验，而不是每次都回到内部真源或零散旧文档中重新组织知识。

重点补强文档

本阶段要补什么

  • 增加更结构化的附录，例如联邦或 SAML 兼容矩阵、排障知识库、交付检查模板、平台值守手册。
  • 视产品演进情况，评估是否拆出独立子专题，例如更完整的安全信号解释、监控接入 SOP、联邦模板库说明。
  • 建立路线图和平台文档的版本标记或阶段标记方式，让读者知道哪些部分是稳定基线、哪些部分是企业化增强沉淀。
  • 逐步把高频排障经验和交付经验从“人脑经验”转成平台文档资产。

完成标准

  • platform-ops-docs 不再只是当前态文档集合，而是形成稳定的知识沉淀入口。
  • 至少存在一类结构化附录或知识库型内容，能够支持后续平台交付和排障复用。
  • 路线图更新机制和阶段状态表达稳定下来，不依赖单次集中重写。

当前依赖事实

  • 后续 backlog 优先级变化
  • 已稳定运行一段时间后的平台交付与排障反馈
  • 当前 platform-ops-docs 的使用反馈

维护规则

  • 当 platform-ops-docs 新增专题、承接页或新增 SOP 时，更新本路线图中的“当前基线”和阶段目标。
  • 当产品优先级发生变化时，复核 Next / Later 阶段内容。
  • 当平台已支持能力边界发生变化时，同步调整“当前基线”和阶段描述，避免路线图继续沿用过期口径。
  • 不要求每次小改动都更新本路线图；只有在阶段目标、优先级、文档集合或关键事实源变化时才更新。
  • 如果后续出现平台文档建设与产品 backlog 口径冲突，以产品 backlog 为准，再回头修正本路线图。