凌晨两点，医院急诊科的电话骤然响起。值班医生从休息室小跑出来，目光扫过中央监护站的大屏——三号床心率曲线异常，血压骤降，红色报警灯闪烁。他没有慌乱，而是按照训练过的节奏：先看一眼监护仪上的趋势变化，再翻一下电子病历，确认这位病人昨晚的手术史，然后迅速下达抢救指令。与此同时，住院总医师也收到了系统自动派发的升级通知，正从更远的病区赶来。 这难道不是今天每一家互联网公司运维值班室的真实写照吗？当订单服务的错误率曲线突然拔高，当数据库连接数逼近上限，当支付网关的延迟出现异常尖峰——现代软件的 On-Call 工程师，就像那位急诊科值班医生：面前是层层叠叠的监控仪表盘（监护仪），口袋里的告警手机（寻呼机），桌上是昨天交接班留下的运行手册（病历）。微服务与云原生架构让系统变得极其复杂，单凭直觉已经无法理解所有故障，可观测性体系帮助我们“看见”系统的每个角落，而 On-Call 实践，则是让这些“看见”真正转化为“行动”的完整机制。 这篇文章将带你走进一个成熟团队的 On-Call 体系：从值班制度设计、告警体系，到监控仪表盘、故障响应流程，再到交接班与复盘改进。你会发现，稳定可靠的系统背后，不仅有优雅的架构，还有一套像医院急诊室一样科学运转的“救人”方法。

岗位关联

掌握 On-Call 实践，是 SRE、DevOps 和云原生工程师的必修课。它让你的团队在凌晨三点依然能淡定应对故障，把“系统崩了”从灾难变成日常工作流的一环——这也是从普通开发走向高薪运维专家的分水岭。

目录
  1. 可视化演示
  2. 值班基础制度
  3. 告警体系设计
  4. 监控仪表盘
  5. 故障响应流程
  6. 交接班制度
  7. 复盘改进机制
  8. 值班文化建设
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示可观测性体系下的On-Call值班流程，从告警触发、工单分派、响应处理到事件复盘，展示值班层级升迁与关键SRE指标的持续追踪。

本节配有交互动效（进入视口后自动加载，约 3KB）。

On-Call 响应闭环 告警触发：事件发现 工单分派：值班响应 层级升迁：超时升级 MTTA+MTTR 衡量响应效率

值班基础制度

急诊科的墙上有张神圣的排班表，写着每一个时段的“责任人”：今天谁值一线、谁是二线、谁在备班。绝对不可能出现“系统崩了但不知道找谁”的窘境。值班基础制度就是这张排班表——它解决的核心问题是：当告警响起，谁有责任、有权利、有能力站起来处理。

在软件领域，On-Call（待命值班）是 SRE 实践中最硬核的一环。一个微服务系统可能有上百个服务、上千个实例，任何时刻都可能出故障。On-Call 制度规定：每一时刻都有明确的“值守人”（Primary，一线），同时安排一个“备份人”（Secondary，二线）兜底。一线负责第一时间响应所有告警，二线负责支援与升级。轮换机制以周为单位——本周你值守，下周换别人，节假日提前排好。

和排班表紧密挂钩的是 SLO（服务级别目标）。SLO 定义了系统可靠性的量化目标，比如“月度可用性 99.9%”。值班质量最终要用数字说话：这个月因响应慢浪费了多少错误预算？可用性公式是这一切的基石：

就像急诊科承诺“危急病人 5 分钟内必须接诊”一样，SLO 是团队向用户做出的可靠性承诺，而值班制度则是兑现承诺的排班表——它确保任何时刻都有人为这份承诺负责。没有这张表，再好的监控也只是墙上闪烁的霓虹灯。

