راهنمای جامع هشدار در پایش سرور: خبر درست، به آدم درست، به‌موقع

سامانهٔ پایشی که هیچ هشداری نمی‌دهد بی‌فایده است؛ سامانه‌ای که هر روز صد هشدار می‌دهد، بدتر از بی‌فایده است. دومی را بیشتر دیده‌ام: گروه تلگرامی یا صندوق ایمیلی که روزی چند صد پیام «CPU High» و «Disk Warning» در آن می‌آید و همهٔ اعضای تیم آن را بی‌صدا کرده‌اند. روزی که پیام «سرور قطع شد» واقعاً مهم بود، در میان همان سیل گم شد و صبح، کاربران خبر دادند.

هشدار خوب سه ویژگی دارد که در عنوان این راهنما آمده: درست است (یعنی واقعاً مشکلی هست که کاری لازم دارد)، به آدم درست می‌رسد (کسی که می‌تواند کاری بکند و مسئول است)، و به‌موقع است (نه آن‌قدر زود که جهش لحظه‌ای را مشکل بداند، نه آن‌قدر دیر که کار از کار گذشته باشد). این راهنما دربارهٔ طراحی چنین سامانه‌ای است، مستقل از اینکه از چه ابزاری استفاده می‌کنید. اینکه دقیقاً چه چیزی را بپایید را در راهنمای جامع پایش سرور نوشته‌ام؛ اینجا موضوع این است که از آن داده‌ها، کِی و چطور کسی را صدا کنیم.

هر هشدار باید یک اقدام داشته باشد

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

برای هر هشداری که تعریف می‌کنید، این چهار سؤال را بپرسید:

1. وقتی این هشدار بیاید، دقیقاً چه کاری باید کرد؟ اگر جواب روشن ندارید، هشدار را تعریف نکنید یا اول جواب را بنویسید.
2. چقدر فوری است؟ همین الان، تا پایان روز، یا این هفته؟
3. چه کسی باید انجامش دهد؟
4. چند بار در ماه کاذب خواهد بود؟ اگر بیشتر از واقعی، آستانه یا شرطش را عوض کنید.

جواب سؤال دوم تعیین می‌کند هشدار از چه کانالی برود. فقط چیزهایی که «همین الان» لازم دارند، باید از کانالی بروند که آدم را از هر کاری بیرون بکشد.

شدت: دو سطح کافی است

بسیاری از ابزارها پنج یا شش سطح شدت دارند: Information، Warning، Average، High، Disaster. در عمل، تیم‌های کوچک فقط دو سطح را واقعاً از هم تشخیص می‌دهند و رفتارشان را بر اساس آن تغییر می‌دهند:

سطح سومی هم هست که هشدار نیست: رویداد. «نرم‌افزاری نصب شد»، «سرور ریبوت شد». این‌ها باید ثبت و قابل جستجو باشند ولی کسی را صدا نکنند، مگر اینکه خودشان نشانهٔ مشکل باشند.

آستانه و مدت: تفاوت جهش با مشکل

بیشترین هشدار کاذبی که دیده‌ام از آستانه‌های بدون مدت می‌آید. CPU سرور سالم ده‌ها بار در روز برای چند ثانیه بالای ۹۵٪ می‌رود: هنگام اسکن آنتی‌ویروس، فشرده‌سازی بکاپ، کامپایل، یا یک گزارش سنگین. اگر هشدار روی هر نمونه‌ای که از آستانه گذشت فعال شود، هر روز صدها هشدار بی‌معنا می‌گیرید.

راه‌حل، شرط مدت است: «CPU بالای ۹۵٪ به مدت ۱۰ دقیقهٔ پیوسته». این شرط جهش‌های کوتاه را نادیده می‌گیرد و فقط مشکل پایدار را گزارش می‌کند. انتخاب مدت هم مصالحه است:

یک نکتهٔ ظریف دربارهٔ برطرف شدن: هشداری که با رسیدن CPU به ۹۴٪ بسته و با ۹۶٪ دوباره باز شود، در اطراف آستانه دائم نوسان می‌کند (flapping). ابزارهای خوب یا برای بستن هم مدت می‌گذارند یا آستانهٔ بستن را کمی پایین‌تر از آستانهٔ باز شدن (hysteresis) قرار می‌دهند.

یک مشکل، یک هشدار

دیسکی که ساعت ده شب به ۹۶٪ رسید و تا صبح همان‌جا ماند، اگر هر دقیقه بررسی شود و هر بار هشدار بدهد، ششصد پیامک می‌سازد. این نه‌تنها آزاردهنده است، بلکه هزینه دارد و هشدارهای دیگر را هم دفن می‌کند. اصل درست: هر مشکل تا وقتی برطرف نشده، یک هشدار باز است. بررسی‌های بعدی فقط شمارندهٔ تکرار و زمان آخرین مشاهده را به‌روز می‌کنند.

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

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

