استراتژی های بازگشت و انتشار اتمی

استراتژی های بازگشت و انتشار اتمی

1) چرا شما نیاز به بازگشت سریع دارید

• MTTR را به چند دقیقه کاهش دهید.
• محدود کردن شعاع تاثیر (حداقل کاربران/معاملات تحت تاثیر قرار).
• حفظ یکپارچگی داده ها و سازگاری قرارداد.

کلید: ساخت نسخه ها، بنابراین بازگشت یک اقدام بی اهمیت است، نه یک مینی پروژه.

2) مفهوم «انتشار اتمی»

انتشار اتمی - زمانی که گنجاندن یک نسخه جدید/رفتار را می توان انجام (و لغو) توسط یک عمل اتمی بدون عوارض جانبی پایدار.

• مصنوعات غیر قابل تغییر (تصویر/بسته امضا شده).
• تنظیمات نسخه شده (نسخه های ارتقاء، نه ویرایش دستی).
• جداسازی «تحویل» از «گنجاندن» (مسیریابی/پرچم).
• طرح داده سازگار (هر دو نسخه می توانند به طور همزمان زندگی کنند).
• Runbook Rollback: یک مرحله روشن (تغییر انتخاب/وزن/پرچم) + بررسی.

3) موجودی ماشین آلات رول بک

3. 1 لایه ترافیک (سریعترین)

آبی-سبز: انتخابگر گروه/هدف را به نسخه پایدار تغییر دهید.
قناری: وزن را به 0٪ کاهش دهید و پیشرفت را متوقف کنید.
Gateway/NGINX/Service Mesh: بازگشت به وزن/مسیرهای قبلی.

3. 2 سطح نوار نقاله

Helm/Argo Rollouts: 'لغو/بازگشت' به نسخه قبلی.
GitOps: بازگشت MR/commit به مخازن آشکار (کنترل بقیه را انجام خواهد داد).

3. 3 ضمیمه/ویژگی ها

Feature-flags/kill-switch: بلافاصله مسیر خطرناک را خاموش کنید.
Toggle configs: بازگشت به عکس پیکربندی قبلی.

3. 4 داده ها

مهاجرت رول به جلو (ترجیح داده شده) + سازگاری.
بازیابی نقطه در زمان (PITR) و پشتیبان گیری برای حوادث.
جبران خسارت (Saga) و idempotency برای اقدامات برگشت پذیر.

4) «گسترش → مهاجرت → قرارداد» الگوی

برای بازگشت امن، طرح داده باید اجازه دهد نسخه های قدیمی و جدید به همکاری زندگی می کنند.

1. گسترش - اضافه کردن زمینه های جدید/شاخص (nullable) بدون شکستن منطق قدیمی.
2. مهاجرت - دو نوشتن/خواندن، پر کردن، کارهای پس زمینه با idempointency.
3. قرارداد - پس از خروج 100٪ و پنجره پایدار، فیلدها/کد های قدیمی را حذف کنید.

5) SLO دروازه و بازگشت خودکار

ورود به هر مرحله انتشار باید توسط معیارها «محافظت» شود.

SLO های فنی: تاخیر p95/p99، نرخ 5xx، اشباع (CPU/حافظه)، سوزاندن خطا بودجه.
معیارهای کسب و کار: CR برای سپرده/cashout، انکار پرداخت، درصد تقلب، خطاهای KYC.

• 5xx> 0 5% 10 دقیقه → عقبگرد.
• p95 ↑> 20٪ از خط پایه → نگه دارید + تجزیه و تحلیل.
• خطای PSP> 0. 3 پی پی → بازگشت + تغییر مسیر پرداخت.

6) نمونه: Kubernetes/هلم/آرگو/NGINX

6. 1 آبی سبز (انتخاب خدمات K8s)

yaml
Service points to "blue"; switch to green - change selector apiVersion: v1 kind: Service metadata: {name: app-svc}
spec:
selector: { app: app, version: blue }
ports: [{ port: 80, targetPort: 8080 }]

Rollback = بازگشت انتخابگر به 'آبی' (اتمی، بدون مونتاژ مجدد).

6. 2 قناری (веса مجازی Istio)

yaml http:
- route:
- destination: { host: app, subset: stable } # 100 weight: 100
- destination: { host: app, subset: canary } # 0 weight: 0

Rollback = قناری وزن → 0, پایدار → 100.

6. 3 آرگو رول اوت - سقط جنین

yaml kubectl argo rollouts abort app # stop and return to stableService

6. 4 هلم - بازگشت به بازنگری

bash helm history app -n prod helm rollback app 17 -n prod # revert to revision 17

6. 5 NGINX - وزن بالادست

nginx upstream app {
server blue:8080 weight=100;
server green: 8080 weight = 0; # rollback - return 100/0
}

7) ویژگی های پرچم و کشتن سوئیچ به عنوان یک «چتر نجات»

کشتن سوئیچ برای جریان های با ریسک بالا (سپرده/پرداخت/پاداش) - اجباری.
چسبندگی: اختصاص دادن کاربران «نوع» از طریق یک کلید هش - مقایسه قابل پیش بینی است.
Fail-safe: اگر سرور پرچم در دسترس نیست، به طور پیش فرض امن است.

