مانیتورینگ آپتایم سایت چیست؟ چک HTTP، هشدار و انتخاب ابزار

آپتایم ۱۰۰٪ در داشبورد، لزوماً به این معنا نیست که مشتری می‌تواند وارد سایت شود، جست‌وجو کند یا پرداخت انجام دهد. اگر مانیتور فقط صفحه اصلی را از یک کشور Ping کند، خطای DNS یک اپراتور، گواهی منقضی، پاسخ اشتباه CDN یا خرابی مسیر خرید را نمی‌بیند. مانیتورینگ آپتایم خوب باید «آنچه کاربر واقعاً نیاز دارد» را از بیرون سامانه آزمایش و هشدار قابل‌اقدام ایجاد کند.

این راهنما روی Black-box و Synthetic Monitoring تمرکز دارد: انتخاب Check، Probe، فاصله بررسی، هشدار، Status Page و ابزار. برای مشاهده متریک‌ها، لاگ‌ها و Trace داخل برنامه، راهنمای جداگانه Observability و مانیتورینگ لحظه‌ای وب‌سایت را بخوانید.

آپتایم سایت چیست؟

Uptime سهم زمانی است که یک سرویس طبق تعریف مورد انتظار در دسترس و قابل‌استفاده بوده است. تعریف «در دسترس» باید روشن باشد. برای صفحه عمومی شاید پاسخ HTTPS با وضعیت ۲۰۰، متن صحیح و زمان پاسخ قابل‌قبول کافی باشد؛ برای فروشگاه، دسترسی کاتالوگ بدون امکان افزودن به سبد، سرویس سالم محسوب نمی‌شود.

فرمول ساده در یک بازه:

Availability = (کل زمان − زمان اختلال) ÷ کل زمان × ۱۰۰

اما نتیجه به بازه اندازه‌گیری، Maintenance برنامه‌ریزی‌شده، منطقه کاربر و تعریف موفقیت وابسته است. عدد ابزار را بدون قرارداد SLI/SLO تفسیر نکنید.

تفاوت SLA، SLO و SLI

• SLI: شاخص اندازه‌گیری‌شده، مانند سهم درخواست‌های موفق یا صدک ۹۵ زمان پاسخ.
• SLO: هدف داخلی برای همان شاخص در یک بازه، مثلاً سطح دسترس‌پذیری مسیر پرداخت.
• SLA: تعهد قراردادی و پیامد نقض آن؛ ممکن است تعریف و استثناهای متفاوتی داشته باشد.

یک ابزار Monitoring فقط داده می‌دهد؛ خودش SLO کسب‌وکار را تعیین نمی‌کند. ابتدا مسیرهای حیاتی و پیامد اختلال را مشخص کنید، سپس Check بسازید.

چند دقیقه قطعی پشت درصدها پنهان می‌شود؟

این جدول هدف را ملموس می‌کند، اما کیفیت توزیع قطعی هم مهم است. ۴۰ دقیقه اختلال در اوج کمپین با چند وقفه نیمه‌شب اثر کسب‌وکاری یکسانی ندارد.

مانیتورینگ آپتایم چگونه کار می‌کند؟

1. یک یا چند Probe در بازه مشخص به URL، DNS، TCP یا سرویس هدف درخواست می‌فرستند.
2. ابزار وضعیت، زمان پاسخ، گواهی، بدنه و Redirect را با انتظار مقایسه می‌کند.
3. شکست ممکن است از مکان دوم یا با Retry تأیید شود تا نویز کاهش یابد.
4. پس از عبور از شرط، Incident ساخته و به تیم On-call اطلاع داده می‌شود.
5. تیم Runbook را اجرا، وضعیت عمومی را به‌روزرسانی و رخداد را حل می‌کند.
6. داده برای گزارش SLO، تحلیل روند و Postmortem نگه‌داری می‌شود.

Probe باید بیرون از همان زیرساخت باشد. اگر مانیتور و سایت روی یک سرور یا شبکه قرار دارند، خرابی مشترک می‌تواند هر دو را خاموش و هشدار را حذف کند.

چه Checkهایی برای سایت لازم است؟

HTTP/HTTPS

URL را باز می‌کند و وضعیت، زمان پاسخ، Redirect و Header را می‌سنجد. فقط انتظار ۲۰۰ کافی نیست؛ صفحه خطای سفارشی هم ممکن است ۲۰۰ بدهد. عبارت یا نشانه‌ای پایدار از محتوای درست را بررسی کنید و پاسخ بسیار کند را نیز Failure/Degraded در نظر بگیرید.

