SLA 合同与 On-Call 值班

• 值班后的补偿机制（comp time）
• 值班期间任务优先级（紧急 vs 日常）
• 值班负担与健康管理

On-call 与日常工作的平衡是 SRE 文化的重要课题。① 补偿机制（comp time）——值班被唤醒应获得补偿休（compensatory time），例如被唤醒一次补偿 1-2 小时，平台应记录被唤醒次数并给值班者补休，避免「值班即加班」的透支。② 值班期间非紧急工单处理——值班期间应以「紧急事件」优先，非紧急工单（日常需求、低优告警）应记录待办，值班结束后再处理，避免被次要任务打断对关键事件的响应。③ 值班轮换——班次长度合理（如 1 周 + 2 周休养），避免连续高频值班。④ 任务交接——值班期间未完成的非紧急事项在交接时明确移交。设计上，值班系统应区分「紧急 page」与「非紧急工单」，值班者只对紧急事件即时响应，非紧急事项进入队列；组织应认可值班的额外负担，通过补休、奖金、轮换公平性保障身心健康。

平衡的核心是「保护值班者精力」与「保障响应速度」的双重目标。comp time 是对「被唤醒」的补偿，非紧急工单延迟处理是「聚焦关键」的体现。管理应从制度（补休、轮换）与工具（优先级分级）两方面保障。

• SLA 与 SLO 的关系（SLA 是外部契约，SLO 是内部目标）
• SLA 承诺的定义与度量口径
• 违约处理（积分、赔偿、免责）

SLA（Service Level Agreement）是「对客户的外部合同承诺」，SLO（Service Level Objective）是「内部可靠性目标」。关系：SLA 通常基于 SLO 制定，但比 SLO 更宽松（SLA 目标 ≤ SLO 目标），因为 SLA 涉及违约赔偿、需留出安全余量。SLA 中可用性承诺的定义：明确「可用性」的精确口径（如每月可用率 = 成功请求 / 总请求）、统计窗口、排除项（计划维护、客户侧问题、不可抗力）。度量：需有双方认可的监控与计费系统，采集数据可审计。违约处理：SLA 通常约定「服务积分（service credit）或赔偿」——未达标时按比例退款或赠积分（如低于 99.9% 返 10% 月费），并定义「免责条款」（排除非服务方原因）。落地时 SLA 的可用性目标应「低于 SLO」，确保内部有足够余量履行外部承诺。

核心是「SLA 对外、SLO 对内、SLA 比 SLO 宽松」。SLA 涉及法律与金钱，定义必须精确（口径、窗口、排除项），违约处理需明确且有度量依据。SLO 是工程抓手，SLA 是商业承诺，两者配套但需留余量。

• 数据安全责任（保密、访问控制、加密）
• 隐私合规（GDPR、个人信息保护法）
• 责任划分与违约处理

SLA 中的数据安全与隐私条款是合同重点。需约定：① 数据安全责任——服务方对数据保密、访问控制、传输与存储加密、安全事件响应（如 72 小时内通知）的义务；② 隐私合规——遵循 GDPR、中国个人信息保护法（PIPL）、CCPA 等法规，明确「数据最小化、目的限制、用户同意」等要求；③ 数据处理约定——明确数据存储位置（地域）、留存期限、删除机制、数据跨境传输的合规；④ 责任划分——区分「服务方负责」与「客户负责」的数据安全边界（如客户侧配置、客户数据本身的合规）；⑤ 违约处理——数据泄露的赔偿、合同解除权、免责与调查权。落地时 SLA 需引用具体法规条文，明确「安全事件报告时限」「数据泄露通知义务」，并约定「审计与合规检查权」。提供方应具备 ISO 27001、SOC2 等认证作为合规能力的佐证。

数据安全与隐私是 SLA 的「法律与技术」复合条款，需法务与工程共同制定。核心是「责任划分清晰、合规要求明确、违约处理可执行」。合规条款对服务提供方是硬约束，需有对应的技术能力（加密、日志、删除机制）支撑。

