Учебная тревога раз в квартал: ломаем нарочно и смотрим, придёт ли алерт

MAATRIX

Мониторинг настроен, правило алерта написано, в Telegram даже прилетело тестовое сообщение в день установки — и с тех пор об этом никто не вспоминал полгода. Проблема в том, что «настроен» и «работает при настоящей проблеме» — это два разных факта, и разница между ними обычно вскрывается в худший момент: когда сервис уже лежит, а уведомление почему-то не пришло. Единственный способ узнать заранее — самим сломать что-то контролируемо и засечь, дойдёт ли сигнал до живого человека.

Зачем алерт может молчать, даже если он настроен

Правило алерта — не разовая настройка, а звено в цепочке из пяти-шести компонентов, и каждое может незаметно сломаться по отдельности, не трогая остальные. Метрика собирается — но правило сравнивает её с порогом не с той стороны. Правило срабатывает — но алертменеджер молчит, потому что на нём висит забытый silence с прошлого инцидента. Алертменеджер отправляет — но токен телеграм-бота истёк или бота выкинули из чата при очередной чистке участников. Сообщение доходит до чата — но в него никто не смотрит, потому что уведомления давно отключены на телефоне. По отдельности каждое звено выглядит рабочим: график в Grafana есть, правило видно в конфиге, бот отвечает на /start. Но сквозную цепочку «событие → детект → алерт → доставка → человек увидел» никто не проверяет целиком, потому что для этого нужна настоящая (или имитированная) проблема, а не разглядывание конфигов.

Компоненты этой цепочки к тому же меняются со временем сами по себе, без участия того, кто настраивал алерты изначально: увольняется сотрудник, чей телефон был привязан к дежурному боту; у почтового провайдера ужесточается антиспам, и алерты начинают улетать в «Спам» без единого сообщения об ошибке на стороне отправителя; истекает или отзывается токен бота после ротации секретов. Ни одно из этих событий не генерирует алерт о том, что алерты сломались — классическая проблема «сторож не знает, что сам заснул», разобранная отдельно в статье про то, как алерт может уйти в чат, который никто не открывает.

Есть и более тонкая версия той же проблемы — порог алерта в принципе не задевается при настоящей аварии. Классика: алерт настроен на «место на диске < 5%», а сервис начинает сыпать ошибками уже при 15% свободного места, потому что не может писать временные файлы. Формально алерт «работает», но к моменту его срабатывания сервис уже час как недоступен. Эта категория граблей разобрана в статье про алерт на девяносто процентов, когда сервис умирал на семидесяти. Учебная тревога закрывает обе проблемы разом — и «дойдёт ли сигнал», и «сработает ли порог вовремя», — потому что создаёт условия, похожие на реальную деградацию, а не просто дёргает тестовый вебхук.

Что можно ломать безопасно

Ключевое слово — «безопасно»: цель не устроить настоящий инцидент, а вызвать событие, которое пересечёт реальный порог алерта, но не нанесёт ущерба, который нельзя быстро откатить. Безопасность держится на трёх вещах: изоляции (тестовая среда либо некритичный сервис в проде), обратимости (заранее известный способ отмены за секунды) и ограничении по времени.

Практичные способы контролируемо создать проблему:

• Занять диск. fallocate -l 9G /tmp/testfile создаёт файл нужного размера без реальной записи данных. Удаляется мгновенно: rm /tmp/testfile.
• Нагрузить CPU. stress-ng --cpu 4 --timeout 300s создаёт управляемую нагрузку на заданное время и сам завершается.
• Остановить некритичный сервис. systemctl stop имя-сервиса на тестовом воркере или на одной из нескольких реплик за балансировщиком — сервис недоступен ровно до systemctl start.
• Заблокировать порт файрволом. iptables -A INPUT -p tcp --dport 443 -j DROP на тестовом сервере имитирует недоступность извне; снимается iptables -D INPUT -p tcp --dport 443 -j DROP. На проде так делать не стоит.
• Заполнить лог ошибками. Если алерт настроен по числу ERROR-строк за окно времени, можно нагенерировать нужное число строк скриптом в тестовый лог-файл, который читает тот же коллектор.
• Отозвать доступ к базе. На тестовом окружении — сменить пароль БД в конфиге приложения (не в самой БД) на заведомо неверный, перезапустить сервис, зафиксировать алерт, откатить конфиг.

