Arch Day 20: 可观测性工程(高级)

日期: 2026-04-19 (Day 20) 阶段: 第一阶段 - 架构基础 标签: #可观测性 #SLO #SLI #ErrorBudget #OpenTelemetry #AIOps #告警设计

---

核心概念

一句话定义

可观测性工程(Observability Engineering)是通过度量(Metrics)、日志(Logs)、追踪(Traces)三大支柱以及SLO/SLI/Error Budget体系，将系统内部状态外部化的工程实践，其终极目标不是"收集更多数据"，而是"更快地发现和解决问题"。

为什么资深架构师仍需关注

可观测性不只是运维团队的事。在微服务架构中，一个用户请求可能经过20个服务，任何一个环节出问题都会影响用户体验。我的经验总结：

1. MTTR > MTBF：现代系统不可能不出故障，关键是能多快恢复。可观测性直接决定MTTR(平均恢复时间)。
2. 告警疲劳是真正的风险：见过太多团队配了500条告警规则，结果团队对告警完全脱敏(wolf-crying effect)。好的告警设计比多告警重要100倍。
3. 业务指标才是王道：CPU使用率80%不一定是问题，但交易成功率从99.9%降到99%一定是大问题。可观测性必须把技术指标和业务指标关联起来。
4. SLO是架构决策的依据：选择什么可用性方案、花多少钱在冗余上，都应该由SLO驱动，而不是"凭感觉"。

常见误区与反模式

---

知识点详解

知识点一：SLO/SLI/Error Budget体系

这是Google SRE提出的可靠性工程框架，也是可观测性工程的基石。

概念关系：

SLI (Service Level Indicator)
  │  "我们如何度量服务质量？"
  │  例: 成功请求比例、P99延迟
  │
  ▼
SLO (Service Level Objective)
  │  "我们的质量目标是什么？"
  │  例: 成功率 ≥ 99.95%，P99 ≤ 500ms
  │
  ▼
Error Budget (错误预算)
  │  "我们还能容忍多少错误？"
  │  例: 30天内允许21.6分钟的不可用
  │
  ▼
SLA (Service Level Agreement)
  │  "对外承诺是什么？违反有什么后果？"
  │  例: 99.9%可用性，违反赔偿10%月费
  │
  关系: SLO比SLA更严格(内部标准高于外部承诺)

SLI定义最佳实践：

SLI选择的黄金法则：

好的SLI:
✓ 直接反映用户体验
✓ 可以精确度量
✓ 团队可以采取行动改善
✓ 数量不超过3-5个(每个服务)

坏的SLI:
✗ CPU利用率(用户不关心你的CPU)
✗ 平均响应时间(掩盖了长尾延迟)
✗ 错误日志数量(不等于用户影响)
✗ 代码覆盖率(和运行时质量无关)

知识点二：Error Budget机制

Error Budget是SLO的"可花费"部分，它改变了开发和运维之间的对话方式。

Error Budget计算:

SLO = 99.95% 可用性
→ Error Budget = 100% - 99.95% = 0.05%
→ 30天内允许的不可用时间 = 30×24×60×0.05% = 21.6 分钟

Error Budget消耗追踪:
┌─────────────────────────────────────────────┐
│  30天Error Budget: 21.6分钟                   │
│                                              │
│  Day 1-10: 消耗2分钟(一次小故障)              │
│  ████░░░░░░░░░░░░░░░░ 剩余19.6分钟(91%)     │
│                                              │
│  Day 11: 消耗8分钟(一次部署回滚)              │
│  ████████████░░░░░░░░ 剩余11.6分钟(54%)     │
│                                              │
│  Day 15: 消耗10分钟(数据库故障)               │
│  ██████████████████░░ 剩余1.6分钟(7%)  ⚠️   │
│                                              │
│  → 触发: 冻结非关键变更，集中修复可靠性问题    │
└─────────────────────────────────────────────┘

Error Budget驱动的决策矩阵：

Error Budget的组织价值：