• RTO/RPO 定义（恢复时间/恢复点目标）
• SLA 与 RTO/RPO 的关系
• 容灾演练与连续性计划

业务连续性管理（BCM，ISO 22301）与 SLA 的衔接点在于「容灾目标」。RTO（Recovery Time Objective，恢复时间目标）指「故障后多久恢复业务」，RPO（Recovery Point Objective，恢复点目标）指「能容忍丢失多少数据」。SLA 与 RTO/RPO 的关系：SLA 承诺的是「正常运行期的可用性」，而 RTO/RPO 承诺的是「故障后的恢复能力」，两者互补。例如：SLA 承诺 99.9% 可用性，但需明确「故障后 RTO 为 30 分钟、RPO 为 5 分钟」，即中断 30 分钟内恢复、最多丢失 5 分钟数据。衔接方法：① 把 RTO/RPO 纳入 SLA 的「连续性承诺」条款；② 设计容灾架构（主备、双活、多活）满足 RTO/RPO；③ 定期容灾演练（切换、恢复）验证 RTO/RPO 可达；④ 定义「灾难场景」的 SLA 例外（如大范围灾难走 BCP 而非常规 SLA）。ISO 22301 要求建立业务影响分析（BIA）、连续性策略与演练计划，RTO/RPO 是核心量化指标。

SLA 面向「常规可用性」，RTO/RPO 面向「灾难恢复」，两者共同构成完整的可靠性承诺。衔接的关键是把 RTO/RPO 明确写入 SLA 并靠演练验证，避免「SLA 只承诺可用性却不承诺恢复能力」的缺口。

• 告警疲劳的定义与危害
• 告警治理手段（合并、抑制、阈值调优、下线）
• 告警质量评估

告警疲劳（alert fatigue）指「告警过多/过滥，值班人员对告警麻木、忽略或延迟响应」，导致重要告警被淹没，是可靠性事故的常见诱因。治理手段：① 告警合并（aggregation）——把同一根因、同一时刻的相似告警合并为一条，避免风暴；② 告警抑制（suppression）——上游故障时抑制下游关联告警、维护窗口抑制；③ 阈值调优——提高误报告警的阈值或改用动态基线，区分「需要人工介入」与「仅记录」；④ 无用告警下线——删除「无条件行动」「长期无价值」的告警，保证每条告警都「可行动（actionable）」。治理原则是「每一条告警都应有明确动作、明确意义、明确责任人」，否则应下线。落地时用「告警/事件比」「误报率」「响应率」评估告警质量，建立「告警合理化」定期评审，把告警数控制在值班可承受范围（如每天 3-5 条可处置告警）。

告警疲劳的本质是「告警信号/噪音比过低」。治理的核心是「减少噪音、提升每条告警的价值」，通过合并、抑制、调优、下线四板斧，并建立持续评审机制。目标是「告警不多但每条都精准」。

• 交接信息的完整性（未恢复告警、进行中变更、已知异常、待办）
• 交接流程与工具
• 避免信息丢失

值班交接是保障「连续性」的关键，必须逐项传递关键信息。应包含：① 未恢复告警——当前仍处于告警状态、未解决的事件及当前处理状态；② 正在进行的变更——值班期间发起的变更（发布、扩容、配置变更）及其进度与风险；③ 已知异常——已观察但未触发告警的异常现象（如某指标缓升、某节点不稳），供接班者关注；④ 待跟进事项——未完成的事项、待确认的工单、待复盘的事件；⑤ 其他——最近的告警趋势、环境变更、测试窗口、值班联系人。交接方式：用交接文档（handoff note）模板 + 值班工具记录，或站立交接会，确保信息结构化、可追溯。交接质量影响「是否重复排查、漏掉关键事件」，因此交接文档应存续、可查，值班主任在交接时逐项确认。

交接的信息是「上下班次之间的连续性」，缺失会导致「重复排查、遗漏待办、断点」。结构化模板 + 工具记录 + 逐项确认是保障交接质量的手段。交接不仅是「口头说明」，更是「可追溯的记录」。

