پنج چیزی که قبل از ری‌استارت سرور باید ثبت کنیم

منبع مفهومی: Incident Response — Google SRE Workbook. چک‌لیست پیش از ری‌استارت زیر، پیشنهاد مستقل این یادداشت است و دستور عمومی ری‌استارت همه سرورها نیست.

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

پنج مورد پیش از اقدام

• اثر روی کاربران: چه کسانی متأثر می‌شوند؟ چه کسی زمان توقف را تأیید کرده و اطلاع‌رسانی کجا ثبت شده است؟
• وابستگی‌ها: سرویس به کدام پایگاه داده، ذخیره‌ساز یا سامانه احراز هویت وابسته است؟ ترتیب توقف و شروع را از مستند همان سرویس بخوانید.
• کارهای فعال و شواهد: پردازش زمان‌بر، تراکنش، انتقال فایل و عملیات بکاپ در جریان است؟ خطاها و زمان وقوع را پیش از ازبین‌رفتن وضعیت موقت ثبت کنید.
• مسیر بازیابی و دسترسی: نسخه قابل‌استفاده، مسئول بازیابی و دسترسی کنسول در صورت برنگشتن شبکه مشخص است؟ Snapshot را بدون بررسی، جایگزین بکاپ مستقل فرض نکنید.
• معیار پایان: کدام آزمون کاربر، سلامت سرویس را تأیید می‌کند و چه کسی نتیجه را اعلام می‌کند؟

ثبت کوتاه، ولی قابل‌استفاده

یک الگوی ساده برای یادداشت عملیات:

علت اقدام: …؛ سرویس‌های متأثر: …؛ شواهد ثبت‌شده: …؛ مسئول بررسی: …؛ آزمون پس از راه‌اندازی: …؛ تصمیم در صورت شکست: …

این الگو پیشنهاد من برای جلوگیری از تصمیم مبهم است؛ جایگزین رویه تأییدشده سازمان یا راهنمای سازنده نیست. برای خوشه‌ها و سرویس‌های دارای افزونگی، تخلیه بار و نقش گره هم باید مطابق طراحی بررسی شود.

بعد از روشن‌شدن، کار تمام نشده است

در یک مثال فرضی، وب‌سرور بالا آمده ولی سرویس زمان‌بندی گزارش‌ها شروع نشده است. صفحه ورود سالم، این نقص را آشکار نمی‌کند. بررسی باید به همان کارهایی برگردد که پیش از توقف فهرست کرده بودیم.

اگر ری‌استارت مشکل را موقتاً برطرف کرد، نتیجه را دقیق ثبت کنید: «پس از راه‌اندازی، سناریوی مشخص موفق شد؛ علت هنوز بررسی نشده است.» این عبارت برای پیگیری بعدی بسیار مفیدتر از «مشکل حل شد» است.

مطالعه مرتبط: سلامت واقعی سرویس.