استقرار صفر خرابی

(بخش: معماری و پروتکل ها)

1) Zero-Downtime چیست و چرا مورد نیاز است

• خرابی صفر برای مشتریان و ادغام.
• انتشار قابل پیش بینی، بازگشت سریع و ریسک قابل کنترل.
• حفظ SLO/SLI (تاخیر، خطاها، در دسترس بودن) در مرزهای توافقنامه.

کلید ZDT یک تکنیک «جادویی» نیست، بلکه ترکیبی از الگوهای تحویل، سازگاری داده ها و مسیریابی ترافیک صالح است.

2) اصول اساسی صفر خرابی

1. سازگاری نسخه: نسخه های جدید و قدیمی باید همزمان ترافیک و داده ها را به درستی اداره کنند.
2. عدم توانایی عملیات: بازفرآوری نباید دولت را بشکند.
3. خاموش شدن و تخلیه اتصال.
4. بررسی سلامت گام به گام: آزمون آمادگی/زندگی، نقاط پایانی سلامت.
5. بازگشت به عنوان شهروند درجه اول: بازگشت آسان تر و سریع تر از hotfix است.
6. قابلیت مشاهده توسط طراحی: علائم انتشار، داشبورد تک، هشدارهای SLO.
7. اتوماسیون: سناریوهای انتشار و برگشت کد هستند، نه دستورالعمل های دستی.

3) الگوهای تحویل بدون خرابی

3. 1 به روز رسانی نورد

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

مزایا: اقتصادی در زیرساخت، فقط در k8s/ASG.
منفی: برای برخی از زمان خوشه با دو نسخه در همان زمان کار می کند (نسخه انحراف).

3. 2 آبی سبز

دو طرفدار کامل: فعال (آبی) و نامزد (سبز). سوئیچینگ ترافیک - تلنگر اتمی.

مزایا: بازگشت فوری، انزوا تمیز.
معایب: هزینه های زیرساخت های ↑، سخت تر با stateful.

3. 3 قناری/برنامه ریزی پیشرفته

ما سهم کوچکی از ترافیک (1-5-10-25-50-100٪) را به نسخه جدید با دروازه های متریک می دهیم.

مزایا: حداقل شعاع انفجار، راه حل های مبتنی بر داده ها.
منفی: نیاز به مشاهده بالغ و مسیریابی هوشمند.

3. 4 ترافیک سایه/راه اندازی تاریک

درخواست های واقعی را به نسخه جدید (بدون پاسخ به کاربر) ارسال کنید یا برای جمع آوری معیارها پنهان کنید.

مزایا: شناسایی زودهنگام مشکلات.
منفی: دو بار در اعتیاد، شما نیاز به کنترل عوارض جانبی.

4) مدیریت ترافیک و اتصال

4. 1 آمادگی/زنده بودن

Liveness می گوید ارکستر به «راه اندازی مجدد من».
آمادگی: «ترافیک را هدایت نکنید، من هنوز آماده نیستم».
نمی توان بدون منطق آمادگی صحیح و زمانبندی منتشر کرد.

4. 2 زهکشی اتصال

• پذیرش ارتباطات جدید را متوقف کنید
• در انتظار پایان فعالیت،
• وقفه «آویزان» را قطع کنید.

4. 3 جلسه چسبنده و مسیریابی L7

چسبنده برای سناریوهای حالت دار مفید است، اما تعادل بار را پیچیده می کند.
قوانین L7 (مسیر، هدر، کوکی، نسخه های API) برای canary/ring مناسب هستند.

4. 4 اتصالات طولانی مدت

جریان WebSocket/gRPC: قبل از به روز رسانی، حالت تخلیه + سیگنال «GOAWAY» را روشن کنید.
پنجره ها را برای غلبه بر جریان ها و backhoe مشتری برنامه ریزی کنید.

5) سازگاری داده ها و مهاجرت پایگاه داده

5. 1 گسترش-مهاجرت-قرارداد

1. گسترش: اضافه کردن ستون های جدید/شاخص/جداول بدون شکستن نسخه قدیمی.
2. مهاجرت: ما انتقال داده ها در پس زمینه و idempootently (دسته، ایست بازرسی).
3. قرارداد: حذف قدیمی تنها پس از تثبیت.

5. 2 شیوه ها

اجتناب از قفل DDL منحصر به فرد در پنجره انتشار.
قراردادهای نسخه بندی API/رویداد (رجیستری طرح، CDC).
برای مهاجرت های سنگین - ابزارهای آنلاین، کپی، سوئیچینگ مرحله ای.
نوشتن دوگانه فقط با deduplication و مصرف کنندگان idemotent.
صندوق ورودی/صندوق ورودی برای ادغام قابل اعتماد از طریق صف.

6) کش ها، جلسات و کارهای پس زمینه

جلسات و حافظه پنهان خارجی هستند (Redis/Memcached) به طوری که نسخه ها قابل تعویض هستند.
گرم کردن کش/jits/سرعت شاخص قبل از جمع آوری.
تقسیم صف پس زمینه توسط نسخه و یا استفاده از رهبری برای جلوگیری از مسابقه.

7) قابلیت مشاهده و دروازه های SLO

