值班第一年：最先要学的不是排障，是叫人

值班第一年：最先要学的不是排障，是叫人

凌晨三点被 page 叫醒，你独自排查到六点，服务恢复了。复盘会上没人感谢你，焦点是"谁的锅"，以及一句"为什么拖了三个小时"。

这是很多人值班第一年的标准剧本，病根只有一句：**把升级当失败，把求助当丢脸，于是选择硬扛。**方向从第一天就反了------值班的核心能力不是忍耐，是可升级性：什么时候叫人、叫谁、怎么叫。

一、先算账：少于六个人，撑不起 24/7

一周 168 小时，一名工程师每周可持续投入约 40 小时。24/7 双层值班（primary + secondary）每周要 336 小时容量；按"每人值一周、值完至少隔一周"的健康节奏，最少要 6 人轮 3 组。少于 4 人的"24/7 on-call"必然演变成轮流烧伤。

这笔账的另一半是公平：跨时区团队用 follow-the-sun 各值白天班；没有时区资源却要求"均匀"分夜班，只是换一种方式轮流透支。

人手不足时，正确动作是缩小值班范围：只对 SEV1（用户大面积不可用、SLO 预算快烧）级别的少数告警保持 24/7，其余次日处理。值班范围可以谈判，人的恢复力不能。

项	推荐做法	反例
班次	一周一轮，交接固定在周中低峰（如周三 10:00）	月班恢复力差，日班交接成本高
层级	primary 响应 + secondary 备援 + 值班经理升级出口	单层值班，primary 睡着就没人管
补偿	夜间 page 调休/补贴------组织问题，不是福利问题	拿"责任心"抵睡眠

另一条红线：每班可操作的 page 不超过 2 次（Google 的经验值）。一个班 10 次 page 的团队，三个月内必然出现漏响应------正确响应不是"加强责任心"，是回去删掉不可操作的告警。

告警每次响起的处理都是"忽略它"，它就该被删除或降级成工单------不可操作的 page 训练出"狼来了"免疫，真 SEV1 来时没人当真。告警量决定轮值可持续性，页数是健康指标，不是运气。

二、升级不是认输，是带时限的流程

先有分级，才有升级。用影响定级，不用技术细节定级：SEV1 是用户大面积不可用或 SLO 预算快烧，page 加状态页，首响 5 分钟；SEV2 部分用户受损，page，15 分钟；SEV3 无用户影响的隐患，进工单工作时间处理；SEV4 信息级，进看板周报。

新手最常见的失误是把升级当失败。升级路径应是带时限的阶梯，写进值班手册并做成自动升级（escalation policy），不依赖人的意志：

T+0min   告警 page primary（含 runbook 链接）
T+5min   primary 未 ack → 自动 page secondary
T+15min  未控制（根因未明或影响未止）→ 通知值班经理，拉 SME 进沟通桥
T+30min  SEV1 仍未缓解 → 部门负责人；涉及外部依赖时开供应商工单；状态页首报

Alertmanager 的 repeat_interval 只解决"再喊一遍"，"喊更高层级的人"要靠 escalation policy------两层必须同时配，否则弃疗的 primary 会让告警空响一整晚：

# [master] alertmanager 路由片段：critical 每 5 分钟重发，直到有人处置
route:
  routes:
    - matchers:
        - severity = "critical"
      receiver: oncall-phone
      group_wait: 0s
      repeat_interval: 5m      # 机器侧的升级节拍
      continue: false
    - matchers:
        - severity = "warning"
      receiver: ticket-queue
      group_wait: 5m
      repeat_interval: 12h     # page 与工单分流：warning 不进电话通道

什么时候叫人？七条判据，满足任意一条就走流程：时限到了（15 分钟连根因方向都没有，SEV1 是 5 分钟）；影响在扩大；需要你没有的权限，等授权的时间计入升级；需要外部依赖，先开单再排障；触及知识边界；疲劳（连续处置超 2 小时或凌晨 3 点后）；两难决策（全量回滚、丢缓存，该业务方拍板）。

怎么叫人？话术带上下文，别只喊救命："INC-1024，CoreDNS 解析失败影响全集群，已排查 X/Y 排除，怀疑 ConfigMap 被改，需要你帮忙看 Z，当前影响 30% 请求"------编号让人能查上下文，排除项防止重复劳动，影响面让人能排优先级，收到的人不用反问就能进场。