可用性=Ttotal−TdownTtotal×100%\displaystyle \text{可用性} = \frac{T_{\text{total}} - T_{\text{down}}}{T_{\text{total}}} \times 100\%
这个公式告诉你：系统一整个月（如 43200 分钟）里，去掉故障无法服务的时间，剩余时间占比就是可用性。
  1. 总时长 T_total统计周期的总时间，比如一个月按 30 天算就是 43200 分钟。
    Ttotal=30×24×60=43200\displaystyle T_{\text{total}} = 30 \times 24 \times 60 = 43200
  2. 故障时长 T_down周期内所有不可用时间的累计值，例如一次故障持续 25 分钟。
    Tdown=25 min\displaystyle T_{\text{down}} = 25 \text{ min}
  3. 分子相减（可用时长）总时长减去故障时长，得到系统真正正常服务的时间。
    Ttotal−Tdown\displaystyle T_{\text{total}} - T_{\text{down}}
  4. 比值×100%可用时间占总时间的百分比，99.9% 意味着全月累计不可用不超过 43.2 分钟。
    Ttotal−TdownTtotal×100%=99.9%\displaystyle \frac{T_{\text{total}} - T_{\text{down}}}{T_{\text{total}}} \times 100\% = 99.9\%

告警体系设计

急诊科的报警声是分等级的：心搏骤停的红色警报会让所有人弹起来，而输液完成的提示音只是护士站的一声轻响。如果所有报警都用同一个声音高强度轰炸，护士很快就会麻木——这就是著名的“狼来了”效应。告警体系设计要回答的问题是：什么该响？响多大声？谁来处理？

在 On-Call 世界里，“报警”被称为 Alert（告警），但并不是随便发一条消息。业界通常把信号分为三类：Page（寻呼级，必须立即行动）、Notification（通知级，工作时间处理）、Log（日志级，仅记录）。告警分级一般用 P1/P2/P3：P1 是核心业务受损，需要立刻响应；P2 是服务降级但用户无感；P3 只是潜在风险。

告警规则应该“宁可少报，不可误报”。因为 On-Call 的注意力是最稀缺的资源，每一条误导性告警都在消耗值班者的信任。衡量告警质量的核心公式是准确率 Precision：

降噪手段有很多：相同告警合并去重、已知问题维护静默窗口、深夜低级别告警自动转工单……目的只有一个——让每一次响铃都值得 On-Call 爬起来。好的告警体系就像急诊科的分诊台，先过滤掉所有“虚惊一场”，把真正的危重病人送到你面前。

Precision=NtpNtp+Nfp\displaystyle \text{Precision} = \frac{N_{\text{tp}}}{N_{\text{tp}} + N_{\text{fp}}}
这是“报警的可信度”：收到的 10 条告警里 8 条是真故障，准确率就是 80%；如果不到一半是真的，说明告警体系需要优化。
  1. 真实告警数 N_tp确实对应真实故障的有效告警数量。
    Ntp=真实故障次数\displaystyle N_{\text{tp}} = \text{真实故障次数}
  2. 误报告警数 N_fp没有对应真实故障的噪音告警，比如阈值设置过浅、监控项配置错误。
    Nfp=噪音告警次数\displaystyle N_{\text{fp}} = \text{噪音告警次数}
  3. 分母（总告警量）真实告警与误报告警之和，也就是值班者实际收到的总打扰次数。
    Ntp+Nfp\displaystyle N_{\text{tp}} + N_{\text{fp}}
  4. 比值 Precision百分之多少的告警值得人类去处理，它直接决定值班者对告警的信任感。
    Precision=NtpNtp+Nfp≈1\displaystyle \text{Precision} = \frac{N_{\text{tp}}}{N_{\text{tp}} + N_{\text{fp}}} \approx 1

监控仪表盘

急诊室的中央监护站，护士抬头就能看到一整面墙的屏幕：几十个床位的血压、心率、血氧实时跳动。她不用跑到每个病床前读数据，一切尽收眼底。监控仪表盘就是 On-Call 的中央监护站——在告警电话打来之前，值班者应该能从这里一眼看出系统的健康度。

可观测性领域有著名的“黄金四指标”（来自 Google SRE）：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。延迟是请求有多慢，流量是每秒多少请求，错误是请求失败的比例，饱和度是系统资源还剩多少。这四个维度覆盖了大多数微服务故障的表征。

优秀仪表盘通常分三层：顶部放业务 SLO 和错误预算——这是“病人体温”；中间放各服务黄金四指标——这是“器官功能”；底部才是 CPU、内存等基础设施——这是“血压血氧”。而错误预算消耗率把 SLO 变成了一个可实时观测的仪表：

