مانیتورینگ آپتایم سایت؛ چه چیزهایی را باید زیر نظر داشت؟

کاری که مانیتورینگ آپتایم سایت برات می کنه ساده ست: یه ابزار هر یک تا چند دقیقه سایتت رو از بیرون امتحان می کنه، و اگه باز نشد، کند شد یا محتوای درست نشون نداد، همون لحظه خبرت می کنه. برای شروع لازم نیست سراغ سامانه های سنگین بری. پنج چیز کافیه: در دسترس بودن صفحه های مهم، زمان پاسخ، درست بودن محتوا، تاریخ انقضای SSL و دامنه، و یه مسیر هشدار که واقعاً کسی ببینه. توی این راهنما قدم به قدم جلو می ریم تا آخرش برنامه ای داشته باشی که توی یه بعدازظهر اجرا می شه.

بیشتر صاحب کسب و کارها وقتی از قطعی سایت خبردار می شن که یکی بهشون بگه: مشتری، همکار یا یه پیام توی دایرکت. یعنی سایت مدتی پایین بوده و تو اون مدت هیچ کس چیزی نگفته. هدف اینه که این ترتیب عوض بشه.

گام اول: «پایین بودن سایت» برای کسب و کار تو یعنی چی؟

قبل از انتخاب هر ابزاری باید مشخص کنی چی برات «خرابی» حساب می شه. ابزار فقط چیزی رو چک می کنه که تو بهش بگی.

فقط صفحه های مهم رو فهرست کن

لازم نیست کل سایت زیر نظر باشه. یه فهرست پنج تا هشت آدرسی کافیه: صفحه اصلی، ورود، سبد خرید، صفحه شروع پرداخت، فرم تماس و اگه اپلیکیشن داری، یکی دو آدرس API که اپ بهشون وابسته ست. هر چی این فهرست کوتاه تر و دقیق تر باشه، هشدارها قابل اعتمادتر می شن.

خرابی رو از چشم مشتری تعریف کن

صفحه باز می شه ولی دکمه «پرداخت» به جایی نمی ره؟ برای مشتری سایت پایینه، حتی اگه سرور روشن باشه. صفحه محصول بعد از ده ثانیه بالا میاد؟ خیلی ها تا اون موقع رفتن. پس دو تا سؤال رو برای خودت جواب بده: چی باید کار کنه تا بگیم سایت سالمه؟ و چند ثانیه کندی هنوز قابل تحمله؟

یه تشبیه کمک می کنه. مغازه ای رو در نظر بگیر که در بازه ولی فروشنده پشت پیشخوان نیست. اگه فقط بپرسی «در باز؟»، جواب همیشه «آره»ست. بررسی ساده «سایت جواب می ده؟» هم فقط باز بودن در رو می بینه، نه حضور فروشنده رو.

یه سناریوی فرضی

فرض کن یه فروشگاه اینترنتی برای شب یلدا یا جشنواره آخر سال کمپین گذاشته. ساعت ۱۱ شب صفحه پرداخت خطا می ده. صاحب فروشگاه از یه پیام ناراحت توی اینستاگرام می فهمه. تا بره سراغ برنامه نویس و اون جواب بده، پرترافیک ترین ساعت کمپین گذشته. این ماجرا واقعی نیست، ولی برای هر فروشگاهی که فروشش توی چند شب مشخص جمع می شه، اتفاق بعیدی هم نیست. نتیجه ش روشنه: مانیتورینگ باید زودتر از مشتری خبردار بشه.

یه جدول کوچک برای تصمیم گیری

این جدول رو چاپ کن یا توی یه فایل بذار. اولویت بندی هشدارها بعداً از همینجا درمیاد.

گام دوم: مانیتورینگ آپتایم سایت باید چی رو زیر نظر داشته باشه؟

پنج چیز هست که بدون اون ها، پایش سایتت ناقصه. چهار تاش رو همینجا می گیم. پنجمی، یعنی هشدار، می ره برای گام پنجم.

۱. در دسترس بودن (HTTP/HTTPS)