قطعی: هشداری که از همه مهم‌تر است

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

چه کسی، از چه کانالی

هشداری که به «همه» می‌رسد، در عمل به هیچ‌کس نمی‌رسد؛ هر کس فکر می‌کند دیگری رسیدگی می‌کند. برای هر هشدار بحرانی باید یک نفر مشخص مسئول باشد، و اگر او در دسترس نبود، نفر دوم.

کانال‌ها

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

ساعت سکوت

هشدار «گواهی ۲۰ روز دیگر منقضی می‌شود» ساعت سه بامداد کسی را بیدار نکند. ساعت سکوت یعنی در بازهٔ مشخصی (مثلاً ۲۲ تا ۷)، هشدارهای غیربحرانی پیامک نمی‌شوند و در داشبورد می‌مانند، ولی بحرانی‌ها همیشه می‌رسند. این ساده‌ترین تنظیمی است که خستگی از هشدار را کم می‌کند، به شرطی که دسته‌بندی شدت درست باشد. اگر «دیسک ۹۸٪» را هشدار عادی تعریف کرده باشید، ساعت سکوت آن را هم ساکت می‌کند.

ارجاع

نفر اول ممکن است خواب باشد، در جلسه باشد، گوشی‌اش خاموش باشد. ارجاع (escalation) یعنی اگر هشدار بحرانی تا N دقیقه تأیید نشد، نفر دوم هم خبردار شود. این کار فقط وقتی ممکن است که «تأیید» وجود داشته باشد: نفر اول با یک کلیک بگوید «دیدم، دارم رسیدگی می‌کنم». چرخهٔ ساده و مؤثر هر هشدار:

1. باز: مشکل تشخیص داده شد، پیام رفت.
2. تأییدشده: کسی مسئولیتش را گرفت؛ ارجاع متوقف می‌شود و بقیه می‌دانند کسی رویش کار می‌کند.
3. بسته‌شده: مشکل برطرف شد؛ خودکار (وقتی سنجه به حالت عادی برگشت) یا دستی.

برخی هشدارها نباید خودکار بسته شوند. هشدار باج‌افزار نمونهٔ روشنش است: اینکه تغییر انبوه فایل‌ها متوقف شده، یعنی رمزگذاری تمام شده، نه اینکه مشکل حل شده.

حالت نگهداری: کار برنامه‌ریزی‌شده بدون سیل پیام

وقتی سرور را برای آپدیت ریبوت می‌کنید، هشدار قطعی، سرویس متوقف و احتمالاً CPU بالا هنگام بالا آمدن، همه درست‌اند ولی بی‌فایده. حالت نگهداری (maintenance) برای یک سرور و یک بازهٔ زمانی، هشدارها را ثبت می‌کند ولی کسی را صدا نمی‌کند. دو اشتباه رایج: فراموش کردن پایان حالت نگهداری (سروری که یک هفته در نگهداری مانده و مشکلش دیده نمی‌شود) و قرار دادن کل سازمان در نگهداری برای کار روی یک سرور. همیشه مدت محدود تعیین کنید.

هزینه و سقف

هر پیامک هزینه دارد، و یک قانون اشتباه می‌تواند در یک شب هزاران پیامک بسازد: آستانه‌ای که روی همهٔ سرورها اعمال شده و همه از آن رد می‌شوند، یا یک سرور که هر دقیقه بین قطع و وصل نوسان می‌کند. سقف پیامک در بازهٔ زمانی (مثلاً ۲۴ ساعت) این ریسک را محدود می‌کند. ولی سقف ساده خطر دیگری دارد: اگر سقف با هشدارهای کم‌اهمیت پر شود، پیامک بحرانی بعدی نمی‌رسد. پس بخشی از سقف را برای بحرانی‌ها رزرو کنید و وقتی سقف پر شد، یک پیامک آخر بفرستید که «سقف پر شد، داشبورد را ببینید».

متن هشدار: آنچه باید در پیام باشد

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

Alert: Trigger fired on host 17 (item 4521)

CRITICAL  FS-01
Disk D: 97% full (12 GB free)
1405/07/18 02:14
https://monitor.example.local/servers/fs-01

پیام دوم شدت، نام آشنای سرور، مشکل با عدد، زمان و لینک مستقیم را دارد. برای رویدادهای امنیتی، عدد و منبع حیاتی‌اند: «۳۸ ورود ناموفق از 203.0.113.24 به حساب administrator» خیلی بیشتر از «Security alert on DC-01» به تصمیم کمک می‌کند. اگر هشدار runbook دارد (سند کوتاهی که می‌گوید چه باید کرد)، لینکش در پیام یا در صفحهٔ هشدار باشد.

runbook: هر هشدار بگوید چه باید کرد