传统对话:
  开发: "我要上新功能！"
  运维: "别上了，系统不稳定！"
  → 政治博弈，谁voice大谁赢

Error Budget对话:
  "这个月的Error Budget还剩60%，可以上新功能。"
  "Error Budget只剩5%了，暂停新功能，先修可靠性。"
  → 数据驱动决策，不需要争论

知识点三：SLO驱动的告警设计

传统告警(阈值触发)的最大问题是告警疲劳。SLO驱动的告警关注的是"Error Budget的消耗速率"，而不是单个指标的瞬时值。

传统告警 vs SLO告警：

传统告警:
if (error_rate > 1%) { alert! }
问题:
  - 短暂毛刺也告警(5秒的1.5%错误率)
  - 但其实对SLO影响微乎其微
  - 结果: 一天收到50条告警，团队脱敏

SLO告警(基于Burn Rate):
if (error_budget_burn_rate > 14.4×) { P1 alert! }
if (error_budget_burn_rate > 6×) { P2 alert! }
if (error_budget_burn_rate > 3×) { P3 ticket }
含义:
  - 14.4×: 按这个速率，2天内Error Budget耗尽
  - 6×:    按这个速率，5天内Error Budget耗尽
  - 3×:    按这个速率，10天内Error Budget耗尽

多窗口多燃烧率告警(Google推荐方案)：

告警规则设计:

Page (P1/P2, 需要立即响应):
┌────────────────────────────────────────────┐
│ 条件: 短窗口Burn Rate高 AND 长窗口Burn Rate高│
│                                            │
│ 规则1 (P1):                                │
│   1小时Burn Rate > 14.4× AND              │
│   5分钟Burn Rate > 14.4×                   │
│   → 立即page oncall                        │
│                                            │
│ 规则2 (P2):                                │
│   6小时Burn Rate > 6× AND                 │
│   30分钟Burn Rate > 6×                     │
│   → 30分钟内响应                            │
└────────────────────────────────────────────┘

Ticket (P3/P4, 工作时间处理):
┌────────────────────────────────────────────┐
│ 规则3 (P3):                                │
│   3天Burn Rate > 3× AND                   │
│   6小时Burn Rate > 3×                      │
│   → 创建ticket，当天处理                    │
│                                            │
│ 规则4 (P4):                                │
│   7天Burn Rate > 1× AND                   │
│   1天Burn Rate > 1×                        │
│   → 创建ticket，本周处理                    │
└────────────────────────────────────────────┘

为什么用两个窗口？
- 短窗口: 确认当前正在发生问题(避免误报)
- 长窗口: 确认问题持续且有影响(避免对短暂毛刺过度反应)

知识点四：分布式追踪(OpenTelemetry)

OpenTelemetry(简称OTel)是CNCF的可观测性标准项目，统一了Metrics、Logs、Traces的采集和传输。

OpenTelemetry架构:

应用层(自动/手动注入)
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│  Service A   │ │  Service B   │ │  Service C   │
│  ┌────────┐ │ │  ┌────────┐ │ │  ┌────────┐ │
│  │OTel SDK│ │ │  │OTel SDK│ │ │  │OTel SDK│ │
│  └────┬───┘ │ │  └────┬───┘ │ │  └────┬───┘ │
└──────┼──────┘ └──────┼──────┘ └──────┼──────┘
       │               │               │
       └───────────────┼───────────────┘
                       │
              ┌────────┴────────┐
              │ OTel Collector   │
              │ (收集+处理+导出)  │
              └───┬────┬────┬───┘
                  │    │    │
           ┌──────┘    │    └──────┐
           ▼           ▼           ▼
    ┌──────────┐ ┌──────────┐ ┌──────────┐
    │Prometheus│ │  Jaeger   │ │  Loki    │
    │(Metrics) │ │(Traces)  │ │(Logs)    │
    └──────────┘ └──────────┘ └──────────┘
           │           │           │
           └───────────┼───────────┘
                       ▼
              ┌────────────────┐
              │   Grafana       │
              │ (统一可视化)     │
              └────────────────┘

