Rolbacks和恢復穩定性

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

簡短摘要

回滾是最後一個穩定版本的托管回歸，數據丟失和SLO違規風險最小。可靠的過程包括：SLO信號，清晰的門和回滾標準，開關機制（GitOps/Ingress/mesh），兼容的數據電路，隔離的同源/秘密/緩存，runabook-i和事件後改進周期。

1）何時回滾（啟動標準）

SLO/商業門戶：p95/99高於門檻，error-rate ↑，支付/費率轉換下降，PSP時間表增加。
Techsignals： Pod Crash,內存泄漏,隊列增長,令牌/秒降解（LLM）, 5xx on Edge。
數據風險：不正確的遷移、副本不一致、定型交易/付款。
安全/PII：懷疑泄漏-立即回滾/隔離。

規則：如果2+關鍵指標超出閾值>N分鐘-則會觸發回滾。

2） Rolback類型

1.應用程序：將容器/數據包回滾到以前的標簽。
2.Fichi：通過feature flag/kill-switch即時關閉。
3.路由：將重量恢復為穩定版本（canary→stable）或Blue→Green。
4.數據庫：邏輯回滾（補償），逐步恢復計劃；PITR是極端措施。
5.基礎設施：回滾宣言/Terraform計劃；返回網絡/WAF配置。
6.數據/緩存/隊列：重置/殘疾/重播消息；保值緩存。

3）安全回滾的建築原則

電路兼容性：expand→migrate→contract策略（expand和合同之間可以回滾）。
孤立依賴：分離的秘密/密碼/緩存/審核隊列。
等效操作：重復啟動遷移和跳躍-安全。
工件的不可移動性：圖像，圖表，SQL腳本-轉換和簽名。
GitOps真理：當前版本和路由已提交到清單存儲庫中。

4）回滾力學（Kubernetes/GitOps）

Argo Rollouts（重量回報）

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: api }
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 10m }
in case of analysis failure → automatic rollback to stable

GitOps回滾（想法）

git revert <commit_with_bad_version>
git push # Argo CD/Flux revert cluster to previous revision

NGINX： stable上的快速卷軸

nginx map $cookie_canary $to_canary { default 0; 1 1; }
upstream stable { server api-stable:80; }
upstream canary { server api-canary:80; }
server {
location / {
if ($to_canary) { proxy_pass http://canary; }
proxy_pass http ://stable; # removed canary cookie - instant rollback
}
}

5） Rolback BD和數據保護

Expand → Migrate → Contract:

Expand：添加新字段/索引,代碼支持新舊模式。
Migrate：代碼開始寫入新方案，舊方案不會中斷。
合同：我們只有在穩定後才能刪除舊的合同。
PITR/snapshots：僅在無法進行邏輯補償時使用。
補償：單獨的腳本/喬巴語以更正插入/余額/付款。
僅讀窗口：當受到批評時,我們暫時阻止記錄以「凍結」狀態。

sql
-- expand
ALTER TABLE wallet ADD COLUMN bonus_balance NUMERIC DEFAULT 0 NULL;
CREATE INDEX CONCURRENTLY idx_wallet_bonus ON wallet(bonus_balance);

-- migrate in code, two-sided write
-- contract (after stabilization)
ALTER TABLE wallet DROP COLUMN legacy_bonus_balance;

6）回滾時的隊列和緩存

版本緩存：帶有版本前綴的密鑰（「v2：」）→安全共存。
殘疾：在回滾時-大規模清洗'v2：'，返回'v1：'。
隊列：分期/按版本排列；重新播放「來自檢查點」的消息。
去陽性/相等性：用於無雙重重復處理的相等性鍵。

7）SLO門和自動回滾

度量標準：p95/99，error-rate，saturations（CPU/IO/GPU），queue depth，令牌/秒，付款轉換。

if p95_latency_ms > 250 for 5m OR error_rate > 1. 5% for 3m OR payment_conv < baseline-0. 3%
then rollback release && open incident && freeze deploys

8）Runabuki（劇本）

A）發布後p99和5xx的增長

1.停止宣傳（冷凍金絲雀/藍綠色）。
2.Switch流量穩定修訂。
3.檢查高速緩存命中/隊列/PSP延遲。
4.刪除診斷程序：邏輯、配置文件、客戶端/圖形版本。
5.通訊：ChatOps，狀態頻道，事件卡。
6.開始糾正操作：修補程序/熱小玩意/取消小玩意。

B） DB遷移錯誤

1.Freeze writes（只讀，簡要）。
2.回滾應用程序→穩定版本（與舊方案兼容）。
3.執行補償/滾回腳本。
4.解凍記錄；觀察漂移/錯誤。

C）付款退化（PSP）

1.將PSP路由切換到以前的路由。
2.回滾處理版本。
3.核對所有未完成的付款，重復使用等效密鑰。

D）LLM/建議退化

1.禁用新模型/選項（功能標誌）。
2.帶回以前的endpoint/重量；清除新修訂版的KV緩存。
3.測試tokens/s，第一個令牌latency，毒性。

9）通信和凍結發布

Freeze Window：回滾後-暫停發布到RCA/fix。
單一渠道：狀態更新，行動時間表，誰在做什麼。
Stakholders：產品/CS/付款/律師（在PII下）。

10）事後事件： 審查和預防

RCA（無指控）：根本原因，為什麼門不起作用的因素的貢獻（如果不起作用）。
行動：遷移測試，限制，ficheflag門，可觀察性。
SLO閾值：如果過於「軟「/」硬」，則進行調整。
文檔：更新runabooks,添加Alerts,訓練（遊戲日）。

11）工具和模板

GitOps：Argo CD/Flux是帶有版本的「revert」/「rollback」 commit。
漸進式交付：Argo Rollouts/Flagger-按指標停止/回滾。
Edge/Ingress：重量路由、Cookie漫遊、快速卷軸。

Feature flags: fractional rollout, kill-switch.

DB遷移：帶有up/down，dry-run，throttling的mig框架。
觀察力：現成的「釋放比較」（stable vs canary）行列板。

12）回扣準備清單

1.已驗證和簽名的工件（圖像/圖表/SQL）。
2.雙軌configs/秘密/緩存/隊列（旋轉前綴）。
3.expand→migrate→contract DB計劃。
4.帶有SLO門和自動回扣的金絲雀和藍色綠色版本。
5.關鍵方案（付款/DB/緩存/LLM）的Runabooks。
6.ChatOps按鈕：'/rollback'，'/freeze'，'/promote'。
7.審核和邏輯：誰，何時，什麼時候回滾；診斷工件。
8.遊戲日訓練：模擬失敗和恢復。
9.與企業和sapport的通信計劃。
10.一個屏幕上的比較指標（stable vs new）。

13）反模式

分解代碼前遷移（沒有向後兼容性）。
共享緩存/無版本隊列→「臟」回滾。
沒有GitOps/更改歷史記錄 →「手動」編輯到插圖。
沒有門/遙測的金絲雀釋放→晚發現。
沒有凍結和RCA的回滾→事件的重播。
僅監控沒有業務指標（付款/費率）的技術指標。
所有修訂的「秘密共享」→很難孤立事件。

結果

可靠的後退不是停止起重機，而是版本中內置的過程：忠誠度和兼容性，孤立的依賴性，SLO門，GitOps現實，自動回滾和清晰的套件。這種方法使iGaming平臺能夠快速恢復穩定性，最大限度地減少數據和收入損失，並將每個事件轉變為改進的來源。