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平台能够快速恢复稳定性，最大限度地减少数据和收入损失，并将每个事件转变为改进的来源。