Коли телефон розбудив мене о 2-й ночі втретє за місяць, я перестав списувати це на невезіння. Це історія про автоматичний моніторинг дискового простору — той, що ловить диск до того, як він заповниться вночі, а не будить тебе, коли вже пізно. Роками автоматикою був я сам: заходиш напівсонний, зносиш пару гігів старих логів, закриваєш тикет і заповзаєш назад у ліжко, знаючи, що той самий алерт прилетить за тиждень. Він завжди прилітав.
Після тієї третьої ночі я розлютився достатньо, щоб нарешті це полагодити.
Реактивна петля, в якій соромно зізнаватися
Старий сценарій до болю знайомий. Диск о 2-й ночі впирається в 100%. Спрацьовує алерт. Хтось, зазвичай найбільш невиспаний із чергових, гарячково чистить місце, закриває тикет і йде спати. Ні тренду, ні прогнозу. Ніхто не помітив, що цей диск три тижні ріс по відсотку на день і був приречений рвонути саме в середу. Просто гасіння пожеж по колу.
А інфраструктура тільки погіршувала. Ми стежили за сотнею з гаком production-дисків на приблизно п'ятдесяти серверах — змішаний парк Windows і Linux. Windows і Linux рахують зайнятість диска по-різному, тому один наївний запит бреше тобі через раз. Згори NFS-маунти постійно давали false positive: «переповнена» мережева шара, яка до самого хоста не мала жодного стосунку. Я особисто спалив години, ганяючись за привидами, яких не існувало.
Перевернути все: звіт до інциденту, а не після
Полагодження було не в ще одному алерті. Воно було в тому, щоб розвернути таймлайн.
Я зібрав Azure Logic App, який запускається щоранку о шостій — до того, як усі прокинуться, до першої кави. Він ганяє KQL-запити до Log Analytics по всіх ста з гаком дисках, причому Windows і Linux ідуть різними шляхами, бо віддають дані вони просто по-різному. NFS-маунти відсікаються автоматично, тож привиди в результат уже не потрапляють. На той момент, коли команда відкриває ноутбуки, звіт уже лежить у них у пошті.
Дві смуги, бо не кожне число — це НП
Головний трюк був у маршрутизації. Один поріг на все — це або потонути в шумі, або проспати пожежу. Тому система працює у дві смуги.
- Вище 90% — критично. Одразу на on-call із високопріоритетним тикетом і повним ланцюжком ескалації. Це справжня аварія, і вона зобов'язана когось розбудити.
- Вище 75% — проактивно. Тихо лягає в щоденний звіт по трендах. Команда бачить це за ранковою кавою, планує чистку й лагодить у вівторок удень, замість авралу о 2-й ночі в середу.
Контекст важливіший за будь-який один відсоток. 80% на томі в 2 ТБ — це знизування плечима. 80% на диску в 50 ГБ — це зворотний відлік. Саме звіт по трендах перетворює сире число на рішення, яке ти ухвалюєш із розплющеними очима й кавою в руці.
Жодної няньки для cron-джоби
Я свідомо не став вішати cron на VM. Cron на віртуалці — це брехня, яку ти розповідаєш сам собі. Він працює, поки хтось не накотить патч, не перезавантажить машину або не дасть протухнути сертифікату, і тоді твій моніторинг тихо вмирає рівно тоді, коли він потрібен.
Тут serverless. Оплата за запуск. Self-healing ретраї на тимчасових збоях. Він уже місяцями крутиться без жодного ручного втручання: без няньки, без перевірок «а моніторинг ще живий?», без моніторингу для моніторингу.
Найкращий інцидент — той, якого не сталося
Остання фраза звучить як слоган, але в ній уся окупність. Місяці без жодного нічного виклику через диск. Диски й досі заповнюються, це фізика, але тепер вони ввічливо повідомляють про це о шостій ранку, поки є і місце, і час щось зробити.
Якщо ти тримаєш щось на масштабі, урок виходить за межі дисків. Побудуй систему один раз, щоб спати, замість того щоб бути цією системою щоночі. Реактивний моніторинг робить тебе циклом ретраїв. Проактивний змушує машину робити нудну частину й будить тебе тільки заради того, що справді не може чекати.
Коли тебе востаннє піднімали серед ночі через те, що міг би відвернути скрипт?