信噪比是仪表盘的灵魂：如果一屏有 30 个图，值班者找不到关键的那个，那这个盘就是噪音。好的做法是保留“能驱动行动”的图，删掉从不看的图——就像监护站的护士，她需要在一秒内判断“哪个床位现在最危险”。

Burn=Tdown, cumulativeTallowed×100%\displaystyle \text{Burn} = \frac{T_{\text{down, cumulative}}}{T_{\text{allowed}}} \times 100\%
这个仪表告诉你：这个月的“欠账”用了多少。消耗率超过 80% 就该警惕，超过 100% 意味着 SLO 违约已成定局。
  1. 累计不可用时长 T_down_cumulative从月初至今所有故障占用的时间总和。
    Tdown, cumulative=∑iTfailure, i\displaystyle T_{\text{down, cumulative}} = \sum_{i} T_{\text{failure, i}}
  2. 允许最大不可用时长 T_allowedSLO 允许的容错时间，如 99.9% 对应每月最多 43.2 分钟。
    Tallowed=(1−0.999)×43200=43.2\displaystyle T_{\text{allowed}} = (1 - 0.999) \times 43200 = 43.2
  3. 比值×100%消耗掉错误预算的百分比，是仪表盘上最应该被盯住的数字。
    Burn=Tdown, cumulativeTallowed×100%\displaystyle \text{Burn} = \frac{T_{\text{down, cumulative}}}{T_{\text{allowed}}} \times 100\%

故障响应流程

凌晨两点，报警响起。急诊科医生不会立刻冲出去，而是先看监护仪确认病人当前状况，再翻病历，然后按标准流程操作：评估、处置、观察、请示。故障响应流程就是给 On-Call 工程师写好的“急诊标准操作流程”，它保证在高度紧张时，人的行为依然可预期、不遗漏。

一次完整的故障响应有五个环节：确认（Acknowledge）→ 评估（Assess）→ 定位（Diagnose）→ 止血（Mitigate）→ 恢复（Resolve）。收到告警后第一件事是点“确认”，告诉系统“有人接手了”，避免告警重复轰炸。然后评估影响面：哪些服务挂了？影响多少用户？紧接着定位：是最近一次发布引入的问题？还是依赖的下游服务挂了？

定位之后不是立刻修根因，而是先止血——回滚代码、限流保护、切流量到备用集群。等系统恢复稳定后，再从容修复根因。整个过程的效率用两个指标衡量：

流程的最大价值在于“不用想”。就像急诊医生在抢救时不会翻课本一样，On-Call 工程师在告警风暴中需要肌肉记忆般的行动顺序。如果 15 分钟还没定位，就应该触发升级——呼叫二线甚至召集作战室，正如急诊科病情危重时呼叫住院总医师会诊。

MTTA=1n∑i=1n(tack,i−talert,i)\displaystyle \text{MTTA} = \frac{1}{n} \sum_{i=1}^{n} (t_{\text{ack}, i} - t_{\text{alert}, i})
MTTR=1n∑i=1n(tresolved,i−talert,i)\displaystyle \text{MTTR} = \frac{1}{n} \sum_{i=1}^{n} (t_{\text{resolved}, i} - t_{\text{alert}, i})
MTTA 是“从响铃到有人接电话”的平均时间，MTTR 是“从响铃到系统恢复”的平均时间。前者考验流程，后者考验技术。
  1. 告警时间戳 t_alert第 i 次告警由监控系统发出的时刻，这是计时的起点。
    talert,i\displaystyle t_{\text{alert}, i}
  2. 确认时间戳 t_ack值班者点击确认的时刻，与告警时刻的差值代表“反应速度”。
    tack,i−talert,i\displaystyle t_{\text{ack}, i} - t_{\text{alert}, i}
  3. MTTA 平均确认时间所有告警响应耗时的平均值，是 On-Call 流程质量的直接度量。
    MTTA=1n∑i=1n(tack,i−talert,i)\displaystyle \text{MTTA} = \frac{1}{n} \sum_{i=1}^{n} (t_{\text{ack}, i} - t_{\text{alert}, i})
  4. MTTR 平均恢复时间系统恢复时刻与告警时刻的差值平均，包含定位、止血与恢复全过程。
    MTTR=1n∑i=1n(tresolved,i−talert,i)\displaystyle \text{MTTR} = \frac{1}{n} \sum_{i=1}^{n} (t_{\text{resolved}, i} - t_{\text{alert}, i})