DNS

Resolve شدن A/AAAA/CNAME و پاسخ Resolver را کنترل می‌کند. این Check خطای Nameserver، رکورد حذف‌شده یا انتشار ناقص را از خطای وب‌سرور جدا می‌کند.

TLS/SSL

اعتبار گواهی، Hostname، زنجیره و زمان باقی‌مانده را بررسی می‌کند. هشدار تمدید را آن‌قدر زود بفرستید که خطای صدور یا DNS Challenge فرصت اصلاح داشته باشد.

TCP و Port

برای سرویس‌هایی مانند SMTP، دیتابیس مجاز، VPN یا endpoint شبکه مفید است. بازبودن Port به معنای سلامت برنامه نیست؛ آن را کنار Check سطح کاربرد استفاده کنید.

Keyword/Body

وجود یا نبود یک متن، JSON field یا checksum مشخص می‌کند پاسخ واقعاً محتوای مورد انتظار دارد. عبارت را پایدار انتخاب کنید تا تغییر کپی صفحه هشدار کاذب نسازد.

Transaction و Browser Check

مسیر چندمرحله‌ای مثل Login، جست‌وجو یا افزودن به سبد را با مرورگر Headless شبیه‌سازی می‌کند. این Check ارزش بالایی دارد اما شکننده‌تر و پرهزینه‌تر است؛ از حساب و داده آزمایشی و گام‌های محدود استفاده کنید.

Heartbeat یا Dead Man’s Switch

برای Cron، Backup، صف یا Import مناسب است. Job پس از موفقیت به ابزار پیام می‌دهد؛ اگر در بازه مقرر پیام نرسد، Incident ساخته می‌شود. صرف اجرای Process کافی نیست—موفقیت خروجی را گزارش دهید.

برای یک سایت ایرانی از کجا Probe بگذاریم؟

یک Probe اروپایی یا آمریکایی تجربه کاربران ایران را نمایندگی نمی‌کند. حداقل سه زاویه مفید است:

• داخل شبکه هدف: Probe خصوصی یا نقطه‌ای نزدیک کاربران ایرانی برای دیدن DNS و مسیر داخلی؛
• خارج از ایران: برای تشخیص مشکل مرزی، دسترسی خزنده‌ها و سرویس‌های خارجی؛
• داخل زیرساخت: Check داخلی برای وابستگی‌های خصوصی که از اینترنت قابل‌دسترسی نیستند.

اختلاف میان این نقاط تشخیصی است: اگر فقط Probe خارجی Fail شود، ممکن است مسیر بین‌الملل یا WAF مسئله داشته باشد؛ اگر همه Fail شوند، DNS/Origin یا خطای برنامه محتمل‌تر است. Probe داخلی نباید تنها منبع حقیقت باشد.

فاصله بررسی و تأخیر تشخیص

Check هر یک دقیقه الزاماً اختلال را دقیقاً در یک دقیقه تشخیص نمی‌دهد؛ زمان اجرا، Retry، تأیید مکان دوم و ارسال اعلان اضافه می‌شود. فاصله کوتاه‌تر داده بیشتر و هزینه/بار بالاتر دارد. آن را بر اساس اهمیت مسیر تنظیم کنید:

چگونه هشدار کاذب را کم کنیم؟

• شکست را از دو Probe مستقل تأیید کنید.
• یک Retry کوتاه با jitter بگذارید، اما اختلال واقعی را بیش از حد پنهان نکنید.
• هشدار latency را بر اساس صدک و چند نمونه بسازید، نه یک Spike.
• Maintenance Window را زمان‌دار تعریف و بعد از کار خودکار لغو کنید.
• وابستگی‌ها را Inhibit کنید؛ خرابی Origin نباید ده‌ها هشدار فرعی بفرستد.
• Alert recovery را نیز ارسال کنید تا وضعیت Incident روشن بماند.
• خود سامانه Monitoring و مسیر اعلان را با یک Check مستقل پایش کنید.

راهنمای رسمی Alerting در Prometheus توصیه می‌کند Page بر نشانه درد کاربر متمرکز، ساده و قابل‌اقدام باشد؛ مانیتورینگ Black-box خارجی نیز خرابی‌هایی را می‌بیند که White-box داخلی ممکن است از دست بدهد.

هشدار خوب چه اطلاعاتی دارد؟

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