ts const enabled = flags. bool("new_cashout_flow", false);
if (! enabled) return classicFlow () ;//instant rollback - disable the return newFlow () flag;

8) API و رویداد قرارداد: چگونه به «شکستن عقبگرد»

قراردادهای نسخه بندی (OpenAPI/gRPC/Avro): نسخه جدید فیلدها را اضافه می کند، معانی قدیمی را تغییر نمی دهد.
Event-versioning: 'type = v2'، مصرف کنندگان باید فیلدهای ناشناخته را نادیده بگیرند.
Outbox + Idempotency: هر تکرار رویداد امن است، مصرف کننده idempotent است.

9) معاملات افست (حماسه)

• ارسال شده - جبران خسارت: بازگشت، معکوس، رکورد اصلاح.
• ضبط در مجله عملیات جبرانی و retractions قبل از موفقیت.
• کلید های idempotent برای هر عملیات.

json
{
"sagaId": "b7d2...",
"action": "withdraw. execute",
"idempotencyKey": "user123:withdraw:7845",
"compensation": "withdraw. refund"
}

10) پیکربندی و اسرار: بازگشت به عنوان نسخه

پیکربندی فروشگاه به عنوان مصنوعات نسخه (semver/commit-sha).
Rollback = پیکربندی را به نسخه قبلی برگردانید (GitOps revert)، نه «با دستان خود اصلاح کنید».
اسرار - از طریق ذخیره سازی (KMS/Vault) ؛ چرخش و نسخه بندی در انتشار گنجانده شده است.

11) Rollback runbook (حداقل)

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

12) سیاست های خودکار محافظت

ممنوعیت «آخرین» و برچسب های قابل تغییر برای تصاویر.
کنترل پذیرش: فقط مصنوعات امضا شده.
دروازه CI: SAST/SCA/سیاست چک باید سبز برای ارتقاء باشد.
پنجره های یخ زده: بدون انتشار/وزن> X٪ در طول دوره های خطر.

13) ضد الگوهای مکرر

ما «رول» پایه DDL به جای سازگاری - قفل طولانی/خرابی.
مهاجرت سر به سر فوری بدون idempointency و بازگشت پر کنید.
مخلوط کردن «تحویل» و «گنجاندن» - هیچ راهی برای بازگشت سریع ترافیک وجود ندارد.
ویرایش دستی در پیکربندی تولید بدون حسابرسی.
بدون سوئیچ در پرداخت/خروجی.
بازسازی مصنوع برای prod (نقض «ساخت یک بار - اجرای بسیاری»).
هیچ دکمه بازگشت/runbook کار نمی کند وجود دارد.

14) چک لیست پیاده سازی (0-45 روز)

0-10 روز

شامل آبی سبز/قناری در خدمات کلیدی.
«آخرین» را انکار کنید، امضای تصویر و تاریخچه هلم/آرگو را فعال کنید.
اتصال تخته SLO (تاخیر، 5xx، سیگنال های کلیدی کسب و کار).

11-25 روز

پیاده سازی سوئیچ کشتن برای جریان خطر.
تبدیل مهاجرت پایگاه داده به expand-migrate-contract + idempopotency.
اضافه کردن خودکار توقف/بازگشت توسط SLO (Argo AnalysisTemplate/alerts).

26-45 روز

پیکربندی نسخهبندی) GitOps (، برگشت از طریق MR-برگردان.
Runbook را به «game-day» (شبیه سازی حادثه و برگشت) اجرا کنید.
جبران حماسه را وارد کنید که در آن برگشت به پایین امکان پذیر نیست.

15) معیارهای بلوغ

MTTR برگشت: هدف <5 دقیقه.
٪ از نسخه های که در آن بازگشت = سوئیچ مسیر/پرچم (بدون بازسازی)> 90٪.
سهم مهاجرت های گسترش-مهاجرت-قرارداد> 90٪.
پوشش خدمات kill-switch با پرچم> 95٪.

تعداد رخدادهای ناشی از طرحها/قراردادهای ناسازگار → 0

16) برنامه های کاربردی: مینی قالب

Argo AnalysisTemplate توقف 5xx

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: guard-5xx }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

Kubernetes: بازگشت سریع استقرار

bash kubectl rollout undo deploy/app -n prod

هلم: انتشار اتمی

bash helm upgrade --install app chart/ \
--atomic \
--timeout 5m \
--set image. tag=v1. 9. 3

NGINX: جرثقیل قناری

nginx map $cookie_canary $weight {
default 0;
"~ on" 10; # enable 10% by cookie
}

17) نتیجه گیری

بازگشت قابل اعتماد یک «دکمه آتش» نیست، بلکه یک ویژگی معماری است: مصنوعات غیر قابل تغییر، جداسازی تحویل و گنجاندن، طرح داده سازگار، پرچم های ویژگی و دروازه SLO. ساخت نسخه های اتمی، تمرین runbook و خودکار دروازه های امنیتی - و هر گونه انتشار در عرض چند دقیقه قابل برگشت خواهد بود، بدون درد برای کسب و کار و کاربران.