چطور هشدارهای اشتباه قطعی رو کم کنیم بدون اینکه قطعی واقعی رو از دست بدیم.

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

نکته‌های کلیدی

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

هشدار اشتباه از کجا میاد؟

تأیید از چند لوکیشن

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

noc724 یه قدم جلوتر می‌ره: اگه بعضی لوکیشن‌ها به سایت برسن و بعضی نه، مانیتور به‌جای قطع، مختل (degraded) نشون داده می‌شه؛ پس مشکل منطقه‌ای رو می‌بینید بدون اینکه قطعی کامل حساب بشه. مانیتورینگ از چند شهر رو ببینید.

خرابی‌های پشت‌سرهم رو شرط کنید

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

timeout واقع‌بینانه بذارید

تاریخچه‌ی زمان پاسخ مانیتور رو نگاه کنید. اگه صفحه معمولاً در ۴۰۰ تا ۹۰۰ میلی‌ثانیه جواب می‌ده، timeout یک‌ثانیه‌ای در ساعت‌های شلوغ حتماً هشدار اشتباه می‌ده. timeout رو با فاصله‌ی راحت بالای اوج‌های عادی بذارید (مثلاً ۱۰ تا ۳۰ ثانیه برای صفحه‌ی وب) و یه هشدار زمان پاسخ جدا برای «کندی» اضافه کنید؛ کندی و قطعی واکنش‌های متفاوتی لازم دارن.

چک‌های محتوا رو مقاوم کنید

• کلمه‌ای رو انتخاب کنید که بخشی از قالب صفحه است (یه متن فوتر، اسم برند)، نه تیتری که تیم مارکتینگ هر هفته عوضش می‌کنه.
• برای چک‌های «این کلمه نباید باشه»، متنی رو انتخاب کنید که فقط روی صفحه‌های خطا میاد، مثل عنوان صفحه‌ی خطای فریم‌ورک.
• بعد از طراحی مجدد سایت، کلمه‌های کلیدی رو دوباره چک کنید.

بذارید مانیتور وارد بشه

لایه‌های امنیتی معمولاً مانیتورینگ رو حمله حساب می‌کنن:

• IPهای سرویس مانیتورینگ رو در فایروال، WAF و محدودکننده‌ی نرخ مجاز کنید.
• از یه آدرس سلامت اختصاصی استفاده کنید که کش نمی‌شه و پشت ورود نیست.
• مطمئن بشید چالش‌های «محافظت از ربات» CDN جلوی چک‌کننده رو نمی‌گیرن.

نرخ هشدار اشتباه رو اندازه بگیرید

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

پرسش‌های پرتکرار

• تأیید باعث نمی‌شه دیرتر از قطعی واقعی باخبر بشم؟

  +

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

• طولانی‌تر کردن فاصله‌ی چک راه خوبی برای کم کردن نویزه؟

  +

  نه واقعاً. تشخیص رو دیر می‌کنه و هنوز روی اختلال‌هایی که اتفاقاً موقع چک رخ می‌دن هشدار می‌ده. تنظیمات تأیید و خرابی پشت‌سرهم نویز رو بدون این هزینه کم می‌کنن.

• چرا سایتم سالم به نظر می‌رسه ولی مانیتور می‌گه قطعه؟

  +

  معمولاً مانیتور مسدود شده (فایروال، WAF، محدودیت جغرافیایی) یا از مسیر دیگه‌ای مثل IPv6 استفاده می‌کنه. خطایی که مانیتور ثبت کرده رو نگاه کنید؛ می‌گه timeout بوده، اتصال رد شده یا یه کد وضعیت.