交接班制度

急诊科最神圣的仪式是交接班：夜班医生会把每个危重病人的情况、刚做的处理、下一步计划，一件件交代给白班医生。如果交班不清，白班医生面对突发情况时等于从零开始。交接班制度是 On-Call 团队记忆的接力棒。

On-Call 交接班发生在两个层面：人与人的口头交接与文档化的书面交接。口头交接要求交班者把进行中的事件、当前影响、已做尝试讲清楚；书面交接则依赖结构化交接文档模板，字段通常包括：当前告警列表、进行中事件的完整时间线、可疑的变更发布、未解决问题的建议下一步。

衡量交接质量最直观的指标是交接完备率——接班者逐条确认了文档中的多少内容：

交接单不仅是当班人的备忘，更是团队知识沉淀的原料。把多次事件的处理方式总结成 Playbook（运行手册），下一位值班者遇到同样问题时不用再“发明轮子”——就像急诊科把抢救流程固化成胸痛通道、卒中通道一样。

交接完备率=NcheckedNrequired×100%\displaystyle \text{交接完备率} = \frac{N_{\text{checked}}}{N_{\text{required}}} \times 100\%
交接完备率 100% 意味着交班者与接班者对系统状态达成完全同步，没有任何“我以为你知道了”的误会。
  1. 应确认条目数 N_required交接文档模板要求逐条确认的字段总数。
    Nrequired=模板字段总数\displaystyle N_{\text{required}} = \text{模板字段总数}
  2. 已确认条目数 N_checked接班者已逐条阅读并确认的字段数量。
    Nchecked=已完成确认的字段数\displaystyle N_{\text{checked}} = \text{已完成确认的字段数}
  3. 两者比值×100%交接完整度的量化表达，低于 100% 意味着存在信息盲区。
    NcheckedNrequired×100%\displaystyle \frac{N_{\text{checked}}}{N_{\text{required}}} \times 100\%

复盘改进机制

急诊科每周召开病例讨论会：为什么这位病人的病情恶化了？是检测项目漏了？还是交接时信息丢失？会议气氛不是追责，而是追问“系统哪里还能改进”。复盘改进机制是 On-Call 体系持续进化的引擎。

故障复盘（Postmortem）在 SRE 文化中有三条铁律：无指责、关注流程缺陷、产出行动项。因为大多数事故都是系统性问题——告警延迟、命令误操作、流程缺失——追责只会让工程师隐瞒风险，让系统更脆弱。复盘会按时间线还原：告警何时发出、谁处理、做了什么、哪里断片了，再定位根因，最后产出一批行动项。

衡量复盘是否真正落地，靠的是行动项闭环率——开完会不跟进等于白开：

复盘的另一个输出是告警降噪闭环：每次误报都去优化规则，每次响应慢都去优化流程。就像急诊科发现血压计不准，不是责备护士读错数，而是立刻校准设备。这个循环跑起来，团队的告警量会越来越小，而系统越来越稳。

行动项闭环率=NclosedNtotal×100%\displaystyle \text{行动项闭环率} = \frac{N_{\text{closed}}}{N_{\text{total}}} \times 100\%
团队通常设目标：每次复盘产生的行动项，30 天内闭环率不低于 80%，否则复盘就是形式主义。
  1. 行动项总数 N_total复盘会上确定的所有待办事项数量。
    Ntotal=复盘产出的行动项数\displaystyle N_{\text{total}} = \text{复盘产出的行动项数}
  2. 已关闭行动项数 N_closed在指定时间内完成并被验证关闭的数量。
    Nclosed=已完成并验证的行动项数\displaystyle N_{\text{closed}} = \text{已完成并验证的行动项数}
  3. 闭环率行动项从“待办”到“完成”的转化比例，代表复盘对系统的真实改善。
    NclosedNtotal×100%\displaystyle \frac{N_{\text{closed}}}{N_{\text{total}}} \times 100\%

