وقتی ارتباط اینترنتی یک شرکت ناپایدار میشود، مشکل فقط باز نشدن وبسایتها نیست. دسترسی به سرویسهای ابری، ارتباط شعب، تلفن اینترنتی، احراز هویت و فرایند بازیابی اطلاعات هم ممکن است تحت تأثیر قرار بگیرد. این راهنمای فنی به جای پیشبینی رویدادهای سیاسی، روی اقدامهای عملی برای آمادهسازی زیرساخت IT تمرکز دارد.

اولین اثر اختلال اینترنت بر شرکتها چیست؟
سرویسهایی که به اینترنت یا DNS بیرونی وابستهاند ممکن است کند یا غیرقابلدسترس شوند. این وابستگی میتواند شامل ایمیل، VPN، سامانههای SaaS، سرویس لایسنس، مانیتورینگ ابری، تماس VoIP و بکاپ خارج از سایت باشد. شدت اثر به معماری شبکه، مسیر ارتباطی و سرویسدهنده وابسته است.
چکلیست هفتمرحلهای تابآوری شبکه
- نقشه وابستگیها: فهرست کنید کدام سرویسها بدون اینترنت خارجی متوقف میشوند و مالک هر سرویس کیست.
- ارتباط جایگزین: امکان استفاده از سرویسدهنده دوم، لینک پشتیبان و مسیر ارتباطی مستقل را بررسی کنید.
- DNS و DHCP: سرویسهای حیاتی داخلی را از وابستگی غیرضروری به سرویسهای بیرونی جدا کنید.
- بکاپ و بازیابی: نسخه پشتیبان آفلاین یا غیرقابلتغییر داشته باشید و بازیابی واقعی را آزمایش کنید.
- احراز هویت: روش ورود اضطراری و دسترسی مدیران به سامانههای داخلی را مستند و محدود کنید.
- ارتباط شعب: سناریوی قطع VPN یا تغییر مسیر WAN را از قبل آزمایش کنید.
- پایش و اطلاعرسانی: وضعیت لینکها، زمان قطعی و اثر بر سرویسهای حیاتی را ثبت کنید و راه ارتباط جایگزین با کارکنان داشته باشید.
چطور بفهمیم مشکل از ISP است یا شبکه داخلی؟
از لایه فیزیکی شروع کنید: وضعیت لینک و خطاهای اینترفیس، Gateway، پاسخ DNS داخلی، مسیرهای Routing و دسترسی به مقصدهای آزمون از چند نقطه شبکه را مقایسه کنید. فقط با یک Ping ناموفق درباره منشأ اختلال نتیجهگیری نکنید. برای تشخیص دقیقتر، زمان پاسخ و مسیر هر تست را ثبت کنید.
نقش MikroTik و FortiGate در زمان اختلال ارتباط
مانیتورینگ لینک WAN، Failover کنترلشده، ثبت NetFlow یا Traffic Flow و سیاستهای دسترسی حداقلی به مدیر شبکه کمک میکند اثر قطعی را سریعتر ببیند. تغییر مسیر ترافیک باید با کنترل DNS، NAT، VPN و الزامات امنیتی انجام شود؛ فعالکردن بیبرنامه چند لینک میتواند باعث ناپایداری بیشتر شود.
برای مدیریت مصرف و پایش کاربران، راهنمای Traffic Flow و مدیریت پهنای باند MikroTik و برای دسترسی بین دفاتر راهنمای VPN سازمانی را ببینید.
بکاپ در بحران؛ فقط داشتن فایل پشتیبان کافی نیست
بکاپی که تنها روی همان شبکه و با همان دسترسی مدیر قرار دارد، در برابر باجافزار یا خطای انسانی آسیبپذیر است. قاعده ۳-۲-۱ و آزمایش دورهای بازیابی کمک میکند زمان بازگشت سرویس را واقعبینانه برآورد کنید. نسخه آفلاین یا Immutable و مستندات بازیابی باید در برنامه تداوم کسبوکار لحاظ شوند.
برای شرکتهای ۱۰ تا ۱۰۰ کاربر از کجا شروع کنیم؟
ابتدا سه سرویس حیاتی را مشخص کنید؛ برای هرکدام مسئول، زمان قابلتحمل قطعی، وابستگیهای شبکه و روش جایگزین را ثبت کنید. سپس یک مانور کوتاه قطع اینترنت یا از دسترس خارج شدن لینک اصلی، در بازه هماهنگشده، اجرا کنید. نتایج را به برنامه اصلاحی تبدیل کنید.
سؤالات متداول
آیا داشتن اینترنت دوم همیشه مشکل را حل میکند؟
خیر. اگر دو سرویس از مسیر مشترک استفاده کنند یا مشکل مربوط به سرویس مقصد باشد، اینترنت دوم لزوماً راهگشا نیست.
آیا باید همه سرویسها را داخلی کنیم؟
خیر. تصمیم به امنیت، هزینه، قابلیت نگهداری و الزامات هر سرویس بستگی دارد؛ معماری ترکیبی ممکن است مناسبتر باشد.
آیا این مقاله درباره وقوع قطعی مشخصی خبر میدهد؟
خیر. این مطلب یک راهنمای آمادگی فنی برای سناریوهای اختلال است و وقوع رویداد مشخصی را تأیید یا پیشبینی نمیکند.
برای ارزیابی وابستگی سرویسها و طراحی برنامه تداوم کسبوکار، خدمات پشتیبانی شبکه IT Network Care را بررسی کنید.
جدول تشخیص اولیه اختلال اینترنت در شرکت
| نشانه | بررسی بعدی | اقدام قابل ثبت |
|---|---|---|
| فقط یک کاربر مشکل دارد | کابل، Wi-Fi، IP و تنظیمات دستگاه | مقایسه همان سرویس روی دستگاه سالم |
| همه کاربران یک سایت را باز نمیکنند | DNS، دسترسی مقصد و سیاست فایروال | ثبت دامنه، زمان و نوع خطا |
| اینترنت برقرار است ولی VPN قطع میشود | لاگ تونل، کیفیت لینک و مسیر مقصد | مقایسه زمان قطع با رخدادهای WAN |
| بعد از جابهجایی لینک، بعضی سامانهها قطعاند | وابستگی به IP خروجی و نشستهای موجود | فهرست سرویسهای نیازمند آزمون مجدد |
آزمون لینک پشتیبان چگونه مستند شود؟
صرف داشتن مودم دوم کافی نیست. در یک بازه هماهنگشده، مسئول اجرا، راه بازگشت و سرویسهای قابل آزمایش را مشخص کنید. نتیجه دسترسی به ایمیل، سامانه حسابداری، VPN و تلفن را جداگانه ثبت کنید؛ اتصال اینترنت به معنی سالم بودن همه سرویسها نیست. مدت تغییر مسیر، نیاز به اتصال مجدد کاربران و نتیجه بازگشت به لینک اصلی را بنویسید. این یک روش پیشنهادی آزمون است و زمان بازیابی مشخصی را تضمین نمیکند.
چه چیزهایی در گزارش حادثه بماند؟
زمان شروع و پایان، کاربران تحت تأثیر، لینک فعال، تغییرات انجامشده و شواهد علت را نگه دارید. گزارش باید فرق «علت تأییدشده» و «فرضیه نیازمند بررسی» را روشن کند. برای طراحی مسیر کاربران دورکار، راهنمای مقایسه راهکارهای VPN و برای تعیین مسئول رسیدگی، انتخاب مدل پشتیبانی شبکه را ببینید.