عملیات و → چرخه انتشار و به روز رسانی مدیریت

چرخه انتشار و به روز رسانی

1) هدف

• عدم اطمینان و هزینه هماهنگی را کاهش می دهد
• کاهش خطر حوادث و عقب نشینی،
• همگام سازی فن آوری با رویدادهای کسب و کار (بازاریابی، ورزش، گزارش نهایی)،
• بهبود عملکرد دستورات بدون رشد CFR (Change Failure Rate).

2) مدل های انتشار: کدام یک را انتخاب کنید

1. قطار انتشار - اسلات ثابت (به عنوان مثال،. سه شنبه/پنجشنبه 10:00 EET)

مناسب برای مونولیت های چند تیمی و تغییرات دامنه «سنگین».

2. تحویل مداوم (در صورت درخواست) - هر ادغام که دروازه های کیفیت را گذرانده است می تواند به غذا برود.

مناسب برای میکروسرویس ها و فرهنگ ویژگی پرچم.

3. ترکیبی - جبهه محصول در قطار, خدمات باطن «در تقاضا».

معیارهای انتخاب: بلوغ آزمون/مشاهده پذیری، وابستگی به شرکای خارجی (PSP/KYC)، الزامات انطباق، اندازه سازمان.

3) انتشار تقویم و ویندوز

تقویم واحد (در سراسر شرکت): اسلات انتشار، مهاجرت پایگاه داده، کمپین های بازاریابی، رویدادهای مهم ورزشی، دوره های گزارش.
دوره های انجماد: پنجره های به وضوح تعریف شده که فقط hotfix P1 مجاز است (به عنوان مثال فینال لیگ قهرمانان، جمعه سیاه، گزارش مالیاتی).
امواج منطقه ای: اولین بازارهای «گرم »/ترافیک کم، سپس - پایه ؛ پنجره های شبانه TZ های محلی.
خط مشی عبور: ممنوعیت تغییرات همزمان در یک مسیر بحرانی (پرداخت، KYC، مجوز).

4) شاخه و نسخه

شاخه های مبتنی بر تنه + کوتاه مدت (شاخه های ویژگی ≤ 3-5 روز).
Release-branch - فقط برای قطارها/تأیید طولانی ؛ ادغام سخت در «اصلی».
SemVer: سرگرد. جزئی است. PATCH برای کتابخانه ها/SDK ؛ برچسب ها از مصنوعات و محیط.

قراردادها: طرح ها (Avro/Protobuf) با سازگاری عقب/جلو ؛ مهاجرت - دو مرحله ای

5) کانال های کیفیت (دروازه)

1. استاتیک + SAST/DAST + خطوط

2. تست واحد/قرارداد/جزء

3. E2E/Performance دود (روی صحنه)

4. چک های امنیتی/انطباق

5. انتشار نامزد → امضا, SBOM, مصنوعات

6. گسترش پیشرفته با گاردریل های خودکار (نگاه کنید به § 7)

تمام دروازه ها - کد و سیاست (سیاست به عنوان کد)، نتایج - در مصنوعات انتشار.

6) محیط ها و تبلیغات

Dev → Int → Stage → Prod، برای داده ها: Sandbox/Data-Stage.
تبلیغات GitOps, تصاویر تغییر ناپذیر, ممنوعیت «کتابچه راهنمای» ویرایش در تولید.
پارامتری کردن: مناطق، محدودیت ها، ارائه دهندگان - از طریق پیکربندی (حسابرسی).

7) استراتژی نورد

قناری: 1٪ → 5٪ → 25٪ → 100٪ (или در هر منطقه).
آبی سبز: محیط های موازی + سوئیچینگ اتمی.

ویژگی پرچم: سوئیچ های کاربردی/کشتن سوئیچ ؛ A/B и سایه

مرحله بندی موبایل/وب: توسط نسخه مشتری/کانال تحویل (فروشگاه/OTA).

Gardrails (توقف خودکار): تاخیر p95 ↑> 25٪، خطا٪> 2٪، کاهش مجوز/سپرده، رشد در بازپرداخت، SLO نرخ سوختگی برای پنجره 1 ساعته> آستانه.

8) هماهنگی با کسب و کار و همکاران

بازاریابی/رویدادها: انتشار عملکرد برای کمپین ها با حاشیه ≥ 48 ساعت.
شرکا (PSP/KYC/ارائه دهندگان بازی): اسلات برای گواهینامه/به روز رسانی SDK، نقطه پایان دوگانه برای دوره مهاجرت.
پشتیبانی: ماکروها/سوالات متداول برای تغییرات UX، صفحات وضعیت، کانال های تشدید.

