پیامک، تلگرام یا بله؟ انتخاب کانال هشدار بدون خستگی از هشدار
کدوم هشدارهای قطعی با پیامک برن و کدوم با تلگرام یا بله، چطور بر اساس فوریت مسیریابی کنیم و چطور هشدارهای مهم زیر هشدارهای بیمورد گم نشن.
«سایت رو مانیتور کن» شبیه یه کار تکی به نظر میاد. ولی در عمل، سایت به زنجیرهای از چیزها وابسته است (DNS، گواهی SSL، وبسرور، API، دیتابیس، کارهای پسزمینه) و هر حلقهای ممکنه بشکنه در حالی که صفحهی اصلی هنوز سالم به نظر میرسه. این چکلیست کمک میکنه تصمیم بگیرید چی رو، به چه ترتیبی و هر چند وقت یه بار زیر نظر بگیرید.
noc724 سایت، سرور و APIهای شما رو شبانهروز چک میکنه و همون لحظهای که چیزی خراب شد با پیامک، تلگرام یا بله خبرتون میکنه.
چند صفحه و کاری رو فهرست کنید که اگه خراب بشن، مشتریها بهتون زنگ میزنن. برای بیشتر کسبوکارها اینها هستن:
برای هر کدوم، یه چک سادهی HTTP که کد 200 انتظار داره شروع خوبیه. بهترش مانیتورینگ کلمهی کلیدی است که دنبال کلمهای میگرده که فقط وقتی صفحه واقعاً کار میکنه دیده میشه، مثل اسم محصول یا «خروج». صفحههای خطا هم خیلی وقتها کد 200 برمیگردونن.
بعضی مشکلها هیچوقت به شکل کندی صفحه دیده نمیشن؛ یه روز همهچیز یهو متوقف میشه.
گواهی منقضیشده باعث میشه مرورگر یه صفحهی کامل هشدار نشون بده. تاریخ انقضا رو مانیتور کنید و دو تا چهار هفته قبل هشدار بگیرید؛ حتی اگه تمدید دستی باشه وقت کافی دارید. مانیتورینگ SSL رو ببینید.
دامنهای که تمدید نشده، سایت، ایمیل و همهی زیردامنهها رو یکجا از کار میندازه و پس گرفتنش ممکنه طول بکشه. یه مانیتور انقضای دامنه هزینهای نداره و جلوی یه قطعی خجالتآور رو میگیره.
تغییرات DNS، منقضی شدن تفویض نیمسرور یا یه رکورد اشتباه میتونه بازدیدکنندهها رو جای دیگه بفرسته. مانیتورینگ DNS که جوابها رو با مقدار مورد انتظار مقایسه میکنه، این رو پیدا میکنه.
بکاپها، صدور فاکتور و همگامسازی داده بیسروصدا شکست میخورن. از مانیتورینگ Heartbeat استفاده کنید: کار بعد از تموم شدن یه آدرس رو پینگ میکنه و اگه پینگ نرسه هشدار میگیرید.
همهی سرورها صفحهی وب نمیدن. سرور ایمیل، دیتابیس، درگاه VPN و ابزارهای داخلی هم مراقبت لازم دارن:
| چی | نوع چک | چی رو ثابت میکنه |
|---|---|---|
| سرور یا روتر | پینگ (ICMP) | میزبان روی شبکه در دسترسه |
| سرور ایمیل | پورت ۲۵ / ۴۶۵ / ۵۸۷ | SMTP اتصال قبول میکنه |
| دیتابیس | پورت ۵۴۳۲، ۳۳۰۶ و... | دیتابیس گوش میده (از یه لوکیشن مجاز) |
| SSH | پورت ۲۲ | هنوز میتونید وارد بشید و درستش کنید |
| سرور DNS، VoIP | UDP | سرویس به بستهها جواب میده |
چک پورت فقط ثابت میکنه سرویس اتصال قبول میکنه، نه اینکه درست کار میکنه؛ هر جا میشه کنارش یه چک در سطح برنامه بذارید.
فاصله رو از روی هزینهی بیخبری انتخاب کنید:
| فاصله | مناسب برای |
|---|---|
| ۳۰ ثانیه تا ۱ دقیقه | پرداخت، API پرداخت، ورود؛ هر دقیقه قطعی پول از دست میده |
| ۵ دقیقه | بیشتر سایتها، صفحههای معرفی، ابزارهای داخلی |
| روزانه | انقضای گواهی SSL و دامنه |
| طبق زمانبندی کار | مانیتورهای Heartbeat؛ مهلت باید زمان عادی اجرا رو پوشش بده |
چک سریعتر مشکل رو زودتر پیدا میکنه، ولی هشدار هنوز به تأیید نیاز داره. چک کردن از چند لوکیشن و هشدار دادن فقط وقتی بیشتر از یه نقطه خرابی رو ببینه، بیشتر هشدارهای اشتباهی رو که از یه مسیر شبکه میان حذف میکنه.
مانیتوری که کسی نمیخونه فقط تزئینه. برای هر مانیتور مشخص کنید:
مانیتورهای کماهمیت (مثل کند شدن یه صفحهی معرفی) رو از گوشیهایی که نصف شب آدمها رو بیدار میکنن دور نگه دارید.
اگه از صفر شروع میکنید، این مجموعه در کمتر از پونزده دقیقه بیشتر سایتهای کوچیک و متوسط رو پوشش میده:
نه. صفحهی اصلی معمولاً کش میشه یا از CDN میاد و ممکنه سالم بمونه در حالی که ورود، پرداخت یا API خرابه. مسیرهایی رو مانیتور کنید که کاربر برای انجام کاری طی میکنه.
اونهایی که مسیر اصلی کارتون بهشون وابسته است: درگاه پرداخت، سرویس پیامک، نقشه. نمیتونید درستشون کنید، ولی زود باخبر شدن کمک میکنه سرویسدهنده رو عوض کنید یا به کاربرها بگید چه خبره.
برای یه سایت معمولی کسبوکار، معمولاً بین پنج تا بیست تا. با مجموعهی شروع بالا شروع کنید و هر بار که یه رخداد خرابی جدیدی بهتون یاد داد، یه مانیتور اضافه کنید.
نویسنده
تیم noc724
تیم فنی مانیتورینگ آپتایم
ما noc724 رو میسازیم و اداره میکنیم؛ سرویس مانیتورینگ آپتایمی که سایت، سرور و API رو از چند شهر ایران چک میکنه. این راهنماها از مشکلهایی میان که خودمون و کاربرهامون موقع آنلاین نگه داشتن سرویسها باهاشون روبهرو میشیم.
تماس با تیمتخصص:مانیتورینگ
کدوم هشدارهای قطعی با پیامک برن و کدوم با تلگرام یا بله، چطور بر اساس فوریت مسیریابی کنیم و چطور هشدارهای مهم زیر هشدارهای بیمورد گم نشن.
چرا مانیتورهای آپتایم هشدار اشتباه میدن (اختلال شبکه، timeout، محدودیت نرخ، تغییر محتوا) و تنظیماتی که اینها رو حذف میکنه و هشدار واقعی رو سریع نگه میداره.
چطور یه چرخهی آنکال ساده و سیاست ارجاع هشدار بچینیم که هر هشدار حیاتی جواب داده بشه، بدون اینکه یه تیم کوچیک فرسوده بشه.