• نام سرویس و شدت؛
• URL یا Check شکست‌خورده؛
• زمان شروع و مناطق درگیر؛
• وضعیت/پیام خطا و latency اخیر؛
• لینک Dashboard، Log و Runbook؛
• مالک و مسیر Escalation؛
• شناسه Incident و دکمه Acknowledge.

CPU بالا بدون اثر کاربر لزوماً نباید نیمه‌شب کسی را بیدار کند. Page را برای رخداد فوری و قابل‌اقدام نگه دارید؛ هشدارهای ظرفیت یا علت فنی می‌توانند Ticket یا اعلان ساعات کاری باشند.

کانال اعلان برای تیم ایرانی

فقط به ایمیل تکیه نکنید. یک اختلال شبکه یا سرویس خارجی ممکن است همان کانال را نیز مختل کند. بر اساس شدت، ترکیبی از تماس، پیامک، Push، پیام‌رسان سازمانی و ایمیل داشته باشید. هر فصل مسیر اعلان را با رخداد آزمایشی End-to-End تست کنید؛ «ارسال از ابزار» با «دریافت و Acknowledge توسط فرد On-call» فرق دارد.

شماره‌ها، برنامه On-call و دسترسی‌ها باید به تیم تعلق داشته باشد، نه حساب شخصی یک همکار. خروج فرد نباید زنجیره هشدار را قطع کند.

Status Page؛ ارتباط شفاف هنگام اختلال

Status Page باید روی زیرساختی جدا از سرویس اصلی باشد تا در همان قطعی از دسترس خارج نشود. وضعیت را بر اساس اجزای قابل‌فهم برای کاربر نشان دهید: وب‌سایت، پنل، API، پرداخت و پشتیبانی. از نمایش نمودار سبزِ کلی وقتی یک بازار یا قابلیت مهم خراب است پرهیز کنید.

یک Update مناسب شامل زمان شروع، دامنه اثر، اقدام جاری و زمان به‌روزرسانی بعدی است. علت قطعی را پیش از اطمینان حدس نزنید. مستندات Status Page در Better Stack نیز تفکیک وضعیت Degraded، Downtime و Resolved و انتشار Update در طول Incident را توضیح می‌دهد.

انتخاب ابزار مانیتورینگ آپتایم

به‌جای انتخاب «بهترین ابزار» برای همه، نیاز خود را با این مدل‌ها مقایسه کنید:

قابلیت و قیمت سرویس‌ها تغییر می‌کند؛ نام‌ها برای ساخت Shortlist هستند، نه تأیید تجاری. در Proof of Concept این معیارها را بسنجید:

• Probe عمومی در منطقه موردنیاز و امکان Private Probe؛
• HTTP، DNS، TLS، Browser، Heartbeat و API؛
• حداقل Interval و سیاست تأیید Failure؛
• On-call، Escalation، Acknowledge و Status Page؛
• خروجی داده، API، Terraform و نگهداری History؛
• RBAC، SSO، Audit Log و محل ذخیره داده؛
• پایداری دسترسی، پرداخت و پشتیبانی برای تیم ایرانی؛
• هزینه هر Check، Probe، اعلان و Browser execution.

Grafana Synthetic Monitoring نمونه‌ای از Checkهای HTTP، DNS، TCP، Traceroute و Browser و امکان Probe خصوصی را مستند کرده است. هر ابزار را با همان URLها و Incident واقعی آزمایش کنید.

از چه URLهایی شروع کنیم؟

1. صفحه اصلی با بررسی نشانه متن صحیح؛
2. یک صفحه محتوایی یا محصول از CDN؛
3. endpoint سلامت برنامه که وابستگی‌های ضروری را با پاسخ کنترل‌شده نشان دهد؛
4. Login بدون ارسال رمز واقعی؛
5. جست‌وجو یا API خواندنی؛
6. سبد با کاربر و داده آزمایشی؛
7. درگاه/پرداخت با Canary غیرمالی یا محیط Sandbox—نه تراکنش تولیدی بی‌محابا؛
8. DNS و TLS همه دامنه‌های حیاتی؛
9. Heartbeat برای Backup، Queue و Job مالی.

امنیت در Synthetic Monitoring