值班文化建设

急诊科医生压力巨大，但如果医院只是压榨，不出三个月就没人愿意值班了。值班文化建设要解决的是“如何让团队成员愿意值、值得好、值不垮”。

On-Call 的本质是“把人的注意力租给系统”，所以必须先保护人。三个方面缺一不可：心理安全——值班失误被当作数据点而非罪证，工程师才敢快速决策；疲劳管理——值班频次应有限制（如每人每季度值班总周数有上限），保证值班后休息；激励机制——值班补贴、调休、晋升认可，让付出被看见。

除了保障，还要训练。故障演练（Game Day）和混沌工程是 On-Call 团队的“军事演习”：人为制造故障，检验监控是否告警、值班者是否知道如何处理、流程是否顺畅。衡量值班响应质量的基础指标是响应达标率：

最后回到开头的比喻：医院为什么能留住优秀的急诊医生？因为制度保护人、文化尊重人、演练锻炼人。On-Call 实践的最高境界，是让值班成为一种团队荣耀——不是“这周我要倒霉值夜班了”，而是“系统由我守护，我清楚地知道出了事该怎么处理”。这才是可观测性体系与 On-Call 实践真正的价值。

响应达标率=NmetNtotal×100%\displaystyle \text{响应达标率} = \frac{N_{\text{met}}}{N_{\text{total}}} \times 100\%
即告警在 SLO 规定时限内（如 P1 要求 15 分钟确认）被响应或确认的比例，它反映全队训练的成果。
  1. 告警总数 N_total一个值班周期内分配到个人或团队的告警次数。
    Ntotal=周期内告警次数\displaystyle N_{\text{total}} = \text{周期内告警次数}
  2. 达标响应次数 N_met在时限内完成确认的处理次数。
    Nmet=按时确认的告警次数\displaystyle N_{\text{met}} = \text{按时确认的告警次数}
  3. 达标率值班质量的核心 KPI，配合 MTTA 可以定位响应瓶颈的时段与人员。
    NmetNtotal×100%\displaystyle \frac{N_{\text{met}}}{N_{\text{total}}} \times 100\%

AI 应用场景

智能告警降噪：让AI过滤“狼来了”

阶段：告警压缩与智能路由（属于可观测性体系中的告警体系设计环节）

解决的问题：传统告警依赖静态阈值，误报率高。凌晨 3 点一条 P1 误报会把值班者从睡梦中惊醒，消耗精力与信任感。AI 通过历史告警数据训练模型，自动学习告警与真实故障的关联，对告警做实时分类、聚合、预测，把有效告警和噪音告警分流，让手机只响“真正该响”的铃。

具体案例：某电商平台大促期间，告警量暴涨到平时的 20 倍。接入 AI 降噪后，系统基于历史故障标签训练 XGBoost 分类器，实时预测每条告警的“真实性”，将 P1 误报率从 35% 降至 6%，并把相似告警聚合为一条根因分析摘要，值班者每晚只需处理约 5 条有效告警。

智能根因分析：从线索到病灶

阶段：故障定位（故障响应流程中的“诊断”环节）

解决的问题：微服务架构中一次调用跨越十几个服务，传统排查靠人工查日志、追链路，平均耗时超过 40 分钟。AI 利用链路追踪数据和指标时序数据，构建服务依赖图，通过异常传播分析自动锁定“病灶服务”，把定位时间从分钟级压缩到秒级。

具体案例：某在线支付系统某次故障中，订单服务延迟突增。AI 根因分析系统在 2 分钟内关联了 20 个上下游服务的指标变化，发现数据库连接池耗尽导致的级联效应，给出 Top3 可疑根因。值班工程师直接跳过大海捞针，5 分钟完成决策并回滚。

AI值班助手：自动交接班报告

阶段：交接班制度中的文档自动生成

解决的问题：凌晨忙碌的值班结束后，交班者要在困倦中整理交接报告，容易遗漏关键信息。基于 LLM（大语言模型）的 AI 助手自动汇总夜间告警、变更记录、处理动作，生成结构化交接文档，并识别“尚未闭环”的高危事项，提醒接班者重点关注。

