服务治理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 推荐）：

快速告警（5分钟内发现）：
  IF 错误率 > 14.4 × (1-SLO) 持续 2分钟
  → Page 值班（1小时消耗掉2%预算的速率）

慢速告警（30分钟内发现）：
  IF 错误率 > 6 × (1-SLO) 持续 15分钟
  → Page 值班

趋势告警（6小时内发现）：
  IF 错误率 > 1 × (1-SLO) 持续 1小时
  → Ticket（不紧急但需处理）

四、服务拆分判断框架

什么时候该拆：

什么时候不该拆：

拆分验证 checklist：

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

五、API 演进治理

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

追问方向：

• “SLO 怎么和产品方协商？”→ 先统计现有 SLI 基线，再根据用户体验要求设定；不是越高越好
• “错误预算透支了怎么办？”→ 停发布+事后复盘+改进 SLO 或基础设施
• 拆分后数据怎么迁移？（双写过渡期→切读→切写→清理旧表）
• “跨服务调用超时怎么设？”→ 下游 P99 + buffer；总超时 < 上游超时

易错点：

• ❌ “SLO 越高越好”——99.999% 成本是 99.9% 的 100 倍，要权衡
• ❌ “拆微服务就是好架构”——没有业务驱动的拆分是反模式
• ❌ “错误预算是用来浪费的”——是用来平衡迭代速度和稳定性的工具
• ✅ 核心思路：SLO 驱动告警和发布决策，拆分基于业务边界而非技术偏好