警報和故障響應

（部分： 技術和基礎設施）

簡短摘要

強差分是違反用戶價值的信號，而不僅僅是「紅色度量」。對於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的熱時段，事件也會更少，更短，更便宜，發布也更可預測。