9) به روز رسانی داده ها و طرح

افزودنی اول: برای اولین بار اضافه کردن، سپس سوئیچ خواندن/نوشتن، در پایان - حذف قدیمی است.
شاخص ها و مهاجرت های بزرگ - پنجره های شب، با دسته، با ایستگاه های بازرسی و پیشرفت.
نسخه بندی فرهنگ لغت پنجره و متریک: به روز رسانی همزمان با انتشار، مهاجرت BI - به طور جداگانه از پنجره های تولید.

10) ارتباطات و مصنوعات

یادداشتهای انتشار (چه/چرا/خطرات/برگشت)، ChangeLog توسط سرویس.
تقویم دعوت به سهامداران، قالب آگهی (قبل/در طول/پس از).
کانال اتاق جنگ برای مدت زمان قطار/نسخه های اصلی، فرکانس به روز رسانی: P1 - هر 15-20 دقیقه.

11) معیارهای عملکرد

DORA: فرکانس استقرار، زمان سرب، تغییر نرخ شکست، MTTR.
نرخ برگشتی بر اساس نوع تغییر.
انطباق SLO٪ قبل/بعد از انتشار.
انتشار بدهی: پرچم های «حلق آویز»، مهاجرت ناقص، وابستگی های قدیمی.
تاثیر کسب و کار: تبدیل، KYC TTV، موفقیت PSP، GGR/NGR رانش به انتشار پنجره.

12) ضد الگوهای

بیگ بنگ: «همه در یک بار» بدون پرچم/قناری.
انتشار در اوج ترافیک/حوادث بدون استثنا یخ.
بدون خودکار گاردریل: نظارت دستی «توسط چشم».
شاخه های طولانی مدت: ادغام دردناک و رگرسیون های پنهان.
مراحل دستی در فروش: بدون حسابرسی و پیش بینی.
پرچم بدون TTL و صاحبان: شاخه های «ابدی».

13) چک لیست

قبل از انتشار

• RFC/بلیط، خطر و شعاع انفجار ارزیابی شده است
• دروازه های CI/CD گذشت، مصنوعات امضا شده است
• برنامه نورد + معیارهای توقف + بازگشت آماده است
• هماهنگی با تقویم، یخ و همکاران
• داشبورد/هشدار محدود به نسخه، اتاق جنگ ایجاد شده است

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

• مراحل قناری و توقف خودکار فعال هستند
• p95/error% metrics, سیگنال های کسب و کار (auth, KYC, PSP) بر روی مانیتور
• ارتباطات برنامه ریزی شده، صفحه وضعیت تجدید

پس از انتشار

• انتشار یادداشت ها و ChangeLog منتشر شده است
• پرچم های حذف شده/استثنائات موقت (TTL)
• پس از مرگ در صورت انحراف ≤ 5 روز کاری
• به روز شده playbooks و اسناد و مدارک

14) قالب های کوچک

• تاریخ/زمان: سه شنبه، 10 صبح تا 12 بعد از ظهر EET
• حوزه انتخابیه: اتحادیه اروپا (10٪ → 50٪ → 100٪) و سپس LATAM (10٪ → 100٪)
• معیارهای توقف: خطا٪> 2٪ 10 دقیقه، p95> + 25٪ 10 دقیقه، موفقیت PSP <97٪
• برگشت: سوئیچ ترافیک به نسخه قبلی + بازگشت پرچم
• تماس با: @ RelEng، @ SRE-on-call، @ پشتیبانی

• چه جدید است/چرا
• تاثیر بر کاربران و شرکا
• خطرات و محدودیت های شناخته شده
• برنامه نورد/معیارهای توقف/عقب نشینی
• معیارهای نظارت
• تماس ها و کانال های پشتیبانی

15) ادغام با رشته های همسایه

مدیریت تغییر: استاندارد طبقه بندی/عادی/اضطراری، CAB، حسابرسی.
کاهش عواقب حوادث: پرچم های آماده شده، سهمیه ها، ریختن.
ممیزی پیکربندی: تمام تبلیغات از طریق Git، تشخیص رانش و ورود به سیستم برنامه.
سیاست های اجرایی: محدودیت/زمان بندی/بازپرداخت - مانند کد، با اجبار.

16) خط پایین

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