• 告警生命周期（触发→响应→处置→复盘）
• 规则优化（基于处置结果调整阈值/规则）
• 持续改进循环

告警体系的反馈闭环是把「每一次告警处置」变成「规则优化素材」的循环。流程：① 触发——告警规则触发，通知值班；② 响应——值班确认（ack）、评估严重度；③ 处置——排查、解决、恢复；④ 复盘——分析告警是否有价值（是否误报、是否可行动、响应是否及时）；⑤ 规则优化——基于复盘结果调整：误报的调阈值/下线，无行动的合并，缺漏的补充规则，重复的抑制。这样「告警处置」与「规则调优」形成闭环，告警质量持续提升。落地时：① 记录每次告警的处置结果与价值评估；② 定期（周/月）回顾告警质量指标（误报率、响应率、重复率）；③ 用「告警价值标签」（有效/误报/噪音）驱动规则修订；④ 把「规则变更」纳入评审，避免调优失控。闭环的目标是「告警越来越少、越来越准」。

反馈闭环的核心是「把告警处置的经验沉淀为规则改进」，否则告警体系会因「规则僵化」而退化。闭环需要「记录 + 评估 + 修订」的机制与数据支撑，是告警治理的持续运转形式。

• 关联分析的目的（把多条告警归并为一个根因）
• 关联维度（时间、主机、服务、依赖、指纹）
• 实现方法（规则、聚类、图、ML）

Alert correlation 指「把多条可能相关的告警归并、关联，识别出底层根因」，避免告警风暴。关联维度：① 时间——同一时间窗内触发的告警；② 拓扑/依赖——上游故障时下游的关联告警（如订单服务挂了，下游支付也告警）；③ 主机/实例——同一主机或同一集群的告警；④ 指纹/内容——告警内容相似；⑤ 指标相关性——指标趋势相关。实现方法：① 规则关联——基于「父告警→子告警」的依赖关系静态关联；② 拓扑关联——利用服务依赖图，把「根因告警」与「效应告警」分组；③ 聚类——用 DBSCAN 等按时间+主机+指标特征聚类；④ 图/ML——用图神经网络、因果图做根因推理。落地时，告警系统（如 PagerDuty Alert Grouping、Datadog）把「同根因告警」合并为一条主告警，展示关联告警列表，减少通知数量，并辅助定位根因。

关联分析的本质是「从多到一」——把风暴中的多条告警归并为一个根因，同时保留关联信息用于定位。实现上从「规则/拓扑」到「聚类/图/ML」递进，核心是识别「因果」或「相关」关系，减少噪音、辅助根因。

• 告警的自动化触发（规则、检测）
• 自动化响应（自动通知、自动创建事件）
• 自动化处置（自愈、自动回滚、自动扩容）

Alert 自动化覆盖告警的「创建、通知、处置、关闭」全链路。① 自动触发——监控规则实时检测指标，超过阈值自动生成告警，无需人工；② 自动通知——告警按规则自动路由到值班人员（分级通知、升级链）；③ 自动创建事件——告警自动创建 incident/ticket，关联上下文（指标、日志、runbook）；④ 自动处置（自愈）——对可预测的故障自动执行脚本：如自动重启实例、自动扩容、自动回滚发布、自动清理堆积；⑤ 自动关闭——恢复事件到达后自动关闭告警，无需人工点击。实现方式：告警引擎（Prometheus Alertmanager、Grafana）→ webhook 触发自动化（如自愈 worker、Kubernetes 操作、ChatOps 机器人）；用「自动化门禁」保障安全（仅对「已验证的、可逆的」操作自动化）。落地时需区分「可自动处置」与「需人工判断」的告警，自动化优先用在「低风险、高频、可逆」场景。

告警自动化的价值是「减少人工介入、缩短 MTTR」，但需平衡「自动化风险」。核心是「触发自动、通知自动、处置自动、关闭自动」的闭环，且对自动化操作设「门禁与验证」，防止误操作。

