پایش در دسترس‌بودن و آزمون مصنوعی
اگر قرار باشد فقط یک چیز از کل این مجموعه راه بیندازید، این است. ده دقیقه کار دارد، تقریباً رایگان است، و همان چیزی است که جلوی جملهٔ «دو ساعت سایت پایین بود و ما نفهمیدیم» را می‌گیرد.
ایده ساده‌تر از آن است که مقاله بخواهد: هر چند دقیقه، از بیرون، یک درخواست بفرست. جواب آمد؟ درست بود؟ چقدر طول کشید؟
اسم فنی‌اش آزمون مصنوعی است — مصنوعی، چون ترافیکی است که شما می‌سازید نه کاربر.
چه چیزی را بررسی کنیم
اینجا اولین جایی است که بیشتر تیم‌ها کم‌کاری می‌کنند. صفحهٔ اصلی را بررسی می‌کنند، کد ۲۰۰ برمی‌گردد، خیالشان راحت است.
ولی صفحهٔ اصلی معمولاً ایستاست و از حافظهٔ نهان می‌آید. می‌تواند سالم باشد در حالی که پایگاه داده پایین است و هیچ کاربری نمی‌تواند وارد شود.
پیشنهاد ما، به ترتیب ارزش:
نقطهٔ پایانی سلامت که واقعاً چیزی را بررسی کند — اتصال پایگاه داده، دسترسی
به صف. نه نقطه‌ای که فقط OK برمی‌گرداند.
یک مسیر واقعی کاربر. ورود، جست‌وجو، افزودن به سبد. اگر می‌شود، همان مسیری که پول از آن رد می‌شود.
وابستگی‌های بیرونی. درگاه پرداخت، سرویس پیامک. وقتی آن‌ها پایین‌اند سامانهٔ شما هم عملاً پایین است، حتی اگر سرورتان سالم باشد.
گواهی TLS. بله، انقضای گواهی. یکی از رایج‌ترین قطعی‌های کامل و کاملاً قابل پیشگیری، و بررسی‌اش یک خط است.
بررسی واژهٔ کلیدی. یعنی نه‌فقط کد ۲۰۰، بلکه وجود یک متن مشخص در پاسخ. صفحهٔ خطای سفارشی که با کد ۲۰۰ برمی‌گردد، بدون این بررسی «سالم» دیده می‌شود.
از کجا بررسی کنیم
نقطهٔ بررسی مهم است و برای ما بیشتر از جاهای دیگر.
اگر فقط از یک ماشین در همان مرکز داده بررسی می‌کنید، مشکلات شبکه‌ای بین کاربر و شما را هرگز نمی‌بینید. و برای کاربران ایرانی، مسیر شبکه بخش بزرگی از تجربه است.
حداقل از دو نقطه بررسی کنید، و یکی‌شان جایی باشد که کاربران واقعی‌تان هستند. و قاعده‌ای که به‌سختی یاد گرفته می‌شود: وقتی یک نقطه خطا داد، پیش از هشدار از نقطهٔ دوم تأیید بگیرید. وگرنه هر اختلال شبکهٔ محلی، یک هشدار کاذب می‌شود و بعد از چند بار، کسی دیگر هشدارها را جدی نمی‌گیرد. چرا این فاجعه است را در هشدار و کشیک نوشته‌ایم.
«پایین» یعنی چه — این را قبل از قطعی تعریف کنید
سؤالی که وسط بحران پرسیدنش دیر است.
یک درخواست ناموفق یعنی پایین؟ سه تای پشت سر هم؟ پاسخی که می‌آید ولی سی ثانیه طول می‌کشد چه؟ از نظر کاربر آن هم پایین است، ولی بررسی ساده «موفق» ثبتش می‌کند.
تعریفی که ما پیشنهاد می‌کنیم: دو بررسی ناکام پشت سر هم از دو نقطهٔ متفاوت، یا پاسخی کندتر از آستانه‌ای که خودتان تعیین کرده‌اید. آستانه را از داده‌های واقعی‌تان دربیاورید، نه از حدس.
و اگر توافق‌نامهٔ سطح خدمات دارید، این تعریف باید با همان چیزی که آنجا امضا کرده‌اید یکی باشد. تیم‌هایی دیده‌ایم که پایش داخلی‌شان ۹۹٫۹٪ می‌گفت و مشتری با تعریف خودش ۹۸٪ حساب می‌کرد — و قرارداد، حرف مشتری را تأیید می‌کرد.
چیزی که این ابزار به شما نمی‌گوید
آزمون مصنوعی به شما می‌گوید چیزی خراب است. نمی‌گوید برای چه کسی.
بررسی از یک سرور با اینترنت خوب انجام می‌شود، در حالی که کاربر شما روی اینترنت همراه است با گوشی میان‌رده. صفحه‌ای که برای بررسی‌کننده در ۴۰۰ میلی‌ثانیه می‌آید، ممکن است برای نیمی از کاربرانتان چهار ثانیه طول بکشد — و هیچ‌وقت هشداری نگیرید.
آن نیمهٔ دیگر، کار RUM است. تفکیک کاملشان و اینکه کدام را اول راه بیندازید، در آزمون مصنوعی در برابر کاربر واقعی آمده.
صفحهٔ وضعیت
اگر مشتری سازمانی دارید، یک صفحهٔ وضعیت عمومی ارزش راه‌اندازی دارد. نه به‌خاطر شفافیت — هرچند خوب است — بلکه به یک دلیل عملی: در هر قطعی، بخش بزرگی از وقت تیم پشتیبانی صرف جواب دادن به «شما هم مشکل دارید؟» می‌شود.
یک صفحهٔ وضعیت، آن ترافیک را جذب می‌کند و تیم را آزاد می‌گذارد که مشکل را حل کند.
⚠️ و یک نکته که بارها تکرار شده: صفحهٔ وضعیت را روی همان زیرساختی که پایش می‌کند میزبانی نکنید. وقتی همه‌چیز پایین است، صفحهٔ وضعیتتان هم پایین است.
گزینه‌ها
اینجا خوش‌شانسیم؛ گزینهٔ متن‌باز خوب و بی‌دردسر وجود دارد.
Uptime Kuma با مجوز MIT، خودمیزبان، و به‌معنای واقعی ظرف چند دقیقه با Docker بالا می‌آید. انواع بررسی‌ای که دارد برای بیشتر تیم‌ها بیش از کافی است: HTTP و HTTP با واژهٔ کلیدی، TCP، رکورد DNS، پینگ، وب‌سوکت، پرس‌وجوی JSON، و بررسی کانتینر. بیش از ۹۰ مسیر اطلاع‌رسانی دارد — از تلگرام و ایمیل تا Gotify — و صفحهٔ وضعیت چندگانه هم می‌سازد که می‌شود به دامنهٔ خودتان وصلش کرد.
GlitchTip هم علاوه بر ردیابی خطا، پایش در دسترس‌بودن دارد. اگر آن را برای خطا نصب کرده‌اید، یک ابزار کمتر.
⚠️ یک هشدار که ارزش گفتن دارد: اگر Uptime Kuma را روی همان سروری بگذارید که برنامه‌تان است، وقتی آن سرور بمیرد پایش هم مرده و هیچ هشداری نمی‌آید. روی چیز دیگری بگذاریدش — حتی یک سرور مجازی کوچک و ارزان کافی است.
ترتیب درست را یک بار دیگر بگوییم، چون تیم‌ها معمولاً برعکسش را انجام می‌دهند: اول بفهمید سامانه بالاست، بعد بفهمید چقدر سریع است، بعد بفهمید چرا کند است. و قدم اول، همانی است که کمترین کار را دارد.