چرا نگهداری «روتین» شبکه هم میتونه قطعی بسازه
خلاصهٔ کاملتر
نویسنده تعریف میکنه که اوایل کارِ مشاورهش فکر میکرد پنجرههای نگهداری (maintenance window) ریسک رو کم میکنن؛ آخه هدفِ نگهداریِ برنامهریزیشده بهبود پایداری و اعمال اصلاحاته. ولی این فرض بعد از یه تغییر زیرساختیِ بهظاهر روتین عوض شد: همهٔ پیشچکها پاس شده بود، سلامت دستگاهها نرمال بود و همگامسازی HA کامل بود، اما درست بعد از تغییر کاربرها شروع کردن به گزارش خرابی. علت اصلی نه یه ارتقای شکستخورده بود، نه نقص سختافزار؛ بلکه اون تغییر یه وابستگی جای دیگهی مسیر ترافیک رو رو کرد که هیچکس بهش فکر نکرده بود.
به گفتهٔ نویسنده، خودِ تغییر بهندرت مشکلسازه؛ مشکل، این فرضه که تغییر ایزولهست. «روتین» به معنای «کمریسک» نیست؛ فقط یعنی این کار قبلاً انجام شده، نه اینکه محیط فعلی هم مثل قبل واکنش نشون میده. خیلی از حادثههای production از کارهای روتینی مثل آپدیت فایروال، تغییر DNS، تمدید گواهی، تنظیم مسیریابی، failover لودبالانسر، آپدیت WAF یا پچ نرمافزار میان.
دلیلش اینه که مدل قدیمی «واحد تغییر = یه دستگاه» دیگه جواب نمیده. امروز یه تراکنش تکِ کاربر ممکنه از DNS، مدیریت ترافیک سراسری، مسیریابی WAN، سوییچینگ دیتاسنتر، فایروالها، لودبالانسرها، نقاط بازرسی TLS، سیاستهای WAF، API gatewayها و لایههای backend رد شه؛ هر لایه هم مستقل دربارهٔ دسترسپذیری، امنیت یا مسیریابی تصمیم میگیره. تیمها معمولاً فقط همون جزئی رو که عوض کردن اعتبارسنجی میکنن، نه کل جریان ترافیک رو. نویسنده به راهنمای SRE گوگل اشاره میکنه که تغییرات رو یکی از رایجترین منابع اختلال سرویس میدونه.
نویسنده چند نقطهٔ شکست رایج رو نام میبره. یکی عدمتطابق stateه: فایروالها، لودبالانسرها و NATها اغلب state اتصال یا نشست رو نگه میدارن؛ موقع failover یا reboot ممکنه اتصالهای جدید موفق بشن ولی نشستهای طولانی بمیرن. یکی دیگه مسیریابی نامتقارنه: اگه مسیر رفت و برگشت از فایروالها یا زونهای بازرسی متفاوت رد شن، بازرسی stateful بستهها رو معتبر نمیبینه و میندازهشون دور، حتی وقتی شبکه ظاهراً «بالا»ست.
رفتار لایهٔ ۲ هم دستکم گرفته میشه: MAC learning، کش ARP، تگ VLAN و رفتار gateway میتونه تعیین کنه ترافیک بعد از failover تمیز حرکت میکنه یا نه. تغییرات DNS و GSLB هم یه کلاس ریسک دیگهان؛ تیمها معمولاً فقط resolve شدن نام رو تست میکنن، ولی سوال مهمتر اینه که کاربر داره به کجا فرستاده میشه و اون مقصد آمادهی ترافیک production هست یا نه. اگه ترافیک به یه دیتاسنتر دیگه منتقل شه، اون سایت باید قوانین فایروال، پیکربندی لودبالانسر، گواهیها و ظرفیت backendِ هماهنگ داشته باشه.
تمدید گواهی هم میتونه بیشتر از endpoint سمت مرورگر رو خراب کنه، چون TLS معمولاً تو چند hop terminate، رمزگذاری مجدد یا بازرسی میشه؛ کارِ واقعی، اعتبارسنجی مذاکرهٔ TLS بهصورت سرتاسریه، نه فقط سرور بیرونی. سیاستهای امنیتی مثل WAF و IPS هم موقع آپدیت یا refresh امضاها ممکنه ترافیک مشروع رو بلاک کنن، بهخصوص برای APIها که تفاوت کوچیک تو هدر یا متد میتونه enforcement غیرمنتظره راه بندازه.
نویسنده روی «مشکل محیط تست» هم تأکید میکنه: پیشچکها فقط دسترسپذیری زیرساخت رو تأیید میکنن نه بقای تراکنش رو، و محیطهای تست بهندرت آینهٔ productionان. راهحل پیشنهادی اینه که قبل از پنجره، مسیر ترافیک نقشه شه (مسیر ورودی/خروجی، زونهای فایروال، نقاط NAT، نقاط تصمیم DNS/GSLB، نقاط terminate شدن TLS و وابستگیهای backend)، انتظارات شکست از قبل تعریف شن، و پیشچکها هم شواهد control-plane و هم data-plane (دستدادن TCP، مذاکرهٔ TLS، کدهای وضعیت HTTP، پاسخ API، پایداری نشست) رو شامل شن. حین تغییر هم باید سراغ علائمِ زودهنگامِ خرابی رفت: reset اتصال، لاگهای deny فایروال، جهش نقض WAF، خطاهای 5xx و retransmissionهای TCP.
جمعبندی نویسنده اینه که هدف، پیچیده و بوروکراتیک کردن نگهداری نیست، بلکه دستکم نگرفتن ریسکشه. هر پنجرهٔ نگهداری یه فرصت کنترلشدهست تا تست کنیم شبکه همونطور که معماری میگه رفتار میکنه یا نه. نویسنده میگه شبکههای امروزی تو فاصلهٔ بین سیستمها خراب میشن — بین DNS و لودبالانسینگ، بین فایروال و مسیریابی، بین بازرسی TLS و رفتار اپلیکیشن — و نگهداری دقیقاً همین فاصلهها رو رو میکنه؛ برای همین باید هر پنجره رو یه تست زندهٔ معماری و تابآوری دید، نه فقط یه چکلیست.
نکات کلیدی:
- بیشتر قطعیها از کارهای روتینِ نگهداری میاد، نه خرابیهای دراماتیک؛ خطر، فرضِ «ایزوله بودن تغییر»ه.
- تو شبکههای امروزی یه تراکنش از دهها لایه رد میشه؛ چک کردن فقط جزء تغییریافته کافی نیست.
- نقاط شکست رایج: عدمتطابق state، مسیریابی نامتقارن، رفتار لایهٔ ۲، تغییر DNS/GSLB، گواهی و WAF.
- راهحل: نقشه کردن مسیر ترافیک، تعریف انتظارات شکست، و اعتبارسنجی واقعیِ data-plane نه فقط سلامت دستگاه.
