通知和警報系統
（部分： 業務和管理）
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，減輕呼叫負荷並提高業務可持續性的方式，即使提供商出現尖銳的激增和故障。