وقتی هشدارها را خاموش می‌کنند: درس ۱۵۰ پیامک در ۷۲ ساعت

این مقاله دربارهٔ اشتباهی است که خودم کردم، چون درسش از هر توصیهٔ کلی‌ای مفیدتر است.

قاعده‌ای نوشته بودم برای هشدار «لاگ ترنزکشن پر شده». منطقش ساده بود: اگر درصد پر بودن لاگ از آستانه بالاتر رفت، هشدار بده. در آزمایش کار می‌کرد. روی سرور واقعی، در ۷۲ ساعت ۱۵۰ پیامک فرستاد.

چه شد

بیشتر آن پیامک‌ها از tempdb بود. لاگ tempdb طبیعتاً مثل ارّه بالا و پایین می‌رود: با یک عملیات مرتب‌سازی بزرگ پر می‌شود، بعد از checkpoint آزاد می‌شود، و دوباره. هیچ‌کدام از آن اوج‌ها مشکل نبودند.

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

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

ریشه: معیار غلط بود، نه آستانه

وسوسهٔ اول این است که آستانه را بالا ببرید: از ۸۵٪ به ۹۵٪. این کار تعداد پیامک را کم می‌کند و مسئله را حل نمی‌کند، چون مشکل در عدد نبود، در مفهوم بود.

«لاگ پر است» مشکل نیست. «لاگ پر است و نمی‌تواند خالی شود» مشکل است. SQL Server خودش دومی را در یک ستون می‌گوید:

SELECT name, log_reuse_wait_desc
FROM   sys.databases
WHERE  log_reuse_wait_desc <> N'NOTHING';

با این معیار، لاگ ۹۰٪ پرِ tempdb که در checkpoint بعدی آزاد می‌شود، هشدار نمی‌دهد؛ ولی لاگ ۶۰٪ پری که روی LOG_BACKUP ایستاده، می‌دهد — و آن دومی دقیقاً همان چیزی است که می‌خواستیم بدانیم.

درس عمومی‌اش این است: وقتی هشداری زیاد می‌آید، اول معیار را زیر سؤال ببرید، نه آستانه را. بالا بردن آستانه، هم هشدارهای کاذب را کم می‌کند و هم هشدارهای واقعی را — و شما نمی‌دانید کدام را از دست داده‌اید.

چهار لایه‌ای که در نهایت لازم شد

اصلاح معیار لازم بود ولی کافی نبود. چیزی که ساختیم چهار لایه دارد و هر کدام یک نوع خرابی متفاوت را می‌گیرد:

۱. شناسهٔ یکتای مشکل

هر مشکل با ترکیب سرور + قاعده + شیء یک شناسه می‌گیرد. تا آن مشکل باز است، دور بعدی بررسی هشدار تازه‌ای نمی‌سازد؛ همان را به‌روز می‌کند. بی این، یک مشکلِ پابرجا در پایشِ دقیقه‌ای، ساعتی ۶۰ پیام می‌شود.

۲. دورهٔ سکوت و نردبان

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

۳. سقف روزانهٔ مستقل

بالای همهٔ منطق‌ها، یک سقف ساده: در ۲۴ ساعت گذشته بیش از n پیامک نه. این لایه عمداً مستقل از منطق هشدار است، چون کار هر لایهٔ دیگر این است که تصمیم بگیرد چه چیزی مهم است؛ کار این لایه این است که وقتی همهٔ آن تصمیم‌ها اشتباه بودند، جلوی خسارت را بگیرد.

و یک جزئیات که در عمل حیاتی شد: بخشی از سقف برای هشدارهای بحرانی رزرو است. بی این، سی هشدار کم‌اهمیت سقف را می‌خورند و هشدار واقعیِ ساعت سه بامداد هرگز نمی‌رسد — یعنی دقیقاً همان چیزی که سقف برای جلوگیری‌اش گذاشته شده بود.

۴. خبر «حل شد»، فقط برای بحرانی‌ها

آرام‌بخش است، ولی حجم را دو برابر می‌کند و برای مشکل نوسانی خودش تبدیل به سیل می‌شود.

چطور بفهمید سیستم هشدارتان مریض است

سه نشانه:

• کسی در تیم قاعده‌ای در موبایلش ساخته که این پیام‌ها را بی‌صدا کند.
• وقتی هشداری می‌آید، اولین واکنش «باز هم همون» است، نه «چی شده؟».
• نمی‌توانید به یاد بیاورید آخرین باری که یک هشدار به کار مشخصی منجر شد کِی بود.

اگر هر کدام از این‌ها صدق می‌کند، افزودن هشدار تازه کمکی نمی‌کند. باید تعداد را کم کنید تا آن‌هایی که می‌مانند دوباره معنا پیدا کنند.

معیار موفقیت

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

بعد از اصلاح معیار در محصول خودمان، همان سروری که ۱۵۰ پیامک فرستاده بود، در روزهای بعد صفر پیامک داد — در حالی که لاگ tempdb همچنان تا ۹۰٪ بالا می‌رفت. تفاوت این بود که حالا سیستم می‌دانست کدام ۹۰٪ مهم است.