具体案例：某云厂商的 SRE 团队部署了值班助手，每早 7 点自动推送前日值班摘要，包含告警分布、误报清单、进行中事件、建议关注项。交接班时间从平均 45 分钟降为 15 分钟，交接完备率明显提升。

Python 演示

python46 行
"""On-Call 告警统计与降噪分析器"""from collections import defaultdict # 模拟一周告警: 字段 = 时间, 级别, 是否误报, 确认耗时(分), 恢复耗时(分)ALERTS = [    ("01-06 02:13", "P1", False, 3, 42),    ("01-06 03:55", "P2", True, 0, 0),    ("01-06 08:31", "P1", False, 5, 28),    ("01-06 14:02", "P3", True, 0, 0),    ("01-07 01:47", "P1", False, 8, 65),    ("01-07 09:16", "P2", False, 12, 33),    ("01-07 22:40", "P2", True, 0, 0),    ("01-08 00:22", "P1", False, 2, 18),    ("01-08 10:05", "P3", True, 0, 0),    ("01-08 18:47", "P2", False, 15, 51),] def compute_metrics(bucket):    """计算告警准确率与平均耗时"""    total = len(bucket)    if not total:        return 0.0, 0.0, 0.0    real = [a for a in bucket if not a[2]]    precision = len(real) / total    mtta = sum(a[3] for a in bucket) / total    valid = [a for a in real if a[4] > 0]    mttr = sum(a[4] for a in valid) / len(valid) if valid else 0.0    return precision, mtta, mttr def daily_report(alerts):    """按天输出值班统计"""    by_day = defaultdict(list)    for a in alerts:        by_day[a[0][:5]].append(a)    print("日期   | 总量 | 误报 | 准确率 | MTTA | MTTR")    for day in sorted(by_day):        p, mtta, mttr = compute_metrics(by_day[day])        fp = sum(1 for a in by_day[day] if a[2])        print(f"{day} | {len(by_day[day]):>3} | {fp:>3} | {p:>5.0%} | "              f"{mtta:>4.0f}m | {mttr:>4.0f}m") if __name__ == "__main__":    print("=== On-Call 值班周报 ===")    daily_report(ALERTS)    p, mtta, mttr = compute_metrics(ALERTS)    print(f"本周整体: 告警准确率 {p:.0%}, MTTA {mtta:.0f} 分钟, MTTR {mttr:.0f} 分钟")
目的：读取一周的告警记录，按天统计告警总量、误报数、准确率（Precision）、MTTA 与 MTTR，输出值班周报——这正是正文中告警质量度量公式的实际工程落地。
  1. ALERTS = [("01-06 02:13", "P1", False, 3, 42), ...]模拟监控平台导出的告警原始数据，元组包含时间、级别、是否误报、确认耗时、恢复耗时。
  2. real = [a for a in bucket if not a[2]]筛选出非误报（有效）告警，对应公式中的 N_tp。
  3. precision = len(real) / total计算正文中的告警准确率 Precision，即有效告警占总告警的比例。
  4. mtta = sum(a[3] for a in bucket) / total计算平均确认时间 MTTA，对应公式中 ∑(t_ack − t_alert)/n。
  5. by_day[a[0][:5]].append(a)取时间字符串前 5 个字符（如"01-06"）作为日期键，完成告警按天分组。
  6. print(f"{day} | {len(by_day[day]):>3} | ...")格式化输出日报表，使用右对齐让数据列清爽可读。

常见误区

误区我理解的 On-Call 就是人必须一直坐在电脑前盯着监控，眼睛不能离开屏幕，否则系统出问题没人发现。这活儿太累人了，根本没法干。

正解恰恰相反，On-Call 是“待命 + 响应”，不是“盯屏”。监控和告警是自动的——系统出问题会有告警电话/短信/IM 通知你。你可以在值班期间正常生活，只要在 SLO 规定的时限内（如 15 分钟）确认并处理告警即可。真正该“盯屏”的是自动化监控系统，这正是可观测性体系存在的意义。如果 On-Call 需要人工盯屏，说明告警体系还没建设好。

