پنجره های نگهداری

1) «پنجره نگهداری» چیست و چرا لازم است

تعمیر و نگهداری پنجره - چارچوب زمانی از پیش توافق شده برای فعالیت هایی که به طور بالقوه در دسترس بودن/عملکرد تاثیر می گذارد. هدف، تغییرات کنترل شده با ریسک قابل پیش بینی، ارتباطات شفاف و گزارش مبتنی بر شواهد است.

• برنامه ریزی شده: انتشار، مهاجرت، چرخش گواهی/کلید، ارتقاء پایگاه داده/کارگزار.
• اضطراری: رفع فوری ایمنی/بازگشت حادثه.
• خاموش/صفر تاثیر: بدون تاثیر کاربر (قناری پنهان، کپی، ورودی موازی).
• ارائه دهنده رهبری: پنجره های ارائه دهندگان خارجی (PSP/KYC/CDN/Cloud).

2) اصول

SLO اول: تصمیم گیری در زمان/فرمت پنجره با توجه به تاثیر بر SLI و بودجه خطا ساخته شده است.
حداقل شعاع انفجاری: قناری → گام به گام → گنجاندن کامل.
برگشت پذیری: هر عملیات دارای یک برنامه پشتیبان و یک بازپرداخت اثبات شده است.
تنها منبع حقیقت: تقویم پنجره + بلیط/RFC با بسته داده کامل.
شواهد: جمع آوری شواهد (سیاههها، نمودارها، تصاویر، هش های مصنوعی).
ارتباطات SLA: در پیشبرد، در طول کار، پس از اتمام.

3) برنامه ریزی: زمان بندی و پوشش

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

4) روند مذاکره (RFC/CAB lite)

1. سازنده یک بلیط/RFC با تجزیه و تحلیل ریسک و طرح ایجاد می کند (نگاه کنید به قالب زیر).
2. ارزیابی ریسک (Low/Med/High) و تأیید صاحب سرویس + SRE/security.

3. تقویم: رزرو اسلات ؛ بررسی تعارض (سایر پنجره ها/ارائه دهندگان)

4. طرح COMM: اطلاعیه از پیش توافق شده و صفحه وضعیت.
5. Go/No-Go-meeting (در 24-48 ساعت) برای تغییرات پرخطر.

5) آماده سازی: دروازه های امنیتی

چک های قبل از راه اندازی: آزمایش های مرحله موفقیت آمیز، مصنوعات امضا شده، خطرات کل قابل قبول ≤.
قناری: 1٪ → 5٪ → 25٪ توسط کوهورت/منطقه ؛ SLO-gardrails اتوماتیک و بازگشت خودکار.
پرچم های تخریب و محدودیت ها آماده هستند.
طرح برگشت/برگشت در جعبه شن و ماسه بررسی می شود ؛ دستورات برگشت ثبت شده اند.
سرکوب هشدارها: فقط برای نویز مورد انتظار، سیگنال های SLO خفه نمی شوند.
دسترسی: حساب های JIT/JEA برای عملیات، حسابرسی اجباری.

6) ارتباطات (زمان بندی و محتوا)

روزهای T-14/7/2 (برنامه ریزی شده): سرپرستی برای مشتریان/تیم های داخلی (چه زمانی/تاثیر/مخاطبین).
T-60/30/15 دقیقه: یادآوری در داخل و در صفحه وضعیت.
در طول کار: به روز رسانی هر 15-30 دقیقه (وابسته به SEV) با توجه به قالب: تاثیر → مرحله → به روز رسانی بعدی.
پس از: نهایی «تکمیل/تا حدی تکمیل/نورد تماس», لیست تغییرات, بررسی SLO.

7) عملکرد آثار (سناریوی مرجع)

1. یخ زدن نسخه های غیر مرتبط

2. انتقال به canary (گروه محدود) → معیارهای SLI/p95/p99 را مشاهده کنید.
3. افزایش گام به گام در سهم با گاردریل سبز.
4. تأیید SLI کسب و کار (تبدیل، موفقیت پرداخت/ثبت نام).
5. تأیید عملکرد لیست را بررسی کنید (مسیر مبارک + سناریوهای بحرانی).
6. راه حل انتشار/بدون انتشار (مالک IC/SRE/سرویس).
7. حذف سرکوب، بازگشت سیاست های هشدار.

8) پس از پنجره: تأیید و گزارش

پنجره مشاهده (به عنوان مثال، 1-24 ساعت): ردیابی SLO و خطاها.
گزارش پنجره: آنچه انجام شد، معیارها، انحرافات، شواهد، کل.
اگر مشکلی وجود داشت: AAR → RCA → CAPA (قوانین ثابت، تست ها، مستندات).
بایگانی: بلیط، مصنوعات، امضا، چک سام.