سیگنال های طلایی: تاخیر p95/p99، میزان خطا، RPS، اشباع، تاخیر صف.
SLA کسب و کار: مجوز، تبدیل، پرداخت موفق، امتناع از مراحل قیف.
گیتس: راه اندازی تنها در صورتی ترویج می شود که canary ≤ baseline + آستانه تخریب، و بودجه خطا از بین نمی رود.

8) تکمیل و بازگرداندن ایمن

Rollback همان خط لوله است، فقط در جهت مخالف: دستورات ثابت، نه «کرافت دستی».
برای آبی سبز - تلنگر به عقب ؛ برای قناری - کاهش وزن به 0٪ یا مرحله پایدار قبلی.
داده ها: جبران معاملات، پردازش مجدد، deduplication رویداد.

9) چک لیست صفر خرابی

قبل از انتشار

• یک مصنوع امضا شده (تغییر ناپذیر)، SBOM و بررسی وابستگی جمع آوری می شوند.
• آمادگی/زنده بودن اجرا و آزمایش شده است.
• برنامه مهاجرت در حالت گسترش، برگشت پذیری تایید شده است.
• داشبورد و هشدار برای نسخه جدید آماده هستند، علائم انتشار پرتاب می شوند.
• رول بک برای مرحله بندی/قبل از prod بررسی می شود.

در زمان انتشار

• زهکشی اتصال فعال است، زمان خروج کافی است.
• ترافیک قناری/حلقه یا تلنگر (آبی سبز) است.
• معیارها با پایه مقایسه می شوند، آستانه دروازه برآورده می شود.

پس از انتشار

• پس از نظارت N ساعت، هیچ حادثه.
• مهاجرت قرارداد کامل، پرچم موقت/مسیرهای حذف شده است.
• گذشته نگر، به روز رسانی playbook.

10) ضد الگوهای

بازسازی و استقرار بدون تخلیه و آمادگی ⇒ شکستن درخواست.
DDL آماده نشده ⇒ قفل و وقفه در زمان نخست.
مخلوط کردن طرح های ناسازگار بین نسخه های سرویس.
عدم توانایی در کارکنان و کارگران.
«رول با احساس» بدون دروازه و مقایسه با پایه.
DNS-TTL طولانی با آبی-سبز، به همین دلیل تلنگر ساعت ها طول می کشد.
نشستهای محلی/نهانگاه در حافظهٔ نمونه با نورد/قناری.

11) سناریوهای پیاده سازی

11. 1 Kubernetes (نورد + قناری)

استقرار с «maxUnavailable = 0»، «maxSurge = 25٪».
آمادگی منتظر گرم شدن است (مقدار دهی اولیه حافظه پنهان، مهاجرت جزئی).
سرویس مش/ورودی با مسیریابی وزن (1-5-10-25-50-100٪).
هشدارها: p95، 5xx، تاخیر صف، قیف کسب و کار.

11. ۲ آبی-سبز در ابر

دو پشته در پشت متعادل کننده: آبی. به عنوان مثال. کام «и» سبز. به عنوان مثال. کام.
گرم کردن سبز، دود/رگرس، سپس مبادله شنونده/مسیر (یا سوئیچ DNS با TTL کم).
در مورد مشکلات - تلنگر فوری به عقب.

11. 3 خدمات دولتی

کپی داده ها + مهاجرت آنلاین ؛ خواندن دو برابر با اعتبار.
ضربه های پس زمینه توسط نسخه «رهبری» یا تقسیم صف انجام می شود.
نشستها/نهانگاه خارج از نمونه ؛ sticky فقط به طور موقت فعال می شود.

12) Ficheflags و برنامه های مشتری

ویژگی های جدید توسط پرچم ها فعال می شوند (بخش ها: کارکنان → بتا → همه).
برای مشتریان تلفن همراه/دسکتاپ، مرزهای سازگاری پروتکل و سیاست تخریب میراث (بازپرداخت سمت سرور) را در نظر بگیرید.

13) عملکرد و هزینه

نورد ارزان تر است، اما نیاز به سازگاری دقیق دارد.
آبی سبز در زمان انتشار گران تر است، اما بازگشت فوری است.
قناری ریسک و هزینه را متعادل می کند، اما نیاز به مشاهده قوی دارد.
صرفه جویی از طریق پیش نمایش های کوتاه مدت و ایستگاه های خودکار تمیز کردن.

14) حداقل خط لوله مرجع ZDT

1. ساخت: تک مصنوع، امضا، SBOM.
2. تست: واحد/ادغام/قرارداد + امنیت.
3. مرحله بندی: دود، بار، گسترش مهاجرت، چک برگشت.
4. Prod: سایه → canary (دروازه) یا تلنگر آبی سبز.
5. پس از استقرار: نظارت، تمیز کردن قرارداد، یکپارچهسازی با سیستمعامل.

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

Zero-Downtime یک رشته است: نسخه های سازگار + مسیریابی صحیح + مهاجرت های مدیریت شده + مشاهده پذیری و بازگشت سریع. یک الگوی برای زمینه (نورد، آبی-سبز، قناری) را انتخاب کنید، دروازه های SLO را خودکار کنید، داده ها را به صورت خودکار نگه دارید - و نسخه ها یک رویداد متوقف می شوند و به یک روند معمول قابل اعتماد تبدیل می شوند.