分布式追踪的核心概念：

一个请求的Trace:

Trace ID: abc123
├── Span: API Gateway (12ms)
│   ├── Span: Auth Service (3ms)
│   └── Span: Payment Service (45ms)
│       ├── Span: Risk Check (8ms)
│       ├── Span: DB Query (5ms)
│       └── Span: External Payment API (30ms)  ← 瓶颈!
└── Total: 60ms

从Trace中可以看到:
1. 哪个服务是瓶颈 (External Payment API: 30ms/60ms = 50%)
2. 调用链路是否合理 (是否有不必要的串行调用)
3. 哪些调用可以并行化
4. 是否有N+1查询问题

OTel在金融系统中的最佳实践：

知识点五：业务指标 vs 技术指标关联

指标层次金字塔:

         ┌─────────────┐
         │ 业务KPI      │  收入/转化率/客户满意度
         │(Board关心)   │
         └──────┬──────┘
                │ 影响
         ┌──────┴──────┐
         │ 产品指标     │  交易成功率/首屏时间/注册转化
         │(PM关心)     │
         └──────┬──────┘
                │ 影响
         ┌──────┴──────┐
         │ SLI/SLO     │  可用性/延迟/正确性
         │(SRE关心)    │
         └──────┬──────┘
                │ 驱动
         ┌──────┴──────┐
         │ 技术指标     │  CPU/内存/队列深度/连接数
         │(开发关心)   │
         └─────────────┘

关键: 建立从底向上的因果链
例:
  数据库连接池满(技术)
  → API P99延迟从200ms飙升到5s(SLI)
  → 交易超时失败率升高(产品)
  → 当日交易额下降15%(业务KPI)

金融系统核心指标体系：

知识点六：AIOps初探

AIOps将AI/ML技术应用于IT运维，提升异常检测、根因分析和智能告警的能力。

AIOps能力层次:

Level 1: 异常检测(Anomaly Detection)
  传统: 固定阈值(CPU>80%)
  AIOps: 动态基线(周末的CPU正常就是低，不该按工作日标准告警)
  价值: 减少50%+误报

Level 2: 事件关联(Event Correlation)
  传统: 10个告警各自独立
  AIOps: 识别出这10个告警其实是同一根因导致
  价值: 减少告警风暴

Level 3: 根因分析(Root Cause Analysis)
  传统: 人工排查，从告警→日志→trace，逐步定位
  AIOps: 自动分析时间序列关联，推断最可能的根因
  价值: 缩短MTTR

Level 4: 预测性运维(Predictive)
  传统: 等问题发生再响应
  AIOps: 预测未来可能发生的问题(如磁盘将在3天后满)
  价值: 预防故障

Level 5: 自愈(Self-Healing)
  传统: 人工处理
  AIOps: 自动执行修复(如自动扩容/自动重启)
  价值: 无需人工干预(部分场景)

AIOps实际应用场景：

# 概念：AIOps异常检测
class TimeSeriesAnomalyDetector:
    """
    传统: 延迟>500ms就告警
    问题: 促销期间延迟本来就高，会误报

    AIOps: 学习历史模式(周期性/趋势)，检测偏离
    例: 每周三下午延迟通常会升高(批处理窗口)
        → 周三下午延迟升高不告警
        → 周一早上延迟升高就告警(异常)
    """

    def detect(self, metric_name, current_value, timestamp):
        # 1. 获取该时间点的历史基线
        baseline = self.get_seasonal_baseline(metric_name, timestamp)

        # 2. 计算偏离度
        deviation = abs(current_value - baseline) / baseline

        # 3. 考虑季节性和趋势
        # AI模型会学习：周末、月末、节假日、促销期等模式
        if deviation > self.dynamic_threshold(timestamp):
            return Anomaly(metric_name, current_value, baseline, deviation)

---

对比分析

可观测性工具对比

金融系统推荐方案：

