Reprinted from Lao Yang’s WeChat public account.

SRE_Team_Building.md

老杨聊 SRE 团队建设全攻略：从 0 到 1 的组织进化

写在前面：为什么你需要"神器"而非"常用命令"

大家好,老杨是老杨,干货满满的老杨欢迎点击原文链接或直接访问 vps.top365app.com,来看老杨的全球 vps 信息还有各种咱们用得着的信息实时收集分析项目.

正文

一、先定方向：为什么要 SRE

老杨要的证据先给你看。

• 错误预算是硬指标。月度 99.9% 可用性，月可用时间是 30×24×60=43,200 分钟。错误预算是 43.2 分钟。这不是口号。它决定了"还能不能发版"。

• DORA 四项指标很好用。它们是部署频率、变更交付时间、变更失败率、恢复时间。许多团队用它来对齐研发和运维的节奏。

• Google SRE 的建议是把重复劳动（toil）压到 50% 以下。因为人力应该放在工程化，而不是一遍遍点按钮。

老杨的观点很直接。把这三条落到制度里。团队自然会往前走。

二、从一个试点开始

老杨只选一个服务。越聚焦越好。

• 要求接口稳定。用户量不低。

• 有指标基础。比如有 Prometheus 指标。

• 有发布流程。能灰度或回滚。

老杨把试点按以下目标来跑：

• 设 1 个 SLO，只看可用性。

• 设 2 条告警，只报"用户受影响"的事。

• 跑 1 次演练，走完整个事故流程。

三、定 SLI/SLO：说清楚"什么叫好"

这是它的工作原理。用户只在意"能不能用、快不快"。所以老杨用"成功率"和"延迟"来定义 SLI。

例子：API 成功率

• SLI：1 分钟窗口内，HTTP 200 占比。

• SLO：28 天滚动窗口，成功率 ≥ 99.9%。

• 错误预算：28 天内最多失败 0.1% 的请求。

老杨把定义写成配置，团队都能看懂。

# OpenSLO 示例
apiVersion: openslo/v1
kind: SLO
metadata:
  name: api-availability-99-9
spec:
  service: user-api
  indicator:
    metricSource: prometheus
    spec:
      query: |
        sum(rate(http_requests_total{job="user",status=~"2.."}[5m]))
        /
        sum(rate(http_requests_total{job="user"}[5m]))
  timeWindow:
    duration: 28d
    isRolling: true
  target: 99.9

老杨再把告警写出来。只报"长时间跌破 SLO 的趋势"。

# PrometheusRule 示例（简化）
groups:
  - name: slo-burn
    rules:
      - alert: SLOErrorBudgetBurn2h
        expr: |
          (1 - (sum(rate(http_requests_total{job="user",status=~"2.."}[5m])) /
                sum(rate(http_requests_total{job="user"}[5m]))))
          > (1 - 0.999) * 14.4   # 2 小时燃尽阈值
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "SLO 燃尽过快（2h 级别）"
          runbook: "https://wiki/runbooks/user-api"

这样做的好处很直观。告警减少。报警都是"该起床"的事。

四、把值班与事故流程定下来

老杨不先谈工具。先谈角色和节奏。

• **当班官（Incident Commander）**负责定方向。

• **技术执行（Ops/Dev）**负责排查。

• **信息官（Comms）**负责同步状态。

• 10 分钟内定级别。半小时内给状态更新。

老杨用一个简单的分级矩阵。

SEV	描述	示例
SEV1	全站不可用	核心支付 5 分钟失败率 > 50%
SEV2	关键功能降级	下单失败率 10%–50%
SEV3	局部影响	单地域延迟上升

老杨把"谁接电话"和"怎么拉群"写死在工具里。用 Alertmanager 发到飞书/企业微信就够了。

# Alertmanager 飞书 Webhook（示例）
receivers:
  - name: feishu-sre
    webhook_configs:
      - url: https://open.feishu.cn/...
