自動修復錯誤

1）宗旨和原則

目標：通過保留SLO、收入和合規性，減少MTTR，防止事件升級。

• SLO-first：只有在確認的錯誤預算威脅下才允許自動操作。
• 安全性優先：最小閃光燈,明確限制和taymbox。
• 可通過設計進行解釋：每個操作都是可理解和可審計的。
• 滾回準備：任何步驟都附有返回標準。
• 在風險較高的地方進行人間循環：P1臨界變化-通過雙重控制或IC/on-Coll確認（除非其他策略設置）。

2）術語

自動復制：對事件的軟件響應（警報/異常）而無需人工參與。
Guardrails：限制策略（閾值，持續時間，嘗試次數，暴露區域）。
Runbook-Action：具有前/後檢查和回滾的原子操作。
決策引擎：將事件映射到策略並觸發操作的服務。

3）解決方案架構

1.信號：SLO/burn-rate，KRI，合成，RUM，深度健康。
2.上下文相關性：發行版，fichflags，計劃工作，從屬提供商。
3.決策引擎：規則/策略（策略即代碼），影響和風險評估，場景選擇。
4.執行：runbook動作編曲器（等效性，帶抖動的retrai）。
5.控制：先驗者，後驗證者，時間框，回滾。
6.審核和可觀察性：活動預告片，成功指標，日誌（WORM/immutable）。
7.通訊：狀態頁面（通過Comms Lead），var室，劄幌宏。

4）政策和入學率（政策即代碼）

• Failover PSP:
• `allow if burn_rate(payments.auth) > fast && impact>threshold && psp_alt.healthy && within_limits("psp_reroute")`
• Degrade Non-Critical Features:
• `allow if p99(bet_settlement)>3x && queue_lag>limit && feature("replay_center").enabled`
• Autoscale by Lag:
• `allow if consumer_lag>target && cost_budget.ok && region_capacity.available`
• Block PII Exports:
• `allow if export_spike && no_ticket && data_class=PII -> action=block + notify(Compliance)`

每個策略都包含：條件，動作，限制（scope/時間/頻率），成功標準，回滾。

5）安全操作目錄（原子運行手冊操作）

付款：將流量切換到備用PSP/銀行；重新確定衛生×健康×交流的優先次序；包括簡化的3 DS；用噴射器提高中繼限制。
投註/遊戲：擴大投註者；啟用cache-warmup；暫時禁用非關鍵性仙女（動畫，輔助仙女）；啟用waiting-room/queue-page。
基礎架構：撤回降解實例（outlier檢測器），將流量疏散到鄰近的AZ/地區；增加池/配額；用lint檢查重新啟動竊聽器。
數據/隊列：重新分配批次；將消費者提升到cap；將讀取流量切換到健康的復制副本；啟用自適應軌道采樣。
安全/合規性：暫時阻止PII的出口，沒有滴答聲；加強推理的優勢限制；在敏感操作上啟用雙重控制。
Comm層：Comms Lead的自動狀態草案+升級插槽；在PSP降解時通知合作夥伴。

6）預審和後審定

• 檢查問題是否真實且新鮮（N到 M窗口；沒有Cylens/計劃工作）。
• 確保政策允許采取行動，並提供資源預算。
• 估算成本（FinOps）和合規約束。

• 確認burn-rate/度量的下降；記錄結果；根據條件安排返回（自動滾回）。

7) Rollback и “escape hatch”

在穩定度量並通過max-TTL動作時自動返回。
在var room中的IC/on call的回滾按鈕。
破玻璃僅用於緊急訪問；強制性後審計。

8）與Alerting和事件集成

任何自動動作都附在事件卡上：誰/什麼/何時/為什麼，結果，圖形引用。
尋呼機被靜音以進行重復，但不適用於失敗的自動偽造（升級）。
狀態頁面通過模板通過Comms Lead更新。

9）安全與合規設計