为何常见：很多人把“监控”和“待命”混淆，以为系统必须有个人看着才放心，忽略了自动化告警才是发现故障的第一线。

误区监控越全面越好，告警越及时越好。我宁愿多设几条告警规则，反正多收几条消息总比漏掉故障强。

正解告警过多会导致“告警疲劳”——就像狼来了喊多了，真正的 P1 告警反而不被重视。告警不是看数量而是看准确率（Precision）。一条高质量告警（如“支付成功率下跌 30%”）胜过一百条低质量噪音。好的告警体系“宁缺毋滥”，人只有在告警可信时才会快速响应。

为何常见：人们天然恐惧“未知的故障”，觉得越多监控越安心，但忽略了注意力是稀缺资源，误报会摧毁告警系统的公信力。

误区出了故障肯定要找个负责人，谁部署的谁背锅，不然以后没人对事故负责。复盘就是开会骂人呗。

正解无指责复盘恰恰相反：它假定大多数事故不是某个人的“坏心”，而是系统性流程缺陷（告警配置过期、操作手册缺失、发布审批不严等）的必然结果。追责会让工程师学会隐瞒小问题，导致更大的灾难。复盘的产出是行动项和改进，比如“更新告警阈值”“补充回滚指南”，而不是一份检讨书。

为何常见：这源自传统工业事故处理中“责任人受罚”的习惯，忽略了软件故障大多是复杂系统的涌现行为，单一归因反而掩盖真正的改进机会。

误区交班就跟室友交接钥匙一样，说一句“有个故障还在查，你继续看”就行了，反正信息系统里都有记录，接班的人自己翻聊天记录呗。

正解口头交接极易丢失关键上下文。成熟团队用结构化交接文档：进行中事件、时间线、影响范围、已做尝试、可疑变更、需要跟进事项，接班者逐条确认。文档化不仅是为了这个班次，更是为了沉淀知识——当同一问题出现第二次，交接文档和 Playbook 会让你几分钟内恢复，而不是重新排查几小时。

为何常见：值班结束时人很疲惫，图省事口头带过；同时低估了“上下文丢失”对下次响应速度的影响，总以为工具里有记录，但工具不会告诉你“为什么当初要那么处理”。

误区我们都是专业团队，SLO 当然要设 99.99% 甚至 99.999%，多一点不可用都觉得丢人。

正解SLO 越高，错误预算越小，系统越“脆弱”——稍微一点故障就消耗完预算，团队只能停止一切变更、如履薄冰，导致创新和迭代停滞。合理的 SLO 要平衡可靠性与迭代速度，比如核心支付链路 99.95%、新业务内测 99%。SLO 是给业务的一个承诺，不是给自己上的一把枷锁。

为何常见：受“越是追求完美越是专业”的直觉影响，忽略了错误预算机制的本质：用可量化的容错空间换取业务敏捷性。

面试题

Q1. 在On-Call实践中，MTTA代表什么？

单选题 · easy

  • A.平均确认时间← 正确答案
  • B.平均恢复时间
  • C.平均故障间隔
  • D.平均响应时间

答案：A。MTTA 是 Mean Time To Acknowledge，即平均确认时间——从告警发出到有人点击“确认”的间隔。它衡量的是流程响应速度，就像急诊科承诺“接到报警后几分钟内接诊”；而 MTTR 才是平均恢复时间，衡量从告警到系统恢复的全过程。

Q2. 告警准确率Precision的正确计算公式是？

单选题 · easy

  • A.有效告警除以告警总数← 正确答案
  • B.有效告警乘以误报数
  • C.误报数除以告警总数
  • D.有效告警减去误报数

答案：A。Precision = 有效告警数 /（有效告警数 + 误报数）= 有效告警 / 告警总数。它回答“收到的告警里有几成值得处理”，就像分诊台判断“真正需要抢救的病人占比”。误报太多会引发告警疲劳，准确率越高，值班者的信任度越高。

Q3. P1与P2告警之间的主要区别是什么？

单选题 · mid

  • A.通知渠道完全不同
  • B.发送时间有区别区分
  • C.紧急程度差异明显← 正确答案
  • D.两种级别没有区别

