SRE 从零到一实施路线图

不是理论推导，是从 “没有监控、没有告警、没有 On-Call” 到 “SLO 驱动发版、故障 5 分钟定位” 的完整操作清单。每一步都带验收标准。

整体节奏

gantt
    title SRE 从零到一实施时间线
    dateFormat  YYYY-MM-DD
    section Phase 0 基础设施
    部署 Prometheus + Grafana       :p0a, 2026-08-01, 7d
    日志管道 (Loki+Promtail)        :p0b, after p0a, 7d
    基础 Dashboard + 告警规则       :p0c, after p0a, 7d
    section Phase 1 SLI/SLO
    定义核心 SLI                    :p1a, after p0c, 7d
    设定 SLO + Error Budget         :p1b, after p1a, 5d
    Burn Rate 告警上线             :p1c, after p1b, 3d
    section Phase 2 事件管理
    制定 On-Call 轮值               :p2a, after p1c, 7d
    故障响应流程 + 升级策略         :p2b, after p2a, 5d
    Postmortem 模板 + 第一次演练    :p2c, after p2b, 5d
    section Phase 3 自动化
    识别 Top 5 Toil                 :p3a, after p2c, 5d
    自愈 Runbook 1.0               :p3b, after p3a, 14d
    Canary 发布 + 自动回滚          :p3c, after p3b, 14d
    section Phase 4 混沌工程
    故障注入实验                    :p4a, after p3c, 14d
    全链路压测                      :p4b, after p4a, 14d

Phase 0 — 基础设施 & 监控上线

目标

生产环境有基本监控覆盖，团队能在 Grafana 上看到所有服务的健康状态。

具体步骤

部署 Kube-Prometheus-Stack

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm upgrade --install kps prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --values kps-values.yaml

接入 Loki 日志聚合

helm repo add grafana https://grafana.github.io/helm-charts
helm upgrade --install loki grafana/loki-stack \
  --namespace monitoring \
  --set promtail.enabled=true \
  --set loki.persistence.enabled=true \
  --set loki.persistence.size=100Gi

配置服务暴露 Metrics 端点

每个 Go 服务加 /metrics 端点（参见可观测性六维信号深度实战 1.1 节）
创建 ServiceMonitor 让 Prometheus 自动发现

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: care-mate-api
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: care-mate-api
  endpoints:
    - port: metrics
      interval: 30s
      path: /metrics

创建基础 Dashboard

Dashboard	内容	受众
Home	全集群概览：节点数、Pod 数、总体 CPU/Mem	全员
Service Overview	每个服务的 RED 指标	开发 + SRE
K8s Cluster	Node/Pod/Deployment 状态	SRE
Ingress	入口流量、4xx/5xx、延迟	SRE + 网络
Database	DB 连接数、慢查询、复制延迟	DBA + SRE

基础告警规则

# 就这些就够了，先别贪多
- Pod 处于 CrashLoopBackoff 超过 5 分钟      → critical
- Node 不可用超过 5 分钟                       → critical
- Pod 内存 > limit 80% 超过 10 分钟            → warning
- PVC 使用率 > 80%                             → warning
- 证书 30 天内过期                              → warning

验收标准

Grafana 上能看到每个业务服务的 RED 面板
收到过至少一次真实告警并成功响应
团队每人能独立在 Grafana 上查询指标
日志能从 Loki 搜索，按 pod/service/trace_id 过滤

Phase 1 — SLI / SLO / Error Budget

目标

不再凭感觉判断 “服务稳不稳”，用量化指标驱动发版决策。

具体步骤

画用户旅程图

带上产品经理和开发，白板上画出 3-5 条关键用户旅程。模板见 SRE-SLI-SLO-ErrorBudget实战手册。

定义 SLI → 写 PromQL → 建 Recording Rules

先从一条 SLI 开始，别贪多。

Week 1: 为 care-mate-api 定义 availability SLI
Week 2: 加上 latency_p99 SLI
Week 3: Review 数据，调整 SLO 值
Week 4: 为第二个服务重复

建 Error Budget Dashboard

让全团队（不只是 SRE）能看到 “我们还剩多少 Error Budget”。

烧钱率告警上线

把 SRE-SLI-SLO-ErrorBudget实战手册的规则部署到 Prometheus。

制定 Error Budget Policy

团队坐下来签一份 “Error Budget 公约”（模板同上 5.2 节），明确：什么时候冻结发布？谁能特批？

验收标准