管弦樂隊的最低特權；每個動作/域的不同角色。
高風險的SoD和雙重控制：PSP路由，獎金限制，PII出口。
所有自動解決方案（包括輸入信號和策略版本）的WORM/immutable審核。
PII衛生：標簽和行為日誌中沒有個人標識符。

10）自動輪廓的可觀察性

度量標準：成功率動作,反應時間,回扣百分比,節省MTTR,影響SLO。
Traces：用於「信號 解決方案 操作 效果」 端到端跟蹤。
Logs：結構化,帶有policy_id、版本和前/後檢查。
Dashbords：Exec（對收入的影響/SLO），Ops（動作矩陣×域），FinOps（自動度量的成本）。

11）腳本示例（iGaming）

11.1 PSP降解（TR/EU）

信號：auth-success在PSP-1 10分鐘內↓了25%,覆蓋率超過30%的交易。
行動：將40%的流量重新分配給PSP-2/3；包括簡化的3 DS；用jitter提起X銀行查詢的轉發。
邊界：每個備用PSP的總流量不超過60％；TTL 45分鐘。
Rollback：在15分鐘內≥目標正常化的成功率。

11.2在投註設置中增加p99

信號：p99 「bet→settle」> 3 ×規範+消費者lag>閾值。
行動：從上限到上限；加熱系數緩存；暫時關閉「重播歷史記錄」。
Rollback： headroom> X和p99之後20分鐘。

11.3個副本DB落後

信號：replic-lag> N秒,lock-wait增長。
行動：將閱讀流量轉移到健康的復制品；啟用低優先級的throttling寫操作。
Rollback：在正常化錯誤和鎖定錯誤之後。

11.4 Spike PII出口產品

信號：導出率>基線× K,沒有滴答聲。
操作：導出塊,Compliance通知,啟用雙重控制。
Rollback：確認請求並關閉異常後。

12) KPI и KRI

MTTR↓自動模擬器起作用的事件。
TTD→Action：從檢測到執行操作的時間。
成功率動作和滾動率（低-好，如果不是由於誤報）。
假動作速率（沒有效果或具有負面影響的動作）。
SLO impact saved（分鐘/收入,避免罰款）。
Pager fatigue↓（相同/最佳SLO的手動尋呼機更少）。

13）實施路線圖（8至12周）

奈德。1-2：選擇3-5個高ROI腳本（PSP feilover, autoscale by lag, feature-degrade）；描述政策/限制/回扣。
奈德。3-4：實現動作編排器、秘密和角色,與事件平臺集成；增加可觀察性和審計性。
奈德。5-6：「影子」模式下的飛行員（僅模擬）→ A/B效果評估；然後包含在低覆蓋率插件中。
奈德。7-8：擴展腳本目錄（DB/緩存/隊列/前沿）,鏈接到狀態頁和Comms。
奈德。9-10：添加FinOps限制（成本/SLI）規則，為高風險引入雙重控制。
奈德。11-12：tabletop/chaos教學，KPI/KRI修訂，haidlines出版和課堂教學。

14）工件和模板

自動補救政策：條件，行動，限制，TTL，回滾，所有者，風險等級。
Runbook-Action Spec：預測、步驟、驗證、錯誤、監控、回滾邏輯。
改變控制：誰可以統治策略，公關評論，測試，diff和版本。
Evidence Pack：對SLO的記錄/說明/影響指標,後驗屍報告/審核。

15）反模式

「用癥狀治療」，不檢查原因，SLO →翻轉。
無回滾動作和TTL →凍結降解。
沒有guardrails的通用腳本→級聯故障。
缺乏策略審核和驗證。
忽略成本（沒有限制的汽車軌道）和合規性（PII導出）。
在P1風險中完全自治，沒有人類循環。

底線

自動錯誤修復是一個受控的輪廓：帶有guardrails的→策略的SLO信號→帶回滾的安全運行簿操作→可觀察性和審計→事件培訓。這種方法可測量地降低了MTTR，將收入保持在峰值中，並消除了電子呼叫的例行程序，同時仍符合安全和監管要求。