• 告警审计的意义（追溯、合规、改进）
• 审计要素（时间、规则、触发者、处置、结果）
• 审计记录与保留

告警审计指「完整记录告警全生命周期，供追溯、合规与改进」。审计要素：① 告警触发信息——时间、规则、指标值、服务、告警级别；② 响应信息——谁 ack、何时 ack、响应时长（MTTA）；③ 处置信息——处置动作、参者、恢复时间（MTTR）、解决过程；④ 结果信息——是否误报、根因、影响。这些记录需「不可篡改、可检索、可保留」一段期限（如 1-2 年）以满足合规。实现方式：告警系统把每次告警的状态变更（触发→ack→升级→关闭）写入审计日志（审计 trail），接入 SIEM/日志平台；对「告警规则的变更」也要审计（谁在何时改了哪条规则）。落地时：① 告警明确的 ID 与时间戳；② 用事件流（如 systemd/journald、日志）记录状态变迁；③ 定期导出并归档；④ 对高敏感操作（如关闭告警、修改规则）加权限与审计。审计的价值是「责任可追溯、合规可证明、改进有依据」。

告警审计是「可追溯性」的保障。核心是「记录全生命周期状态变更 + 规则变更审计 + 保留与检索」。审计数据既是合规凭证，也是告警质量改进的数据来源。

• 告警策略的组成（触发、分级、路由、处理）
• 分级与路由的规则
• 处理规则与自动化

告警策略（alert policy）是「决定告警如何生成、如何流转、如何处置」的规则集合。应包含：① 触发条件——基于哪些指标、什么阈值、什么窗口触发告警（如「P99 延迟 > 500ms 持续 5 分钟」）；② 分级——按严重度（P1-P4）定义优先级，结合影响范围与紧急程度；③ 路由——告警分发给谁（按服务 owner、按值班轮换、按团队），按分级决定通知渠道（电话/IM/工单）；④ 处理规则——ack 时限、升级链、自动关闭、自动处置（如自动回滚）；⑤ 抑制与去重——维护窗口、重复告警合并、上游抑制。定义时需「可行动性」：每条告警都应能触发明确动作。示例：if (error_rate > 5% for 10m) then page (sev1) route(team-orders) auto_runbook(rollback)。策略通过 YAML 或 UI 声明式管理，纳入版本控制。

告警策略是「告警体系的规则引擎」，把「何时告警、告多严重、给谁、怎么处理」全部显式化。好的策略是「每个字段都有明确语义」，且可评审、可审计、可演进。

• 慢燃尽场景（低错误率但持续）
• 慢燃尽告警的窗口与阈值设计
• 与快速告警的区分

慢燃尽（slow burn）指「错误率不高（如 1x 燃烧率）但持续消耗错误预算」，短期内不触发紧急告警，但长此以往会耗尽预算。这类问题通常不是瞬时故障，而是「长期性能退化、渐进式错误、请求量突增下的持续失败」。设计慢燃尽告警：① 用长窗口（如 6 小时、3 天）观察平均错误率与燃烧率；② 阈值设为「燃烧率 ≥ 1x 持续一段时间」——即错误率达到目标错误率水平并持续，预示预算在该窗口内耗尽；③ 用「低优先级通知（ticket/工单）」而非 page，避免打断值班；④ 结合「预计耗尽时间」预警——如「按当前速率，预算将在 3 天内耗尽」时发工单。例：99.9% SLO 下，错误率持续在 0.1% 附近（燃烧率 1x），可用 3 天窗口的燃烧率告警 burn_rate >= 1 触发。与快速告警（14.4x page）区分：慢燃尽不紧急但需跟踪，快燃尽立即 page。

慢燃尽告警解决「温水煮青蛙」问题——错误率低但持续会耗尽预算。关键是「长窗口 + 1x 燃烧率阈值 + 低优先级通知」，把「长期消耗」与「急性故障」区分开，既及时预警又不打扰值班。

• 响应流程各环节（触达→确认→处置→升级→交接）
• 各环节的时限与动作
• 关键角色的职责

