OpenTelemetry Runbook自愈效果度量 - 第1节
1.1 什么是可观测性
可观测性（Observability）源自控制理论，在 IT 系统中指通过外部输出来推断系统内部状态的能力。与传统监控不同，可观测性强调在未知问题发生时，能够基于已有数据快速定位根因，而不仅仅是对已知指标的告警。
核心公式：可观测性 = 指标（Metrics）+ 日志（Logs）+ 链路追踪（Traces）
三大支柱各自承担不同角色，缺一不可：
| 支柱 | 数据形态 | 典型用途 | 示例工具 |
|---|---|---|---|
| 指标（Metrics） | 时序数值 | CPU 使用率、请求延迟 P99、错误率 | Prometheus、VictoriaMetrics |
| 日志（Logs） | 带时间戳的文本记录 | 错误堆栈、业务操作记录、审计日志 | ELK、Loki |
| 链路追踪（Traces） | 请求跨服务的调用链 | 慢请求根因定位、依赖关系分析 | Jaeger、Zipkin |
实践要点：三大支柱必须关联才能发挥最大价值。例如：通过指标发现延迟升高 → 通过追踪定位到具体服务 → 通过日志查看详细错误信息。OpenTelemetry 正是实现这种关联的标准框架。
1.2 故障自愈的核心理念
故障自愈（Self-Healing）是指系统在检测到异常后，无需人工介入即可自动执行恢复操作的能力。它并非消除故障，而是缩短故障持续时间、降低影响范围。
自愈闭环四阶段
- 检测（Detect）：通过可观测性数据发现异常，如错误率突增、延迟超阈值。
- 诊断（Diagnose）：基于关联数据定位根因，判断是否需要自愈。
- 决策（Decide）：匹配预定义 Runbook 规则，选择恢复动作。
- 执行（Execute）：自动执行修复操作，如重启容器、回滚版本、扩容实例。
关键前提：自愈不是万能药。对于数据损坏、安全入侵等复杂故障，仍需人工介入。自愈的目标是处理 80% 的已知模式故障，释放 SRE 人力处理剩余 20% 的非常规问题。
| 阶段 | 输入 | 输出 | 典型工具 |
|---|---|---|---|
| 检测 | 指标/日志/追踪 | 告警事件 | Prometheus Alertmanager |
| 诊断 | 告警事件 + 上下文 | 根因推断 | OpenTelemetry + 知识库 |
| 决策 | 根因 + Runbook 规则 | 执行计划 | 规则引擎 / 策略表 |
| 执行 | 执行计划 | 恢复操作 + 验证 | Ansible / K8s API / 脚本 |
1.3 OpenTelemetry 与 Runbook 的关系
OpenTelemetry（OTel）是 CNCF 孵化的可观测性标准框架，负责统一采集指标、日志和链路追踪数据。Runbook 是标准化的故障处理手册，定义了针对特定故障的排查步骤和修复操作。两者结合形成“数据驱动自愈”的核心能力。
联动逻辑
- OTel 提供数据基础：通过 SDK 和 Collector 采集标准化可观测数据，输出结构化的告警上下文。
- Runbook 提供动作定义：将专家经验转化为可执行的自动化脚本或 API 调用。
- 联动桥梁：告警事件携带 OTel 上下文 → 匹配 Runbook 规则 → 触发自动化执行。
核心价值：OTel 解决了“数据从哪里来”的问题，Runbook 解决了“数据来了怎么办”的问题。两者结合，才能实现从告警到自愈的完整闭环。
| 维度 | OpenTelemetry | Runbook | 联动效果 |
|---|---|---|---|
| 数据采集 | 统一 SDK + Collector | — | 标准化告警上下文 |
| 故障检测 | 指标/日志/追踪异常 | — | 精准触发告警 |
| 诊断分析 | 关联三大支柱数据 | 提供排查步骤 | 快速根因定位 |
| 修复执行 | — | 自动化脚本/API | 秒级自愈恢复 |
| 持续优化 | 数据反馈 | 规则迭代 | 自愈准确率提升 |
课程实践路径：本课程将带领你从零搭建 OTel 采集管道，编写可执行的 Runbook 脚本，并通过告警事件将两者串联，最终实现“告警触发 → 自动诊断 → 自动修复 → 结果验证”的完整自愈闭环。