运维体系（Ops / SRE Platform）
目标：让系统“可发布、可回滚、可治理、可恢复”
P0（基础运维）
├── CMDB
├── 容器平台（K8s）
├── 发布平台
├── 配置中心
P1（稳定运行）
├── 服务治理（Service Mesh / Dubbo / SpringCloud）
├── 运维工具集
P2（事件驱动）
├── 事件中心（告警 / 事件 / 变更）
├── 灰度平台（Feature Flag）
├── 变更管理平台
P3（可靠性工程）
├── 自动化运维 / 自愈
├── 容量 & 成本管理
├── 运维审计 / 合规
服务治理
下面我将从“工具不是清单，而是能力组合”的视角，对运维工具集（Ops Toolchain / SRE Tooling）做一次体系化、平台化、可演进的详细拆解，重点放在：每一类工具解决什么问题、如何组合成体系、以及如何避免“工具堆砌而无治理”。
一、运维工具集的总体定位
1️⃣ 一句话定义
运维工具集，是围绕“系统稳定运行与快速恢复”，在不同阶段提供感知、控制、自动化与治理能力的一组工具与平台组合。
它不是：
- 某一个工具
- 某一个厂商方案
而是：
一条贯穿“发现 → 决策 → 行动 → 复盘”的工具链。
二、运维工具集的能力分层（最重要）
┌──────────────────────────────┐
│ 治理与决策层 │ SLO / Error Budget / 风险
├──────────────────────────────┤
│ 分析与定位层 │ 日志 / Trace / RCA
├──────────────────────────────┤
│ 感知与告警层 │ 监控 / 告警
├──────────────────────────────┤
│ 控制与变更层 │ 发布 / 配置 / 流量
├──────────────────────────────┤
│ 执行与自动化层 │ Runbook / 自愈
├──────────────────────────────┤
│ 资源与基础设施层 │ 主机 / K8s / 云
└──────────────────────────────┘
三、核心工具分类与作用详解
1️⃣ 可观测性工具集（Observability）
监控（Metrics）
- Prometheus / VictoriaMetrics
- 关注趋势、容量、SLO
日志（Logs）
- ELK / Loki
- 定位“发生了什么”
链路（Traces）
- Jaeger / Tempo
- 回答“为什么慢 / 在哪里慢”
📌 这是所有高级运维能力的“数据地基”。
2️⃣ 告警与事件管理工具
告警工具
- Alertmanager / PagerDuty
- 告警规则、收敛、路由
事件工具
- Incident 管理系统
- On-call / 复盘
👉 目标不是“零告警”，而是零惊吓。
3️⃣ 发布与变更工具
- 发布平台
- 蓝绿 / 灰度
- 回滚
📌 70% 故障来自变更，工具必须围绕它。
4️⃣ 配置与 Secrets 工具
- 配置中心
- KMS / Vault
- 动态生效、审计
5️⃣ 自动化与 Runbook 工具
- Ansible / Rundeck
- 自愈流程
- 参数化执行
6️⃣ 容器与基础设施工具
- Kubernetes
- Terraform / IaC
- 节点管理
7️⃣ 服务治理工具
- Dubbo / Spring Cloud
- Service Mesh
- 限流 / 熔断 / 灰度
8️⃣ 安全与合规工具（与运维强相关）
- 堡垒机
- 审计
- 漏洞扫描
四、工具之间的正确“连接方式”
1️⃣ 数据打通 > 工具统一
- CMDB 作为事实源
- Service 作为主键
2️⃣ 事件驱动
- 告警 → 事件
- 事件 → 自动化
- 自动化 → 状态回传
五、常见失败模式（非常真实）
- 工具太多，没有统一视图
- 各工具模型不一致
- 自动化不敢用
- 运维“人肉 Glue”
六、正确的运维工具建设路线
Step 1：统一对象模型
- Service
- Instance
- Change
- Incident
Step 2：统一入口
- 运维控制台
- API Gateway
Step 3：自动化优先
- 人只做兜底
七、成熟度演进
L1：工具堆砌
- 各自为战
L2：工具集成
- 数据打通
L3：平台化
- 能力抽象
L4：SRE 化
- SLO 驱动
L5：智能化
- 预测、自愈
八、一句话总结
真正成熟的运维工具集，不是“你用了哪些工具”，而是：当系统出问题时，你能否在最短路径内完成“感知 → 决策 → 行动”。