Общее правило: не тестируйте то, что не откатите одной командой. Если для отмены нужно вспоминать пять шагов — сценарий слишком рискованный для боевой среды, переносите его на тестовый стенд.

Подготовка: объявленный тест или «слепой», и чек-лист перед запуском

Здесь два подхода, и путать их не стоит. Объявленная тревога (все знают время и суть заранее) проверяет техническую цепочку: сработает ли правило, дойдёт ли сообщение, корректен ли формат. Слепая тревога (знает только инициатор) дополнительно проверяет человеческий фактор: заметит ли дежурный уведомление вовремя, не проигнорирует ли его как шум.

Для ежеквартальной практики разумно начинать с объявленных тестов — они дешевле по нервам и быстрее выявляют технические сбои (истёкший токен, неверный вебхук, забытый silence). Слепые тесты имеет смысл проводить реже, раз в полгода-год, и только когда техническая часть уже несколько раз подряд отработала штатно. Важная деталь для объявленных тестов: предупреждать нужно не в тот канал, куда прилетит тестовый алерт, а отдельным сообщением заранее — иначе вы проверите только то, что люди читают предупреждения о тестах, а не то, замечают ли алерты вообще.

Прежде чем ломать что-либо, стоит письменно зафиксировать несколько вещей — это занимает пять минут, но экономит часы разбора, если тест пойдёт не по плану.

1. Дата и окно времени. Например, «третий вторник квартала, 11:00–12:00 по МСК» — не в пятницу вечером и не перед праздниками.
2. Что именно ломаем и какой командой откатываем. Обе команды выписаны заранее и проверены на выполнимость даже под стрессом.
3. Какой алерт должен сработать. Название правила из конфига (Prometheus rule, Zabbix trigger, Uptime Kuma monitor) — чтобы не гадать, тот ли это был алерт.
4. Кто должен получить уведомление. Конкретное имя дежурного и канал (Telegram, email, SMS), а не абстрактное «команда».
5. Кто наблюдает и фиксирует время. Отдельный человек, не участвующий в действии, засекает три момента: поломку, появление алерта, подтверждение дежурного.
6. План Б. Если через 15 минут алерт не пришёл и откат не восстановил ситуацию — кому звонить и что делать руками.

Такой чек-лист по сути — мини-версия обычного регламента на инцидент, только для контролируемой ситуации. Если в компании уже есть регламент на первые минуты после обнаружения проблемы, учебную тревогу удобно тестировать именно на нём — подробнее в статье про первые 15 минут инцидента.

Пошаговый сценарий на примере диска

Разберём целиком один прогон, чтобы было видно, как чек-лист превращается в конкретные действия.

Шаг 1. Фиксируем состояние «до». Смотрим текущее свободное место и статус алертменеджера:

df -h /var
curl -s http://localhost:9093/api/v2/status | jq '.cluster.status'

Шаг 2. Наблюдатель запускает секундомер и фиксирует время старта в отдельном документе (время события, время алерта, время подтверждения).

Шаг 3. Создаём проблему. На тестовом сервере (или на некритичном разделе прода, если тест согласован):

fallocate -l 9G /var/tmp/drilltest.img
df -h /var

Шаг 4. Ждём и не трогаем систему. Не перезапускаем сервисы и не лезем в конфиги — это смажет замер времени. Засекаем момент, когда сообщение реально дошло до канала дежурного, а не появилось в интерфейсе алертменеджера.

Шаг 5. Дежурный подтверждает получение. Не молча выключает алерт, а отвечает в канал: «Вижу, тестовая тревога, отбой». Это фиксирует не только доставку, но и то, что человек понял смысл сообщения.