自建方案(合规优先):
  Metrics: Prometheus + Thanos(长期存储)
  Traces: Jaeger(OTel后端)
  Logs: Loki + Grafana
  采集: OpenTelemetry Collector

理由:
1. 数据不出境(合规)
2. 成本可控(大规模)
3. 生态成熟(CNCF)
4. 统一Grafana看板

SLO vs SLA vs KPI对比

---

架构设计实操

实操目标

为"交易系统"设计完整的SLO体系，包括SLI定义→SLO目标→Error Budget→告警策略→升级路径。

Step 1: SLI定义

# 交易系统SLI定义

sli_availability:
  name: "交易API可用性"
  definition: "返回非5xx状态码的请求比例"
  measurement: |
    sum(rate(http_requests_total{status!~"5.."}[5m]))
    /
    sum(rate(http_requests_total[5m]))
  excludes:
    - 健康检查端点
    - 内部管理接口
    - 客户端错误(4xx不算服务器问题)

sli_latency:
  name: "交易API延迟"
  definition: "请求在500ms内完成的比例"
  measurement: |
    sum(rate(http_request_duration_seconds_bucket{le="0.5"}[5m]))
    /
    sum(rate(http_request_duration_seconds_count[5m]))
  tiers:
    - fast: ≤200ms (目标80%请求)
    - acceptable: ≤500ms (目标99%请求)
    - slow: ≤2s (目标99.9%请求)

sli_correctness:
  name: "交易处理正确性"
  definition: "交易结果正确的比例(金额/状态/通知一致)"
  measurement: "对账系统检测到的不一致交易 / 总交易数"

Step 2: SLO目标

# 交易系统SLO

slo_availability:
  target: 99.95%
  window: 30天滚动
  error_budget: 21.6分钟/30天
  justification: |
    99.99%需要多活架构(成本增加3x)
    99.9%对金融交易用户体验影响过大
    99.95%是成本和体验的最优平衡

slo_latency:
  target: 99%请求在500ms内完成
  window: 30天滚动
  error_budget: 1%的请求可以慢于500ms
  justification: |
    支付场景用户对延迟敏感
    外部依赖(银行核心)响应时间波动
    500ms是用户可接受的上限

slo_correctness:
  target: 99.999%
  window: 30天滚动
  error_budget: 0.001%(每百万笔交易最多10笔不一致)
  justification: |
    金融交易的正确性是底线
    任何不一致都需要人工对账处理

Step 3: Error Budget与告警

# 告警策略(基于Burn Rate)

alerts:
  - name: "交易可用性-严重(P1)"
    condition: |
      burn_rate_1h > 14.4 AND burn_rate_5m > 14.4
    meaning: "按此速率，2天内Error Budget耗尽"
    action: "立即page oncall"
    response_time: "5分钟"
    escalation: "15分钟无响应→升级到Tech Lead"

  - name: "交易可用性-紧急(P2)"
    condition: |
      burn_rate_6h > 6 AND burn_rate_30m > 6
    meaning: "按此速率，5天内Error Budget耗尽"
    action: "30分钟内响应"
    response_time: "30分钟"
    escalation: "1小时无响应→升级到Tech Lead"

  - name: "交易可用性-警告(P3)"
    condition: |
      burn_rate_3d > 3 AND burn_rate_6h > 3
    meaning: "按此速率，10天内Error Budget耗尽"
    action: "当天工作时间处理"
    response_time: "4小时"

  - name: "交易可用性-信息(P4)"
    condition: |
      burn_rate_7d > 1 AND burn_rate_1d > 1
    meaning: "Error Budget在缓慢消耗"
    action: "创建ticket，本周处理"
    response_time: "3个工作日"

Step 4: 升级路径

升级矩阵:

P1 (5分钟响应):
  ├── 0-5min:  Oncall工程师
  ├── 5-15min: 如无响应 → 备选Oncall
  ├── 15-30min: Tech Lead + SRE Manager
  ├── 30-60min: VP Engineering
  └── 60min+:  CTO (金融系统有监管通报义务)