هشداری که ساعت دو بامداد به کسی می‌رسد که سرور را نمی‌شناسد (مثلاً همکار تازه یا نفر کشیک از تیم دیگر)، بدون راهنما تقریباً بی‌فایده است. runbook سند کوتاهی است که برای هر نوع هشدار می‌گوید: این هشدار یعنی چه، چطور تأیید کنم که واقعی است، اولین اقدام‌ها چیست، و اگر حل نشد با چه کسی تماس بگیرم. لازم نیست مفصل باشد؛ نیم صفحه کافی است. نمونه برای «دیسک پر»:

Alert: Disk usage critical (any server)
1. Open the server page; which drive, how fast did it fill (7-day graph)?
2. Sudden jump  -> look for runaway logs / dumps:
     Windows: C:\inetpub\logs, C:\Windows\Temp, SQL error logs
     Linux:   du -xh --max-depth=1 /var | sort -rh | head
3. Steady growth -> data growth; plan extension, not cleanup.
4. Never delete: WinSxS, database files, anything you do not recognise.
5. Not solved in 30 min and above 98%: call the server owner (see list).

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

webhook: هشدار در سامانه‌های دیگر

پیامک برای خبر دادن فوری عالی است، ولی جای ثبت و پیگیری نیست. اگر تیم شما سامانهٔ تیکت دارد (مثلاً GLPI، Jira یا سامانهٔ داخلی) یا در یک پیام‌رسان کاری گفتگو می‌کند، webhook پل بین پایش و آن سامانه است: هر بار هشداری باز، تأیید یا بسته می‌شود، یک درخواست HTTP با بدنهٔ JSON به نشانی‌ای که تعیین کرده‌اید فرستاده می‌شود و طرف گیرنده هر کاری بخواهد با آن می‌کند؛ تیکت باز می‌کند، در گروه پیام می‌گذارد، یا در پایگاه دادهٔ گزارش‌ها ثبت می‌کند.

چند نکته در پیاده‌سازی گیرندهٔ webhook:

• idempotent باشد. ممکن است یک پیام دو بار برسد (مثلاً بعد از تلاش دوباره). با شناسهٔ هشدار، تکراری‌ها را تشخیص دهید تا دو تیکت باز نشود.
• سریع جواب دهد. کار سنگین را در پس‌زمینه انجام دهید و فوراً کد 200 برگردانید.
• احراز هویت داشته باشد. نشانی گیرنده را عمومی و بی‌حفاظ نگذارید؛ دست‌کم یک توکن مخفی در نشانی یا سرآیند بررسی کنید.
• شکستش پایش شود. اگر گیرنده خراب شد، هشدارها هنوز باید از کانال دیگری (پیامک) برسند. webhook را تنها کانال بحرانی‌ها نکنید.

هشدارهای پیش‌فرض: از کجا شروع کنیم

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

منطق هشدارهای امنیتی و باج‌افزاری این فهرست را در راهنمای امنیت سرور و راهنمای محافظت در برابر باج‌افزار باز کرده‌ام، و آستانه‌های آنتی‌ویروس و آپدیت را در راهنمای به‌روزرسانی و آنتی‌ویروس.

بازبینی ماهانه: هشدارها هم نگه‌داری می‌خواهند

سامانهٔ هشدار بعد از راه‌اندازی تمام نمی‌شود. ماهی یک بار نیم ساعت وقت بگذارید و این‌ها را مرور کنید:

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

ServerMug را با همین اصول ساخته‌ایم: قانون‌های سنجه با آستانه و «به مدت»، یک هشدار برای هر مشکل با شمارش تکرار، چرخهٔ باز و تأییدشده و بسته‌شده، پیامک و webhook، ساعت سکوت، ارجاع به سطح دوم، سقف پیامک با سهم بحرانی و حالت نگهداری. جزئیات تنظیم قانون‌ها در قانون‌های هشدار و تنظیم مخاطبان و ارجاع در مخاطبان، پیامک و سقف پیامک آمده است. ولی ابزار هرچه باشد، بخش سخت کار انتخاب‌هایی است که فقط تیم خودتان می‌تواند بکند: چه چیزی واقعاً بحرانی است، و چه کسی ساعت سه بامداد جواب می‌دهد.

منابع و مطالعهٔ بیشتر

• پایش سیستم‌های توزیع‌شده، کتاب SRE گوگل — اصولی دربارهٔ اینکه چه چیزی ارزش پیج کردن دارد و چه چیزی نه.
• بهترین شیوه‌های هشدار در مستندات Prometheus — راهنمای کوتاه و عملی برای هشدار بر اساس نشانه به‌جای علت.
• هشدار بر اساس SLO، کتاب کار SRE — بحث دقیق دربارهٔ مصالحهٔ دقت، فراخوانی و زمان تشخیص در طراحی هشدار.
• مستندات پاسخ به حادثهٔ PagerDuty — نقش‌ها، کشیک و ارجاع؛ برای تیم‌هایی که می‌خواهند فرایند کشیک بسازند.