Когда телефон разбудил меня в 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 ретраи на временных сбоях. Он уже месяцами крутится без единого ручного вмешательства: без няньки, без проверок «а мониторинг ещё живой?», без мониторинга для мониторинга.

Лучший инцидент — тот, которого не случилось

Последняя фраза звучит как слоган, но в ней вся окупаемость. Месяцы без единого ночного вызова из-за диска. Диски по-прежнему заполняются, это физика, но теперь они вежливо сообщают об этом в шесть утра, пока есть и место, и время что-то сделать.

Если ты держишь что-то на масштабе, урок выходит за пределы дисков. Построй систему один раз, чтобы спать, вместо того чтобы быть этой системой каждую ночь. Реактивный мониторинг делает тебя циклом ретраев. Проактивный заставляет машину делать скучную часть и будит тебя только ради того, что действительно не может ждать.

Когда тебя в последний раз поднимали среди ночи из-за того, что мог бы предотвратить скрипт?