微型博客的可观测性与 SRE 实践：SLO、告警、容量与故障演练

监控（Monitoring）：
  预定义指标 + 阈值告警
  回答：系统是否正常？（已知故障模式）

可观测性（Observability）：
  任意维度的高基数数据 + 即席查询
  回答：为什么异常？（未知故障模式）

Metrics（指标）：便宜、聚合、适合告警与趋势
Logs（日志）：详细、离散、适合定位具体请求
Traces（链路）：串联、跨服务、适合定位慢在哪一跳

L1 业务层：发帖成功率、首页可打开率、登录成功率
L2 服务层：各服务 QPS / 错误率 / 延迟（RED 方法）
L3 资源层：CPU / 内存 / 磁盘 / 网络 / 连接池
L4 依赖层：MySQL / Redis / Kafka / 第三方 API

RED 方法（面向服务）：
  Rate    请求速率
  Errors  错误数/率
  Duration 延迟分布

USE 方法（面向资源）：
  Utilization 使用率
  Saturation  饱和度（排队）
  Errors      错误数

SLI（指标）：实际测量值，如「首页请求成功率」
SLO（目标）：期望水平，如「30 天成功率 ≥ 99.9%」
SLA（承诺）：对外合同，通常比 SLO 宽松
错误预算 = 1 - SLO，如 99.9% → 0.1%（30 天约 43 分钟）

可用性 SLI = 成功请求数 / 总请求数
延迟 SLI   = P95 延迟 < 300ms 的请求数 / 总请求数

错误预算消耗率 = 已消耗预算 / 总预算
燃尽率(burn rate) = 当前消耗速率 / 均匀消耗速率

预算充足 → 可以激进发布、做实验
预算耗尽 → 冻结发布，全力稳定性
预算持续充裕 → SLO 过松，应收紧目标

结构化日志（JSON）：
{"ts":"2026-10-02T12:00:00Z","level":"error","svc":"feed",
 "trace_id":"abc123","user_id":"u_1","path":"/api/feed",
 "code":500,"msg":"upstream timeout","latency_ms":1502}

采样策略：
- 头部采样：请求入口按比例采样（简单，但可能漏掉慢请求）
- 尾部采样：先收集全部 span，按「慢/错」条件决定是否保留（推荐）
  保留条件：latency > 500ms OR status >= 500 OR 特殊用户

Trace  → Span（每跳耗时）→ Log（该 span 的日志）→ Metric（该跳指标）

三者的粘合剂是 trace_id / span_id，
查询路径：从告警指标 → 找异常 trace → 看该 trace 的日志

分级：
P0 页面告警（Page）：用户可感知的核心功能不可用 → 立即响应
P1 工单告警（Ticket）：影响部分用户或有损 → 工作时间内处理
P2 记录（Log）：仅记录，不通知 → 复盘时看

- alert: FeedHighErrorRate
  expr: sum(rate(http_requests_total{svc="feed",code=~"5.."}[5m]))
        / sum(rate(http_requests_total{svc="feed"}[5m])) > 0.05
  for: 5m
  labels: { severity: page }
  annotations:
    summary: "首页错误率 > 5%"
    runbook: "https://wiki/runbook/feed-error"

抑制（Inhibit）：数据库故障时，抑制所有「下游超时」告警
聚合（Group）：同一服务的多条告警合并为一条通知
静默（Silence）：计划内维护期间静默对应告警

容量 = f(峰值 QPS, 单请求资源消耗, 冗余系数)
所需实例数 = 峰值 QPS × 单请求成本 / 单实例容量 × 冗余系数
冗余系数：跨可用区 1.5~2.0，单区 1.3

1. 全链路压测：从入口打到数据库，避免「网关能扛、DB 先挂」
2. 流量染色：压测流量打标记，与真实数据隔离
3. 阶梯加压：找到拐点（延迟陡增点）而非「最大 QPS」
4. 容量基线：每次大促前重测，代码变更后容量会漂移

过载保护顺序：
限流（入口）→ 降级（非核心）→ 扩容（加实例）→ 排队（保核心）

混沌实验四要素：
1. 稳态假设：明确「正常」的指标基线
2. 实验变量：注入什么故障（延迟/错误/资源/网络）
3. 爆炸半径：影响范围（单实例/单服务/单可用区）
4. 中止条件：指标恶化到阈值立即回滚

剧本：Redis 主节点故障
1. 稳态：首页 P95 < 200ms，错误率 < 0.1%
2. 注入：kill Redis 主节点
3. 预期：30s 内完成主从切换，期间降级走本地缓存
4. 观察：P95 是否 < 500ms，错误率是否 < 1%
5. 中止：错误率 > 5% 或持续 > 2min → 立即恢复
6. 复盘：切换耗时、降级是否生效、告警是否触发

On-call 要素：
- 轮值表：明确 primary / secondary，避免无人响应
- 升级路径：X 分钟未响应 → 升级到 secondary → 再到负责人
- 交接：班次交接必须同步「未决问题 + 进行中的变更」
- 补偿：值班强度可度量，避免倦怠

1. 确认（Ack）：收到告警立即确认，避免重复通知
2. 止血（Mitigate）：先恢复服务（回滚/降级/扩容），再找根因
3. 沟通：建立事故频道，同步状态给相关方
4. 定位（Diagnose）：用链路 + 日志 + 变更记录定位
5. 恢复（Resolve）：确认指标回到稳态
6. 复盘（Postmortem）：无指责复盘，产出行动项

成本构成：
指标：时间序列数 × 保留时长（高基数最贵）
日志：写入量 × 保留时长（量最大）
链路：span 数 × 保留时长（采样率决定）

保留策略示例：
指标  15s 精度留 15 天，1min 精度留 13 个月
日志  热存 7 天（可查），冷存 90 天（归档），之后删除
链路  100% 错误 + 10% 正常，留 30 天