通知和警报系统
（部分： 业务和管理）
1）任命和原则
目标是很少但恰当地传递信号：只有相关信号，及时负责的人/机器人，可以理解下一步。
原则：- 默认可操作：每个警报具有所有者，优先级，反应截止日期和动作按钮。
- SLO-first：Alerts是围绕SLI/SLO而不是任意指标构建的。
- 噪音控制：祖先，相关性，风暴抑制。
- Context-rich：元数据（区域，tenant，版本，trace_id）和指向runbook的链接。
- 试用就绪：所有异形和反应都被握住并保存在不变的日志中。
2）信号源
那些。遥测：可用性,p95/p99, error-rate,排队,资源限制。
业务活动：PriceMismatch，WebhookLag，RTP Drift，frod信号。
安全/合规性：SoD违规、PII访问、密钥/证书行使。
调度程序：过期任务SLA, DLQ雪崩,retry-storms。
3）分类和优先事项
Guardrails： Alerts是根据SLO/错误预算 （burn rate）制定的。
4）漫游和升级24 × 7
上下文漫游："region/tenant/product/provider/severity"。
升级楼梯：通话工程师→团队领导→ Duty Manager → Exec/Legal（用于PII/财务）。
职责：按角色轮换（SRE，App，Data，Security，Payments），备用联系人（聊天/语音/SMS）。
沉默窗口：夜间，发布和营销；P1的例外情况。
5）降噪和相关性
重复数据消除：通过'（fingerprint, region, tenant, route）'和'trace_id'。
"风暴"抑制：在活动的P1下暂时抑制重复。
相关性：围绕根原因分组信号（发布/信息/提供程序）。
滞后：进出阈值不同，避免"锯"。
6） Alerta内容（模板）
标题：简短而实质-"EU/Checkout：p95> 250 ms（SLO突破）"。
关键字段：优先级，时间，区域，tenant，版本，trace_id，affected％，*。原因。
现在该怎么办：前1-3步+链接到runbook/按钮 （Re-route, Rollback, Pause Promo）。
以下沟通：N分钟后,所有者（IC/上通话）。
7）送货渠道
聊天/信使：三重奏的主要通道（带按钮的机器人卡）。
寻呼机/语音/SMS：用于P1。
邮件：报告和非urgent （P3/Info）。
Webhooks：与tiketing/编排器集成。
状态页面：客户和合作伙伴的外部通知。
8）集成和"动作按钮"
事件机器人：创建卡片,指定IC,打开视频邮件,计时器开始。
Руны (auto-actions): Re-route, Rollback, Raise Limit, Flush Cache, Disable Webhooks, Enable Safe Mode.
权利：运行符文仅限于角色；所有活动都是签名和合成的。
9）多区域和多区域
按地区分列的独立SLO/阈值；当地事件不会"染色"整个世界。
可见性过滤器：合作伙伴/tenant只看到自己的。
管辖要求：通知文本、语言、时区。
10）政策,时间表,沉默的窗口
Alert策略：所有者，阈值，通道，上报，模式。
日历：工作时间/非工作时间、发布/营销窗口。
Change freeze：在大股期间放宽门槛或"非P1"镇压。
11）审计和法律记录
收据：对于关键标记-"receipt_hash"和DSSE签名。
WORM日志：事件和反应的不变存储（已确认已完成）。
定制链：跟踪升级和解决方桉。
12）通知系统的度量和SLO
MTTA（acknowledge）：P1 ≤ 5-10分钟；P2 ≤ 30分钟。
Page rate/On-call load：换用信号-在目标范围内。
False Positive%：目标阈值≤（通常小于10-15%）。
矫正效应：分组信号的比例≥ 80％。
Delivery SLO： Chat ≥ 99.9％，SMS/语音 ≥ 99。5%.
时间到动作：p95从警报中启动符文。
13）Dashbords和记者
操作：活动事件,burn-rate, 区域/tenant地图,Alert队列。
Alert的质量：噪音，FP，急流检查，"无声区域"。
呼叫负载：分页频率，反应时间，"超时"。
事后事件：符文效率，原因重复性。
14） iGaming/fintech特点
Payments/PSP：P1-提供商故障，授权故障增加；备用PSP上的自动路由。
RTP和极限：观察到的RTP漂移，超过极限，可疑的获胜模式。
会员/webhooks：交货时差，双倍增加，确认收据下降。
Price/FX/Tax：vitrina↔checkout不匹配，工件版本不一致。
负责任的游戏：RG触发器及其及时升级以支持/合规性。
15) RACI
16）实施支票
- 确定北极星和SLI/SLO；将Alertes与burn-rate相关联。
- 输入策略目录：阈值、通道、升级、静默窗口。
- 实现滞后、相关、滞后、风暴抑制。
- 配置多区域和多能见度规则。
- 连接"动作按钮"和runbooks；限制启动权限。
- 启用WORM/收据、 trace_id跟踪和运行审核。
- 构建质量仪表板（noise，FP，MTTA，page rate）。
[] Провести GameDay: PSP outage, WebhookLag, PriceMismatch, RTP Drift.- 定期审查门槛；A/B阈值在"无声"度量上。
- 每月通话负荷和改进报告。
17）花花公子（参考书）
PSP Outage （P1）：自动预订、降低客户时间、隔离"灰色"交易、15分钟后升级状态。
WebhookLag （P2）：增加锻炼者/训练营,优先排队,暂时暂停可选的残局。
PriceMismatch （P1/P2）：高速缓存强制失效、'fx_version/tax_rule_version'对账、工件回滚、补偿。
RTP漂移（P2）：奖金/促销暂停、配置文件审核、监视窗口扩展。
安全：SoD/MFA失误（P1/P2）：在需要时锁定操作，JIT检索，forenzik和法律。
18) FAQ
如何减少误报?
针对SLO的规则，相关性，滞后性，培训窗口和定期检修阈值。
更重要的是-覆盖范围或准确性？
对于P1，精度和速度（更小但更关键）。对于P3，涵盖趋势和成本。
需要电话分页吗?
是的，对于P1；聊天可能不可用或"溷淆"。
如何不"燃烧"呼叫团队？
页数限制，负载重新分配，"follow-the-sun"，月度轰鸣。
摘要：通知和警报系统是从信号到动作的受控管道。在SLO上构建它，消除噪音，通过上下文进行路由，让我们操作按钮并合法捕获所有内容。这就是您减少MTTA，减轻呼叫负荷并提高业务可持续性的方式，即使提供商出现尖锐的激增和故障。