每个核心服务有 3-5 个 SLI
Grafana 上有 Error Budget 面板，全团队可见
Error Budget Burn Rate 告警已上线且触发过至少一次
有过一次因 Error Budget 不足而推迟发布的案例

Phase 2 — 事件管理 & On-Call

目标

故障发生时，团队知道谁该响应、怎么响应、事后怎么复盘。

具体步骤

制定 On-Call 轮值表

# 双人轮值，主 + 备
rotation:
  primary:  每周轮换，周五 18:00 交接
  secondary: 作为备份，primary 15min 不响应时升级到此
  schedule: 7×24（非工作时间为主，工作时间无限制）
  escalation:
    - 15min 无响应 → secondary
    - 30min 无响应 → Engineering Manager
    - 60min 无响应 → CTO

故障响应流程

告警触发
  → On-Call 确认（5min 内 ACK）
  → 初步判断严重等级（P0/P1/P2）
  → P0: 拉 War Room（IM 建群 / 腾讯会议）
    → Incident Commander 指定
    → 每 30min 状态更新到全员
    → 解决后：写 Timeline → 发 Postmortem

Postmortem 模板

## 事件：[简短标题]

| 属性 | 值 |
|------|-----|
| 日期 | 2026-08-04 |
| 严重等级 | P0 / P1 / P2 |
| 持续时间 | 14:30 - 15:12 (42 min) |
| 影响 | 200 用户无法下单 |
| 指挥官 | 小徐 |
| 参与人 | 张三, 李四 |

### 时间线（精确到分钟）
- 14:28 - 部署 v2.3.1 到生产
- 14:30 - Prometheus 告警：订单创建 5xx 率 > 5%
- 14:32 - On-Call 确认告警，拉 War Room
- 14:35 - 定位到数据库连接池配置错误
- 14:45 - 回滚到 v2.3.0
- 14:50 - 错误率归零
- 15:12 - 确认所有服务恢复

### 根因
数据库连接池 `max_connections` 从 200 误改为 20

### 5 Whys
1. 为什么 5xx？→ 数据库连接池耗尽
2. 为什么耗尽？→ max_connections 配置错误
3. 为什么配置错误？→ 代码审查未发现
4. 为什么审查未发现？→ 配置变更未触发差异检查
5. 为什么没有检查？→ CI 流水线缺少配置变更扫描步骤

### Action Items
- [ ] CI 中增加配置变更差异扫描（张三，8/10）
- [ ] 连接池参数加入基础监控（李四，8/08）
- [ ] 发布 checklist 增加 "检查数据库连接池配置" 项（小徐，8/06）

第一次故障演练（Gameday）

挑一个低峰时段，人为注入一个已知故障，全流程跑一遍。不是考谁技术好，是考流程通不通。

验收标准

On-Call 轮值表已公布，每人至少值过一周
发生过一次真实事件，全流程走通（告警 → 响应 → 解决 → Postmortem）
至少完成过一次 Gameday 演练
Postmortem Action Items 100% 落地

Phase 3 — Toil 自动化

目标

减少重复手工操作，把 SRE 的时间从 “救火” 转向 “防火”。

识别 Toil 的方法

Toil 的定义（Google SRE）：和业务增长绑定的、手动的、重复的、可自动化的、没有持久价值的工作。

Toil Audit 模板——每人记录一周：

任务	频率	耗时	是否可自动化	自动化方案
证书续签检查	周	10min	是	cert-manager
工单处理	日	30min	部分	自动分类 + 模板回复
日志捞取	天 3 次	15min	是	Loki + Grafana 自助
发布操作	天 2 次	20min	是	ArgoCD + GitOps

自动化优先级矩阵

高价值 + 低难度 → 先做（证书续签、发布自动化）
高价值 + 高难度 → 排期做（容量自动伸缩、自动回滚）
低价值 + 低难度 → 有空做（工单模板）
低价值 + 高难度 → 别做

Phase 3 具体产出

自愈 Runbook v1.0

# 例：Pod OOM 自动处理
trigger:
  alert: MemoryNearLimit
  condition: "container_memory_working_set > limit * 0.9"
actions:
  - name: "记录事件"
    type: log
    message: "Pod {{ .pod }} memory near limit, triggering auto-scale"
  - name: "扩容"
    type: hpa_scale
    deployment: "{{ .deployment }}"
    replicas: "+2"
  - name: "通知"
    type: im
    channel: "#sre-alerts"
    message: "已自动扩容 {{ .deployment }} 至 {{ .new_replicas }} 副本"

