وقتی سایت ناگهان Down می‌شود، عجله برای restart همه سرویس‌ها قابل‌درک است؛ اما این کار هم دامنه خرابی را بیشتر می‌کند و هم شواهد علت را از بین می‌برد. قطعی ممکن است از DNS، شبکه، TLS، reverse proxy، برنامه، دیتابیس، دیسک پر یا کمبود حافظه باشد. پاسخ حرفه‌ای ابتدا اثر را محدود و لایه خراب را مشخص می‌کند.
پاسخ سریع: زمان شروع و پیام دقیق کاربر را ثبت کنید، از چند مسیر وضعیت DNS و TCP/TLS/HTTP را بسنجید و آخرین تغییر را متوقف کنید. سپس از بیرون به داخل—DNS، شبکه، proxy، برنامه و dependency—پیش بروید. اگر اقدام بازیابی لازم است، قبل از آن snapshot لاگ و وضعیت منابع را نگه دارید و یک تغییر در هر مرحله انجام دهید.
اول ایمنی و ارتباط، بعد عیب‌یابی
incident commander یا مسئول تصمیم را مشخص کنید تا چند نفر هم‌زمان config را تغییر ندهند. زمان‌ها، فرمان‌ها، نتیجه‌ها و تصمیم‌ها را در timeline ثبت کنید. اگر قطعی عمومی است، پیام وضعیت کوتاه و واقع‌گرایانه بدهید؛ زمان رفع حدسی یا علت تأییدنشده اعلام نکنید. دسترسی و secret را در کانال عمومی نفرستید.
Down برای همه یا فقط برای یک کاربر؟
- از شبکه موبایل و یک مسیر مستقل آزمون کنید.
- دامنه اصلی و یک hostname مستقیم کنترل‌شده را مقایسه کنید.
- IPv4 و IPv6 را در صورت فعال بودن جدا ببینید.
- کاربر واردشده و ناشناس را تفکیک کنید.
- همه صفحات یا فقط عملیات dynamic را بررسی کنید.
خطای یک ISP، cache مرورگر یا DNS محلی با قطعی عمومی فرق دارد. در مقابل، سالم بودن صفحه اصلی cacheشده ثابت نمی‌کند Checkout یا API سالم است. معیار را بر اساس journey واقعی کاربر انتخاب کنید.
پیام خطا را به لایه تبدیل کنید
| نشانه | لایه‌های محتمل | بررسی نخست |
|---|---|---|
| دامنه resolve نمی‌شود | DNS، registrar، DNSSEC | رکورد و nameserver معتبر |
| Connection refused | listener، firewall، سرویس | پورت از بیرون و ss |
| Connection timeout | route، firewall، provider | مسیر شبکه و وضعیت provider |
| TLS error | certificate، SNI، chain، زمان | hostname و اعتبار گواهی |
| 502/504 | proxy و upstream | error log و وضعیت backend |
| 500 | برنامه و dependency | application/PHP log |
یک Snapshot کم‌ریسک از سرور
date --iso-8601=seconds
uptime
free -h
df -h
df -i
ss -lntp
systemctl --failedاین خروجی زمان، load، memory، disk، inode، listener و unitهای failed را نشان می‌دهد و تغییری ایجاد نمی‌کند. اطلاعات IP، hostname خصوصی و نام سرویس محرمانه را پیش از اشتراک حذف کنید. snapshot لحظه‌ای باید با monitoring پیش از قطعی مقایسه شود.
مرحله اول: DNS
رکورد A/AAAA، CNAME، nameserver و وضعیت DNSSEC را از resolverهای مستقل بررسی کنید. تغییر اخیر، رکورد منقضی یا IPv6 اشاره‌کننده به سرور آماده‌نشده می‌تواند فقط بخشی از کاربران را قطع کند. TTL پایین انتشار را سریع‌تر می‌کند اما خطای رکورد را درست نمی‌کند. تغییر چند رکورد هم‌زمان تشخیص را دشوار می‌سازد.
مرحله دوم: شبکه و Port
ببینید IP پاسخ می‌دهد و portهای 80/443 از بیرون قابل دسترسی‌اند. ping معیار قطعی HTTP نیست و ممکن است عمداً بسته باشد. اگر روی host listener وجود دارد ولی از بیرون اتصال نمی‌رسد، cloud firewall، host firewall، route یا provider را بررسی کنید. rule مدیریتی را بدون console اضطراری تغییر ندهید.
مرحله سوم: TLS
گواهی باید برای hostname درست، در بازه اعتبار و با chain کامل ارائه شود. clock اشتباه سرور یا client نیز اعتبار زمانی را خراب می‌کند. اگر renewal انجام شده ولی سرویس certificate قدیمی را ارائه می‌دهد، ممکن است path یا reload اشتباه باشد. HSTS می‌تواند bypass موقت HTTP را برای کاربر ناممکن کند؛ آن را بدون برنامه دستکاری نکنید.
مرحله چهارم: Nginx یا وب‌سرور
status سرویس، config test، listener و error log را بررسی کنید. active بودن process به معنی route درست نیست؛ یک درخواست محلی با Host صحیح انجام دهید. اگر config جدید syntax نامعتبر دارد ممکن است reload رد شده و process قدیمی هنوز فعال باشد، یا پس از restart دیگر بالا نیاید. برای ساختار درست، کانفیگ Nginx وردپرس را ببینید.
مرحله پنجم: برنامه و Runtime
PHP-FPM، application server یا container باید running و آماده پاسخ باشد. log startup، exit code، restart count و healthcheck را ببینید. خطای 502 Bad Gateway معمولاً ارتباط proxy و upstream را هدف می‌گیرد؛ 504 بیشتر با انتظار طولانی و queue سازگار است.
مرحله ششم: دیتابیس و سرویس‌های وابسته
برنامه ممکن است اجرا باشد اما منتظر دیتابیس، Redis، storage، DNS یا API بیرونی بماند. connection، latency، pool و authentication را طبق log بررسی کنید. تغییر رمز یا certificate dependency پس از deploy سناریوی رایجی است. credential را برای آزمون در command line یا log چاپ نکنید.
دیسک پر و Inode تمام‌شده
دیسک ۱۰۰٪ می‌تواند database write، session، log و startup را متوقف کند. inode نیز ممکن است با وجود فضای ظاهری تمام شود. پیش از حذف، مصرف را شناسایی کنید و فایل بازشده توسط process را در نظر بگیرید. حذف تصادفی دیتابیس، volume یا backup قابل بازگشت نیست؛ پاک‌سازی production باید هدف دقیق، retention و backup داشته باشد.
RAM، Swap و OOM Killer
اگر kernel برای آزاد کردن حافظه process حیاتی را کشته باشد، restart فقط چرخه را تکرار می‌کند. eventهای kernel، مصرف قبل از قطعی و memory هر process را ببینید. افزایش worker یا cache بدون بودجه حافظه می‌تواند عامل اصلی باشد. memory leak، burst ترافیک و job هم‌زمان را از هم تفکیک کنید.
CPU، Load و I/O
CPU صددرصد، load بالا و I/O wait سه وضعیت متفاوت‌اند. process مصرف‌کننده، زمان شروع و workload را پیدا کنید. backup، compression، crawler، Query یا job زمان‌بندی‌شده ممکن است با ترافیک هم‌پوشانی داشته باشد. kill کردن process ناشناس می‌تواند write را ناقص کند؛ ابتدا نقش و اثر آن را مشخص کنید.
آیا Deploy اخیر عامل قطعی است؟
نسخه image، commit، migration، config و زمان deploy را با شروع incident مقایسه کنید. correlation علت قطعی نیست، اما rollback را به گزینه‌ای قابل بررسی تبدیل می‌کند. rollback فقط وقتی امن است که schema و داده جدید با نسخه قبلی سازگار باشند. deploy دستی بدون manifest دقیق بازگشت قابل اعتماد ندارد.
بازیابی سرویس با کمترین تغییر
- شواهد و وضعیت فعلی را ثبت کنید.
- لایه خراب و اثر کاربر را مشخص کنید.
- اگر تغییر اخیر واضح و rollback امن است، بازگشت کنترل‌شده انجام دهید.
- در غیر این صورت فقط سرویس معیوب را پس از فهم failure start/reload کنید.
- health فنی و journey اصلی کاربر را آزمون کنید.
- metric و log را برای بازگشت خطا زیر نظر بگیرید.
بالا آمدن process پایان incident نیست. DNS، TLS، صفحه dynamic، login و عملیات حیاتی باید از بیرون تأیید شوند. اگر داده در صف مانده یا callback تکرار می‌شود، reconciliation لازم است.
چه کارهایی وضعیت را بدتر می‌کند؟
- restart هم‌زمان وب، برنامه و دیتابیس
- پاک کردن log و cache بدون فرضیه
- خاموش کردن firewall یا امنیت برای تست عمومی
- حذف فایل بزرگ بدون شناخت مالک و backup
- افزایش همه timeoutها و limitها
- تغییر DNS و سرور در یک زمان
- load test روی سامانه نیمه‌خراب
- اعلام علت پیش از تأیید شواهد
بعد از احیا: Root Cause Analysis
timeline، trigger، علت فنی، عوامل تشدیدکننده، دلیل دیر تشخیص دادن و دلیل طولانی شدن بازیابی را ثبت کنید. RCA برای مقصر پیدا کردن نیست؛ باید اقدام قابل مالکیت با deadline بسازد. «مانیتورینگ بهتر شود» اقدام مبهم است؛ alert مشخص برای disk trend یا restart count قابل پیگیری است.
پیشگیری عملی
- مانیتورینگ بیرونی DNS، TLS و HTTP
- metric منابع، queue، dependency و نرخ خطا
- alert با مسئول، severity و runbook
- backup بازیابی‌شده و RPO/RTO آزموده
- deploy مرحله‌ای با rollback
- ظرفیت‌سنجی و load test کنترل‌شده در staging
- console اضطراری و دسترسی‌های جدا
- ثبت تغییر و نگهداری config نسخه‌دار بدون secret
چک‌لیست کانفیگ اولیه لینوکس baseline دسترسی، backup و monitoring را برای پیشگیری از incident پوشش می‌دهد.
چه زمانی کمک تخصصی لازم است؟
اگر قطعی تکرار می‌شود، علت پس از restart ناپدید می‌ماند یا چند لایه زیرساخت درگیرند، دستکاری بیشتر production ریسک از دست رفتن شواهد و داده را دارد. مدیریت ماهانه سرور می‌تواند پاسخ incident، correlation لاگ‌ها، RCA و اقدام پیشگیرانه را در یک روند قابل پیگیری انجام دهد.
پرسش‌های متداول
اولین کار هنگام Down شدن سایت چیست؟
زمان و دامنه اثر را ثبت کنید و از بیرون DNS/TLS/HTTP را بسنجید؛ قبل از restart، snapshot لاگ و منابع را نگه دارید.
اگر سرور ping می‌شود یعنی سالم است؟
خیر. ping فقط بخشی از دسترسی شبکه را نشان می‌دهد و سلامت port، TLS، وب‌سرور، برنامه و دیتابیس را ثابت نمی‌کند.
آیا reboot سرور راه‌حل مناسبی است؟
فقط وقتی علت یا runbook آن را توجیه می‌کند. reboot کور شواهد را کم می‌کند و ممکن است سرویس‌های auto-start نشده را نیز آشکار کند.
چرا سایت بعد از restart دوباره Down می‌شود؟
علت ریشه‌ای مانند leak حافظه، دیسک پر، job سنگین یا dependency خراب باقی مانده است؛ metric و log بازه قبل از هر قطعی را مقایسه کنید.