vault backup: 2026-07-16 16:10:15

xinfra/requirements.md

@@ -27,7 +27,7 @@ mindmap
       标准化部署
       任务中心
     监控
-      健康状态看板
+      状态看板
     告警
       统一告警
 ```
@@ -54,17 +54,30 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
 
 ## 痛点 2：出了问题，不知道谁操作过
 
-某台机器配置被改了、某个服务被重启了，事后无法追溯是誰在什么时间做的操作。
+某台机器配置被改了、某个服务被重启了，事后无法追溯是谁在什么时间做的操作。
 
-| | 不使用 XINFRA | 使用 XINFRA |
+|      | 不使用 XINFRA         | 使用 XINFRA                 |
-|------|--------------|------------|
+| ---- | ------------------ | ------------------------- |
 | 责任追溯 | 出了问题不知道谁操作过，排查全靠问人 | 每次操作自动记录，谁、什么时间、做了什么，一查便知 |
 
 ### 我们怎么解决
 
-主系统内置审计面板，记录每一次登录事件和运维操作，支持按时间、操作人、操作类型筛选查询。
+主系统内置审计面板，记录**谁在什么时间进入了哪个子系统**，以及**在主系统本身执行的操作**（如节点加入向导、配置查看等），支持按时间、操作人、操作类型筛选查询。
 
-> **用户故事**：SRE 小王发现昨天有人在运维终端执行了节点操作，打开审计面板按时间筛选，立刻定位到具体操作人和操作内容。普通操作员 SRE 小张只能看到自己的登录记录，管理员老刘则能查看全局审计日志。
+**注意**：子系统内部的操作详情（如 Wayne 里的部署动作、CacheCloud 里的配置变更）由各子系统自行记录。主系统提供从审计面板跳转到对应子系统审计日志的入口，便于链路追溯。
+
+### 战略决策：为什么不将子系统操作统一纳入主系统审计？
+
+统一审计听起来更完整，但在当前阶段既不现实也不划算：
+
+| 维度 | 统一采集（主系统接管所有子系统操作日志） | 分级审计（各子系统自行记录，主系统提供跳转入口） |
+|------|------|------|
+| 可行性 | Wayne、CacheCloud、CloudDM 等子系统是独立平台，不暴露标准化审计接口，主系统无法侵入实现去拦截操作 | 无需侵入子系统，利用各子系统已有的审计能力即可 |
+| 成本收益 | 需与每个子系统逐一对接审计事件采集协议，开发维护成本高；子系统已有审计记录，重复采集无增量价值 | 几乎零额外开发成本，主系统只管自己能掌控的部分 |
+| 职责边界 | 主系统越界接管子系统内部事务，耦合度高，后续子系统变更会直接影响主系统 | 主系统负责「谁进了哪里」+「在主系统做了什么」，子系统各管各的，边界清晰 |
+| 可演进性 | 架构一次到位但改动面大，后续子系统升级可能需要重做对接 | 当前跳转方案够用；未来子系统开放审计 API 后可按需接入聚合，渐进演进 |
+
+> **用户故事**：SRE 小王发现昨天有人进入了运维终端，打开审计面板按时间筛选，看到某人在 14:32 跳转进入了 Wayne 并在主系统执行了节点加入操作。需要进一步查看该人员在 Wayne 内部的具体部署动作时，从审计面板直接跳转到 Wayne 的审计日志。普通操作员 SRE 小张只能看到自己的记录，管理员老刘则能查看全局审计日志。
 
 ---
 
@@ -98,7 +111,7 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
 
 **做什么 / 不做什么**
 
-- ✅ 变更审批流程、SQL 审核与脱敏、变更历史记录
+- ✅ 主要做入口接入
 - ❌ SQL 执行/变更操作本身由 CloudDM 处理，XINFRA 不直接执行数据库操作
 
 > **用户故事**：SRE 小王需要在生产 MySQL 执行一条线上变更，在 CloudDM 提交工单，系统自动预检风险，通过后等待 DBA 审核，审核通过后自动执行。SRE 小张需要查询业务库数据做排查，在 CloudDM 申请临时查询权限，在线查询时敏感字段自动脱敏。出了问题，管理员老刘可以通过审计记录追溯完整的操作链路。
@@ -126,13 +139,13 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
 
 ---
 
-## 痛点 6：多机房配置变更靠逐台操作
+## 痛点 6：服务配置变更管理分散
 
 服务配置分散在各机房，变更时需要逐机房登录修改，改漏一个就出故障，没法撤回。
 
-| | 不使用 XINFRA | 使用 XINFRA |
+|      | 不使用 XINFRA            | 使用 XINFRA            |
-|------|--------------|------------|
+| ---- | --------------------- | -------------------- |
-| 配置变更 | 7 个机房逐个改，改漏一个就出故障，没法撤回 | 改一次自动下发所有机房，改错了能立刻回滚 |
+| 配置变更 | 多个机房逐个改，改漏一个就出故障，没法撤回 | 改一次自动下发所有机房，改错了能立刻回滚 |
 
 ### 我们怎么解决
 
@@ -147,13 +160,13 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
 
 ---
 
-## 痛点 7：资源台账散落在多个平台
+## 痛点 7：机器（物理机/虚机）信息存储在 CMDB 平台
 
-服务器信息散在好几个平台，查一台机器要登录好几个地方。
+服务器信息散落在内部 CMDB，查看机器信息不包含有机器情况的信息。
 
 | | 不使用 XINFRA | 使用 XINFRA |
 |------|--------------|------------|
-| 资源台账 | 服务器信息散在好几个平台，查一台机器要登录好几个地方 | 一个页面查到所有服务器，按业务线、机房随便筛 |
+| 资源查找 | 服务器信息散落在 CMDB 和多个云平台，各平台数据格式不统一，查一台机器要逐个平台查看、手动拼凑 | 一个页面聚合所有平台的服务器信息，按业务线、机房统一筛选 |
 
 ### 我们怎么解决
 
@@ -161,6 +174,17 @@ SRE 日常工作涉及 6+ 个系统，每个系统有独立地址和账号，每
 
 > **用户故事**：SRE 小王打开资源台账，看到所有资源的来源统计和最近同步状态。需要查找某台机器时，按业务线和机房筛选，快速定位。SRE 小张发现某台虚机信息需要补充，在台账中标记为人工维护，后续云同步不会覆盖这些字段。需要申请新虚机时，通过台账的「创建虚机」入口直接跳转。
 
+### 战略决策：为什么不直接在 XINFRA 上做 CMDB 的增改查？
+
+XINFRA 只做查找和展示，不替代 CMDB 的写入能力。原因：
+
+| 维度 | 在 XINFRA 上做完整 CRUD | 只做查找与展示 |
+|------|------|------|
+| 数据源头 | 需要在 XINFRA 与多个 CMDB 之间做双向同步，写入冲突难以仲裁 | CMDB 仍是唯一写入源，XINFRA 只读同步，不存在一致性问题 |
+| 职责边界 | XINFRA 变成"超级 CMDB"，和各平台职责重叠，运维人员不知道该在哪改数据 | XINFRA 是聚合查询入口，CMDB 是数据维护入口，各有分工 |
+| 开发成本 | 每对接一个 CMDB 都要实现完整的读写逻辑和权限校验，开发量随平台数线性增长 | 只对接读取接口，成本低、上线快 |
+| 数据正确性 | 多写入源必然引入脏数据风险，需要额外的冲突检测和修正机制 | 单一写入源，数据正确性由 CMDB 自身保障 |
+
 ---
 
 ## 痛点 8：服务注册信息分散，跨机房查找困难