• Secret را داخل URL یا متن عمومی Check قرار ندهید.
• توکن با کمترین دسترسی و عمر محدود بسازید.
• حساب Synthetic را از مشتری واقعی جدا و تراکنش آن را برچسب‌گذاری کنید.
• خروجی Log را از رمز، Cookie، داده شخصی و پاسخ پرداخت پاک کنید.
• IP Probe را فقط در صورت نیاز Allowlist کنید؛ Check عمومی نباید Backdoor بسازد.
• تغییر تنظیم Monitor، Silence و Contact را Audit کنید.
• حذف و خروج داده از ابزار SaaS را پیش از قرارداد بررسی کنید.

Runbook اولین هشدار Down

1. هشدار را Acknowledge و دامنه اثر را از چند Probe تأیید کنید.
2. DNS، TLS، CDN/WAF، Origin و وابستگی خارجی را لایه‌به‌لایه جدا کنید.
3. تغییر یا Deploy اخیر را روی Timeline بگذارید.
4. اگر اثر کاربر واقعی است، Incident Commander و کانال رخداد تعیین کنید.
5. Status Page و پشتیبانی را با اطلاعات تأییدشده به‌روزرسانی کنید.
6. Mitigation کم‌ریسک مانند Rollback یا Failover را اجرا کنید.
7. پس از بازیابی، Monitor را تا تثبیت دنبال و Postmortem بدون سرزنش ثبت کنید.

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

چک‌لیست اجرای مانیتورینگ آپتایم

• مسیرهای حیاتی و تعریف موفقیت هرکدام نوشته شده است.
• HTTP فقط Status Code را نمی‌سنجد و صحت محتوا را هم بررسی می‌کند.
• DNS، TLS، API، Transaction و Heartbeat پوشش لازم دارند.
• Probe داخل و خارج بازار هدف داریم.
• Failure با منطق چندمنطقه‌ای تأیید می‌شود.
• هشدارها شدت، مالک، Runbook و Escalation دارند.
• کانال‌های اعلان End-to-End آزمایش می‌شوند.
• Status Page از زیرساخت اصلی جداست.
• Monitoring خود مانیتور می‌شود.
• گزارش SLO بر اساس زمان و اثر کاربر بازبینی می‌شود.
• Secret و داده شخصی در Check و Log قرار ندارد.
• پس از هر Incident، Checkهای گمشده اصلاح می‌شوند.

سؤالات متداول مانیتورینگ آپتایم

مانیتورینگ آپتایم چیست؟

پایش خودکار و بیرونی دسترس‌پذیری و صحت سرویس است. Probeها URL، DNS، TLS یا تراکنش را بررسی و در صورت شکست تأییدشده Incident و هشدار ایجاد می‌کنند.

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

به اهمیت مسیر و زمان قابل‌تحمل تشخیص بستگی دارد. مسیر درآمدی فاصله کوتاه و چند Probe می‌خواهد؛ Check گواهی یا Job روزانه می‌تواند کم‌دفعات‌تر باشد.

آیا Ping برای تشخیص Down بودن سایت کافی است؟

خیر. ICMP ممکن است مسدود باشد یا سرور به Ping پاسخ دهد درحالی‌که برنامه خراب است. HTTP با بررسی وضعیت، محتوا و latency برای تجربه وب معنادارتر است.

چرا ابزار Down گزارش می‌دهد اما سایت برای من باز است؟

ممکن است مشکل فقط در منطقه Probe، DNS Resolver، IP آن، WAF یا یک لحظه کوتاه رخ داده باشد. نتیجه چند منطقه، Retry، Trace و هدر پاسخ را مقایسه کنید.

بهترین ابزار مانیتورینگ آپتایم کدام است؟

ابزار واحدی برای همه بهترین نیست. تعداد و محل Probe، انواع Check، On-call، Status Page، امنیت، دسترسی تیم ایرانی، API و هزینه را با Proof of Concept مقایسه کنید.

جمع‌بندی

مانیتورینگ آپتایم خوب از «URL سبز» فراتر می‌رود: مسیر حیاتی را از دید کاربر، در چند شبکه، با انتظار صحت و زمان پاسخ می‌سنجد و در زمان درست به فردی که Runbook دارد هشدار می‌دهد. ابزار مهم است، اما تعریف SLI، کیفیت Alert و تمرین Incident نتیجه را تعیین می‌کند.

اگر نمی‌دانید کدام مسیرها باید مانیتور شوند یا هشدارهای فعلی نویز زیادی دارند، در فرم مشاوره مایندیو معماری، بازار کاربران و نمونه Incident اخیر را ثبت کنید تا طرح پایش متناسب پیشنهاد شود.