警报和故障响应

（部分： 技术和基础设施）

简短摘要

强差分是违反用户价值的信号，而不仅仅是"红色度量"。对于iGaming来说，SLO门很重要（潜在性，可访问性，付款转换，时间到钱包），多燃烧规则，明确的呼叫角色，上报，聊天操作和运行手册。目的是快速看到偏差，告知那些能够修复的人，并记录知识，以便下次做出更快，更便宜的反应。

1）基本面： 从指标到行动

SLI → SLO →警报：可测量的质量→目标水平→"预算着火"条件。
Severity （SEV）：SEV1是关键（收入/GGR处于危险之中），SEV2是严重的，SEV3是中等的，SEV4是次要的。
Impact/Urgency：谁在受苦（所有/地区/tenant/频道），以及有多紧迫（TTW↑，p99↑，error-rate↑）。
Actionability：对于每个警报-一个特定的动作（runbook+所有者）。

2）信号分类

ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.

BusinessSLO：付款转换（attempt→success），时间到钱包（TTW），投注成功，游戏启动。
支付路线：PSP特定指标（定时/分段）。
正面/移动：RUM度量（LCP/INP），崩溃率，脚本合成（登录/存款/利率/输出）。

3）警戒政策： SLO和burn-rate

SLI/SLO示例

"payments-api" ≥ 99的可用性。9% / 30d p95 `/deposit` ≤ 250 ms / 30d

转化"payments_attempt→success" ≥基线− 0。3% / 24h

TTW p 95 ≤ 3分钟/24 h

Multi-window / Multi-burn (идея PromQL)

快速燃烧：5-10 ×的SLO违规比正常速度快（5-15分钟的Alert Page）。
慢烧伤：预算疲惫缓慢（1-3小时滴答作响+分析）。

yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }

4）降噪和信号质量

正确的真相来源：按集合来区分（记录规则），而不是沉重的"原始"表达。
重复数据消除：Alertmanager分组为"服务/region/severity"。
层次结构：首先是企业/SLI的同位素,下面是Technometrics作为诊断。
抑制：在计划维护/发布期间（注释），在上游事件中。
基数：不要在标注中使用"user_id/session_id"。
测试变量：定期"培训"触发器（检查通道，角色，runabook引用）。

5） Alertmanager： 路由和升级

yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack

receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"

inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]

想法：SEV=page → PagerDuty/SMS；剩下的是Slack/tiket。该抑制作用可抑制上方活性SEV的低水平"炒作"。

6）Grafana Alerting（作为涂料）

集中式警报规则（Prometheus/Loki/Cloud）。

Contact points: PagerDuty/Slack/Email, Notification policies per folder.

Silences：计划工作、迁移、发布。
带有自动屏幕截图的Snapshots进入柚木。

7）呼叫和"实时"过程

轮换：第一线（SRE/平台），第二线（服务所有者），第三线（DB/Payments/Sec）。
反应SLA：识别≤ 5分钟（SEV1），诊断≤ 15分钟，每15-30分钟通讯一次。
值班频道："#incident-warroom"，"#status-updates"（仅事实）。
Runbooks：每个alerta+快速命令ChatOps（'/rollback'，'/freeze'，'/scale'）中的链接。
培训焦虑：每月（检查人员，渠道，runabook相关性）。

8）事件： 生命周期

1.细节（警报/复制/合成）→ Acknowledge呼叫。
2.三位一体：定义SEV/受影响/假设，打开战争室。
3.稳定：卷轴/回滚/缩放/ficheflagi。
4.通讯：状态模板（见下文）,ETA/下一步。
5.关闭：确认SLO恢复。
6.事后评论（RCA）：24至72小时，无指控，行动项目。

• 什么被打破/谁受到影响（区域/tenant/频道）
• 何时开始/SEV
• 临时措施（mitigation）
• N分钟后下一次状态更新
• 联系人（事件经理）

9）iGaming特点： "疼痛"区域和Alerta

Payments/TTW：PSP计时器的份额，代码故障增加，TTW p 95> 3m。
锦标赛高峰：p99 API/游戏开始时间/queue lag；限额/自动滑道的宣传。
资金调查结果：反式/手动检查SLA，国家限制。
游戏提供商：工作室的可用性、会话初始化时间、发布时间下降。
RG/Compliance：冗长会话/"dogon"激增，超出阈值不是page，而是ticket+通知RG团队。

10）规则示例（可选）

p95的高潜伏性（API）

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"

引线队列"燃烧"

promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"

付款转换已下降

promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"

11） ChatOps和自动化

自动定位带有动作按钮的警报： 停止金丝雀、滚回、Scale+N.

命令缩写： '/incident start'、'/status update'、'/call '、'/grafana '

机器人拉动上下文：最新的deploi，依赖图，trace示例（exemplars），相关的tikets。

12）事后工作（RCA）

事实：看到的/尝试过的，有用的时间线。
根原因：技术和组织原因。
Detections&Defenses：哪些信号帮助/失败。
行动项目：具体任务（SLO/Alerta/代码/限制/测试/runabook）。
Due dates&owners：时限和责任；2-4周后倒闭。

13）实施支票

1.定义关键线程的SLI/SLO （API/Payments/Games/TTW）。
2.配置记录规则和多烧伤Alerta+Alertmanager路由。
3.键入具有旋转、SLO反应和升级的呼叫。
4.将Alerta带到runbooks和ChatOps命令。
5.配置抑制/安静的窗口、发布/工作注释。
6.做训练焦虑和游戏日场景（PSP下降，p99上升，queue lag上升）。
7.测量警报质量：MTTA/MTTR,% noisy/false, SLO覆盖。
8.定期RCA和阈值/流程修订。
9.输入与业务/sapport的状态通信（模板）。
10.将所有内容记录为代码：规则、路由、runabook链接。

14）反模式

在"每个度量标准"→ alert-fatig，忽略。
没有SLO →不清楚"规范"和"燃烧"。
没有抑制/抑制→重复雪崩。
佩奇晚上参加次要活动（SEV与Impact不匹配）。
Alerts没有运行簿/所有者。
没有ChatOps/审核的"手动"操作。
没有RCA/Action items →重复事件。

结果

警报和响应是一个过程，不是规则集。将SLO与多燃烧器相连，建立清晰的呼叫升级，添加ChatOps和实时runabuk-i，定期进行RCA和培训培训。然后，即使在iGaming的热时段，事件也会更少，更短，更便宜，发布也更可预测。