运维体系（Ops / SRE Platform）
目标：让系统“可发布、可回滚、可治理、可恢复”
P0（基础运维）
├── CMDB
├── 容器平台（K8s）
├── 发布平台
├── 配置中心
P1（稳定运行）
├── 服务治理（Service Mesh / Dubbo / SpringCloud）
├── 运维工具集
P2（事件驱动）
├── 事件中心（告警 / 事件 / 变更）
├── 灰度平台（Feature Flag）
├── 变更管理平台
P3（可靠性工程）
├── 自动化运维 / 自愈
├── 容量 & 成本管理
├── 运维审计 / 合规
一、CMDB 的本质与定位
下面我从体系定位 → 数据模型 → 核心能力 → 与周边平台的关系 → 落地难点与治理 → 成熟度演进六个维度，系统、务实地展开 CMDB（Configuration Management Database，配置管理数据库），重点放在企业级、平台化、可持续治理视角，而不是停留在“资产表”。
1️⃣ 一句话定义（工程视角）
CMDB 是企业 IT 与业务系统的“权威配置事实源（Single Source of Truth）”，用于描述“系统由什么组成、它们如何关联、当前处于什么状态”。
关键词：
- 事实源
- 关系
- 状态
- 变更可追溯
2️⃣ CMDB 不是“资产台账”
很多 CMDB 失败的原因在于定位错误：
| 错误认知 | 正确认知 |
|---|---|
| CMDB = 服务器清单 | CMDB = 配置与依赖图谱 |
| 手工维护 | 自动发现 + 受控写入 |
| 给运维用 | 给整个研发、运维、安全体系用 |
| 记录信息 | 驱动决策与自动化 |
二、CMDB 的核心对象模型（CI Model）
1️⃣ CI（Configuration Item）是什么？
CI 是 CMDB 中一切可被管理、被关联、被变更的对象。
常见 CI 类型
-
基础设施
- IDC / Region / AZ
- 物理机 / 云主机
- 网络设备
-
平台资源
- K8s Cluster / Node / Namespace
- 数据库 / MQ / 缓存
-
应用与服务
- Application
- Service
- Instance
-
逻辑对象
- 账号 / 密钥
- 域名 / 证书
-
组织对象
- Team / Owner / On-call
2️⃣ CI 的三要素
（1）属性（Attributes）
- 名称、类型、规格、状态、标签
- 生命周期状态（创建 / 在用 / 下线）
（2）关系（Relationships）—— CMDB 的灵魂
- 部署关系：Service → Instance
- 依赖关系：Service A → Service B
- 运行关系：Instance → Host / Pod
- 归属关系：Service → Team
（3）版本与变更
- 配置快照
- 变更历史
- 差异比对
三、CMDB 的核心能力模块
1️⃣ 资产与配置管理（基础能力）
- 统一资源视图
- 资源状态管理
- 生命周期管理（上线 / 下线 / 回收）
⚠️ 仅做到这一层，CMDB 价值有限。
2️⃣ 自动发现与同步（成败关键）
常见数据源
- 云厂商 API
- K8s API
- 虚拟化平台
- 监控系统
- 部署系统（CI/CD）
原则
- 系统自动发现为主
- 人工只做确认与补充
- 禁止直接改“事实字段”
3️⃣ 拓扑与依赖关系管理
- 服务调用拓扑
- 资源依赖拓扑
- 多层视角切换（业务 / 技术 / 资源）
📌 这是 CMDB 能真正支撑故障定位、影响分析的核心能力。
4️⃣ 变更管理支撑
CMDB 是变更管理的“基线”。
-
变更前：
- 影响分析（哪些服务 / 用户）
-
变更中：
- 状态锁定
-
变更后：
- 配置漂移检测
5️⃣ 查询与事实服务（API 化）
- CMDB 不只是 UI
-
更重要的是：
- API
- Graph Query
- 订阅变更事件
四、CMDB 在整个运维 / 安全体系中的位置
你可以把 CMDB 看成 “运维与安全平台的底座中枢”。
┌────────────┐
│ 业务系统 │
└─────▲──────┘
│
┌────────────┐ ┌───┴────────┐ ┌──────────────┐
│ CI/CD │→ │ CMDB │ ←│ 云 / K8s │
└────────────┘ └───▲────────┘ └──────────────┘
│
┌──────────┬──────────┬──────────┬──────────┐
│监控告警 │风控安全 │发布变更 │成本治理 │
└──────────┴──────────┴──────────┴──────────┘
五、CMDB 在关键场景中的价值
1️⃣ 故障影响分析
- 一个节点宕机
-
快速定位：
- 影响哪些 Service？
- 哪些业务线？
2️⃣ 预测性运维（强相关）
- 资源趋势 × 拓扑
-
判断：
- 是否会扩散
- 是否需要提前干预
3️⃣ 安全与合规
- 资产可见性
- 敏感系统识别
- 变更审计
六、CMDB 常见失败原因（非常现实）
1️⃣ 数据不可信
- 手工维护
- 多系统冲突
2️⃣ 模型设计过重
- 一开始就想“全建模”
- 结果没人用
3️⃣ 没有治理机制
- 无 Owner
- 无写入规则
- 无变更流程
七、CMDB 的治理原则（务必重视）
三条铁律
- 事实字段只允许系统写
- 每个 CI 必须有 Owner
- 变更必须可追溯
模型演进原则
- 先核心（Service / Instance）
- 再扩展（网络 / 安全 / 账号）
八、CMDB 成熟度模型
L1：资产台账
- 人工维护
- 低可信
L2：自动同步
- 云 / K8s 接入
- 数据开始可信
L3：关系驱动
- 拓扑可用
- 支撑故障分析
L4：平台底座
- 变更、告警、发布强依赖