P2 (30分钟响应):
  ├── 0-30min: Oncall工程师
  ├── 30-60min: Tech Lead
  └── 60min+:  SRE Manager

P3 (4小时响应):
  └── 分配给当值工程师，当天处理

P4 (3工作日):
  └── 分配给团队backlog，Sprint中处理

Step 5: Grafana Dashboard设计

Dashboard布局:

┌─────────────────────────────────────────────────┐
│ 顶部: Error Budget状态(大号字体)                   │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐    │
│ │可用性   │ │延迟    │ │正确性   │ │Error   │    │
│ │99.97%  │ │P99:   │ │99.999% │ │Budget  │    │
│ │🟢 OK   │ │320ms  │ │🟢 OK   │ │62%剩余 │    │
│ └────────┘ └────────┘ └────────┘ └────────┘    │
├─────────────────────────────────────────────────┤
│ 中部: SLI趋势图(时间序列)                         │
│ ┌──────────────────────┐ ┌──────────────────┐   │
│ │ 可用性(30天)          │ │ P99延迟(30天)     │   │
│ │ ─── SLO线(99.95%)    │ │ ─── SLO线(500ms) │   │
│ │ ~~~ 实际值            │ │ ~~~ 实际值        │   │
│ └──────────────────────┘ └──────────────────┘   │
├─────────────────────────────────────────────────┤
│ 下部: Error Budget消耗(30天累计)                   │
│ ┌─────────────────────────────────────────┐     │
│ │ ████████████████░░░░░░░░░░ 62%剩余       │     │
│ │ ↑Day3故障  ↑Day12部署问题                  │     │
│ └─────────────────────────────────────────┘     │
├─────────────────────────────────────────────────┤
│ 底部: 业务关联指标                                 │
│ ┌──────────────────────┐ ┌──────────────────┐   │
│ │ 交易成功率(业务)       │ │ 交易量/分钟      │   │
│ └──────────────────────┘ └──────────────────┘   │
└─────────────────────────────────────────────────┘

---

AI增强实践

AI辅助根因分析

# 概念：AI驱动的根因分析
class AIRootCauseAnalyzer:
    """
    传统根因分析: 人工查看dashboard→翻日志→看trace→猜原因 (30-60min)
    AI根因分析: 自动关联异常指标→匹配历史模式→给出可能原因 (3-5min)
    """

    def analyze(self, alert):
        """
        输入: P1告警(交易可用性下降)

        AI分析过程:
        1. 收集告警时间点前后的所有指标变化
        2. 识别异常指标(哪些指标同时偏离基线)
        3. 基于因果图推断根因
        4. 匹配历史相似事件

        输出:
        - 最可能根因: 数据库连接池耗尽(置信度85%)
        - 证据:
          - DB connection_active 在告警前2分钟飙升到最大值
          - 对应服务的等待队列深度同步增加
          - 3周前有相似模式(当时是慢查询导致)
        - 建议操作:
          - 检查最近5分钟的慢查询
          - 临时增加连接池大小
          - 检查是否有新部署
        """
        pass

AI辅助SLO优化

Prompt模板:

你是一位SRE专家。请帮我优化以下SLO体系:

当前SLO:
[列出当前SLI/SLO定义]

过去90天数据:
- 实际可用性: [数据]
- 实际P99延迟: [数据]
- Error Budget消耗模式: [描述]
- 重大故障: [描述]

请分析:
1. 当前SLO目标是否合理？(太松还是太紧？)
2. 告警规则是否需要调整？(误报率/漏报率)
3. Error Budget策略是否有效？
4. 是否需要增加新的SLI维度？

---

与Web3/DeFi的关联

DeFi协议的可观测性挑战

传统微服务可观测性:            DeFi协议可观测性:
┌─────────────────┐          ┌─────────────────┐
│ 自有服务器/容器   │          │ 区块链节点       │
│ 可以部署Agent    │          │ 无法部署Agent    │
│ 全量日志可获取   │          │ 只有链上事件      │
│ Metrics可采集   │          │ 需要Indexer      │
│ Traces可追踪    │          │ 交易哈希=Trace   │
└─────────────────┘          └─────────────────┘