route:
  receiver: feishu-sre
  group_wait: 30s
  group_interval: 2m
  repeat_interval: 1h
routes:
  - match:
      severity: page
    receiver: feishu-sre

老杨给当班一份最小化清单：

1. 5 分钟内接警。

2. 10 分钟内定 SEV。

3. 30 分钟内更新一次状态。

4. 2 小时内给出缓解措施。

5. 24 小时内完成无责复盘。

五、把"部署和回滚"做成习惯

先做 X：把灰度放进流水线。再做 Y：把回滚做成一条命令。

老杨偏爱金丝雀或蓝绿。理由很简单。风险集中。回滚快捷。

# Argo Rollouts 金丝雀（简化）
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: user-api
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100

老杨把回滚变成一个动作。

kubectl rollout undo deploy/user-api

上线前老杨会跑一组发布门禁：

• 错误预算未透支。

• 最近 24 小时 SEV1/2 为 0。

• 关键看板无红线。

羊毛区

今天老杨推荐一个国内可以直用 chatgpt、gemini、claude、grok 等一流大模型的平台,主要是这个平台还有很羊毛可薅,通过老杨的链接注册可以直接获得 10 元的赠送金额,直接注册没有哦所有模型均可使用哦!记住所有的模型都可以用.废话不说,咱们先看看都有啥!

[Image placeholder]

还等啥呢?快薅起来吧,通过老杨的链接注册才有哦

https://www.shengsuanyun.com/login?code=LPMJ32M0

六、把重复劳动剁碎并自动化

这是它的工作原理。列出所有"手点"的事。给它们记时。超 30 分钟且每周重复的，丢进自动化清单。

老杨常见的自动化清单：

• 一键扩容与回收。

• 证书自动续期。

• 访问日志采集与脱敏。

• 故障注入演练脚本。

• 常见应急脚本（限流、降级、切流）。

目标很朴素。让人去做判断。让机器去反复执行。

七、数据面板：只留三张墙

墙多了没人看。老杨只留三张。

1. SLO 看板：成功率、延迟、错误预算。

2. 发布看板：发布频率、失败率、平均恢复时间。

3. 容量看板：CPU/内存 P95、队列长度、出网带宽。

工具怎么选？老杨会用 Prometheus + Alertmanager + Grafana 做底座。日志用 Loki 或 ELK。中国云也行。阿里云 SLS、ARMS；腾讯云 CLS、TSF；华为云 AOM、APM。关键是指标统一，标签一致，能回放。

八、文化与制度：无责复盘，不等于不复盘

老杨只坚持两条。

• 复盘不找人背锅。直接找系统性改进。

• 行动要落地。每个行动都有截止日期和责任人。

老杨用这个模板。

# Postmortem 模板（摘要）
事件：2025-08-10 19:32 user-api 成功率下降
级别：SEV2
影响：20 分钟内失败率 22%，影响下单
根因：新版本 gRPC 重试与网关限流策略冲突
时间线：19:32 报警 → 19:38 定级 → 19:50 回滚 → 20:05 恢复
做得好的：灰度挡住全量，回滚顺畅
可改进：发布门禁缺少限流策略检查
行动项：
- 增加发布门禁：检查重试与限流配置一致性（负责人 A，8/20）
- 增加 gRPC 客户端限速单元测试（负责人 B，8/22）
- 灰度阶段加入流量压测（负责人 C，8/25）

九、组织形态：嵌入式还是平台组

老杨倾向平台 SRE + 嵌入式协作。

• 平台 SRE 做通用能力：监控、发布、网关、容灾。

• 业务线派出接口人。每周固定碰头 30 分钟。

• 指标和行动在同一份看板上对齐。

老杨给出一个精简的职责表（RACI）。