硬扛是最贵的选项，升级是流程动作，不是能力评价。

三、五顶帽子：指挥、操作、沟通、记录、顾问

SEV1/SEV2 规模的事件里，"所有人都在救火"是最差状态。Google SRE Book 第 6 章的做法是把响应拆成角色：

角色	职责	不做什么
IC 指挥	全局态势、任务指派、升级与对外口径	不敲键盘做操作
OL 操作	执行止血：重启、回滚、切流	不做需要长时间离开键盘的分析
CL 沟通	对内定时播报、状态页、答复高管问询	不掺和排障决策
Scribe 记录	时间线：谁在何时做了什么、观测到什么	不评价对错
SME 顾问	提供领域判断	按需被 IC 拉入，不抢指挥

小团队可以让一人兼任多角色，但同一时刻只能戴一顶帽子。两条铁律：

一，IC 不操作。IC 一敲命令就进入单线程深钻，全局失焦------影响面、升级时限、对外口径从此没人看着。要敲命令，先交出指挥权。

二，指挥通道与操作通道分离。事件频道只放态势与决策，"我去重启了"这种执行细节去操作频道------指挥频道里每条消息才值得所有人读。

认领的第一句话是公开说"我是本次事件的 IC"，避免两个都以为自己在指挥。CEO 追问"什么时候能好"，由 CL 挡掉；复盘吵不清"当时谁做了什么"，多半是没有 Scribe 时间线------记录不是文员活，是事件的黑匣子。

播报节奏也写死：SEV1 对内每 30 分钟一条，对外状态页每 30~60 分钟或状态有实质变化时更新。节奏本身就是对"高管追问"的免疫------下一条什么时候来是确定的，焦虑就不用挤进指挥频道。

四、交接班：四行字，别让下一班从零开始

交接五分钟完成，模板写进共享文档，每次交班追加：

日期/班次：2026-08-20 周三 白班 → 夜班
1. 未关闭事件：#INC-1024 CoreDNS 告警，已缓解待观察，午夜若复发按 runbook rb-06 处理
2. 近 24h 变更：portal v2.3.1 发布（15:20）；monitoring 告警规则变更（16:00）
3. 风险项：node1 磁盘 82%，明日扩容窗口已约
4. 静默中的告警：GrafanaDown 静默至 22:00（维护窗口）

这四行回答四个问题：第 1 行是时间线、当前假设与下一步，"已缓解待观察"没假装它已解决；第 2 行是排障第一线索------业界普遍把过半故障归因于变更，"昨晚发过版"一句话就能把排查范围缩到变更面，直接决定发现速度；第 3、4 行是影响面与地雷图。

反向要求：变更入口必须收拢到能被交接清单自动聚合的地方（CI/CD 记录、变更工单）。散在个人手里的"我顺手改了下"，是交接盲区的最大来源。

交接不带变更清单，等于让下一班从零开始。

五、"我不知道"的工程学价值

事件里最贵的不是不知道，是错误的确定性。一句没有标注的"应该是缓存问题"，能把三个人引去查二十分钟缓存。

事件沟通的硬纪律：只播报事实、时间点与下一步；永远给下一条更新的时间------没消息就是最大的消息；失败比例与持续时长如实写，事中和事后对得上。对外状态页三段式，猜测一律标"疑似"：

[首报] 部分用户无法访问课程页（约 30% 请求失败）。已介入，下一条更新最晚 14:35。
[进展] 根因初步定位为网关配置错误，灰度回滚中。下一条更新最晚 15:00。
[解决] 服务已恢复。故障期间约 12% 请求受影响，持续 40 分钟。复盘 48 小时内发布。

用指标说"我不知道"的价值：错误假设的存活时间------从有人说出"应该是 X"到有人验证出"不是 X"的间隔【从业者判断】。说出"我不知道，需要 SME"那一刻，这个间隔归零；说出一句伪装成事实的猜测，计时开始。

更糟的是假设会接力：你随口一句"应该是缓存"，被转述成"就是缓存"，再变成"已确认是缓存"------三手之后没人记得它只是猜测。承认知识边界，就是升级判据第 5 条。

疲劳判据同理：换人比硬撑快。"我不知道"的最高级形式是"我现在这个状态不适合做判断"。

