可靠性目标

按服务层设可靠性目标使投资匹配服务对业务的关键性。

为什么

非每服务配 99.99% 可靠性 — 那比 99.9% 贵 10 倍且浪费在内部管理工具。同待每服务要么过度投资不重要服务（浪费工程时间）要么投资不足关键服务（宕机损收入）。分层模型（Tier 1 = 收入关键 = 99.95%、Tier 2 = 面向用户 = 99.9%、Tier 3 = 内部 = 99.5%）让你把可靠性努力花在重要处并按层设 SLO、告警、值班。这是成熟组织扩展可靠性的方式：非把一切做 100%，而是把可靠性投资匹配每服务业务影响。

何时使用

当有 3+ 不同关键性服务时。服务业务角色变时 revisit（如内部工具变面向用户）。

如何做

1. 定义 3-4 服务层
   - Tier 1（关键）：收入直接或认证 — 宕机 = 立即收入损
   - Tier 2（重要）：面向用户功能 — 宕机 = 退化 UX、无立即收入损
   - Tier 3（内部）：管理工具、仪表盘 — 宕机 = 开发者摩擦、无用户影响
   - Tier 4（实验）：非生产、沙箱 — 尽力

2. 每层配可靠性目标
   - Tier 1：99.95%（22m 宕机/28d）、24/7 值班、SEV1 paging
   - Tier 2：99.9%（43m/28d）、工作时间值班、SEV2 paging
   - Tier 3：99.5%（3.4h/28d）、下一工作日修、仅工单
   - Tier 4：尽力、无 SLO、无值班

3. 每服务打层标签
   - 层驱动：SLO、告警敏感度、值班覆盖、复盘要求
   - 存服务目录（如 Backstage）使可发现

4. 投资匹配层
   - Tier 1：冗余、多区域、金丝雀、全 APM、每告警 runbook
   - Tier 2：单区域 + 金丝雀、APM、每告警 runbook
   - Tier 3：单区域、基础监控、每告警 runbook
   - 别镀金 Tier 3；别欠建 Tier 1

5. 年度审查层分配
   - Tier 3 现被客户用 → 升 Tier 2
   - Tier 1 已弃用 → 降 Tier 3

示例

# service-catalog.yaml — 层分配驱动可靠性投资
services:
  - name: checkout-api
    tier: 1
    slo: 0.9995
    oncall: 24/7
    regions: [us-east, us-west, eu]  # Tier 1 多区域
    alerts: [SEV1 page, SEV2 page]
  - name: search-api
    tier: 2
    slo: 0.999
    oncall: business-hours
    regions: [us-east]
    alerts: [SEV2 page, SEV3 ticket]
  - name: admin-dashboard
    tier: 3
    slo: 0.995
    oncall: none
    regions: [us-east]
    alerts: [SEV3 ticket]

# 每层投资（工程小时/季）：
#   Tier 1：200h（冗余、金丝雀、runbook、多区域故障转移演练）
#   Tier 2：80h（金丝雀、runbook）
#   Tier 3：20h（基础监控、runbook）
# 这把花费匹配业务影响而非镀金一切。

常见问题

⚠每服务 Tier 1 — 一切关键则无关键，可靠性努力摊太薄无法真保收入关键服务。
⚠层分配一次不 revisit — 变面向客户的内部工具留 Tier 3 造无值班用户宕机。
⚠层驱动 SLO 但不驱动投资 — Tier 1 有 99.95% 目标但无多区域或金丝雀，目标是愿望非可达。
⚠无服务目录 — 层在某人脑里，新服务不打标继承默认（通常过或欠建）。

最佳实践

✓定义 3-4 层带显式可靠性目标、值班覆盖和投资级 — 花费匹配业务影响非统一 100%。
✓层分配存服务目录（Backstage/内部）使每服务打标且新服务继承正确默认。
✓使层驱动投资非仅 SLO — Tier 1 得多区域、金丝雀、故障转移演练；Tier 3 得单区域和基础监控。
✓年度审查层分配；升变面向用户的服务降弃用的使模型保持准确。