7x24 值班响应流程应「标准化、有时限、可升级」。流程：① 告警触达——监控系统按分级通过电话/IM/短信通知值班人员；② 确认（ack）——值班人员在时限内（如 5 分钟）确认告警，表示「已接手」；③ 评估分级——判断严重度、影响范围，决定是否升级；④ 处置——按 runbook 排查、修复、恢复；⑤ 升级——超过时限未解决或影响扩大时，按升级链升级到上级/负责人/管理层；⑥ 恢复与关闭——确认恢复后关闭告警、记录事件；⑦ 交接——值班结束或换人时，交接未完成事项。关键设计：各环节有明确「时限」（ack 时限、处置时限、升级时限），有「升级链」（L1→L2→L3），有「runbook 支撑」，有「记录审计」。落地时用值班工具（PagerDuty/Opsgenie）自动驱动流程，未 ack 自动升级，超时自动通知更高层级。

响应流程的骨架是「有明确时限的环节 + 自动升级」。7x24 的关键是「自动触达、按时确认、超时升级、完整交接」，把「人为判断」沉淀为「流程与工具」，保障任何时刻都有人响应。

• MTTA（确认时间）与 MTTR（恢复时间）的定义
• 采集方法与分位数统计
• 趋势分析与改进

MTTA（Mean Time To Acknowledge，平均确认时间）指「告警触发到值班确认」的时长；MTTR（Mean Time To Repair/Recover，平均恢复时间）指「告警触发到恢复」的时长。采集：由值班工具自动记录——告警触发时间戳、ack 时间戳、恢复时间戳，存入分析系统。统计：用分位数（P50/P90/P99）而非仅均值，因为均值被极端值拉高，分位数更能反映「典型确认/恢复耗时」。趋势分析：按周/月观察 MTTA/MTTR 的变化趋势，识别「是否变慢」；按服务/告警类型/时段细分，定位「哪些告警响应慢」。改进：① MTTA 过高 → 优化提醒渠道、减少误报、提升值班响应；② MTTR 过高 → 完善 runbook、优化自动化、缩短根因定位时间。落地时用 Grafana/仪表盘展示 MTTA/MTTR 分位数与趋势，建立「响应质量」的持续改进闭环。

MTTA/MTTR 是「响应质量与恢复质量」的核心指标。用分位数而非均值，才能反映真实分布；趋势分析才能发现「退化」。改进需区分「确认慢（MTTA）」与「恢复慢（MTTR）」的根因，对症下药。

• on-call SLA 的定义（ack 时限、响应时限）
• 监控与保障手段（工具、升级链、自动化）
• 达标与考核

on-call SLA 是对「值班响应速度」的承诺，通常定义为「在 X 分钟内确认告警（ack）」。例如「P1 告警 5 分钟内 ack、P2 15 分钟内 ack」。满足方法：① 工具自动化——值班工具（PagerDuty/Opsgenie）自动触达、记录 ack 时间、超时自动升级；② 分级通知——按严重度用不同渠道（P1 电话+短信、P2 IM），确保触达；③ 升级链——未按时 ack 自动升级到上级/下一班，保证「总有人响应」；④ 多级 backup——primary/secondary 双岗，primary 失联 secondary 接管；⑤ 监控考核——统计达标率（ack 时限内确认的比例），对未达标告警复盘（是工具问题还是人手问题）。设计时需「可达成」——SLA 时限应匹配轮值规模与工具的可靠触达能力，避免定得过紧导致永远不达标。落地时用「值班日历 + 升级策略 + 达标率报表」保障。

满足 on-call SLA 靠「自动化触达 + 升级链兜底 + 双岗备份 + 达标考核」。SLA 是「响应时限承诺」，需工具可靠、人手充足、升级链完备。考核达标率用于发现「响应瓶颈」。

• 班次长度（轮值周期）选择
• 时区覆盖（follow-the-sun）
• 交接流程与负载均衡

