On-Call

概述 凌晨三点，手机震了。你看了一眼——P1 告警，订单服务 5xx 错误率飙升。爬起来，开电脑，拉日志，查 Grafana，定位到是上游数据库连接池打满。重启、扩容、恢复，一看表四点半了。第二天早上你顶着黑眼圈开会，会上有人说"昨晚那个告警其实是误报"。 这种感觉，干过运维的人都懂。 On-Call（值班响应）是 SRE 工作中绕不开的一环。但很多团队的 On-Call 做成了"谁被叫醒谁处理"，没有轮值，没有备份，没有交接，更没有疲劳管理。结果是：核心工程师离职，告警群形同虚设，故障响应越来越慢。 这篇文章聊聊 On-Call 排班设计中的 7 个工程决策。不是理论框架，是我这些年从 0 到 1 搭建 SRE 值班体系时踩过的坑、做过的取舍。在之前的事件管理与 On-Call 机制设计中讲过事件响应流程，本文聚焦在"排班本身怎么设计"——轮值周期、主备机制、告警分级、疲劳量化、交接班、新人上岗、补偿与度量。 如果你是刚接手 SRE 团队的技术负责人，或者正在被无序的值班制度折磨，这篇文章应该能帮你少走半年弯路。 一、On-Call 到底在解决什么问题 先说清楚 On-Call 是干嘛的，再说怎么设计。 On-Call 的本质是：在非工作时间，系统出问题时，有人能第一时间响应并恢复。 打个比方：医院急诊科不能晚上关门。医生白天上班，晚上也得有人值班。但值班的医生不是同一个人连值一周不睡觉——那第二天手术手抖就出医疗事故了。所以医院有轮班制度：白班、夜班、备班，轮着来，保证每个班次的医生都是清醒的。 On-Call 的逻辑一样。你的系统 7x24 小时跑着，但工程师不能 7x24 小时盯着。On-Call 排班就是让"正确的人在正确的时间收到告警"，而不是"所有人都收到告警"或者"没人收到告警"。 Google SRE 的 On-Call 原则 Google SRE 在《Google 运维解密》里用三个章节讲 On-Call，核心原则就一条：琐事不能超过工作时间的 50%。 什么是"琐事"（Toil）？Google 的定义是：重复的、可自动化的、战术性的、没有持久价值的工作。比如手动重启服务、手动扩容、手动查日志定位问题——这些都是琐事。On-Call 是琐事最大的来源之一。 一个 SRE 至少要花一半时间做工程项目（写代码、做工具、改架构），否则就是在用人力填系统的坑，越填越深。要保证这个比例，团队至少需要 6-8 人轮值——人少了轮不过来，工程时间被值班吃光。 Google SRE 的 on-call 方法和工具 这篇文章里有一个很清晰的分析：Google 通过 Outalator 工具管理告警的全生命周期，包括聚合、标签、分析、交接报告，让 On-Call 不只是"被叫醒"，而是"被管理"。Outalator 的核心功能包括：...

概述 凌晨三点，手机震动。告警群炸了 200 条消息，用户投诉已经涌进客服群。你爬起来打开电脑，登录跳板机，发现某个核心接口 P99 飙到 8 秒。接下来 30 分钟你都在翻日志、查 Grafana、问上下游——最终定位到是某个配置中心推了一行错误参数。 这个场景太熟悉了。在我经手的上百次线上故障中，定位环节消耗的时间占 MTTR 的 60% 以上。恢复操作本身可能只要 2 分钟（回滚、重启、切流量），但找到"到底哪里出了问题"往往要花 20-30 分钟。 MTTR（Mean Time To Repair/Recovery）衡量的是从故障发生到服务恢复的平均时间。但这个数字是个黑盒——30 分钟的 MTTR 里，到底哪些环节在拖后腿？检测花了多久？响应花了多久？定位花了多久？恢复花了多久？不拆开看，优化就无从下手。 这篇文章拆解我在某出行项目和某电商项目中实战验证的 MTTR 优化体系——四层防御模型：检测层、响应层、定位层、恢复层。每层有具体的工程手段和度量指标，不是空谈方法论。最终效果：核心服务 MTTR 从 40 分钟降到 8 分钟，故障定位时间从 30 分钟降到 5 分钟。 MTTR 拆解：你优化的是哪个环节 很多人把 MTTR 当成一个整体来优化，这是错的。MTTR 至少要拆成四个阶段： 阶段 全称 含义 典型耗时 优化重点 MTTD Mean Time To Detect 从故障发生到告警触发 1-5 min 监控覆盖、SLO 告警 MTTA Mean Time To Acknowledge 从告警触发到有人开始处理 2-10 min On-Call 机制、告警路由 MTTI Mean Time To Identify 从开始处理到定位根因 10-30 min 可观测性、诊断工具 MTTR Mean Time To Restore 从定位根因到服务恢复 1-5 min 回滚、自愈、预案 注意 MTTR 有两种常见解读：Repair（修复）和 Recovery（恢复）。SRE 语境下我更推荐用 Recovery——目标是恢复服务而非彻底修复 Bug。彻底修复是 Postmortem 之后的事（相关文章：故障复盘改进项跟踪）。...

概述 SRE 有一句名言：“系统一定会出故障，区别在于你是被它叫醒的还是主动管理它的。” 事件管理不是"出了事再处理"，而是一套从预防、检测、响应到学习的完整工程体系。 从事件分级、On-Call 轮值、事故响应流程、Postmortem 文化、告警治理五个方面，详细梳理如何构建一个可落地的 On-Call 体系。 关于事件管理的系统方法论，可参考 Google SRE Book - Managing Incidents 和 Google SRE Book - Postmortem Culture。 一、事件分级标准 没有分级的事件管理等于没有管理——所有事件都按紧急处理，结果就是没有真正的紧急。合理的事件分级是 On-Call 体系的基石。 P0-P4 事件定义 级别 定义 影响范围 响应时效 示例 P0 生产服务完全不可用 全量用户受影响 立即响应，<5min 核心服务宕机、数据库不可用 P1 核心功能严重降级 大量用户受影响 <15min 支付失败率飙升、API 错误率 >10% P2 部分功能降级 部分用户受影响 <30min 某区域延迟劣化、非核心服务异常 P3 潜在风险 暂无直接影响 <2h（工作时间） 磁盘水位 >80%、单节点故障 P4 优化建议 无影响 下一工作日 告警阈值优化、文档补充 分级原则 分级的本质是资源调度优先级——让有限的人力优先处理影响最大的问题： 以用户影响为准，而非技术指标：CPU 99% 是 P3，但如果导致用户请求超时就是 P1 明确定义，避免模糊：“大量用户"是 30% 还是 50%？需要量化 可自动判定：理想状态下，事件级别应该能通过告警规则自动确定 # 告警分级规则示例 groups: - name: incident-grading rules: # P0: 核心服务完全不可用 - alert: P0ServiceDown expr: up{job="critical-service"} == 0 for: 1m labels: severity: P0 page: true # 触发电话告警 escalation: true # 自动升级到主管 annotations: summary: "核心服务不可用" runbook: "https://wiki/incident/p0-service-down" # P1: 错误率超过 SLO - alert: P1HighErrorRate expr: | sum(rate(http_requests_total{status=~"5....