Шаг 6. Откатываем.

rm /var/tmp/drilltest.img
df -h /var

Шаг 7. Проверяем, что алерт сам погас (для алертов с автоматическим resolve), и фиксируем время разрешения — сколько система молчит после того, как проблема ушла.

Тот же скелет переносится на любой другой тип поломки — меняется только команда на шаге 3 и 6.

Что фиксировать по итогам

Смысл учебной тревоги — не в самом факте «что-то сломали», а в данных, которые остаются после. Минимальный набор, который стоит записывать при каждом прогоне:

По итогу удобно вести файл с историей прогонов — чтобы видеть тренд: время доставки, которое было 40 секунд в первом квартале и стало 6 минут в третьем, — сигнал, что где-то в цепочке появилась задержка, и её стоит найти до того, как она сыграет роль в настоящем инциденте.

Отдельно стоит документировать любой прогон, в котором алерт не сработал или не дошёл — это самый ценный результат учебной тревоги, ради которого всё и затевалось. Такой случай нужно разобрать по той же логике, что и обычный производственный инцидент: что именно сломалось в цепочке, почему не было замечено раньше, что изменить, чтобы не повторилось.

Частые причины, почему тревога не доходит, и как встроить проверку в регламент

По опыту прогонов таких тестов на реальных серверах чаще всего всплывают одни и те же причины молчания:

• Токен бота истёк или был отозван после ротации секретов «для безопасности», а конфиг алертменеджера не обновили.
• Бота выкинули из группового чата при чистке участников — без единого сообщения об ошибке на стороне отправителя.
• На алертменеджере висит забытый silence с прошлого инцидента — кто-то заглушил алерт на время работ и забыл снять заглушку.
• Правило есть, но метрика перестала собираться. Экспортер упал, таргет выпал из discovery — график выглядит «плоским», что легко спутать с «всё в порядке».
• Уведомления отключены на телефоне у конкретного дежурного — сообщение долетело до Telegram, но не показалось как push, потому что чат когда-то заглушили.
• Письмо ушло в спам — особенно если у отправителя нет настроенных SPF/DKIM записей. Похожие причины разобраны в статье о том, почему Uptime Kuma не шлёт уведомления — многие актуальны для любой системы алертинга.
• Дежурный сменился, а список контактов — нет. Человек уволился три месяца назад, а его номер до сих пор в эскалации первого уровня.

Каждая причина по отдельности звучит банально постфактум — но именно поэтому их не находят при обычном аудите конфигов: конфиг синтаксически корректен, ошибки нет нигде, кроме реальности.

Учебная тревога работает как практика, только если она не разовая акция, а рутина с фиксированной периодичностью — раз в квартал достаточно для большинства небольших и средних инфраструктур. Более частые проверки нужны там, где инфраструктура быстро растёт или команда часто меняется; более редкие обычно означают, что к моменту находки проблема уже накопилась в нескольких местах цепочки сразу.

Практические детали, которые делают привычку устойчивой:

• Ставьте прогон в календарь заранее, а не «когда будет время» — задачи без даты откладываются бесконечно.
• Ротируйте, кто инициирует тест. Если один и тот же человек всегда и ломает, и чинит, он невольно подстраивает сценарий под то, что точно сработает.
• Ведите историю прогонов в одном месте и возвращайтесь к ней при следующем, чтобы видеть тренд, а не только последний результат.
• Автоматизируйте повторяющуюся часть — простой bash-скрипт, создающий и удаляющий тестовый файл, экономит пять минут на прогон. Для одного-трёх серверов обычный cron-скрипт с логированием результата достаточен — специализированные chaos-engineering инструменты нужны не всем.
• Не превращайте разбор в поиск виноватого. Цель — найти сломанное звено цепочки, а не наказать того, кто забыл продлить токен. Команда, где за находку сломанного алерта наказывают, быстро перестаёт их находить.

Частые вопросы