هر کدام از ما برای عیب یابی یک مشکل در سرویس سیاست خاصی داریم. بعضی مثل من از بررسی چیزای کوچیک و پایه مثل ارتباط شبکه و بررسی مصرف منابع شروع می کنند. بعضی هم یهو می پرند وسط سرویس. الان قصد ندارم متدولوژی عیب یابی را توضیح بدم. ولی یکی از نقاطی که خیلی هامون شروع می کنیم، بررسی آخرین تغییراتی هست که دادیم و شروع می کنیم برگرداندن یا rollback تغییرات تا ببینیم مشکل از اونها نباشه.
یه موضوع دیگه که هم موقع عیب یابی و هم موقع پیاده سازی و تغییرات خیلی هامون به عنوان پیشفرض در نظر می‌گیریم این هست که فرض می‌کنیم، وضعیت در همین چیزی که هست می مونه، فرض می کنیم، که خوب سخت افزار سالمه، فرض می کنیم دسترسی برقراره، فرض می کنیم اینترنت وصله و …
نکته مهم اینه که وقتی بر روی یک سرور عملیاتی شده داری کار می‌کنی اگه یک مرتبه هم این شرایط برقرار نباشه، ممکنه کل سرویس شما بر باد بره و برای همین من برای خودم اصل «اتوبوس جهانگردی» را گذاشتم و سعی می کنم بهش پایبند باشم. یعنی یه اتفاق شاید سالی یه بار بیفته و احتمال داره همین الان باشه. (اشاره به اتوبوس جهانگردی تو کارتن «مورچه و مورچه خوار»)
یعنی شما یک سال قطعی اینترنت نداشتید، دقیقا یک دقیقه بعد از تغییر IP سرور اینترنت قطع می شه. اینجاست که شما اگه به این اصل «آگاه نباشی» به جای تماس به دیتاسنتر، یکی دوساعت را صرف بررسی مجدد تنظیمات IP سرور می کنی. چون می گی من اینو تغییر دادم اینترنت قطع شد. در صورتی که فقط یه همزمانی اتفاق افتاده ، لامصب سالی یه دفعه هم این همزمانی اتفاق می افته.
چند روز پیش ما حمله ای را روی سرور تجربه کردیم، و به دلیل فراموشی همین اصل عیب یابی ما به بیراهه می رفت (البته یکی از دلایل بود). نمودار سرور وقتی افتاده بود که دقیقا من تغییری را در سرور اعلام کرده بودم. به فاصله پنج دقیقه. خوب من و بقیه در درجه اول به این اعتقاد داشتیم که به احتمال زیاد مربوط به اون تغییرات هست. درصورتی که فقط یک همزمانی مسخره و دقیق بود.
