IDS Tenant Ops Docs main roadmap.md

tenant-ops-docs 文档演进 Roadmap

本文档是 tenant-ops-docs 的长期文档演进真源，用于规划租户运营文档接下来 3 个月 / 半年 / 一年 的建设重点、优先顺序和完成标准。

这份 roadmap 只服务“租户运营文档演进”，不替代产品功能 backlog，也不复述平台级路线图。涉及产品能力优先级，请继续参考内部 backlog 维护口径；涉及平台级运营文档边界，请继续参考 平台问题分流与排障。

当前基线

当前 tenant-ops-docs 已形成完整首版结构，具备：

  • 1 个主导航页：README.md
  • 8 个专题页：用于解释边界、原则、阅读顺序和常见任务
  • 9 个高频 SOP：用于指导租户初始化、用户开通、应用接入、访问治理、联邦 / SCIM 配置和高频排障

当前目录已经可以支撑单租户场景下的基础交付、日常运营和常见问题定位，但仍处于“首版成型、可继续增强”的阶段。接下来的演进重点不是继续扩目录，而是把现有内容补到更可交付、更可接手、更可维护。

目标读者与使用边界

这份 roadmap 默认面向内部团队：

  • 实施与交付同学
  • 客户成功与运营支持同学
  • 负责维护 tenant-ops-docs 的文档维护者
  • 需要判断文档应该落在哪个目录的产品 / 研发协作者

这份 roadmap 不负责：

  • 规划产品 feature 开发优先级
  • 代替 backlog/README.md 的功能路线图
  • 代替 platform-ops-docs 的平台文档演进计划

Roadmap 原则

  • 先补最常用、最影响交付和排障效率的页面
  • 先提升现有页面质量，不优先增加大量新页面
  • 专题页负责解释“为什么、什么时候、边界是什么”，SOP 负责解释“怎么做、做完怎么看”
  • 同一能力只保留一个租户侧正式说法，避免在 tenant-ops-docs 和 docs/usage-guide 出现冲突口径
  • 每个阶段都必须有可验证的文档结果，而不是抽象愿景
  • 页面组织、拆分方式和展项策略统一参考 mkdocs-for-agent

3 个月

目标：把首版文档从“完整”提升到“可直接交付”。

重点工作

  • 补齐高频 SOP 的字段说明、入口截图位、验收结果示例和常见误填提醒
  • 统一专题页与 SOP 的术语、边界、交叉引用和升级条件
  • 为最核心场景建立稳定阅读路径：
    • 新接手租户
    • 用户开通与处置
    • 应用接入与访问开通
    • 联邦 / SCIM 配置
    • 登录失败 / 权限未生效
  • 收敛旧入口迁移策略，明确哪些旧文档继续保留，哪些只保留迁移提示

重点页面

完成标准

  • 高优先级页面都具备“步骤 + 成功判断 + 失败排查”
  • README 到专题页、专题页到 SOP、SOP 到外部参考的链路完整
  • 同一问题不会在 tenant-ops-docs 与 docs/usage-guide 出现冲突说法
  • 新接手租户、开用户、开应用、配联邦 / SCIM、查登录与权限问题都能在目录内找到明确入口

半年

目标：把文档从“可交付”提升到“可运营、可接手、可培训”。

重点工作

  • 为每个主题沉淀标准检查清单、执行模板和建议记录格式
  • 增加更强的场景化内容：
    • 交付前检查
    • 变更后验证
    • 周期性巡检
    • 常见投诉与支持工单处理路径
  • 补齐文档中的证据项说明：
    • 应该看哪个页面
    • 应该确认哪些字段
    • 哪类错误应升级到平台侧
  • 建立租户运营知识库索引：
    • 高频问答
    • 常见误区
    • 排障症状到文档入口的映射
  • 形成固定维护节奏，例如季度回看与功能现状对齐

重点建设方向

完成标准

  • 非原作者可按文档完成主要租户运营任务
  • 实施、客服和租户管理员支持者能从同一目录找到对应入口
  • 常见问题可通过 README 和排障页直接路由到正确 SOP
  • 文档不再只适合“熟悉系统的人”，而能支撑接手、培训和日常协作

一年

目标：把文档从“人工维护”提升到“体系化治理”。

重点工作

  • 建立 tenant-ops-docs 与产品能力、后台入口、审计 / 运维入口之间的长期映射规则
  • 为文档增加版本化维护意识：
    • 哪些文档是基线
    • 哪些文档是专题增强
    • 哪些文档需要随 feature 变化同步更新
  • 评估引入更结构化的文档资产：
    • 模板库
    • 统一术语表
    • FAQ / 知识库专页
    • 交付包式目录组织
  • 把 tenant-ops-docs 从“文档集合”演进为“租户运营知识中心”

长期建设方向

  • 建立“新增租户能力 → 应更新哪些文档”的判断规则
  • 稳定 tenant-ops-docs、platform-ops-docs、docs/usage-guide 三者边界
  • 让 README 既能做导航，也能做知识中心入口
  • 让长期维护更少依赖个人经验，更依赖文档规则和模板

完成标准

  • 新增租户相关能力时，能快速判断应更新哪类文档
  • 文档目录结构稳定，不因零散新增而失控
  • tenant-ops-docs 与 platform-ops-docs、docs/usage-guide 的边界长期清晰
  • 文档维护从“有人记得就改”演进为“有规则、有入口、有节奏地更新”

优先增强主题

以下排序用于指导文档增强顺序，不代表这些页面当前不可用，而是表达“下一步优先补强哪里最有价值”。

  1. tenant-initialization
  2. tenant-handover-checklist
  3. tenant-add-user
  4. tenant-add-application
  5. application-access-assignment
  6. federation-and-sync
  7. configure-federation
  8. configure-scim
  9. troubleshoot-login-failure
  10. troubleshoot-permission-not-effective
  11. branding-and-login-experience
  12. branding-preview-and-publish
  13. daily-checks-and-troubleshooting
  14. core-objects-and-boundaries
  15. permissions-and-access-governance
  16. application-management
  17. user-operations

排序原则

  • 先补最常用、最影响交付和排障效率的页面
  • 再补中层专题说明和边界解释
  • 最后补长期知识治理型内容
  • 导航、承接页和专题拆分方式保持与 mkdocs-for-agent 一致

验收口径

这份 roadmap 本身应满足以下条件：

  • roadmap.md 能独立阅读，不依赖额外上下文解释
  • README.md 能直接跳到 roadmap
  • roadmap 中引用的文档路径全部存在
  • roadmap 中的阶段目标都能映射到当前目录内具体页面，而不是抽象口号
  • roadmap 不与内部 backlog 的产品 feature 路线图混淆

维护规则

  • 本文档是 tenant-ops-docs 的路线图真源；租户运营文档优先级变化时，应先更新这里
  • 如阶段目标变化，应同步更新 README 中对 roadmap 的导航说明
  • 若某个增强方向已经完成，应从对应阶段移到“当前基线”或维护规则，不继续保留在路线图中堆积
  • 如果未来出现平台级路线图需求，应在 platform-ops-docs 独立维护，而不是回写到这里
  • 若页面结构或导航方式需要调整，先查 mkdocs-for-agent 再决定是否拆页或增导航专页

返回 租户运营配置文档