برقراری مجدد ارتباط با شبکه جهانی پس از یک دوره اختلال طولانی، اگرچه باعث امیدواری است، اما لزوما به معنای پایان بحران هم نیست؛ بلکه آغاز مرحلهای حساستر است که در آن باید اقدامات مهمی انجام داد. در حالی که پینگها پاسخ میدهند و ترافیک جریان مییابد، لایههای زیرین زیرساخت ممکن است درگیر ناهنجاریهای پنهان، از جمله عدم تطابق دادهها یا انباشت غیرعادی پروسهها باشند. اتکا به مشاهده ظاهری در این شرایط، میتواند برخی از خطاها و مشکلات را از دید ما پنهان کند. در این راهنما، یک چکلیست عملیاتی دقیق برای اطمینان از پایداری سرویسها و جلوگیری از خرابیهای پنهان در این شرایط ناپایدار را مرور میکنیم تا پیش از بروز فاجعه دوم، زیرساخت را ایمن کنید.
گام اول: سنجش دسترسیپذیری
باز شدن سایت در مرورگر شخصی شما، معیار قابل اتکایی برای آپ بودن سرویس نیست. پس از دورههای اختلال شبکه، جداول مسیریابی در ISPهای مختلف ممکن است هنوز به هماهنگی کامل نرسیده باشند. بنابراین، اولین وظیفه شما انجام تستهای دسترسیپذیری توزیعشده است تا مطمئن شوید ترافیک از تمام نقاط (چه داخل و چه خارج از شبکه ملی) به درستی به سمت سرور روت میشود.
تست پینگ و پکتلاس از لوکیشنهای مختلف (ایران و خارج)
در شرایطی که شبکه ناپایدار است، به دستور ساده Ping اکتفا نکنید. بلکه باید از ابزارهایی مانند MTR (ترکیب Traceroute و Ping) استفاده کنید تا نقاط کور مسیر را پیدا کنید.
- تست دوطرفه: دسترسی را هم از سمت کلاینت به سرور (Inbound) و هم از سرور به دنیای خارج (Outbound) تست کنید. بسیاری از سرویسها به دلیل ناتوانی سرور در اتصال به APIهای خارجی (مثل درگاه بانک یا سرویسهای پیامک) دچار اختلال میشوند.
- بررسی Packet Loss: اگر پینگ دارید اما پکتلاس بالاست (مثلا بالای ۵ درصد)، یعنی ارتباط TCP مدام در حال تلاش مجدد است که باعث کندی شدید تجربه کاربر میشود.
- ابزارهای پایش خارجی: از ابزارهایی مثل Pingdom یا Check-Host استفاده کنید تا مطمئن شوید سرور از نودهای اروپا، آمریکا و آسیا قابل رویت است.
اعتبارسنجی گواهینامههای SSL و تنظیمات DNS
اختلالات شبکه میتواند باعث اختلال در پروسه تمدید خودکار گواهینامهها (مانند Let’s Encrypt) شده باشد.
- وضعیت اعتبار SSL: تاریخ انقضای گواهینامه را چک کنید. همچنین بررسی کنید که آیا مکانیزم OCSP Stapling به درستی کار میکند یا خیر؛ زیرا اگر سرور نتواند وضعیت اعتبار را به مرورگر کاربر اعلام کند، با خطای امنیتی مواجه میشوید.
- بررسی DNS Propagation: ممکن است در دوران اختلال، رکوردهای DNS تغییر کرده باشند اما به دلیل کش شدن در DNS Resolverهای میانی، کاربران همچنان به IPهای قدیمی یا نادرست هدایت شوند. با دستور dig یا ابزارهای آنلاین، وضعیت Propagation را بررسی کنید.
بررسی هدرهای HTTP و کدهای وضعیت
گاهی اوقات فایروالهای سختافزاری یا CDNها در زمان اختلال، صفحه خطای کاستوم خود را کش میکنند. با استفاده از دستور curl -I https://your-site.com هدرهای پاسخ را بررسی کنید. همچنین، مطمئن شوید که کد وضعیت دقیقا 200 OK است. دریافت کدهایی مانند 502 Bad Gateway یا 504 Gateway Timeout در این شرایط بسیار محتمل است که نشاندهنده ناتوانی وب سرور در پاسخگویی به درخواستها در زمان مقرر (به دلیل کندی شبکه یا لود بالا) میباشد.
گام دوم: پایش سلامت منابع سختافزاری و سیستمعامل
با باز شدن مسیر ترافیک، هجوم درخواستهای کاربرانی که مدتها منتظر بودهاند میتواند منابع سختافزاری را که احتمالا در این مدت بدون نظارت دقیق رها شدهاند، مختل کند. قبل از هر چیز باید از سلامت بخشهای ضروری سرور مطمئن شوید.
تحلیل رفتارهای غیرعادی در مصرف CPU و RAM
در نگاه اول ممکن است مصرف CPU پایین باشد، اما باید پارامتر Load Average را بررسی کنید.
- بررسی I/O Wait: در شرایط کندی اینترنت، بسیاری از پروسهها منتظر دریافت پاسخ از دیتابیس یا سرویسهای خارجی میمانند. این موضوع باعث بالا رفتن زمان انتظار میشود. اگر CPU زیاد درگیر نیست اما Load Average بالاست، احتمالا گلوگاه شما دیسک یا شبکه است، نه پردازنده.
- شکار پروسههای زامبی: با استفاده از دستوراتی مثل htop یا ps aux، به دنبال پروسههایی بگردید که در دوران اختلال کرش کردهاند اما هنوز منابع رم را اشغال کردهاند و آنها را متوقف کنید.
مدیریت فضای دیسک و پاکسازی لاگهای انباشته شده
یکی از خطرناکترین پیامدهای قطع دسترسی سرور به مخازن لاگ خارجی (مثل ELK Stack یا S3)، ذخیره شدن تمام لاگها روی دیسک لوکال است.
- بررسی فضای خالی: با دستور df -h وضعیت پارتیشنها را چک کنید. پر شدن پارتیشن /var یا / میتواند باعث توقف سرویسهای دیتابیس و وب سرور شود.
- روتیت کردن لاگها: فایلهای لاگ حجیم (مثل access.log یا error.log) را بررسی کنید. اگر logrotate به درستی تنظیم نشده باشد، ممکن است با فایلهای چند گیگابایتی مواجه شوید. آنها را آرشیو یا در صورت عدم نیاز، خالی کنید تا فضا آزاد شود.
بررسی همگامسازی زمان سرور (NTP Sync)
سرورها برای احراز هویت (مانند کدهای 2FA)، هندشیکهای SSL و Replication دیتابیس به زمان دقیق نیاز دارند. اگر سرور مدت طولانی نتوانسته به NTP Pool وصل شود، ساعت آن دچار انحراف میشود. با دستور timedatectl یا chronyc tracking وضعیت سینک بودن زمان را چک کنید. اگر اختلاف زمانی وجود دارد، سرویس NTP را ریستارت کرده و زمان را فورا سینک کنید تا از بروز خطاهای عجیب در دیتابیس و اپلیکیشن جلوگیری شود.
گام سوم: بازرسی سرویسهای حیاتی و لایه اپلیکیشن
پس از اطمینان از وضعیت شبکه و سختافزار، نوبت به نرمافزارها میرسد. در شرایطی که اینترنت دچار اختلال شدید است، سرویسها رفتار متفاوتی از خود نشان میدهند. تنظیماتی که برای شرایط نرمال بهینه شدهاند، ممکن است در شرایط فعلی باعث کرش کردن سرویس شوند.
وضعیت وب سرورها (Nginx/Apache) و سرویسهای کش
- بررسی کانکشنهای باز: در شرایط کندی اینترنت، کلاینتها دیرتر اتصال را میبندند. این موضوع باعث پر شدن ظرفیت Worker_Connections در Nginx یا MaxClients در Apache میشود. لاگها را بررسی کنید تا مطمئن شوید درخواستهای جدید به دلیل پر شدن اسلاتها دراپ نمیشوند. شاید لازم باشد موقتا مقادیر KeepAlive Timeout را کاهش دهید.
- وضعیت سرویسهای کش: اگر در طول قطعی، دیتابیس آپدیت شده اما سرویس کش به دلیل اختلال شبکه نتوانسته خود را بهروز کند، با دادههای کهنه مواجه خواهید شد. پیشنهاد میشود کش را به طور کامل Flush کنید تا دادههای معتبر مجددا از دیتابیس خوانده شوند.
بررسی سلامت دیتابیس و یکپارچگی دادهها
حساسترین بخش ماجرا اینجاست. اگر معماری دیتابیس شما به صورت Master/Slave یا Cluster است، قطعی ارتباط بین نودها فاجعه به بار میآورد.
- چک کردن Replication Lag: با دستوراتی مثل SHOW SLAVE STATUS (در MySQL) بررسی کنید که آیا Slaveها با Master همگام هستند یا خیر. ممکن است به دلیل قطعی طولانی، لاگهای باینری منقضی یا حذف شده باشند و نیاز به سینک مجدد کامل داشته باشید.
- خطر Split-Brain: اگر کلاسترینگ خودکار دارید، مطمئن شوید که در زمان قطعی، چند نود همزمان خود را Master اعلام نکرده باشند. این وضعیت باعث دوشاخگی دادهها میشود که یکیسازی آنها بسیار دشوار است.
تعیین تکلیف جابهای فیلشده و صفها
سیستمهای صف مثل RabbitMQ یا Redis Queue احتمالا اکنون با انباشت هزاران تسک پردازش نشده روبرو هستند.
- جلوگیری از سیل پردازش: اگر ورکرها را ناگهان روشن کنید، هجوم تسکهای انباشته شده (مانند ارسال هزاران ایمیل یا درخواستهای API) باعث Overload شدن سرور میشود.
- مدیریت Dead Letter Queue: جابهایی که به سرویسهای خارجی مثل درگاه پرداخت یا APIهای بینالمللی وابسته بودهاند، قطعا شکست خوردهاند. آنها را بررسی کنید؛ اگر تاریخ انقضای منطقیشان گذشته، آنها را حذف کنید و تنها تسکهای حیاتی را با ریت محدود مجددا اجرا کنید.
گام چهارم: اقدامات اورژانسی سئو و تعامل با موتورهای جستجو
موتورهای جستجو بهویژه گوگل، در برابر عدم دسترسی پذیری بسیار سختگیر هستند. پس از چندین روز اختلال، احتمالا کرال باجت سایت شما کاهش یافته و بسیاری از صفحات با خطای 5xx علامتگذاری شدهاند.
بررسی دسترسی رباتهای گوگل و فایل Robots.txt
گاهی اوقات ادمینها برای کاهش ترافیک خارجی در زمان حملات یا اختلال، دسترسی IPهای غیر ایران را میبندند که شامل رباتهای گوگل هم میشود.
- تست Fetch: از ابزار URL Inspection در گوگل سرچ کنسول استفاده کنید تا ببینید آیا گوگل میتواند همین الان به سایت شما دسترسی داشته باشد یا خیر.
- بررسی Robots.txt: مطمئن شوید که فایل robots.txt در دسترس است و کدی غیر از 200 برنمیگرداند. اگر گوگل نتواند این فایل را بخواند، برای جلوگیری از ایندکس محتوای ممنوعه، کل کرال سایت را متوقف میکند.
استراتژی درخواست ایندکس مجدد و بررسی خطاهای سرچ کنسول
قبل از اینکه از گوگل بخواهید دوباره سایت را بررسی کند، باید از پایداری صددرصدی مطمئن باشید. پس از این نظر، لازم نیست عجله کنید.
- بررسی گزارش Coverage: به بخش Pages در سرچ کنسول بروید. افزایش ناگهانی خطاهای 5xx Server Error طبیعی است. اما تا زمانی که ارورهای سرور (گامهای قبلی) را رفع نکردهاید، روی دکمه Validate Fix کلیک نکنید. ارسال سیگنال اصلاح و مواجه شدن دوباره گوگل با خطا، اعتبار دامنه را بیشتر خدشهدار میکند.
- نقشه سایت: اگر محتوای جدیدی در این مدت منتشر کردهاید، تنها پس از رفع کامل کندی سرعت، نقشه سایت را ریسابمیت کنید. اولویت را به URLهای اصلی و حیاتی بدهید و از درخواست ریکرال برای صفحات کماهمیت پرهیز کنید تا بودجه خزش روی صفحات مهم متمرکز شود.
گام پنجم: امنیت و شناسایی آسیبهای دوران اختلال
امنیت سایبری تعطیلی ندارد، اما در زمان قطع اینترنت، الگوی تهدیدات تغییر میکند. در حالی که Edge Firewallها ترافیک خارجی را مسدود کرده بودند، شبکه داخلی اینترانت همچنان فعال بوده. خطرناکترین تهدید در این بازه، حرکت جانبی بدافزارها یا نفوذگران داخلی است که از نظارتهای معمول امنیتی (که اغلب مبتنی بر اتصال به دیتابیسهای ابری تهدیدات هستند) پنهان ماندهاند.
پایش لاگهای امنیتی برای شناسایی نفوذهای احتمالی
اکنون که اتصال برقرار شده، سیستمهای تشخیص نفوذ IDS/IPS شروع به ارسال هشدارهای انباشته شده میکنند.
- بررسی لاگهای احراز هویت: فایلهای /var/log/auth.log (در اوبونتو/دبیان) یا /var/log/secure (در CentOS/RHEL) را برای تلاشهای ناموفق ورود از IPهای داخلی بررسی کنید.
- تغییرات فایلهای سیستمی: اگر ابزارهایی مثل AIDE یا Tripwire دارید، فورا چک کنید که آیا فایلهای سیستمی یا کانفیگهای حساس در دوران قطعی تغییر کردهاند یا خیر. تغییر در فایلهای passwd یا crontab بدون اطلاع ادمین، نشانه قطعی نفوذ است.
بهروزرسانی مخازن و پکیجهای امنیتی معوقه
در طول قطعی طولانیمدت اینترنت بین الملل، احتمالا چندین آسیبپذیری حیاتی (CVE) جدید کشف و پچ شدهاند که سرور شما آنها را دریافت نکرده است.
- آپدیت محتاطانه: بلافاصله دستور آپدیت کامل (apt upgrade یا yum update) را نزنید. ابتدا فقط پکیجهای امنیتی را اعمال کنید. آپدیت همزمان کرنل، دیتابیس و زبان برنامهنویسی در شرایطی که سرور هنوز ناپایدار است، ریسک فیلشدن سرویس را بالا میبرد.
- بررسی مخازن: مطمئن شوید که لیست مخازن شما همچنان معتبر است و در زمان تلاش برای اتصال به میرورهای خارجی، تایماوت نمیشوید.
گام ششم: مستندسازی و پروتکلنویسی برای قطعیهای آینده
دقیقا همین لحظه که درگیر حل بحران هستید، بهترین زمان برای جمعآوری دادههای ارزشمند برای تحلیل پس از حادثه است. این اطلاعات در قطعیهای احتمالی بعدی، بسیار موثر خواهند بود.
ثبت دقیق لاگهای خطا و رفتارهای سیستم در زمان اختلال
قبل از اینکه لاگهای قدیمی با لاگهای جدید بازنویسی شوند، آنها را در جایی امن ذخیره کنید.
- اسنپشات از گرافها: از داشبوردهای مانیتورینگ (Zabbix, Prometheus, Grafana) در بازه زمانی قطعی و لحظه وصل شدن خروجی بگیرید. دانستن اینکه کدام منبع (RAM یا CPU) زودتر از همه اشباع شده، گلوگاه اصلی زیرساخت شما را مشخص میکند.
- ثبت خطاهای خاص: ارورهایی که فقط در زمان اینترانت ملی رخ دادهاند را یادداشت کنید. این ارورها نشان میدهند کدام بخش از کد شما وابستگی سخت به سرویسهای خارجی دارد و باید برای آن راهکار جایگزین بنویسید.
تدوین سناریوی Disaster Recovery بر اساس تجربیات اخیر
اکنون دقیقا میدانید چه چیزی کار نمیکند. با علم به این موضوع، اقدامات زیر را انجام دهید:
- ایجاد مخازن لوکال: اگر سرور شما به دلیل عدم دسترسی به مخازن پکیجها یا Docker Hub از کار افتاد، راهاندازی یک “Local Repository Miror یا Private Registry داخل ایران را در اولویت قرار دهید.
- بازنگری در معماری: سرویسهای حیاتی را به گونهای بازطراحی کنید که در صورت قطع APIهای خارجی، کل سیستم کرش نکند.
جمعبندی
بازگشت اینترنت پس از یک دوره طولانی قطعی، پایان کار مدیر سرور نیست؛ بلکه شروع یک عملیات دقیق پاکسازی و پایدارسازی است. همانطور که روشن کردن ناگهانی برق فشار قوی میتواند به لوازم برقی آسیب بزند، باز کردن ناگهانی دریچههای ترافیک روی زیرساختی که حدود ۲۰ روز ایزوله بوده، میتواند منجر به سقوط سرویس شود. با طی کردن گامهای این مقاله، شما از مرحله مدیریت بحران به مرحله مدیریت سرویس باز میگردید.
جدول خلاصه چکلیست سلامت زیرساخت:
| اولویت | بخش مورد بررسی | اقدام عملیاتی | هدف |
| شبکه و DNS | اورژانسی | تست MTR، بررسی پکتلاس و اعتبار SSL | اطمینان از دسترسی کاربر به سرور |
| مناسب سختافزاری | اورژانسی | بررسی Load Average و فضای دیسک | جلوگیری از کرش کردن سرور زیر بار ترافیک |
| دیتابیس | بالا | چک کردن Replication Lag و سلامت دادهها | جلوگیری از ناهماهنگی و خرابی دادهها |
| وب سرور و کش | بالا | بررسی Worker Connections و فلاش کردن کش | پاسخگویی صحیح به درخواستهای جدید |
| سئو | متوسط | تست Fetch در سرچ کنسول و چک Robots.txt | بازگرداندن رباتهای گوگل به سایت |
| کرانجابها | متوسط | بررسی و حذف تسکهای منقضی شده در صف | جلوگیری از اجرای عملیات اشتباه یا تکراری |
| امنیت | کم | بررسی لاگهای Auth و آپدیت پکیجها | ایمنسازی حفرههای احتمالی دوران قطعی بعدی |
| مستندسازی | کم | آرشیو لاگها و بهروزرسانی سناریوی بازیابی فاجعه | آمادگی برای حوادث احتمالی آینده |
