服务治理SLO与拆分复盘#

一、SLI/SLO/SLA 三层体系

核心 SLI 选择：

二、错误预算机制

错误预算 = 1 - SLO

示例：SLO = 99.95% 可用性（月度）
  → 错误预算 = 0.05% = 30天 × 24h × 60min × 0.05% ≈ 21.6 分钟/月

含义：每月允许 21.6 分钟的不可用时间

预算使用规则：
  ├─ 预算充足(>50%) → 正常迭代发布
  ├─ 预算紧张(20-50%) → 减少变更频率、加强灰度
  ├─ 预算耗尽(<20%) → 冻结非关键变更、全力修复稳定性
  └─ 预算透支 → 停止所有非安全发布，复盘根因

三、SLO 驱动的告警设计

多窗口多燃烧率告警（Google SRE Workbook 推荐起步值，按 30 天预算）：
长窗口和短窗口的错误率都超过阈值才触发（短窗口让问题恢复后告警尽快解除）

快速燃烧：
  IF 1小时 与 5分钟 窗口的错误率都 > 14.4 × (1-SLO)
  → Page 值班（相当于 1 小时烧掉 2% 预算）

中速燃烧：
  IF 6小时 与 30分钟 窗口的错误率都 > 6 × (1-SLO)
  → Page 值班（6 小时烧掉 5% 预算）

慢速燃烧：
  IF 3天 与 6小时 窗口的错误率都 > 1 × (1-SLO)
  → Ticket（3 天烧掉 10% 预算，不紧急但需处理）

四、服务拆分判断框架

什么时候该拆：

什么时候不该拆：

拆分验证 checklist：

□ 调用链是否增加（Trace 跨度数）→ 跨度增加 >3 需警惕
□ 故障爆炸半径是否缩小 → 拆后单服务故障不影响其他
□ 延迟是否劣化 → 新增 RPC 调用的 P99 增量
□ 数据一致性方案是否可行 → 分布式事务/最终一致
□ 运维负担是否可接受 → CI/CD/监控/日志 是否就绪

五、API 演进治理

服务治理我用 SLO 作为度量标尺。首先选择关键 SLI，API 服务看 P99 延迟和成功率，然后设定 SLO 比如 P99 小于 200ms、成功率 99.95%。错误预算等于 1 减 SLO，99.95% 对应每月约 21 分钟不可用。预算充足时正常迭代，预算紧张时减少发布频率，预算耗尽就冻结非关键变更。告警也基于 SLO：用多窗口多燃烧率，1 小时窗口配 5 分钟短窗口、燃烧率 14.4 倍就 Page，抓急性故障；3 天窗口配 6 小时短窗口、燃烧率 1 倍开 Ticket，抓缓慢恶化。服务拆分的判断框架是看四个信号：发布耦合、团队冲突、扩缩容差异、故障爆炸半径。但也有不该拆的情况：团队太小、频繁跨服务事务、数据强耦合。拆完后必须验证调用链复杂度和延迟劣化是否可接受。API 演进优先选向后兼容只加字段，必须不兼容时走 URL 版本号加废弃过渡期。

追问方向：

• “SLO 怎么和产品方协商？”→ 先统计现有 SLI 基线，再根据用户体验要求设定；不是越高越好
• “错误预算透支了怎么办？”→ 停发布+事后复盘+改进 SLO 或基础设施
• “拆分后数据怎么迁移？”→ 先建新库并做存量全量同步 + 增量同步（CDC 或双写）；对账校验一致后先切读、观察稳定再切写；旧表保留只读一段时间可回滚，最后下线清理
• “跨服务调用超时怎么设？”→ 下游 P99 + buffer；总超时 < 上游超时

易错点：

• ❌ “SLO 越高越好”——每多一个 9，允许的不可用时间缩到 1/10，冗余、演练和发布限制的成本大幅上升，还会压缩迭代速度，要按用户实际感知权衡
• ❌ “拆微服务就是好架构”——没有业务驱动的拆分是反模式
• ❌ “错误预算是用来浪费的”——是用来平衡迭代速度和稳定性的工具
• ✅ 核心思路：SLO 驱动告警和发布决策，拆分基于业务边界而非技术偏好