六、第一年怎么准备：在靶场先淋一遍雨

没值过班的人缺的不是命令知识，是"边看时钟边决策"的肌肉。靶场（kubeadm 集群）演练单人也能做------分时戴帽：前 10 分钟只当 IC 只指派，后 10 分钟换 OL 帽执行。

# [master] 注入：Service 找不到后端（对外表现是访问拒绝/超时）
sudo bash scripts/faults/break-endpoints.sh

# [master] IC 视角：先定影响面（fault-ep 命名空间）
kubectl -n fault-ep get pods -o wide
kubectl -n fault-ep get endpoints
# 预期：Pod 全部 Running/Ready，但 endpoints 为空

# [master] OL 视角：复现用户路径
kubectl -n fault-ep run curl-test --image=curlimages/curl:8.10.1 \
  --restart=Never --rm -it -- curl -sS --max-time 3 \
  http://fault-web-svc.fault-ep.svc.cluster.local/ -o /dev/null -w '%{http_code}\n'
# 预期输出: 000（connection refused）------"服务全绿但用户不可用"

教学点：定级锚点是用户影响和 SLO 燃烧率，不是"进程挂没挂"------Pod 全绿、curl 000，就是 SEV2。修复线索在 kubectl -n fault-ep describe svc fault-web-svc 对比 selector 与 Pod label（完整答案在靶场 FIXES.md）。时间线边做边记：

T0      注入 break-endpoints
T+5m    OL 确认：Pod 2/2 Ready，curl 000，影响面=fault-ep 全部流量 → 定级 SEV2
T+14m   curl 200，持续 2 分钟无复发 → IC 宣告关闭，转复盘

演练完给自己掐表：从注入到确认用户受影响用了几分钟，到修复又用了几分钟------这两个数就是你的发现时长与修复时长，第一次掐表多半会被自己吓到【从业者判断】------真实事件的紧迫感就是从这里长出来的。

第一年的积累就三件事。runbook 沉淀：把每次排障里"下次直接抄"的那步写进去，留给下一个人当杠杆。

跟班观察（shadow 值班）【从业者判断】：正式值班前跟有经验的人值一两轮，看他什么时候开口求助、话术怎么带上下文------升级时机是看会的，不是背会的。复盘参与：复盘要检查"该升未升"，这是升级文化变成制度的关键一环。

七、反方诚实：津贴买不回睡眠

把丑话说完。夜间 page 的调休与补贴是组织问题，不是福利问题------"拿责任心抵睡眠"是最坏的答案。但我再走一步【从业者判断】：津贴买不回睡眠------被切碎的睡眠与第二天的判断力损耗，补贴对价不了。

所以衡量值班制度健不健康，不看津贴数额，看三个数字：每班 page 数（不超 2）、轮换人数（不少于 6）、值班范围（是否只对 SEV1 全天候）。津贴是组织在承认成本，减页才是组织在偿还成本。

边界在哪？如果对页数超标的回答是"加钱"而不是"减页"，这份值班购买的是你的健康，不是响应能力。页数超标就该触发告警治理，删或降级不可操作告警；系统真不稳定，就回到错误预算------烧穿预算冻结发布、还可靠性债。两条路都在，"忍一忍"不在。

同样要诚实的是对第一年的预期：你会把该 SEV2 的事拖到早上，会在该叫人的时候多扛二十分钟。复盘盯的是流程漏洞，不是你的性格缺陷------把"我当时犹豫了"翻译成"判据清单当时不在手边"，才是这个系统能升级的原因。

现在就能做的三件事

1. 数两个数字：值班轮换人数、最近一班的 page 次数，对着"6 人"和"每班 2 次"两条线，超标就是行动项。
2. 检查 SEV1 有没有配 T+5、T+15 两级自动升级；只配了 repeat_interval 的，补上"喊更高的人"那层------escalation policy 配在值班平台侧（Alertmanager 配置有改动的话，用 amtool check-config 校验）。
3. 靶场随机抽一个 break 脚本注入，掐表走完全流程，记下发现/修复时长------第一次测，做好被吓一跳的准备【从业者判断】。

留一个提问：你值第一年班时，第一次开口求助用了多久？晒一个"该升未升"的教训------那条判据，你是背会的还是踩坑才会的？

完整的靶场脚本、演练流程与值班手册模板，GitHub 搜 sre-learning-hub。