On-Call 轮换设计需平衡「覆盖、公平、健康」。① 班次长度——常见 1 周（周一至周日）好交接，或 1 天（高覆盖）。一周一值便于「交接 + 恢复」，但需「值班后休养」；一周连续高频值班负担重，可配合「值班后减负」。② 时区覆盖——多时区团队用 follow-the-sun 模式，让当地时区的人值班，避免夜间跨时区打扰；每个 region 有当地值班。③ 交接流程——明确交接文档、交接会、交接清单，确保连续性。④ 负载均衡（公平性）——按「被唤醒次数、MTTA、夜间打断次数」统计，轮换顺序公平，避免「总是同一人扛」；对节假日、夜间班次加权补偿。落地时用值班工具（轮转规则）自动维护排班，公平性通过「值班数据报表」持续监控与调整。

轮换设计的关键是「公平 + 健康 + 覆盖」。班次长度影响负担与交接，时区覆盖影响被打扰程度，负载均衡影响公平与士气。用数据驱动轮换（统计被唤醒次数），避免不公。

• runbook 的要素与质量
• 升级路径与 SOP 文档
• 文档的持续维护（版本、评审、更新）

值班制度文档化把「值班经验」沉淀为可执行的文档。内容：① runbook——针对具体告警/故障的处理步骤（症状、排查、修复、验证、回滚），要求「步骤清晰、可执行、含命令与验证」；② 升级路径——明确「什么情况升级、升到谁、如何联系」；③ SOP——常见场景（如备份失败、pod 重启）的标准处理流程。质量要求：runbook 必须「可执行、无二义、含验证点」，且「与实际系统一致」。维护机制：① 版本管理——文档入库（Git/Markdown），变更走评审；② 定期评审——告警/故障处置后复盘，更新 runbook 中过时/不全的步骤；③ 演练验证——通过故障演练验证 runbook 可用性，发现缺陷即修订；④ 关联——runbook 与告警关联（告警附 runbook 链接），值班者一键打开。落地时用「文档即代码」+ 告警系统关联，保证「值班时找得到、用得上、用得对」。

文档化的价值是「把经验变成组织能力」。关键是 runbook 的「可执行性」与「持续维护」——文档如果长期不更新，会与实际系统脱节而失效。通过「复盘更新 + 演练验证 + 版本管理」持续维护。

• 值班负担的数据指标（被唤醒次数、时长、夜间打断）
• 识别「负担不均」的方法
• 调整轮换策略（轮换顺序、补偿、双岗）

值班负担不均的识别依赖「值班数据」。指标：① 被唤醒次数（每人每班次数）；② 值班时长与处理时长；③ 夜间/节假日打断次数；④ 复杂事件处理数量。识别方法：用值班工具导出数据，按人统计上述指标，计算「方差/基尼系数」或对比「最高 vs 平均」，发现「总是同一人扛」——某些人承担了不成比例的高频/高难值班。修正：① 调整轮换顺序——让高频承担者轮空，按公平算法重排；② 双岗分担——primary/secondary 分担负载；③ 差异化补偿——对高负担班次（夜间、节假日）加权补偿；④ 提升自动化——降低整体告警噪音，减轻所有人负担；⑤ 负责人介入——对「顽固不公」需从上而下调整人员配置。落地时「值班月度报表」公开透明，让数据说话。

负担不均的核心是「数据驱动识别 + 策略调整」。没有数据，不公往往被忽视；有了数据，才能公平轮换、合理补偿。负担不均影响士气与健康，需持续监控。

• P1-P4 分级标准（影响范围、紧急程度）
• 各等级的响应时限与升级路径
• 分级的一致性与落地

告警分级（P1-P4）是用「影响范围与紧急程度」给告警定级，决定响应优先级与升级路径。常见定义：P1（Severity 1，严重）——核心业务完全不可用、大范围影响、数据丢失，需立即响应（如 5 分钟 ack），升级到管理层；P2（高）——部分功能受损、影响部分用户，需尽快响应（如 15 分钟），升级到团队负责人；P3（中）——非关键功能异常、低影响，需当天处理（工单），升级到专项 owner；P4（低）——轻微问题、无用户影响，需排期处理（工单）。制定标准时明确：① 影响范围（哪些用户/服务/数据受影响）；② 紧急程度（是否威胁业务、是否蔓延）；③ 响应时限（ack/响应时间）；④ 升级路径（何时升、升到谁）。分级需「一致且有据」——用「判断矩阵」将影响范围×紧急程度映射到等级，避免主观口径不一。落地时在告警规则中标注等级，值班工具按等级路由与升级。