DeFi需要监控的指标:
1. TVL变化(大额提款=危险信号)
2. 异常交易模式(闪电贷/三明治攻击)
3. 预言机价格偏离(Chainlink延迟)
4. Gas费飙升(可能有MEV攻击)
5. 合约调用失败率
6. 治理提案投票(可能影响协议参数)

DeFi "SLO"概念：

---

今日思考

问题一：Error Budget为零的情况

在金融系统中，某些SLO(如交易正确性)的Error Budget几乎为零——不允许有一笔错误交易。这种情况下Error Budget机制还有意义吗？如何处理"Error Budget为零"的SLO？

问题二：可观测性的成本控制

随着微服务数量增长，可观测性数据的存储和处理成本可能占到总基础设施成本的10-20%。如何在"看到更多"和"花费更少"之间找到平衡？采样策略如何设计？

问题三：AIOps的成熟度

AIOps概念已经提了好多年，但实际落地效果参差不齐。在你看来，AIOps目前最有价值的应用场景是什么？什么场景下"简单规则"仍然优于"复杂AI"？

---

面试题准备

面试题1: SLO和SLA有什么区别？

30秒回答：

SLO是团队自己设定的内部质量目标，SLA是对外客户的合同承诺。SLO通常比SLA更严格——比如SLO设99.95%，SLA对外承诺99.9%。SLO的核心工具是Error Budget，它把"什么时候优先做可靠性vs新功能"变成了数据驱动的决策。

2分钟回答：

SLO和SLA是两个层次的东西。

SLA(Service Level Agreement)是商务合同，对外承诺的服务水平。违反SLA通常有财务后果(赔偿/减免)。SLA的制定需要商务、法务和技术共同参与。

SLO(Service Level Objective)是工程团队自己的内部目标，通常比SLA严格。比如SLA承诺99.9%可用性(年停机8.76小时)，SLO设为99.95%(年停机4.38小时)。这样即使SLO偶尔没达到，SLA仍然是安全的。

SLO的真正价值在于Error Budget机制。假设SLO是99.95%，那么每个月有0.05%的"Error Budget"可以花。当Error Budget充裕时，团队可以快速发布新功能(承担一些风险)；当Error Budget紧张时，冻结变更、优先修复可靠性。这解决了开发和运维之间的永恒矛盾——不再是"我说不稳定"vs"你不让发版"，而是看Error Budget数据说话。

在金融系统中，我的经验是SLO设比SLA严格10倍左右。比如SLA承诺3个9，SLO设4个9。这给了团队足够的缓冲区间，避免在SLA边缘反复拉锯。

追问准备：

• Q: Error Budget耗尽了怎么办？ A: 冻结所有非紧急变更，全团队focus在可靠性改进上。直到Error Budget回到安全水平(通常看一个新的滚动窗口)。这是一个正式的团队协议，不是可选的。

面试题2: 如何设计不扰人的告警系统？

30秒回答：

两个核心原则：第一，用SLO驱动告警而非阈值告警——关注Error Budget的消耗速率而非瞬时值；第二，告警分级——真正需要马上处理的P1/P2才page人，P3/P4创建ticket工作时间处理。我追求的标准是：每条告警都是"可行动的"(actionable)。

2分钟回答：

（展开多窗口多燃烧率告警方案，结合具体案例说明如何减少误报。）

---

学习资源

---

明日预告

Day 21: ATAM架构评审实战 —— Week 3收官。我们将把这一周学到的所有内容(质量属性/ADR/集成/数据/安全/可观测性)串联起来，通过ATAM(Architecture Tradeoff Analysis Method)对一个完整架构方案做评审。学习如何准备和主持架构评审、如何识别敏感点/权衡点/风险点，以及架构评审中的"政治学"。