ابزار یه درخواست می فرسته و کد پاسخ رو می خونه. کد ۲۰۰ یعنی ظاهراً سالمه. خطاهای ۵۰۰ و ۵۰۲ و ۵۰۳ یعنی سمت سرور یه جای کار می لنگه، و تایم اوت یعنی اصلاً جوابی نیومده.

چرا فقط پینگ سرور کافی نیست؟ چون پینگ فقط می گه ماشین روشنه. ممکنه وب سرور یا پایگاه داده خوابیده باشه و سرور هنوز به پینگ جواب بده. مشتری هم با پینگ سایت نمی خره، با صفحه می خره. بررسی HTTP یا HTTPS روی آدرس واقعی صفحه، نزدیک ترین کار به رفتار مشتریه.

یه نکته: آدرس نهایی رو بذار، یعنی همونی که بعد از ریدایرکت ها بالا میاد. اگه آدرس چند بار ریدایرکت بشه، یه مشکل کوچیک توی یکی از حلقه ها می تونه هشدار بی دلیل بسازه یا بدتر، خرابی واقعی رو پنهون کنه.

۲. درست بودن محتوا (Keyword Check)

اینجا ابزار یه عبارت ثابت رو توی صفحه جست وجو می کنه، مثلاً نام برند توی فوتر یا یه کلمه توی صفحه محصول. چرا مهمه؟ چون «صفحه سالم ولی خالی» وجود داره. وردپرس بعد از یه به روزرسانی ناموفق ممکنه صفحه سفید بده یا پیام «خطا در برقراری ارتباط با پایگاه داده» نشون بده. بعضی از این خطاها، مخصوصاً وقتی کش یا پروکسی وسطه، با کد ۲۰۰ برمی گردن. اون موقع بررسی کد پاسخ می گه همه چیز خوبه، ولی مشتری یه صفحه خراب می بینه.

عبارتی رو انتخاب کن که فقط توی صفحه سالم هست و تغییر نمی کنه. اسم محصول یا قیمت مناسب نیست، چون عوض می شه. اگه وردپرس داری، این بررسی بعد از هر آپدیت جواب سریع بهت می ده. مراحل قبل از آپدیت رو هم توی به روزرسانی امن وردپرس؛ مراحل پیش از زدن دکمه Update نوشتیم.

۳. زمان پاسخ

سایتی که باز می شه ولی کنده، معمولاً داره خبر بدتری می ده: دیسک در حال پر شدن، پایگاه داده ای با کوئری های سنگین، یا ترافیکی که از ظرفیت سرور بیشتره. کندی اغلب جلوتر از قطعی میاد.

عدد جادویی ای نیست که برای همه جواب بده. یه هفته معمولی رو ثبت کن و ببین سایتت عادتاً چقدر جواب می ده. مثلاً اگه صفحه ت معمولاً زیر دو ثانیه جواب می ده، هشدار رو روی «چند بررسی پشت سر هم بالاتر از این حد» بذار، نه روی یه جهش تکی. ساعت های اوج ترافیک رو هم جدا نگاه کن، چون شب ها یا روزهای کمپین همون سایت می تونه رفتار دیگه ای داشته باشه.

یه چیز که اغلب نادیده گرفته می شه: اگه اسکریپت درگاه پرداخت، نماد اعتماد یا ابزار تحلیل از منبع بیرونی لود بشه و اون منبع کند باشه، سایت تو هم کند دیده می شه، حتی اگه سرورت سالم باشه. وقتی زمان پاسخ بالا رفت، این رو هم توی فهرست مظنون ها نگه دار.

۴. SSL و دامنه

وقتی گواهی SSL منقضی بشه، مرورگر به مشتری اخطار قرمز نشون می ده و خیلی ها برمی گردن. تمدید خودکار معمولاً کار می کنه، ولی اگه خراب بشه، معمولاً بی صدا خراب می شه. تاریخ انقضا رو مانیتور کن و هشدار رو حدود دو هفته قبل از انقضا بذار، نه دو روز قبل. اگه با وجود گواهی هنوز اخطار می گیری، خطای SSL؛ چرا با وجود گواهی سایت اخطار می دهد؟ رو بخون.