分级是「把有限的响应资源投向最紧急的问题」。关键是「标准明确、可量化、一致执行」，用判断矩阵避免分歧。分级决定响应时限与升级路径，直接影响 MTTA。

• 去重的必要性（告警风暴）
• 指纹/标签合并策略
• 事件窗口与恢复事件关联

告警去重（dedup）解决「同一根因触发大量相似告警」的告警风暴。实现：① 指纹/标签合并——根据告警的「指纹（fingerprint）」（由标签、服务、规则、指标组合生成）识别重复告警：相同指纹的告警合并为一条，或「聚合」进已存在的告警并计数；② 事件窗口——在设定时间窗口（如 5 分钟）内多次触发的同一告警合并为一次，超过窗口再触发才生成新告警；③ 恢复事件关联——当「恢复事件」到达时，自动关闭该指纹对应的所有告警（而不是逐条关闭），并记录「持续时长」。落地时：PagerDuty 的 Alert Grouping、Alertmanager 的 group_by 都是按标签分组的去重；Grafana 用 group_wait/group_interval 控制窗口。设计要点：去重粒度要「不丢关键信息」——合并后保留「受影响实例数、首末时间、样本数」，供评估影响范围。

去重的核心是「按指纹识别同一事件 + 窗口合并 + 恢复联动关闭」。粒度选择是关键——过粗会合并不同根因，过细无法抑制风暴。去重后仍要保留「样本量」以评估影响。

• 告警质量的量化指标（响应率、误报率、告警/事件比）
• 主观噪音评分
• 用指标驱动告警治理

告警噪音的量化指标用于「客观评估告警质量」。① 告警响应率——有明确处置的告警占比，低说明告警无价值；② 误报率——触发后经核实无需处置的告警占比，高说明阈值/规则不当；③ 告警/事件比——每产生一次真实事件平均触发多少条告警，过大说明「告警风暴/重复」；④ 已确认但无价值的告警占比；⑤ 值班人员主观噪音评分——值班者给每条告警打「有用/噪音」标签，或对「被噪音打扰」打分，纳入主观维度。这些指标用于「告警治理」：高误报率调阈值/下线，高告警/事件比做去重，低响应率删除无行动告警。主观评分补充客观指标无法捕捉的「体验噪音」。落地时建立「告警质量评分卡」，定期评估并驱动规则优化。

量化噪音需要「客观指标 + 主观反馈」结合。客观指标（响应率、误报率、事件比）反映「告警与真实事件的关系」，主观评分反映「值班体验」。组合驱动告警治理，才能把噪音降到可控。

• On-call 健康度的量化指标
• 各指标的含义与采集
• 用健康度驱动制度改进

On-call 健康度衡量「值班对人员的负担与影响」，是防止「值班 burnout」的关键。指标：① 每班被叫醒次数——平均每班被打断的次数，过高说明噪音多或人手不足；② MTTA 分布——确认时间的分布，反映响应及时性；③ 夜间打断次数——凌晨时段的被唤醒次数，是「负担感」的核心，夜间打断多需优化轮换或告警；④ 值班后补休落实率——被唤醒后是否真正获得补休，反映制度是否落实；⑤ 值班时长/连续值班天数。这些指标用于「健康度评估」：夜间打断多 → 优化告警降噪或调整睡眠轮换；补休落实率低 → 加强制度执行；被叫醒次数高 → 告警治理或扩容人手。落地时用「值班健康度报表」月度回顾，把「健康度」纳入团队可靠性管理，避免「值班即透支」。

