چرا سرورها را ریبوت میکنیم
سؤالی که به طور منظم مطرح میشود این است که آیا سرورها باید به صورت روتین ریبوت شوند، مانند یک بار در هفته، یا آیا باید اجازه داد تا تا آنجا که ممکن است اجرا کنند تا حداکثر «آپتایم» حاصل شود. برای من پاسخ ساده است - با استثناهای نادر، ریبوتهای منظم مناسبترین انتخاب برای سرورها هستند.
مانند هر قانونی، مواردی وجود دارد که در آنها اعمال نمیشود. به عنوان مثال، برخی کسبوکارها که سیستمهای حیاتی اجرا میکنند هیچ تخصیصی برای خاموشی ندارند و باید ۲۴ ساعته ۷ روز هفته در دسترس باشند. بدیهی است که سیستمهایی مثل این نمیتوانند به سادگی به صورت روتین ریبوت شوند. اما اگر یک سیستم آنقدر حیاتی است که هرگز نمیتواند از کار بیفتد، این وضعیت باید یک پرچم قرمز ایجاد کند که این سیستم یک نقطه شکست است و شاید ملاحظاتی درباره نحوه مدیریت خاموشی، چه برنامهریزیشده یا برنامهریزینشده، باید آغاز شود.
استثنای دیگر این است که برخی سیستمهای AIX به آپتایم قابل توجه، بیشتر از چند هفته، نیاز دارند تا حداکثر کارایی حاصل شود زیرا سیستم خودتنظیم است و به زمان نیاز دارد تا اطلاعات استفاده را به دست آورد و خود را بر این اساس تنظیم کند. این معمولاً محدود به سرورهای پایگاه داده بزرگ که به ندرت تغییر میکنند و سناریوهای استفاده مشابه است که کمتر از پلتفرمهای دیگر رایج هستند.
در IT اغلب مفهوم «آپتایم» را میپرستیم - اینکه یک سیستم چه مدت میتواند بدون نیاز به راهاندازی مجدد اجرا کند. اما «آپتایم» مفهومی نیست که برای کسبوکار ارزش ایجاد کند و IT باید همیشه نیازهای کسبوکار را در نظر داشته باشد نه اینکه بر معیارهای مصنوعی تمرکز کند. کسبوکار نگران این نیست که یک سرور چه مدت موفق شده بدون ریبوت آنلاین بماند - آنها فقط اهمیت میدهند که سرور هنگام نیاز برای پردازش کسبوکار در دسترس و آماده باشد. اینها مفاهیم بسیار متفاوتی هستند.
برای تقریباً هر سرور کسبوکاری عادی، یک پنجره وجود دارد که سرور باید برای اهداف کسبوکاری در دسترس باشد و یک پنجره که مورد نیاز نیست. این پنجرهها ممکن است روزانه، هفتگی یا ماهانه باشند، اما یک سرور نادر است که واقعاً بدون استثنا شبانهروز مورد استفاده قرار میگیرد.
اغلب میشنوم که افراد میگویند چون سیستم عامل X را به جای Y اجرا میکنند دیگر نیازی به ریبوت ندارند، اما این به سادگی درست نیست. دو دلیل اصلی برای ریبوت منظم وجود دارد: تأیید توانایی سرور برای ریبوت موفق و اعمال پچهایی که بدون ریبوت قابل اعمال نیستند.
اعمال پچها دلیلی است که اکثر کسبوکارها ریبوت میکنند. تقریباً همه سیستمهای عامل بهروزرسانیهای منظمی دریافت میکنند که برای اثربخشی نیاز به ریبوت دارند. از آنجا که اکثر پچها برای اهداف امنیتی و پایداری منتشر میشوند، به خصوص آنهایی که نیاز به ریبوت دارند، اهمیت اعمال آنها نسبتاً بالا است. آسیبپذیر نگه داشتن یک سرور به طور غیرضروری فقط برای حفظ آپتایم عاقلانه نیست.
آزمایش ظرفیت سرور برای ریبوت موفق چیزی است که اغلب نادیده گرفته میشود. اکثر سرورها تغییراتی به طور منظم روی آنها اعمال میشود. تغییرات ممکن است پچها، برنامههای جدید، تغییرات پیکربندی، بهروزرسانیها یا موارد مشابه باشند. هر تغییری خطر ایجاد میکند. صرفاً به این دلیل که یک سرور بلافاصله پس از اعمال تغییر سالم است به این معنا نیست که سرور یا برنامههای در حال اجرا روی آن پس از ریبوت طبق انتظار شروع به کار خواهند کرد.
اگر سرور هرگز ریبوت نشود، هرگز نخواهیم دانست که آیا میتواند با موفقیت ریبوت کند. با گذشت زمان تعداد تغییرات اعمالشده از آخرین ریبوت افزایش خواهد یافت. این بسیار خطرناک است. آنچه میترسیم این است که تعداد زیادی تغییر اعمال شده باشد، احتمالاً بسیاری از آنها مستندسازی نشده، و سپس یک ریبوت شکست بخورد. در آن نقطه، شناسایی اینکه کدام تغییر باعث شکست سیستم شده میتواند یک فرایند غیرقابل غلبه باشد. هیچ تغییر واحدی برای بازگشت، هیچ مسیر شناختهشدهای به سمت بازیابی وجود ندارد. اینجاست که وحشت شروع میشود. البته، یک سرور که هرگز عمداً ریبوت نمیشود احتمال بیشتری دارد که ناخواسته ریبوت شود - یعنی احتمال یک ریبوت ناموفق هم بیشتر است و هم احتمال بیشتری وجود دارد که در حین استفاده فعال اتفاق بیفتد.
در حالی که ریبوتهای منظم برای کاهش فرکانس ریبوتهای ناموفق در نظر گرفته نشدهاند - در واقع آنها واقعاً وقوع شکستها را افزایش میدهند - هدف این است که آن شکستها از نظر «تغییر شناختهشده» به راحتی قابل مدیریت باشند و مهمتر از همه، کنترل زمان وقوع آن ریبوتها را به دست بگیریم تا اطمینان حاصل شود که در زمانی اتفاق میافتند که سرور به عنوان در دسترس برای نگهداری تعیین شده و طراحی شده است که تحت فشار باشد تا مشکلات در زمانی یافت شوند که بتوانند بدون تأثیر بر کسبوکار کاهش یابند.
بارها از مدیران سیستم شنیدهام که میگویند از ریبوتهای آخر هفته اجتناب میکنند چون نمیخواهند روز یکشنبه به دلیل عدم بازگشت سرورها پس از ریبوت مجبور به کار باشند. بارها در روزهای یکشنبه صبح از یک ریبوت ناموفق پیجر دریافت کردهام، اما هر بار که آن تماس را دریافت میکنم احساس آرامش میکنم. میدانم که مشکلی را در زمانی کشف کردهایم که کسبوکار از نظر مالی تحت تأثیر قرار نگرفته است. اگر آن سرور در ساعات خارج از وقت راهاندازی مجدد نمیشد، ممکن بود تا زمانی که در ساعات کسبوکاری فعال شکست خورده و باعث از دست رفتن درآمد شده بود، «غیرقابل بوت» بودنش کشف نشده باشد.
به لطف ریبوتهای منظم آخر هفته، میتوانیم بلاهای در شرف وقوع را به طور ایمن کشف کنیم و به لطف دانستن اینکه فقط تغییرات یک هفته را باید بررسی کنیم، به طور معمول میتوانیم مشکلات را با تلاش نسبتاً کم و اطمینان عالی از اینکه میدانیم چه تغییراتی قبل از شکست اعمال شده بود حل کنیم.
ریبوتهای منظم درباره محافظت از کسبوکار در برابر قطعیها و خاموشیهایی است که میتوانند از طریق فرایندهای بسیار ساده و قابل اطمینان کاهش یابند.
آگهی
