بازگشت و بازیابی ثبات

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

Rollback یک بازگشت مدیریت شده به آخرین نسخه پایدار با حداقل خطر از دست دادن داده ها و نقض SLO است. یک فرایند قابل اعتماد شامل: سیگنال های SLO، دروازه های روشن و معیارهای عقبگرد، یک مکانیزم سوئیچینگ (GitOps/Ingress/mesh)، یک طرح داده سازگار، پیکربندی های جداگانه/اسرار/کش ها، runabook و چرخه بهبود پس از حادثه.

1) چه زمانی به عقب برگردیم (معیارهای شروع)

دروازه SLO/کسب و کار: p95/99 بالاتر از آستانه، ↑ خطا نرخ، کاهش در پرداخت/نرخ تبدیل، افزایش در زمان PSP.
سیگنال های فنی: سقوط قلب، نشت حافظه، رشد صف، تخریب نشانه/ثانیه (LLM)، 5xx در لبه.
خطر داده ها: مهاجرت نادرست، ناسازگاری کپی ها، معاملات/پرداخت های یتیم.
ایمنی/PII: نشت مشکوک - بازگشت فوری/انزوا.

قانون: اگر معیارهای کلیدی 2 + خارج از آستانه> N دقیقه باشد، عقبگرد ایجاد می شود.

2) انواع رول بک

1. کاربرد: بازگشت ظروف/بسته به برچسب قبلی.
2. ویژگی: خاموش شدن فوری از طریق ویژگی flag/kill-switch.
3. مسیریابی - وزن را به نسخه پایدار (canary → stable) یا Blue → Green باز می گرداند.
4. پایگاه داده: بازگشت منطقی (جبران)، بازگشت مرحله ای از طرح ؛ PITR آخرین راه حل است.
5. زیرساخت: عقب نشینی آشکار/طرح Terraform ؛ بازگشت تنظیمات شبکه/WAF.
6. داده ها/کش/صف: تنظیم مجدد/ناتوانی/پخش پیام ها ؛ کش نسخه.

3) اصول معماری بازگشت امن

سازگاری طرح: گسترش → مهاجرت → استراتژی قرارداد (بازگشت بین گسترش و قرارداد امکان پذیر است).
وابستگی های جدا شده: اسرار/پیکربندی ها/کش ها/صف های جداگانه برای تجدید نظر.
عملیات idempotent: تکرار شروع مهاجرت و کار - امن است.
تغییر ناپذیری مصنوعات: تصاویر، نمودارها، اسکریپت های SQL - نسخه و امضا شده.
GitOps درست است: نسخه فعلی و مسیریابی به مخزن آشکار متعهد است.

4) مکانیک برگشت (Kubernetes/GitOps)

آرگو رول اوت (بازگشت وزن)

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: سوئیچ سریع پایدار است

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) بازپرداخت پایگاه داده و حفاظت از داده ها

• گسترش - اضافه کردن زمینه های جدید/شاخص ها، کد از طرح قدیمی و جدید پشتیبانی می کند.
• 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:'.
صف: احزاب/موضوعات با توجه به نسخه; پیام های بازپخش «از ایست بازرسی».
De-duplication/idempotency: کلید های idempotence برای پردازش مجدد بدون تکراری.

7) دروازه های SLO و چرخش خودکار

معیارهای: p95/99، نرخ خطا، اشباع (CPU/IO/GPU)، عمق صف، نشانه/ثانیه، تبدیل پرداخت.

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) Runabooks (playbooks)

الف) رشد پس از انتشار p99 و 5xx

1. توقف ترویج (یخ قناری/آبی سبز).
2. سودهی ترافیک به بازبینی پایدار.
3. بررسی ضربه کش/صف/تاخیر PSP.
4. حذف تشخیص: سیاهههای مربوط، پروفایل ها، نسخه های مشتری/طرح.
5. ارتباطات: ChatOps، کانال وضعیت، کارت حادثه.
6. شروع اقدام اصلاحی: وصله/رفع داغ/لغو ویژگی.

ب) خطای مهاجرت پایگاه داده

1. Freeze writes (فقط خواندنی، به طور خلاصه).
2. برگشت برنامه → نسخه پایدار (سازگار با طرح قدیمی).
3. اجرای دستنوشتۀ جبران/برگشت.
4. رکورد ذوب ؛ مشاهده رانندگی/اشتباهات.

