發行策略：藍綠色和金絲雀
（部分： 技術和基礎設施）
簡短摘要
藍綠色在兩個完整的堆棧（藍色/綠色）之間進行即時切換，並具有最簡單的回滾。金絲雀在SLO門控制（潛伏期，錯誤率，業務指標）下逐漸增加新版本的流量份額。對於iGaming來說，這是比賽和股票高峰期在沒有市區的情況下發布的一種方式，同時保持穩定的p99和質量。
1）什麼時候選擇
藍綠色-快速發布,最小難度,需要「雙重」群集/資源預算。適用於沒有復雜狀態遷移的API/前沿。
金絲雀-高風險發布（新漏洞，關鍵更改），允許「捕獲」1-5％的流量退化。它需要遙測和自動門。
2）建築原則
1.L7級路由：平衡器/Ingress/Service-mesh（加權流量模塊,Cookie/flag-routing）。
2.孤立的依賴關系：配置、ficheflagi、秘密、緩存-分開進行修訂。
3.數據兼容性：DB遷移向前兼容（expand→migrate→contract）。
4.可觀察性：度量/邏輯/預告片中的單個版本/標簽。
5.Autogates：比較p95/p99，error-rate，Business KPI；自動回滾。
3）藍綠色： 基本模式
線程
1.我們展開綠色（藍色的副本）→熱緩存/連接。
2.我們運行health/smoke測試。
3.將流量（DNS/LB/Ingress）切換到Green。
4.將Blue保持在「溫暖」狀態，直到窗口結束。
示例： 在Ingress級別切換（想法）
yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80優點/缺點
簡單回滾（返回Blue）。
可預測的發布時間。
需要重復資源。
沒有金絲雀測量的「大爆炸」風險。
4）金絲雀： 逐步建立
線程
1.影子流量運行（可選）→ 1%的實際流量→ 5% → 25% → 50% → 100%。
2.每個階段均采用SLO/業務指標。
3.退化-自動回滾和保存診斷工件。
示例： Argo Rollouts（片段）
yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100示例： Flagger+Istio/NGINX（想法）
yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke5）加熱和狀態管理
緩存/來源：加熱Redis/HTTP 緩存/CDN,準備用於DB/PSP的warm-pool連接。
ML/LLM/型號：權重/索引/積木，KV緩存，「熱身」的主要查詢。
文件/工件：靜態內容、模板、configs-提前提交到本地volume/sidecar。
Ficheflagi：在1-5%的受眾/細分市場上滾動，緊急殺人的可能性。
6）數據庫： 「expand → migrate → contract」戰略"
1.Expand：添加無用/新列/索引,支持兩個版本。
2.Migrate：代碼使用新方案；舊路徑仍然有效。
3.合同：完全展開後,我們刪除舊字段/索引。
在日誌中捕獲方案和客戶端的版本；所有的變化都是相等的。
對於嚴重的遷移-背景喬巴舞，throttling和「停止世界」窗口。
7）可觀察性和門戶（SLO/SLA）
SRE指標：p50/p95/p99，error-rate，saturation（CPU/GPU/IO），queue-depth，冷啟動時間。
業務指標：支付轉換，費率成功，退出時間（TTW），促銷響應。
內容質量/LLM：tokens/s，響應長度，毒性，RAG得分。
門戶：在超出門檻和/或下降「有用的指標」時自動晉級/回滾。
gate:
p95_latency_ms <= 250 error_rate % <= 1. 0 payment_conv >= baseline - 0. 3%
action:
promote rollback8）發行編排和與CI/CD的集成
GitOps：版本/重量更改-通過PR進入清單存儲庫。
自動反駁：在流量開始之前,smoke/e2e。
發布計劃：金絲雀臺階時間表，負責人，ChatOps頻道，回滾窗口。
工件存檔：路由configs，dashbords snepshots，比較指標日誌。
9）多區域與邊緣
順序：首先是「最不關鍵」的區域/ROR，然後是基本區域。
基於Latency的路由：關註本地SLO；不要無緣無故混淆流量。
DR願景：A地區的Blue可能成為B地區Green的DR站點。
10）安全性和合規性發布
簽名圖像/圖表，SBOM；驗證管理策略中的簽名。
秘密：只有外部經理；Blue/Green的獨立版本。
PII/區域性：不要通過「外國」地區帶走PII的流量；比較時掩蓋日誌。
審計：誰在宣傳哪些門工作，回滾在哪裏。
11）配置示例
NGINX： 加那利分公司Cookie/標題（想法）
nginx map $http_x_canary $canary {
default 0;
"1" 1;
}
upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }
server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}Feature-flag 「fractional rollout」（偽）
yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true12） Runbooks（典型腳本）
在繩索上增加p99：停止促銷活動→增加擊球/計時，通過旗幟關閉沈重的菲奇，→重新啟動部分墊子。
支付轉換率下降：比較PSP 路線/fichi,包括陰影成像,回滾到穩定。
DB遷移問題：凍結寫入流量、啟用只讀模式、回滾方案（如果可能）、緊急修補喬布。
PII事件：切斷金絲雀版本，重復秘密，報告和審計。
13）實施支票
1.定義策略：藍綠色在哪裏，金絲雀在哪裏；被認為是「關鍵的」。
2.配置加權路由（Ingress/mesh/路由器）。
3.確定SLO閾值門戶和自動回滾。
4.實施DB expand→migrate→contract；遷移測試。
5.啟用緩存/模型加熱和warm-pool連接。
6.輸入GitOps並記錄所有發布操作。
7.可視化指標比較（金絲雀vs穩定）。
8.玩遊戲日：模擬回滾/失敗門/DB問題。
9.記錄runbooks和「紅色按鈕」（kill-switch）。
10.按次序而不是同時安排多區域發布。
14）反模式
沒有門和遙測的金絲雀釋放→晚期降解檢測。
混合DB方案：在代碼解開之前破壞遷移。
Blue和Green的一個共享緩存/隊列沒有隔離→相互影響。
TTL低的DNS切換無需驗證-「翻轉」流量。
兩個修訂版的秘密/共鳴→復雜的回滾。
沒有影子/煙霧的散布流量是「大爆炸」的風險。
缺少kill-switch/feature-flag可快速關閉。
結果
Blue-green提供即時和簡單的切換,canary-管理風險和早期問題檢測。在iGaming中，兩種模式結合在一起：「尖銳」變化上的繩索+藍綠色作為基本機制，沒有中心。添加SLO門、GitOps、預熱、DB兼容性和依賴性隔離-即使在高峰期,發布也是可預測的,回滾速度很快,p99和業務指標也是穩定的。