9) هماهنگی با ارائه دهندگان خارجی

اسلات های تایید شده و اطلاعات تماس ارائه دهنده ؛ پنجره ای در سیستم شما

Folback/routing به یک ارائه دهنده جایگزین برای دوره کار.
یک اتاق جنگ تنها با یک ارائه دهنده (چت/پل) و به روز رسانی SLA.

10) معیارهای بلوغ فرآیند

نرخ On-time: درصد پنجره های شروع شده/تکمیل شده در زمان.
نرخ شکست تغییر:٪ از پنجره ها با بازگشت/تاثیر در SLO.
Incident-during-MW: حوادثی که در طول پنجره رخ داده است.
SLA ارتباطات: سهم به روز رسانی به موقع.
شواهد کامل:٪ از پنجره ها با بسته کامل شواهد.
تاثیر مشتری: شکایات/بلیط برای 1 پنجره، روند.
پس از 7/30 روز: ثبات SLO و بدون عود.

11) چک لیست

قبل از پنجره

• RFC/بلیط پر است ؛ ارزیابی ریسک تکمیل شده ؛ مالک اختصاص داده شده است.
• قناری و عقب نشینی طرح بررسی می شود ؛ دستورات برگشت تست شده.
• دسترسی JIT صادر شده است ؛ هشدارها پیکربندی شده اند (SLO ها مسدود نمی شوند).
• صفحه تقویم/وضعیت و اطلاعیه ها آماده می شوند.
• انتشار/رقابت ویندوز - منجمد/منتقل شده است.
• ارائه دهندگان تایید ؛ تماس ها و SLA ها ضبط می شوند.

در طول

• به روز رسانی در برنامه ؛ اتاق جنگ فعال است.
• Gardrails در خطاهای SLO/Peak مورد احترام قرار می گیرند ؛ در صورت نقض - بازگشت خودکار.
• شواهد جمع آوری شده است (تصاویر، قبل/بعد از نمودار، ورود به سیستم عمل).

پس از

• SLO در منطقه سبز در طول پنجره مشاهده.
• گزارش نهایی با شواهد ؛ صفحه وضعیت به روز شد.
• CAPA ها صادر می شوند (اگر انحراف وجود داشته باشد) ؛ مستندات به روز شده

12) قالب ها

RFC الگو در هر پنجره تعمیر و نگهداری

RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB

قالب اطلاع رسانی مشتری (مختصر)

Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com      support@example. com

قوانین سرکوب (ایده)

yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]

13) ویژگی های دامنه های تنظیم شده

گزارش حسابرسی غیرقابل تغییر: چه کسی تأیید کرد، چه کسی اجرا کرد، چه دستوراتی، هش مصنوعات.
PII/Finance: پوشش در شواهد، دسترسی محدود به گزارش ها.
شرایط اطلاع رسانی به مشتریان و شرکا - مطابق با قراردادها.
پنجره های ارائه دهنده - با SLA های خارجی و مخاطبین مستند شده است.

14) ضد الگوهای

پنجره بدون برنامه پشتیبان و بازپرداخت تأیید شده.
مسدود کردن سیگنال های SLO «فقط در مورد».
پنجره های رقابتی در همان دامنه/منطقه.
سکوت Comm: هیچ قبل/در طول/پس از به روز رسانی.
ویرایش دستی در محصول بدون حسابرسی و اسکریپت.
پنجره های «بی نهایت» به دلیل معیارهای موفقیت نامشخص.
فقدان شواهد - هیچ چیز برای تایید کیفیت.

15) نقشه راه پیاده سازی (4-6 هفته)

1. «ند». 1-Enter یک تقویم واحد و قالب RFC دوره های خاموشی را تعریف می کنند.
2. «ند». 2: دروازه های استاندارد (قناری، SLO-gardrails، backout).
3. «ند». 3: خودکار حاشیه نویسی سرکوب/انتشار و صفحه وضعیت.

4. «ند». 4: معیارهای گزارش دهی و بلوغ ؛ بررسی هفتگی MW

5. «ند». 5-6: ادغام با ارائه دهندگان و آرشیو حسابرسی ؛ شبیه سازی پنجره با خطر بالا.

16) خط پایین

پنجره های خدماتی که به درستی سازماندهی شده اند، تغییرات قابل کنترل، برگشت پذیر و قابل اطمینان هستند. با SLO-gardrails، rasps canary، ارتباطات دقیق و مجموعه ای کامل از شواهد، پنجره از «خرابی وحشتناک» به یک مکانیسم معمول بهبود بدون شگفتی برای کاربران و شرکا تبدیل می شود.