دامنه هم همین طوره، ولی بدتر. دامنه منقضی شده یعنی سایت و ایمیل سازمانی، هر دو با هم می میرن. بعضی ابزارها ممکنه اطلاعات انقضای دامنه های ir رو درست نخونن، پس یه یادآور تقویمی هم جدا بذار. برای دامنه ir، شناسه ایرنیک هم باید دست خودت باشه تا تمدید گیر نکنه. شناسه نیک ایرنیک چیست و چرا برای دامنه ir لازم است؟ توضیحش رو داده.

۵. هشدار

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

گام سوم: ابزار رو انتخاب کن و جاش رو درست بذار

اصل اول: مانیتور باید بیرون از چیزی باشه که مانیتور می کنه. اگه ابزار روی همون سروری باشه که سایت روشه، با خود سایت می خوابه و هیچ هشداری نمی ده. یعنی دقیقاً وقتی بیشتر از همه لازمش داری، ساکته.

دو راه معمول

راه اول سرویس های آماده ست که معمولاً یه پلن رایگان محدود دارن. محدودیت ها و قیمت ها زود عوض می شن، پس قبل از تصمیم، شرایط فعلی شون رو بخون. راه دوم ابزار متن بازی مثل Uptime Kuma ئه که خودت روی یه سرور کوچیک جدا نصبش می کنی. این راه کنترل بیشتری می ده و وابسته به سرویس خارجی نیستی، ولی نگهداری ش با خودته.

اگه تصمیم گرفتی خودت نصب کنی و داکر روی ماشین نیست، اول نصب داکر روی اوبونتو؛ چک لیست اولیه قبل از اجرای سرویس ها رو ببین. بعدش اجراش شبیه این می شه (قبل از اجرا، مستندات خود پروژه رو برای دستور و تگ فعلی چک کن):

docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma louislam/uptime-kuma:1

مانیتور از کجا چک کنه؟ توی ایران این مهمه

شرایط ایران اینجا بازی رو عوض می کنه. اگه مانیتورت بیرون از کشوره و کاربرهات ایرانی ان، ممکنه اختلال اینترنت بین الملل باعث بشه ابزار سایتت رو «پایین» ببینه، در حالی که مشتری های داخل ایران بدون مشکل کار می کنن. برعکسش هم پیش میاد: مانیتور داخل ایران ممکنه نبینه که کاربر خارجی یا سرویس بیرونی که به API تو وصله، دسترسی نداره.

راه حل ساده ش اینه که اگه می تونی، از دو نقطه چک کنی: یکی داخل ایران و یکی بیرون. اگه هر دو گفتن پایینه، خرابی واقعیه. اگه فقط یکی گفت، احتمالاً مشکل از مسیر شبکه ست و اولویت با مخاطب اصلی خودته. برای فروشگاه ایرانی، دید داخل ایران مهم تره.

یه بررسی دستی سریع

قبل از اینکه همه چیز رو بسپاری به ابزار، با این دستور از ترمینال می تونی کد پاسخ و زمان کل رو ببینی (آدرس رو با سایت خودت عوض کن):

curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://example.ir/

خروجی مثل 200 0.84 یعنی کد ۲۰۰ و زمان حدود ۰٫۸ ثانیه. این عدد یه نقطه مرجع می ده که بعداً آستانه هشدار رو ازش بسازی.

مراقب فایروال خودت باش

اگه روی سرور محدودیت نرخ درخواست یا قاعده های سخت گیرانه گذاشتی، ممکنه IP مانیتور مسدود بشه و هشدار الکی بگیری. IP ابزار رو توی لیست مجاز بذار. اگه تازه داری فایروال می چینی، تنظیم فایروال UFW روی سرور اوبونتو؛ قاعده های ضروری نقطه شروع خوبیه.

گام چهارم: بازه بررسی و آستانه ها رو درست تنظیم کن

اینجاست که بیشتر مانیتورینگ ها یا بی خاصیت می شن یا مزاحم.

هر چند دقیقه یه بار؟

