سایت شما هر چند ساعت یک‌بار، برای دو تا پنج دقیقه، از دسترس خارج می‌شود. بعد خودش برمی‌گردد. مانیتورینگ هاستینگ می‌گوید همه‌چیز سبز است، مشتری می‌گوید صفحه سفید دیده، و شما بین «شاید مشکل از اینترنت خودش بوده» و «حتماً یک جای کار می‌لنگد» گیر کرده‌اید. این وضعیت آزاردهنده‌ترین نوع قطعی سایت است، چون هیچ‌وقت همزمان با شما اتفاق نمی‌افتد.
اولین کاری که باید بکنید این است که قطعی را از «حس» به «عدد» تبدیل کنید. تا وقتی فقط یک روایت شفاهی دارید، هر تغییری در سرور یک شرط‌بندی است.
چرا مانیتورینگ پنل هاست قطعی سایت را نمی‌بیند
پنل‌های هاستینگ معمولاً هر ۵ دقیقه یک‌بار پینگ ICMP یا یک درخواست HTTP به صفحه اصلی می‌زنند. دو مشکل ساختاری اینجا وجود دارد. اول اینکه بازه ۵ دقیقه‌ای، قطعی‌های ۹۰ ثانیه‌ای را کامل رد می‌کند؛ اگر قطعی بین دو چک بیفتد و تا چک بعدی تمام شود، هیچ‌وقت ثبت نمی‌شود. دوم اینکه پینگ ICMP فقط می‌گوید کارت شبکه سرور جواب می‌دهد، نه اینکه PHP یا MySQL یا upstream وب‌سرور سالم است.
یک سرویس پایش بیرونی با بازه ۳۰ یا ۶۰ ثانیه راه بیندازید و آن را روی یک endpoint واقعی تنظیم کنید که به دیتابیس و کد اپلیکیشن وابسته است، نه روی یک فایل استاتیک. مثلاً یک مسیر سلامت مثل /healthz که یک کوئری سبک به دیتابیس می‌زند و کد ۲۰۰ برمی‌گرداند. اگر فقط صفحه اصلی را چک کنید، ممکن است کش صفحه را جواب بدهد و شما قطعی دیتابیس را نبینید.
نکته‌ای که کمتر گفته می‌شود: پایش از یک نقطه کافی نیست. اگر مانیتور از یک دیتاسنتر داخل ایران چک می‌کند و کاربر شما از خارج وصل می‌شود، ممکن است مشکل مسیر شبکه بین‌الملل باشد نه سرور شما. حداقل دو نقطه پایش با ISP متفاوت بگذارید. برای بررسی مسیر و رکوردهای دامنه هم می‌توانید از ابزار بررسی DNS و شبکه استفاده کنید تا ببینید در لحظه قطعی، رزولوشن دامنه درست انجام می‌شود یا نه.
همبستگی زمانی: قطعی سایت را با چه چیزی مقایسه کنیم
وقتی یک بازه قطعی ثبت شد، سؤال درست این نیست که «چرا قطع شد؟» بلکه این است که «در آن بازه دقیقاً چه چیزی روی سرور اجرا می‌شد؟». سه منبع را باید کنار هم بگذارید:
- لاگ وب‌سرور (مثلاً
/var/log/nginx/error.logو access log) با مهر زمانی دقیق - لاگ کند و کرون سیستم:
journalctl -u cron --since "2025-01-14 03:00" --until "2025-01-14 04:00" - نمودار منابع سرور (CPU، RAM، I/O دیسک) با دانه‌بندی یک‌دقیقه‌ای، نه میانگین ساعتی
در بیشتر مواردی که خودم دیده‌ام، الگو یکی از این‌هاست: یک کرون‌جاب سنگین (بکاپ، ایمپورت، پاک‌سازی جدول) که با ترافیک واقعی همزمان می‌شود؛ یا یک اسکریپت با نشتی حافظه که هر چند ساعت OOM killer را فعال می‌کند؛ یا یک فرایند خارجی مثل ربات خزشگر که با نرخ بالا صفحه‌های سنگین را می‌کوبد.
برای دیدن اینکه در لحظه قطعی چه پروسه‌ای بیشترین فشار را داشته، اگر atop نصب است از atop -r /var/log/atop/atop_20250114 -b 03:00 استفاده کنید. اگر ندارید، همین امروز نصبش کنید؛ بدون داده تاریخی، عیب‌یابی قطعی‌های نامنظم عملاً شانس است.
کرون را متهم اول نگیرید، ولی اول از همه چکش کنید
یک اشتباه رایج: مدیر سایت کرون بکاپ را غیرفعال می‌کند، دو روز خبری از قطعی نیست، و نتیجه می‌گیرد مشکل حل شد. بعد سه هفته بعد قطعی برمی‌گردد. دلیلش این است که کرون فقط همزمان‌کننده بوده، نه علت. اگر بکاپ شما ۴۰ دقیقه I/O دیسک را اشغال می‌کند و سایت روی همان دیسک سرو می‌شود، مشکل واقعی این است که بکاپ و ترافیک روی یک منبع مشترک می‌افتند. راه‌حل درست، جابه‌جایی زمان بکاپ یا محدود کردن نرخ I/O با ionice -c2 -n7 است، نه حذف بکاپ.
اینجا اشتباه می‌کنند
جمله‌ای که بیش از همه می‌شنوم: «الان که سایت بالاست، پس مشکل از سرور نیست.» این استدلال غلط است و دقیقاً همان چیزی است که عیب‌یابی را هفته‌ها عقب می‌اندازد. قطعی‌های کوتاه معمولاً از جنس اشباع لحظه‌ای هستند: یک صف پر می‌شود، یک timeout می‌خورد، یک سرویس ری‌استارت می‌شود و همه‌چیز در چند ثانیه به حالت عادی برمی‌گردد. در لحظه‌ای که شما SSH می‌زنید و همه‌چیز را سالم می‌بینید، آن پنجره بسته شده است.
نشانه‌اش هم این است: کاربر می‌گوید «۵۰۲ گرفتم»، شما در لاگ وب‌سرور خط upstream timed out (110: Connection timed out) while reading response header from upstream را می‌بینید، ولی وقتی دستی همان درخواست را می‌زنید، در ۲۰۰ میلی‌ثانیه جواب می‌گیرید. این تناقض، خودش مدرک است، نه دلیل بر بی‌گناهی سرور.
چه چیزی را اندازه بگیریم تا قطعی قابل پیش‌بینی شود
سه عدد را باید همیشه داشته باشید. اول، زمان پاسخ در صدک ۹۵ و ۹۹، نه میانگین. میانگین ۲۰۰ میلی‌ثانیه با صدک ۹۹ برابر ۸ ثانیه، یعنی بخشی از کاربران شما عملاً سایت را باز نمی‌کنند. دوم، تعداد کانکشن‌های فعال در برابر سقف تنظیم‌شده؛ اگر worker_connections روی ۱۰۲۴ است و در ساعات اوج به ۹۰۰ می‌رسید، شما فاصله کمی با قطعی دارید. سوم، مصرف حافظه پروسه‌های PHP-FPM یا اپلیکیشن، به‌صورت جداگانه برای هر pool.
| روش پایش | چه چیزی را می‌گیرد | چه چیزی را از دست می‌دهد |
|---|---|---|
| پینگ ICMP هر ۵ دقیقه | خاموشی کامل سرور | قطعی اپلیکیشن، قطعی دیتابیس، بازه‌های کوتاه |
| HTTP check هر ۳۰ ثانیه روی /healthz | خطای کد، قطعی دیتابیس، کندی شدید | مشکل مسیر شبکه برای کاربران خاص |
| لاگ‌محور با هشدار روی نرخ خطا | الگوهای تدریجی، خطاهای پراکنده | وقتی خود سرور لاگ نمی‌نویسد |
اگر سایت شما روی یک سرور اشتراکی یا یک VPS کوچک است و کنترل لازم برای نصب agent ندارید، ترکیب پایش بیرونی HTTP با لاگ‌های خود اپلیکیشن کافی است. اما وقتی ترافیک بالا می‌رود و قطعی‌ها هزینه واقعی دارند، سرور اختصاصی این امکان را می‌دهد که خودتان کرنل، پارامترهای شبکه و زمان‌بندی کرون را کنترل کنید؛ چیزی که در محیط اشتراکی در دسترس نیست.
بکاپ، بازیابی و تفاوتشان در لحظه قطعی
یک نکته که در بحران معلوم می‌شود: بکاپ داشتن با بازیابی سریع داشتن یکی نیست. اگر بکاپ شما ۲۰ گیگابایت است و روی همان سرور ذخیره شده، در قطعی دیسک هیچ‌کدام از این دو را ندارید. بکاپ را روی مقصد جدا بگذارید و حداقل یک‌بار در ماه زمان بازیابی واقعی را اندازه بگیرید. عددی که به دست می‌آید (مثلاً ۴۵ دقیقه برای بازگرداندن کامل) همان چیزی است که باید به ذی‌نفعان بگویید، نه «بکاپ داریم».
برای سایت‌هایی که روی هاست مدیریت‌شده اجرا می‌شوند، هاست لینوکس با ابزارهای استاندارد مدیریت فایل و دیتابیس، کار بازیابی و بررسی لاگ را ساده‌تر می‌کند؛ ولی همچنان باید خودتان بدانید کدام جدول چقدر بزرگ است و بازیابی‌اش چقدر طول می‌کشد.
چک‌لیست عملی برای امشب
- یک endpoint سلامت بسازید که به دیتابیس وابسته باشد و آن را با بازه ۳۰ ثانیه از دو نقطه پایش کنید.
- لاگ‌های وب‌سرور و کرون را با مهر زمانی یکسان به یک مقصد مرکزی بفرستید تا همبستگی ممکن شود.
- نمودار منابع را با دانه‌بندی یک‌دقیقه‌ای ذخیره کنید، نه میانگین ساعتی.
- زمان‌بندی کرون‌های سنگین را با ساعات اوج ترافیک مقایسه کنید و در صورت تداخل، جابه‌جا یا محدودشان کنید.
- یک‌بار بازیابی از بکاپ را تمرین کنید و زمان واقعی‌اش را یادداشت کنید.
اگر می‌خواهید قبل از هر تغییر زیرساختی، تصویر دقیق‌تری از وضعیت فعلی سایت بگیرید، از ابزارهای رایگان وب‌مستر برای بررسی سرعت و پاسخ‌دهی استفاده کنید. و اگر بعد از این مراحل هنوز الگو پیدا نکردید، احتمالاً مشکل در لایه‌ای است که اندازه‌گیری نمی‌کنید؛ معمولاً DNS یا مسیر شبکه. در بلاگ سرورنت نمونه‌های واقعی این نوع عیب‌یابی مستند شده است.
پرسش‌های پرتکرار
چرا سایت من فقط برای بعضی کاربران قطع می‌شود؟
معمولاً یعنی مشکل در سرور نیست، در مسیر رسیدن به سرور است. تفاوت DNS resolver، مسیر بین‌الملل، یا حتی کش DNS محلی کاربر می‌تواند باعث شود یک نفر سایت را ببیند و نفر دیگر نه. برای تشخیص، از چند نقطه جغرافیایی مختلف تست کنید و نتیجه رزولوشن دامنه را با هم مقایسه کنید.
آیا قطعی‌های چند ثانیه‌ای واقعاً مهم هستند؟
بله، اگر روی endpointهایی بیفتند که کاربر در حال انجام تراکنش است. یک قطعی ۱۰ ثانیه‌ای در میانه پرداخت، سفارش را نیمه‌کاره می‌گذارد و ممکن است داده ناسازگار بسازد. علاوه بر این، خزشگرها هم این خطاها را می‌بینند و روی رتبه صفحه اثر می‌گذارد.
چه بازهای برای پایش مناسب است؟
برای سایتهای تجاری، ۳۰ تا ۶۰ ثانیه نقطه شروع معقولی است. بازه کوتاهتر از ۳۰ ثانیه معمولاً هزینه و نویز هشدار را بالا میبرد بدون اینکه چیز جدیدی نشان دهد، مگر اینکه SLA شما واقعاً سختگیرانه باشد.
چطور بفهمم قطعی از دیتابیس است یا از وب‌سرور؟
یک endpoint سلامت جداگانه برای دیتابیس بسازید که فقط یک کوئری ساده می‌زند. اگر آن endpoint در بازه قطعی خطا داد ولی صفحه استاتیک سالم بود، مشکل دیتابیس است. اگر هر دو خطا دادند، احتمالاً مشکل در لایه وب‌سرور یا شبکه است.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!