任务	负责人	参与者	知情者	审批者
SLO 制定	业务 TL	SRE TL	PM、测试	全员
告警规则	SRE	业务	开发	全员
发布策略	开发	SRE	测试	全员
事故响应	值班 SRE	开发	产品	全员
复盘行动	SRE TL	业务 TL	安全、架构	全员

十、落地时间线：90 天就够起一套骨架

老杨按周推进。节奏紧凑，但能落地。

第 1–2 周

• 定试点。建 SLO。接入指标。

• 立告警路线到飞书/企业微信。

• 排出 Top10 重复劳动。

第 3–4 周

• 灰度上线。打通回滚。

• 第一次 SEV 演练。

• 出第一版复盘模板。

第 5–8 周

• 自动化前三项上线。

• 看板三件套稳定运行。

• 值班制度上线。给津贴。给补班规则。

第 9–12 周

• 发布门禁与错误预算联动。

• 二次演练。做跨地域故障。

• 汇报 DORA 四项指标。

• 把试点方法推广到第二条线。

十一、示例清单（可直接用）

1）值班表（示例）

oncall:
  rotation: weekly
  primary:
    - alice
    - bob
    - chen
  secondary:
    - dana
    - eric
  handoff: "Mon 10:00"
  contact:
    pager: "#sre-oncall"
    chat: "#war-room"

2）发布门禁（伪代码）

# 若错误预算<20%，阻断发布
BUDGET=$(curl -s http://slo-exporter/api/budget/user-api | jq '.remaining')
if (( $(echo "$BUDGET < 0.2" | bc -l) )); then
  echo "Error budget too low, block release"
  exit 1
fi

3）容量基线（PromQL）

# P95 延迟（毫秒）
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="user"}[5m])) by (le))

4）日志采集标签规范

service=user-api
env=prod|stag|test
region=cn-beijing|cn-shanghai
version=githash

十二、和中国团队相关的工具选型

• 监控：Prometheus + Grafana；或阿里云 ARMS / 腾讯云观测平台 / 华为云 AOM。

• 日志：Loki / ELK；或阿里云 SLS / 腾讯云 CLS / 华为云 LTS。

• 发布：Argo Rollouts / Argo CD / GitLab CI；或自建 Jenkins。

• 告警：Alertmanager → 飞书 / 企业微信 / 钉钉。

• 排队与网关：Nginx/Envoy；或阿里云 MSE / 腾讯云网关。

• 事故管理：飞书多维表 / 企业微信应用；小团队可用 GitLab Issues 做行动跟踪。

选型只看三件事。可观测性统一。权限可控。回滚简单。

结尾：把规则写成程序，把程序写入日常

老杨信的路径就这么几步。先选一个试点。把 SLO 与错误预算立起来。把值班、告警、发布、复盘连成一条线。再把重复劳动自动化。三个月你会看到报警变少，发布更稳，跨团队的对齐也更顺。

你要是愿意，老杨可以把上面的模板打包成一套仓库。里面有 SLO、告警、值班、复盘、门禁的样例。你拉下来改下服务名就能用。

老杨时间

这里老杨先声明一下,日常生活中大家都叫老杨波哥,跟辈分没关系,主要是岁数大了.就一个代称而已.老杨的 00 后小同事老杨喊都是带哥的.张哥,李哥的.但是这个称呼呀,在线下参加一些活动时.金主爸爸也这么叫就显的不太合适.比如上次某集团策划总监,公司开大会来一句:"今个咱高兴!有请 IT 运维技术圈的波哥讲两句"这个氛围配这个称呼在互联网这行来讲就有...

运维 X 档案系列文章:

从告警到 CTO：一个 P0 故障的 11 小时生死时速

企业级 Kubernetes 集群安全加固全攻略（ 附带一键检查脚本）

看完别走.修行在于点赞、转发、在看.攒今世之功德,修来世之福报

点击阅读原文或打开地址实时收集分析全球 vps 的项目 vps.top365app.com

老杨 AI 的号: 98dev