بازه یک تا پنج دقیقه برای بیشتر کسب و کارهای کوچیک و متوسط کافیه. کوتاه تر از یک دقیقه معمولاً فقط نویز تولید می کنه. ولی این رو فراموش نکن: زمان کشف قطعی تقریباً می شه بازه بررسی ضربدر تعداد تلاش های تأیید. اگه هر پنج دقیقه چک کنی و دو بار پشت سر هم شکست رو تأیید بگیری، ممکنه تا ده دقیقه خبردار نشی. برای صفحه پرداخت یه فروشگاه شاید این زیاد باشه. برای وبلاگ شرکتی نه.

هشدار باید تأییدشده باشه

یه شکست تکی معمولاً فقط یه اتفاق گذرا توی شبکه ست. دو یا سه بررسی ناموفق پشت سر هم قبل از ارسال هشدار، جلوی بیشتر هشدارهای الکی رو می گیره. استثناش صفحه پرداخته. اونجا شاید بخوای زودتر خبردار بشی و هشدار الکی رو تحمل کنی، چون هزینه نشنیدن گرون تره.

درگاه پرداخت رو چطور پایش کنی؟

خود درگاه پرداخت بیرون از کنترل توئه و نمی تونی کامل زیر نظرش بگیری. چیزی که می شه چک کرد، صفحه ایه که مشتری رو به درگاه می فرسته: اینکه تا مرحله ریدایرکت درست کار می کنه. خرید آزمایشی خودکار با پول واقعی رو هم بدون هماهنگی با ارائه دهنده درگاه و بررسی قوانینش راه نندازی.

وقتی خودت سایت رو می بندی

تعمیر برنامه ریزی شده رو یادت نره. اگه سایت رو برای کار فنی می بندی، دو کار بکن. اول مانیتور رو موقتاً متوقف کن تا هشدار الکی نیاد. دوم، صفحه تعمیر رو با کد ۲۰۰ برنگردون. بهتره کد ۵۰۳ همراه سرآیند Retry-After برگردونه تا موتورهای جست وجو بفهمن این وضعیت موقتیه.

چقدر قطعی قابل تحمله؟

برای تصمیم گیری درباره هزینه، یه حساب ساده کمک می کنه. آپتایم ۹۹ درصد توی یه ماه سی روزه یعنی حدود هفت ساعت قطعی مجاز. آپتایم ۹۹٫۹ درصد یعنی حدود ۴۳ دقیقه. فاصله این دو عدد کوچیک به نظر میاد، ولی رسیدن به عدد بالاتر خیلی گرون تره: برای ۹۹٫۹ اغلب به سرور یدک، پشتیبان گیری سریع و پشتیبانی شبانه روزی نیاز داری. از خودت بپرس: برای کسب و کار من یه ساعت قطعی در بدترین زمان ماه چقدر خسارت داره؟ اگه جوابش از هزینه زیرساخت بیشتره، سرمایه گذاری معنا داره.

گام پنجم: هشدارت رو جوری بساز که واقعاً دیده بشه

قشنگ ترین داشبورد دنیا هم بدون هشدار فقط یه نمودار بی مصرفه.

کانال هشدار رو با عادت تیم انتخاب کن

مهم نیست کدوم پیام رسان؛ مهم اینه که تیمت واقعاً بازش کنه. ایتا، تلگرام، واتساپ یا هر چیزی که تیمت باهاش راحته. برای موارد بحرانی مثل صفحه پرداخت، پیامک هم اضافه کن، چون اینترنت موبایل ممکنه قطع باشه ولی پیامک می رسه. ایمیل رو هم به عنوان پشتیبان نگه دار.

یه تله رایج: ایمیل هشدار رو روی دامنه یا سروری نذار که خودش مانیتور می شه. اگه سرور بخوابه، ایمیلی که قرار بود خبرت کنه هم نمی رسه.

مشخص کن کی جواب می ده

هشداری که معلوم نیست مال کیه، مال هیچ کس نیست. بنویس نفر اول کیه و اگه ظرف حدود ده دقیقه جواب نداد، هشدار به نفر دوم بره. توی تیم کوچیک، این «نفر دوم» ممکنه خود صاحب کسب و کار یا پشتیبانی بیرونی باشه.

