تعمیرات برنامه‌ریزی‌شده و آپتایم: چه چیزی باید قطعی حساب بشه؟

گزارش شما می‌گه سایت این ماه دو ساعت قطع بوده. اون دو ساعت یه ارتقای دیتابیس برنامه‌ریزی‌شده بود، ساعت ۲ بامداد جمعه، که یه هفته قبل اطلاع‌رسانی شده بود. این قطعی بود؟ جواب صادقانه اینه: «برای کاربرهاتون بله؛ برای SLA بستگی داره چی تعهد دادید». این راهنما توضیح می‌ده چطور هر دو نگاه رو درست نگه دارید.

نکته‌های کلیدی

• کاربرها قطعی برنامه‌ریزی‌شده و غیرمنتظره رو یک‌جور تجربه می‌کنن؛ گزارش‌هاتون باید هر دو رو نشون بدن.
• SLAها معمولاً تعمیرات اطلاع‌رسانی‌شده رو استثنا می‌کنن؛ ولی فقط اگه قرارداد این رو بگه.
• پنجره‌ی تعمیرات رو توی ابزار مانیتورینگ تعریف کنید تا کار برنامه‌ریزی‌شده کسی رو بیدار نکنه.
• تعمیرات رو از قبل روی صفحه‌ی وضعیت اعلام کنید و پنجره‌ها رو کوتاه و قابل پیش‌بینی نگه دارید.
• وقتی پنجره تموم می‌شه حواستون جمع باشه: خیلی از رخدادها درست بعد از تعمیرات شروع می‌شن.

دو سؤال متفاوت

دو عدد ارزش دنبال کردن دارن:

• دسترس‌پذیری از نگاه کاربر؛ هر دقیقه‌ای که سرویس به هر دلیلی کار نکرده.
• دسترس‌پذیری نسبت به SLA؛ همون، منهای استثناهایی که توافق‌نامه اجازه می‌ده، معمولاً تعمیرات اعلام‌شده.

قاطی کردن این دو از هر دو طرف دردسر درست می‌کنه. اگه فقط عدد SLA رو گزارش کنید، تیم از یاد می‌بره کاربرها چند بار پشت در موندن. اگه فقط عدد خام رو گزارش کنید، ممکنه بدتر از چیزی که قراردادتون می‌خواد به نظر بیاید.

چه چیزهایی معمولاً جزو SLA حساب نمی‌شن؟

استثناهای رایج قراردادها این‌ها هستن:

1. تعمیراتی که مدت مشخصی از قبل اعلام شده (مثلاً ۴۸ ساعت یا ۷ روز).
2. تعمیرات داخل یه پنجره‌ی توافق‌شده (مثلاً جمعه ۰۱:۰۰ تا ۰۵:۰۰).
3. قطعی‌هایی که مقصرش مشتری یا شرایط قهری باشه.

تعمیراتی که از پنجره‌اش بیرون بزنه معمولاً از لحظه‌ی تموم شدن پنجره حساب می‌شه. «تعمیرات اضطراری» که ده دقیقه قبل اعلام بشه هم همین‌طور؛ قبل از تکیه کردن بهش، SLA خودتون رو بخونید.

تعریف پنجره‌ی تعمیرات

در noc724، پنجره‌ی تعمیرات هشدارهای مانیتورهای انتخاب‌شده رو در زمان برنامه‌ریزی‌شده متوقف می‌کنه:

1. مانیتورهایی رو انتخاب کنید که کار روشون اثر می‌ذاره؛ نه «همه‌چیز».
2. زمان شروع و پایان رو با کمی حاشیه تعیین کنید.
3. مشخص کنید پنجره یک‌باره است یا تکرار می‌شه (مثلاً هر شب جمعه).

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

قبل از شروع به کاربرها بگید

قطعی برنامه‌ریزی‌شده وقتی آدم‌ها ازش خبر دارن خیلی فرق می‌کنه:

• تعمیرات رو چند روز زودتر روی صفحه‌ی وضعیت اعلام کنید؛ با ساعت شروع، مدت تقریبی و چیزهایی که تحت تأثیرن.
• از ساعت محلی کاربرها استفاده کنید یا بگید منظورتون کدوم منطقه‌ی زمانیه.
• اعلان رو موقع شروع کار، اگه طول کشید، و وقتی تموم شد به‌روز کنید.

یه اعلان کوتاه و دقیق جلوی بیشتر پیام‌های «سایت قطعه؟» رو می‌گیره که معمولاً بعد از قطعی سرازیر می‌شن.

پنجره‌ها رو کوتاه و قابل پیش‌بینی نگه دارید

• ساعت‌هایی رو انتخاب کنید که مخاطب شما کمترین ترافیک رو داره؛ به‌جای حدس زدن، آمار سایت رو نگاه کنید.
• چند پنجره‌ی کوچیک رو به یه پنجره‌ی طولانی ترجیح بدید.
• هر جا می‌شه از دیپلوی rolling یا blue-green استفاده کنید تا انتشارهای معمول اصلاً پنجره لازم نداشته باشن.

آخر پنجره رو زیر نظر بگیرید

ری‌استارت‌ها، migrationها و تغییرات تنظیمات دقیقاً همون جاهایی‌ان که چیزها خراب می‌شن. وقتی پنجره بسته می‌شه:

• مطمئن بشید همه‌ی مانیتورهای درگیر به حالت «سالم» برگشتن،
• زمان‌های پاسخ رو نگاه کنید؛ ساعت اول کند معمولاً یعنی کش سرد یا ایندکس جاافتاده،
• یه نفر رو برای ۳۰ دقیقه‌ی اول آماده نگه دارید.

پرسش‌های پرتکرار

• تعمیرات برنامه‌ریزی‌شده درصد آپتایم رو کم می‌کنه؟

  +

  در عدد خام دسترس‌پذیری، بله. در محاسبه‌ی SLA معمولاً نه؛ به شرطی که تعمیرات اعلام شده و داخل پنجره‌ی توافق‌شده مونده باشه.

• موقع تعمیرات مانیتورینگ رو خاموش کنیم؟

  +

  نه؛ هشدارها رو متوقف کنید، نه چک‌ها رو. ادامه‌ی چک‌ها دقیقاً ثبت می‌کنه سرویس کی قطع شد و کی برگشت، که برای گزارش لازمش دارید.

• تعمیرات رو چقدر زودتر اعلام کنیم؟

  +

  از SLA خودتون پیروی کنید. اگه SLA ندارید، چند روز برای کارهای معمول و حداقل یه هفته برای تغییرات طولانی یا پرریسک، ادب حرفه‌ای معقولیه.