Почему поток тревог мешает замечать настоящие сбои и как разделять срочные, обычные и информационные сигналы.
Когда каждый сигнал звучит одинаково
Представьте команду, которая утром открывает десятки сообщений о данных: один отчёт задержался на минуту, другой не обновился вовсе, в третьем изменилась подпись столбца. Если все события отправляются как срочная тревога, человеку трудно заметить то, из-за чего сотрудники уже принимают решение по неверной цифре. Избыток оповещений создаёт не дополнительную надёжность, а очередь на разбор.
Оповещение должно отвечать на вопрос: что произошло и какое действие от команды требуется сейчас? Google SRE рекомендует, чтобы срочные сигналы были сразу пригодны для действия и имели высокое отношение полезного сигнала к шуму. Иначе у дежурных возникает усталость от тревог, а важное событие теряется среди привычных ложных срабатываний.
Начать с последствий для пользователя
Не всякая техническая необычность означает проблему для читателя отчёта. Например, вспомогательная загрузка может опоздать, но итоговая таблица ещё остаётся актуальной по согласованному сроку. Другая ситуация — вчерашние данные показываются под сегодняшней датой. Вторая проблема влияет на доверие к отчёту и требует более быстрой реакции.
Полезно описать для каждого важного набора данных, кто им пользуется, к какому времени он нужен и как выглядит ошибка. Это помогает отделить наблюдение для последующего анализа от сигнала, который должен прервать работу дежурного. Руководство Google SRE предлагает категории и уровни серьёзности: небольшую проблему можно отправить в обычную очередь, а полный отказ требует немедленного ответа.
Условный пример: сто сообщений об одной причине
Допустим, общий источник заказов временно недоступен. Из-за этого десять отчётов не обновились и каждый отправил по нескольку тревог. Для дежурного полезнее одно понятное сообщение о первопричине и список затронутых отчётов, чем отдельный срочный сигнал от каждой таблицы. Это не означает скрыть последствия: их нужно показать в карточке инцидента, но не превращать в десятки одинаковых вызовов.
Google SRE описывает подавление повторяющихся оповещений, когда у многих узлов одна общая проблема, и подчёркивает необходимость снова включать сигнал после завершения события. Для команды данных аналогичный принцип требует аккуратности: объединять можно только связанные тревоги, иначе независимый сбой окажется незаметным.
Срочное, обычное и информационное
Простой маршрут состоит из трёх уровней. Срочный сигнал отправляют человеку, если важный отчёт сейчас недоступен или даёт опасно неверный результат и нужно немедленное действие. Обычную задачу создают для устойчивого, но некритичного отклонения, которое можно разобрать в рабочее время. Информационное событие сохраняют для наблюдения и разбора тенденции без вызова дежурного.
Граница между уровнями зависит от договорённости с владельцами данных, а не от цвета значка в системе мониторинга. Для конкретного отчёта стоит зафиксировать ожидаемое время готовности и последствия задержки. Если такой договорённости нет, поможет материал о SLO для данных. Это цель по надёжности услуги, а не магическая настройка, которая сама решает, когда тревожить людей.
После инцидента пересматривать правила
Каждое реальное происшествие даёт повод спросить: пришёл ли нужный сигнал вовремя, был ли понятен следующий шаг, сколько лишних сообщений сопровождало событие? Если тревога регулярно не требует действия, её стоит изменить или перевести в менее срочную категорию. Если серьёзный сбой обнаружили пользователи раньше команды, правила не охватывают важное последствие.
Для повторяемых ситуаций полезна короткая инструкция дежурному; о её составе рассказывает статья про runbook при сбое данных. Если интересна профессия, в которой качество данных и работа команды рассматриваются вместе, посмотрите программу «DataOPS инженер». Выбирайте обучение по задачам, которые действительно встречаются в вашей системе.