ج) تخریب پرداخت (PSP)

1. تغییر مسیر PSP به مسیر قبلی.
2. نورد به عقب انتشار پردازش.
3. آشتی دادن تمام پرداخت در انتظار، تکرار با کلید idempoint.

D) LLM/توصیه ها کاهش می یابد

1. غیرفعال کردن مدل/پارامترهای جدید (پرچم ویژگی).
2. بازگرداندن نقطه پایانی/وزن قبلی ؛ پاک کردن نهانگاه بازنگری جدید KV.
3. نشانه ها را بررسی کنید، اولین نشانه تاخیر، سمیت.

9) ارتباطات و انتشار انجماد

پنجره یخ: پس از بازگشت - مکث انتشار به RCA/ثابت.
کانال واحد: به روز رسانی وضعیت، تاریخچه اقدامات، چه کسی چه کاری انجام داد.
سهامداران: محصول/CS/پرداخت/وکلا (در PII).

10) پس از حادثه: تجزیه و تحلیل و پیشگیری

RCA (بدون هزینه): علت ریشه ای، عوامل کمک کننده، چرا دروازه ها کار نمی کنند (اگر آنها).
اقدامات: تست های مهاجرت، محدودیت ها، دروازه های ویژگی، قابلیت مشاهده.
آستانه SLO: تنظیم اگر بیش از حد «نرم «/» سخت «.
مستندات: به روز رسانی runabooks، اضافه کردن هشدار، آموزش (روز بازی).

11) ابزار و قالب

GitOps: Argo CD/Flux - کامیت «بازگشت »/« بازگشت» با نسخه.
تحویل پیشرفته: Argo Rollouts/Flagger - توقف/رول بر روی معیارها.
لبه/ورود: مسیریابی وزن، مسیریابی کوکی، سوئیچ سریع.
پرچم ویژگی: rollout کسری، کشتن سوئیچ.
مهاجرت DB: mig-framework با بالا/پایین، خشک اجرا، throttling.
قابلیت مشاهده: داشبورد آماده «مقایسه انتشار» (پایدار در مقابل قناری).

12) چک لیست آمادگی برای عقب نشینی

1. مصنوعات نسخه شده و امضا شده (images/charts/SQL).
2. پیکربندی دو ریل/اسرار/کش/صف (پیشوندهای نسخه).
3. نمودار DB توسط گسترش → مهاجرت → قرارداد.
4. Canary و آبی سبز با دروازه های SLO و بازپرداخت خودکار منتشر می شود.
5. Runabooks برای سناریوهای کلیدی (پرداخت/DB/کش/LLM).
6. دکمه های ChatOps: «/rollback »، «/freeze»، «/promote ».
7. حسابرسی و ورود به سیستم: چه کسی، چه زمانی، چه چیزی برگشت خورد ؛ مصنوعات تشخیصی.
8. تمرینات بازی روز: شبیه سازی افت و بهبود.

9. برنامه ارتباطات تجاری و پشتیبانی

10. پایدار در مقابل جدید در یک صفحه.

13) ضد الگوهای

مهاجرت مخرب قبل از اینکه کد رول شود (بدون سازگاری با عقب).
کش های به اشتراک گذاشته شده/صف بدون نسخه → بازگشت کثیف.
No GitOps/Change History → ویرایش دستی به تولید.
آزادی قناری بدون دروازه/تله متری → تشخیص دیر.
Rollback بدون توقف و RCA → تکرار حادثه.
نظارت بر تنها معیارهای فنی بدون معیارهای کسب و کار (پرداخت/نرخ).
«اسرار مشترک» برای همه تجدید نظر ها، جداسازی حادثه دشوار است.

خلاصه

بازگشت قابل اعتماد یک «جرثقیل توقف» نیست، بلکه یک فرآیند ساخته شده در نسخه های منتشر شده است: نسخه و سازگاری، وابستگی های جداگانه، دروازه های SLO، واقعیت GitOps، بازگشت خودکار و runabooks روشن. این رویکرد اجازه می دهد تا سیستم عامل های iGaming به سرعت ثبات، به حداقل رساندن تلفات داده ها و درآمد را به دست آورند و هر حادثه را به یک منبع بهبود تبدیل کنند.