防止过量过剩

1）问题与目标

当系统发出过多的无关或不可操作的通知时，会发生警报。结果是忽略了分页，MTTA/MTTR的增长以及错过了实际事件。
目的：通过将信号绑在SLO和花花公子上，使信号稀有，有意义和可执行。

2）信号分类法（通道=后果）

Page（P0/P1）-唤醒人类；仅当现在需要手动操作并且有运行手册时。
Ticket（P2）-每小时/每天的异步操作；不叫醒，但在SLA上徘徊。
仅达什（P3）-观察/趋势而没有积极行动；不会产生噪音。
Silent Sentry-背景中的度量/审计（对于RCA/后验尸程序）。

3）设计"正确"的同行

• 目的/假设（我们保护：SLO，安全，金钱，合规性）。
• 触发条件（阈值，窗口，源法定人数）。
• Runbook/Playbook（简短的ID步骤+链接）。
• 所有者（命令/角色组）。
• 完成标准（何时关闭，自动修复）。
• 漏洞类（user-impact/platform/security/cost）。

4）以SLO为中心的监控

SLI/SLO →主要信号：可用性，潜在性，业务运营成功率。

• 简称：1小时预算的5% → Page。
• 长：6小时预算的2% →门票。
• 队列：按地区/提供商/VIP细分市场划分的差额-减少虚假的全球焦虑。

5）降噪技术

1.探头法定人数：只有在独立源（不同区域/提供者）的≥2确认问题时才会触发。
2.重复数据消除：分组相同的事件（aggregation keys： service+region+code）。
3.滞后/持续时间："在红色区域≥ N分钟"以过滤尖峰。
4.限额：最多X警报/小时/服务；超过时-一个页面+摘要。
5.Auto-snooze/智能抑制： T窗口中的重复警报 →转换为Ticket直到根消除。
6.事件相关性：一个"主警报"而不是数十种症状（例如，"DB不可用"会干扰来自微服务的5xx）。
7.窗口维护：计划工作会自动抑制预期信号。
8.Anomaly+guardrails：异常-仅作为Ticket，除非通过SLO信号确认。

6）路由和优先事项

优先事项：P0（Page，15分钟）、P1（Page，30分钟）、P2（Ticket，4-8小时）、P3（观察）。
路由快捷方式：service/env/region/tenant →对应的呼叫。
时间升级：5分钟内没有ack → P2 → Duty Manager/IC。
安静的时光：非关键性的夜晚；Page禁止P2/P3。
Fatigue策略：如果工程师>N Page/Shift-重新分配到P2,则会升级信号污染。

7） Alert质量： 安排

Actionability ≥ 80%：绝大多数分页导致运行簿行动。
False Positive ≤ Page信号的5％。
Time-to-Fix-Alert ≤ 7天-必须修复/删除有缺陷的警报。
Ownership 100%-每个警报都有所有者和存储库及其定义。

8）警报作为代码的生命周期)

1.创建公关（目标说明、条件、运行簿、所有者、测试计划）。
2.沙箱/影子：影子同行写成聊天/日志，但不写成分页。
3.金丝雀：受众人数有限,我们测量FP/TP。
4.Prod：包含从rate-limit+观察2-4周。
5.每周审查：质量指标，编辑/删除。
6.Deprekate：如果信号复制更高或不可操作。

9）成熟度量（在dashboard上显示）

按通话时钟（中位数/95 percentile）。
%actionable（有已执行的步骤）和false-positive rate。
佩奇周围的MTTA/MTTR和page→ticket比例（不得高）。
Top-talkers（产生噪音≥20％的服务/规则）。
要求时间到修复警报（从第一个FP到规则更改）。
Burn-rate coverage：在两个窗口中使用SLO Alert的服务份额。

10）"Alerts的卫生"支票清单"

• Alert与SLO/SLI或商业/安全相关。
• 有运行簿和所有者；指定了战争室的联系人和通道。
• 配置了两个窗口（短/长）和源的法定数量。
• 包括dedup，rate-limit，auto-resolve和auto-snooze。
• 在发布/迁移时指定窗口维护和支持。
• 通过Shadow/Canary；由FP/TP测量。
• 包含有关差分质量指标的报告。

11）迷你模板

Alert规范（YAML想法）

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

标准升级文本（用于减少噪音）

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12）过程： 每周"警报评论"

1.最高噪音规则（top-talkers）→正确/删除。

2.通过页面信号的FP/TP →调整阈值/窗口/法定人数。

3.频道降级的竞争者（Page→Ticket），反之亦然。

4."Time-to-Fix-Alert"状态-延迟升级到服务所有者。

5.检查SLO的覆盖范围以及是否存在运行手册。

13）与发行和运营的联系

发布注释会自动添加临时抑制。
更改窗口：在发布后的前30分钟,只有SLO信号。
花花公子包含"降级/抑制非官僚"的步骤，以专注于根。

14）安全和合规性

安全信号（黑客/泄漏/异常访问）-单独的通道，没有安静的时间。
所有压制/安静窗口的审核日志：谁,何时,为什么,截止日期。
关键警报的不变性要求（事件签名）。

15）反模式

"每个图形=alert" →雪崩。
销售中的阈值"！=0错误"。
一个探针/一个区域作为真理的来源。
没有运行簿/所有者的页面。
永恒的"临时镇压"没有最后期限。
"以后修补"有缺陷的Alertes-复制多年。
将发布噪音与生产事件混合。

16）实施路线图（4-6周）

1.库存：卸下所有的Alerta，放置所有者和渠道。
2.SLO内核：在关键服务中引入带有双窗口的burn-rate规则。
3.噪音控制：包括法定人数、滞后和限额,进行每周审查。
4.Runbook覆盖范围：用花花公子关闭100% Page信号。
5.Fatig policy：分页/班次限制,安静小时,负载重新分配。
6.自动化：警报即代码，影子/金丝雀，质量指标报告。

17）结果

沉默不是缺乏监控，而是与SLO和过程相关的定性设计信号。法定人数，双窗口，滞后和严格的路由使Alertes变得罕见，准确和可执行。团队睡觉，用户满意，事件得到控制。