هشدار بحرانی و هشدار معمولی رو جدا کن

هر هشداری نباید ساعت سه صبح بیدارت کنه. یه تقسیم بندی ساده:

• بحرانی: سایت یا پرداخت پایینه. هر ساعت از شبانه روز، با پیامک و پیام رسان.
• معمولی: کندی طولانی، SSL که کمتر از دو هفته به انقضاش مونده، دامنه نزدیک تمدید. فقط ساعت کاری.

اگه همه هشدارها شبیه هم باشن و زیاد بیان، تیم یاد می گیره نادیده شون بگیره. این خطرناک ترین حالته، چون هشدار واقعی هم مثل نویز رد می شه.

هشدار بازیابی هم بساز و ماهی یه بار تست کن

وقتی سایت برگشت، یه پیام «برگشت» هم بیاد تا لازم نباشه دستی بررسی کنی. ماهی یه بار هم یه مانیتور آزمایشی رو عمداً خراب کن تا مطمئن بشی هشدار واقعاً به همه می رسه. کانالی که ماه ها تست نشده، احتمالاً یه جاش شکسته.

خلاصه روزانه یا هفتگی

فقط واکنش نشون نده؛ گاهی به الگو نگاه کن. قطعی ها رو یه جا ثبت کن و هفته ای ده دقیقه مرورشون کن: کدوم ساعت ها کندی بیشتره؟ کدوم صفحه بیشتر خطا می ده؟ اینطوری مشکل قبل از تماس مشتری دیده می شه. اگه نمی خوای این بخش رو خودت بسازی، مانیتورینگ و پایداری رو هم می شه به تیم سپرد.

گام ششم: وقتی هشدار اومد، دقیقاً چی کار کنی؟

ساعت دو بامداد پیام «سایت پایینه» میاد و ذهن آدم خوب کار نمی کنه. پس از قبل یه ترتیب ثابت بنویس:

1. اول تأیید کن. با curl یا از یه شبکه دیگه (مثلاً اینترنت موبایل) نگاه کن. شاید مشکل از مسیر خودته.
2. ببین کل سایت پایینه یا یه صفحه. اگه فقط یه صفحه خرابه، مشکل احتمالاً توی کد یا پایگاه داده ست، نه سرور.
3. دامنه و DNS رو چک کن. دامنه منقضی نشده؟ اگه تازه نیم سرور عوض کردی، اختلال تا چند ساعت طبیعیه. تغییر نیم سرور دامنه؛ مراحل درست و زمان انتظار رو ببین.
4. گواهی SSL رو چک کن. منقضی نشده و درست نصب شده؟
5. سرور رو نگاه کن. دیسک پر نشده؟ حافظه تموم نشده؟ وب سرور و پایگاه داده روشن ان؟
6. آخرین تغییر رو بپرس. آپدیت، دیپلوی یا تغییر تنظیمات؟ اگه آره، اول برگردون، بعد دنبال علت بگرد.
7. اگه محتوای عجیب می بینی (تبلیغ، صفحه ناشناس، ریدایرکت غیرمنتظره)، به هک شدن هم شک کن و پاکسازی بدافزار وردپرس: نشانه های هک شدن و مسیر درست تمیزکاری رو بخون.
8. ثبت کن. ساعت شروع، ساعت پایان و علت. بعداً همین یادداشت ها نشون می دن مشکل تکراری کجاست.

اشتباه های رایجی که مانیتورینگ رو بی اثر می کنن