渐进式发布接入

手动发布 → 蓝绿部署 → Canary（金丝雀）
  → 基于 Metrics 的自动晋升/回滚（Argo Rollouts）

示例 Argo Rollouts 配置：
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5      # 5% 流量
        - pause: {duration: 10m}
        - setWeight: 20     # 20% 流量
        - pause: {duration: 30m}
        - setWeight: 100    # 全量
      analysis:
        templates:
          - templateName: error-rate-check  # 错误率 > 阈值自动回滚

证书/密钥自动管理

# cert-manager 接入
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16/cert-manager.yaml
# 创建 ClusterIssuer，所有 Ingress 自动签发 Let's Encrypt

验收标准

Toil Audit 完成，Top 5 已识别
至少 3 项手工操作已自动化
发布从 “下班不能发” 变为 “随时可发”
自愈 Runbook 覆盖至少 2 个常见故障场景

Phase 4 — 混沌工程 & 容量规划

目标

不是等故障发生，而是主动制造故障来验证系统的韧性。同时建立容量模型，提前规划扩容。

混沌工程实验阶梯

Level 1: 杀一个 Pod → 看 HPA 是否自动恢复
Level 2: 网络延迟注入 → 看超时重试是否生效
Level 3: 杀掉一个可用区 → 看多 AZ 切换
Level 4: 全链路压测 → 找到系统瓶颈
Level 5: GameDay（全团队演练）→ 验证流程

实验模板

# Chaos Mesh — 网络延迟注入
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: care-mate-db-latency
spec:
  action: delay
  mode: one
  selector:
    namespaces: [production]
    labelSelectors:
      app: care-mate-api
  delay:
    latency: "200ms"
    jitter: "50ms"
  duration: "5m"
  scheduler:
    cron: "@every 60m"

容量规划

压测基线：每个核心接口的 QPS 上限
容量模型：当前 QPS × 120%（留 20% 余量）= 需要的副本数
扩容决策：HPA 基于 CPU/Mem + KEDA 基于 Prometheus 指标

# KEDA — 基于 QPS 伸缩
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: care-mate-api-scaler
spec:
  scaleTargetRef:
    name: care-mate-api
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitoring:9090
        metricName: http_requests_per_second
        query: sum(rate(http_requests_total{service="care-mate-api"}[2m]))
        threshold: "1000"  # 每副本处理 1000 QPS

验收标准

至少完成过 3 个混沌实验，产出实验报告
每个核心服务有压测基线和容量模型
自动扩容策略已覆盖所有核心服务
团队知道 “单点”在哪里，“爆炸半径”多大

关键里程碑总结

Phase	关键里程碑	建议时间	团队状态
P0	告警能响、Dashboard 有图	2 周	有监控
P1	SLO 驱动发版决策	4 周	有度量
P2	故障有流程、复盘有 Action	6 周	有流程
P3	发布随时可做、故障可自愈	10 周	有自动化
P4	容量可预测、韧性可验证	16 周	有韧性

不要跳过的坑

[!danger] 跳过 Phase 0 直接上 Phase 1 没有基础监控就没有数据，SLI/SLO 全是凭空想象。先跑 2 周数据再定义 SLO。

[!danger] 告警太多太快别名”告警疲劳”。每上线一条告警规则，必须回答：凌晨 3 点收到这条告警，值班人能做什么？回答不出来就不发。

[!danger] 做了 Postmortem 但 Action Items 不落地复盘会开完就完了，Action Items 永远停留在 TODO。建议：每个 Action Item 分配 owner + deadline，下一周 Standup 上 review 进度。

[!danger] “我们不需要混沌工程” 你已经在做混沌工程了——只是故障不是你控制的。主动做比被动做好。

SRE-从零到一实施路线图

SRE 从零到一实施路线图

整体节奏

Phase 0 — 基础设施 & 监控上线

目标

具体步骤

验收标准

Phase 1 — SLI / SLO / Error Budget

目标

具体步骤

验收标准

Phase 2 — 事件管理 & On-Call

目标

具体步骤

验收标准

Phase 3 — Toil 自动化

目标

识别 Toil 的方法

自动化优先级矩阵

Phase 3 具体产出

验收标准

Phase 4 — 混沌工程 & 容量规划

目标

混沌工程实验阶梯

实验模板

容量规划

验收标准

关键里程碑总结

不要跳过的坑

相关笔记