运维体系（Ops / SRE Platform）
目标：让系统“可发布、可回滚、可治理、可恢复”
P0（基础运维）
├── CMDB
├── 容器平台（K8s）
├── 发布平台
├── 配置中心
P1（稳定运行）
├── 服务治理（Service Mesh / Dubbo / SpringCloud）
├── 运维工具集
P2（事件驱动）
├── 事件中心（告警 / 事件 / 变更）
├── 灰度平台（Feature Flag）
├── 变更管理平台
P3（可靠性工程）
├── 自动化运维 / 自愈
├── 容量 & 成本管理
├── 运维审计 / 合规
事件中心（Event Center：告警 / 事件 / 变更）
下面我从统一控制面的视角，对 事件中心（Event Center：告警 / 事件 / 变更）做一次企业级、平台化、强治理的系统性拆解。
重点不是“三个模块各自是什么”，而是：为什么一定要把它们放在同一个中心，以及它们如何形成闭环。
一、事件中心的本质定位
1️⃣ 一句话定义
事件中心是生产系统中一切“异常、变化与风险”的统一感知、关联、处置与审计中枢。
它解决的不是“有没有告警”，而是：
系统正在发生什么、为什么发生、是否可控、谁该负责、是否该继续变更。
2️⃣ 为什么一定要“合在一起”
如果把三者拆开：
- 告警系统：只知道“指标异常”
- 事件系统：只知道“有人在处理”
- 变更系统：只知道“有人在发布”
👉 真正的生产事故，恰恰发生在三者的“交叉地带”。
事件中心的价值就在于： 把“异常信号 + 人的响应 + 系统变更”放进同一时间轴和因果链里。
二、核心对象与关系（非常关键）
1️⃣ 三类核心对象
| 对象 | 定义 |
|---|---|
| 告警（Alert） | 系统自动产生的异常信号 |
| 事件（Incident） | 需要人介入处理的生产异常 |
| 变更（Change） | 对生产系统产生影响的主动行为 |
2️⃣ 它们之间的关系
Alert (信号)
↓ 触发 / 聚合
Incident (事故)
↑ ↓
关联 影响
Change (变更)
一句话总结：
告警是“感觉异常”，事件是“确认异常”，变更是“最可能的原因”。
三、告警中心（Alert Management）
1️⃣ 告警的真实职责
告警不是为了“通知”，而是为了“触发正确的动作”。
2️⃣ 告警来源
- Metrics（QPS / RT / Error）
- Logs（关键错误）
- Traces（异常路径）
- 外部系统（云 / 网络 / 安全）
3️⃣ 告警治理能力（重点）
（1）告警收敛
- 时间窗口聚合
- 相同根因合并
- 抑制级联告警
（2）告警分级
- P0 / P1 / P2
- 是否影响用户
- 是否影响 SLO
（3）告警路由
- 服务 Owner
- 值班表（On-call）
- 多渠道（IM / 电话）
📌 没有收敛和分级的告警系统，一定会把人打垮。
四、事件中心（Incident Management）
1️⃣ 什么是“事件”
事件不是告警的集合，而是一个“需要被解决的生产问题”。
2️⃣ 事件生命周期（标准模型）
Detect → Declare → Triage → Mitigate → Resolve → Review → Close
3️⃣ 事件的核心能力
（1）事件定级
- P0：业务不可用
- P1：核心功能受损
- P2：局部影响
（2）事件协同
- War Room
- 时间线记录
- 责任人
（3）指标度量
- MTTA（响应）
- MTTR（恢复）
- 影响范围
📌 事件系统的目标不是“快关闭”，而是“可复盘”。
五、变更中心（Change Management）
1️⃣ 变更的真实地位
在现代系统中，变更不是例外，而是“常态风险源”。
经验法则：
70% 以上的事故，直接或间接与变更相关。
2️⃣ 变更的核心类型
- 发布（Release）
- 配置变更
- 流量策略变更
- 基础设施变更
3️⃣ 变更生命周期
Plan → Review → Approve → Execute → Verify → Close
4️⃣ 变更风险控制（平台价值）
发布前
- 是否在冻结窗口
- 是否有未关闭 Incident
- 是否 Error Budget 不足
发布中
- 指标实时监控
- 自动暂停 / 回滚
发布后
- 变更影响分析
- 与告警/事件强关联
六、三者合一后的“核心能力跃迁”
1️⃣ 因果关联能力
Change A
↓ 5 min
Alert X / Y
↓
Incident #123
👉 平台可以回答：
- 是不是这次变更导致的？
- 是否需要自动回滚？
2️⃣ 风险感知能力（迈向预测性）
- 高频变更服务
- 历史事故关联度高的变更类型
- 高风险时段
3️⃣ 自动化闭环
Alert
→ Incident
→ Runbook
→ Change / Rollback
→ Verify
📌 这是从“人救火”走向“系统控风险”的关键一步。
七、事件中心与周边平台的关系
与 CMDB
- 服务拓扑
- 影响面分析
- Owner 定位
与发布平台
- 变更数据来源
- 回滚执行
与 SRE
- SLO / Error Budget
- 事件复盘机制
八、常见失败模式（非常真实）
- 告警很多，但没人认领
- 事件只是工单
- 变更系统和发布割裂
- 事故无法回答“为什么”
九、成熟度演进模型
L1：工具割裂
- 告警 / 工单 / 发布各自为战
L2：事件平台
- 事件有流程
L3：关联治理
- 告警 ↔ 事件 ↔ 变更
L4：SRE 化
- Error Budget 门禁
- 变更驱动事件分析