On-call 健康度是「人的维度」的可靠性指标，与「系统的维度」同样重要。通过「被叫醒、夜间打断、补休落实」等量化，识别并修正「高压值班」，保障值班人员的身心健康与响应质量。

• primary/secondary 双岗设计
• 轮值周期与人数计算
• 覆盖率与负担的平衡

On-call 轮换设计的核心是「在保证覆盖（365 天有人响应）与合理负担（不超负荷）之间取平衡」。① primary/secondary 双岗——primary 主责响应，secondary 作为 backup（primary 失联/超时未 ack 时接管），提高可靠性、分担压力；② 轮值周期——常见 1 周，也可 1 天（高覆盖）或 2 周（低负担）；③ 人数与频率计算——一天 24h 全年覆盖，若每周轮到一次，需要约「团队人数 / 每人可值班频率」：如 1 人每周 1 次，则需能覆盖 365 天需约 52 人×周；实际按「每人每 N 周值一次」反推需要人数。例如想让每人每 4 周值一次，则需「365/（4×7）≈ 13 人」。④ 覆盖与负担平衡——告警多时增加副班或缩短频率，告警少时延长周期；多时区用 follow-the-sun 减少夜间负担。落地时用值班工具自动排班，按「告警量、人数、时区」动态调整。

轮换的本质是「用多少人、多少频率、什么结构来覆盖全年」，并保证负担可控。双岗提升可靠性，频率与人数反推保证覆盖，时区与告警量决定频率。数值计算是「覆盖天数 / 周期 / 人数」的约束求解。

• shadow（观察）与 reverse-shadow（被观察）阶段
• 培训流程与评估
• 独立上值的准入条件

新人上值的 shadow/reverse-shadow 培训是「渐进式、有保护」的机制。阶段：① shadow（观察）——新人只观察资深值班者如何处理告警，理解流程、工具、runbook，不实际操作；② reverse-shadow（被观察）——新人实际处置告警，资深者在旁监督指导，出现问题时资深者接管；③ 独立上值——新人独立值班，但仍可随时求助资深者。每个阶段有「准入/退出」评估：shadow 阶段需熟悉 runbook 与流程；reverse-shadow 阶段需证明能独立处置常见告警；独立上值前需通过「场景演练」考核。设计要点：① 明确的阶段时长与评估标准；② 独立上值初期「降低风险」——可安排资深者作为 backup；③ 提供「求助通道」——新人值班时遇到不确定情况可快速升级。培训机制降低「新人直接上值导致事故」的风险，同时逐步建立信心。

shadow/reverse-shadow 是「学习-实践-独立」的渐进曲线，核心是「在保护下实践」。reverse-shadow 是「有监督的实操」，是「会」与「能独立」之间关键的一环。评估与求助通道保障独立上值的安全。

• 值班工具的核心配置（排班、通知、升级）
• 排班（rotation）与通知渠道
• 升级策略（escalation policy）

在 PagerDuty/Opsgenie 中配置 on-call 流程的核心是「排班（schedule）+ 升级策略（escalation policy）+ 通知」三件套。① 排班（rotation）——定义值班组（team）、轮换周期（如每周）、时区、参与人员与顺序，工具自动生成「谁在何时值班」的日历；② 通知——为每个服务/告警配置通知渠道（电话、短信、App push、邮件）与通知策略（按严重度分级）；③ 升级策略（escalation policy）——定义「告警发送给谁、超时未 ack 升级到谁」的多层链条，如 L1 值班 → 5 分钟未 ack 升级 L2 团队负责人 → 10 分钟升级 L3 管理层。落地步骤：创建团队 → 创建排班（加入成员、周期）→ 创建升级策略（关联排班与升级层级）→ 创建服务/告警规则（关联升级策略与通知渠道）→ 配置维护窗口与 override。配置后，告警按规则路由到当前值班者，超时自动升级，保障 7x24 响应。

值班工具把「排班、通知、升级」自动化。核心是「排班确定谁值班 + 升级策略确定如何兜底 + 通知确定如何触达」。配置要「分级、有升级链、有时限」，实现「总有人响应」。