答案：C。P1（严重）是核心业务受损、必须立即响应；P2（中等）是服务降级但用户无感，可稍后处理。两者的本质区别是故障的影响范围和紧急程度，而非通知渠道或发送时间。就像急诊科的红色警报与输液提示音，音量大小只是表现，抢救优先级才是核心。

Q4. On-Call轮换机制的首要设计目标是？

单选题 · mid

  • A.增加系统告警数量
  • B.确保团队轮流值守← 正确答案
  • C.降低监控部署成本
  • D.减少告警通知时间

答案：B。轮换机制的首要目标是把 On-Call 的负担公平地分散到团队成员身上，避免个别人长期过度值班而身心俱疲。同时保证任何时刻都有明确的值守人。值班制度不是用来“增加告警”或“降低监控成本”的，而是回答“出事时该找谁”。

Q5. 无指责复盘会的核心追求是？

单选题 · mid

  • A.找出事故责任人
  • B.撰写详尽复盘报告
  • C.惩罚粗心犯错员工
  • D.改进流程而非追责← 正确答案

答案：D。无指责复盘的目的是从流程层面找到系统性的缺陷（告警配置、手册缺失、发布流程等），产出可执行行动项去改进，而非把事故归结到某个人头上。追责会让人隐瞒风险、掩盖问题，反而让系统走向更脆弱。

Q6. 某系统SLO为99.9%，月度总时长为43200分钟，其最大允许不可用时长约为？

单选题 · mid

  • A.43.2分钟多一点← 正确答案
  • B.432分钟约七小时
  • C.4.32分钟非常短
  • D.4320分钟约三天

答案：A。最大允许不可用时长 =（1 − 99.9%）× 43200 = 0.1% × 43200 = 43.2 分钟。这就是该系统的错误预算：一旦当月累积不可用超过 43.2 分钟，SLO 就违约了。计算错误预算的方法正是正文中的可用性公式的逆运算。

Q7. 以下哪些做法属于告警降噪手段？

多选题 · mid

  • A.告警聚合与去重← 正确答案
  • B.维护窗口静默处理← 正确答案
  • C.合并相似告警事件← 正确答案
  • D.彻底关闭全部告警

答案：ABC。聚合去重、把相似事件合并为一条告警、在维护窗口内静默已知问题的告警，都是降低打扰的有效手段。但“彻底关闭全部告警”属于因噎废食——它会让你错过真正的故障，就像为了不吵，把急诊室的监护仪全部静音。

Q8. On-Call交接班文档应包含哪些关键信息？

多选题 · mid

  • A.进行中的事件状态← 正确答案
  • B.可疑变更与发布← 正确答案
  • C.未解决的告警详情← 正确答案
  • D.个人生活闲聊琐事

答案：ABC。交接文档要包含进行中事件、可疑变更、未解决告警以及建议的下一步，目的是让接班者快速获得完整上下文。个人闲聊不属于结构化交接内容。交接完备率 100% 意味着双方对系统状态没有信息差，这是团队记忆的接力棒。

Q9. 下列哪项属于Google SRE黄金四指标之一？

单选题 · hard

  • A.磁盘与内存容量
  • B.延迟与错误率指标← 正确答案
  • C.日志与链路追踪
  • D.代码与测试覆盖率

答案：B。黄金四指标是延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。延迟与错误率都是黄金指标。磁盘内存属于资源指标，日志与链路追踪属于可观测性支柱而非黄金四指标，代码覆盖率属于研发质量范畴。

Q10. 关于On-Call值班文化，以下说法正确的有哪些？

多选题 · hard

  • A.高频率值班损害健康← 正确答案
  • B.心理安全鼓励上报← 正确答案
  • C.故障演练完全没有必要
  • D.激励能提升值班意愿← 正确答案

答案：ABD。高频率值班会导致疲劳和状态下滑，需限制频次；心理安全让人敢主动上报问题，是文化基石；补贴、调休等激励能提升值班意愿。而故障演练（Game Day）恰恰是提升 On-Call 战力的必要手段，与混沌工程配合能提前暴露流程缺陷，并非没有必要。