• فقط صفحه اصلی رو چک کردن. صفحه اصلی معمولاً از کش جواب می ده و ممکنه سبد خرید خراب باشه بدون اینکه کسی بفهمه. حداقل یه صفحه که به پایگاه داده می رسه رو اضافه کن.
• مانیتور روی همون سرور سایت. بالاتر گفتیم؛ با هم می خوابن.
• آستانه خیلی حساس. هر هشدار الکی از اعتماد تیم به سیستم کم می کنه.
• هشدار برای یک نفر. اون یک نفر مسافرته یا گوشی ش خاموشه.
• فراموش کردن تعمیر برنامه ریزی شده. اگه مانیتور رو متوقف نکنی، شب تعمیر پر از هشدار می شه.
• بی توجهی به SSL و دامنه. پرهزینه ترین قطعی ها اغلب از سرور نمیان، از یه تاریخ فراموش شده میان.
• چک کردن فقط از یه نقطه. فقط داخل یا فقط بیرون ایران، نیمی از واقعیت رو نشون می ده.
• تنظیم کردن و رها کردن. سایت عوض می شه و صفحه ها اضافه می شن. هر چند ماه فهرست آدرس ها رو دوباره نگاه کن.

برنامه یک بعدازظهری: از صفر تا مانیتورینگ کارا

این ترتیب و زمان های تقریبی رو دنبال کن:

1. حدود نیم ساعت: پنج تا هشت صفحه مهم رو فهرست کن و برای هر کدوم بنویس خرابی ش چه هزینه ای داره.
2. حدود یک ساعت: ابزار رو انتخاب و نصب کن (یا حساب بساز). برای هر آدرس بررسی HTTP، یه بررسی کلمه کلیدی و برای دامنه اصلی بررسی SSL تنظیم کن.
3. حدود بیست دقیقه: با curl زمان پاسخ عادی هر آدرس رو بگیر و یه آستانه موقت برای کندی بذار. بعد از یه هفته با داده واقعی اصلاحش کن.
4. حدود بیست دقیقه: کانال هشدار بحرانی و معمولی رو جدا کن و نفر اول و دوم رو مشخص کن.
5. حدود ده دقیقه: یه مانیتور آزمایشی رو عمداً خراب کن و ببین هشدار می رسه.
6. حدود ده دقیقه: یه یادآور تقویمی برای تمدید دامنه و گواهی بذار.
7. هر ماه: تست هشدار، و هر سه ماه مرور فهرست آدرس ها.

اگه وقت نداری یا نمی خوای سرور جدا نگه داری، میزبانی وب و سرور مجازی ایران و مدیریت و امن سازی سرور هم بخشی از کارهاییه که انجام می دیم.

سوالات متداول

مانیتورینگ رایگان برای شروع کافیه؟

برای یه سایت کوچیک و چند آدرس مهم، معمولاً بله. فقط شرایط پلن رایگان (تعداد مانیتور، بازه بررسی و کانال های هشدار) رو قبل از انتخاب بخون، چون ممکنه عوض شده باشه. اگه کسب و کارت به فروش آنلاین وابسته ست، بهتره زود سراغ بازه کوتاه تر و هشدار پیامکی بری.

هر چند دقیقه یه بار سایت رو چک کنم؟

برای بیشتر سایت ها بازه یک تا پنج دقیقه مناسبه. صفحه پرداخت و API اپلیکیشن رو نزدیک به یک دقیقه بذار؛ وبلاگ و صفحه معرفی می تونن پنج دقیقه باشن. یادت باشه زمان کشف قطعی به تعداد تلاش های تأیید هم بستگی داره.

اگه هاستم خودش مانیتورینگ داره، باز هم لازمه؟

بله، چون مانیتور هاست معمولاً فقط چک می کنه سرور روشنه، نه اینکه سایت تو درست کار می کنه. سایتی که بالاست ولی صفحه خطا نشون می ده یا سبد خریدش کار نمی کنه، ممکنه از دید اون سیستم «سالم» باشه. بررسی از بیرون، با آدرس ها و کلمه های کلیدی خودت، چیز دیگه ایه.

مانیتورینگ سایت رو کند نمی کنه؟

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

از همین امشب، پنج آدرس اول

لازم نیست همه چیز رو یک جا بسازی. امشب پنج آدرس مهم رو بنویس، برای هر کدوم یه بررسی کلمه کلیدی بذار و هشدار رو به دو نفر وصل کن. همین کار ساده تو رو از «مشتری خبر می ده» به «خودم زودتر می فهمم» می رسونه. بقیه چیزها، از SSL تا آستانه ها، هر هفته می تونه اضافه بشه.