Плейбук внешнего CTO для шумных алертов и медленной реакции

Что идёт не так, когда каждый алерт выглядит срочным

Когда каждый сигнал приходит с одинаковым тоном, команды перестают верить системе. После достаточного числа ложных тревог люди приглушают каналы, выключают звук на телефоне или ждут несколько минут, прежде чем проверить. Эта пауза кажется маленькой, пока не случается настоящий сбой.

Проблема шире, чем усталость от алертов. Срочность теряет смысл. Если предупреждение о небольшом диске, коротком всплеске трафика и сбое входа выглядит одинаково серьёзным, никто не понимает, что требует внимания прямо сейчас, а что может подождать до утра.

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

Слабое владение сервисами обычно и лежит под этой задержкой. Команды знают, что у них есть «API», «сайт» и «база данных», но не понимают, кто ведёт разбор, когда ломаются платежи или регистрации падают до нуля. Страница уходит в группу, а не человеку. Группа реагирует медленно.

Небольшие команды чувствуют это особенно остро. В 2:14 ночи короткий всплеск нагрузки на базу будит разработчика on-call, основателя и подрядчика по ops. Всплеск проходит сам. Полчаса спустя реально ломается checkout, и все думают, что это опять шум. Так плохие алерты приучают команду пропускать важную проблему.

Больше дашбордов это редко исправляет. График помогает изучить проблему после срабатывания алерта. Он не решает, кто отвечает, какой сигнал важен и когда кого будить. Если маршрут запутан, а правила сделаны небрежно, ещё один экран просто даёт людям ещё одно место, куда смотреть.

Внешний CTO должен сначала рассматривать это как проблему доверия, а уже потом как проблему инструментов. Команды работают быстрее, когда алерты указывают на влияние на пользователей, первый ответчик один, а низкоприоритетный шум вообще не попадает в путь оповещений.

Начните с простой карты владения сервисами

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

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

На странице должно быть видно четыре вещи: как называется сервис, кто им владеет, от каких общих систем он зависит и что замечают пользователи, когда он ломается.

Колонка с зависимостями важнее, чем многим кажется. Общие системы чаще всего и вызывают самые сильные лавины алертов. База данных, сервис авторизации, очередь, DNS-провайдер или почтовый сервис могут положить сразу несколько сервисов. Если вход, биллинг и дашборд зависят от одной и той же базы, это должно быть видно сразу, как только вы открываете страницу. Когда такие алерты приходят вместе, команде стоит сначала проверить базу данных, а не будить трёх человек и терять 20 минут.

Описывайте сбой языком пользователя, а не машины. «Клиенты не могут войти» лучше, чем «уровень auth error выше 8%». «Заказы останавливаются на оплате» лучше, чем «таймаут в сервисе B». Люди быстрее сортируют инциденты, когда влияние очевидно.

Большинство небольших команд может собрать такую карту меньше чем за час. Откройте документ, внесите сервисы, назначьте имена и отметьте общие части. Не ждите идеальной детализации. Черновая карта, которой люди действительно пользуются, лучше подробной карты, которую никто не открывает во время инцидента.

Сначала очистите маршруты алертов, а уже потом добавляйте новые правила

Большинство команд реагируют на шумные алерты добавлением новых правил. Обычно это только ухудшает беспорядок. Прежде чем трогать пороги или собирать ещё один дашборд, проследите каждый алерт от срабатывания до конечной точки. Кто получает его первым? Кто получает следующим? Кто реально начинает действовать?

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

Чистый маршрут специально сделан скучным. У одного алерта должен быть один понятный первый владелец. Если одновременно будят три команды, все три решают, что кто-то другой возьмёт задачу. Сначала будите ту команду, которая ближе всего к проблеме пользователя. Остальные могут следить за каналом, но не должны все получать первое пробуждение.

Начните с нескольких простых исправлений:

• уберите каналы, которые никто не читает
• удалите правила, привязанные к старым сервисам или бывшим сотрудникам
• объедините дублирующиеся алерты, которые описывают один и тот же сбой разными словами
• сделайте цепочку эскалации короткой: владелец, резервный, затем incident lead

Дублирующиеся алерты — один из главных источников шума. Одно замедление базы может за минуту вызвать инфраструктурный алерт, алерт ошибки API и алерт таймаута приложения. Но проблема всё равно одна. Объедините их в один основной алерт с достаточным контекстом, чтобы первый ответчик мог действовать.

Длинные деревья эскалации выглядят безопасно, но они съедают минуты. Большинству небольших команд хватает короткой цепочки. Если checkout тормозит, сначала будите владельца сервиса, а не backend, product и infrastructure одновременно. Этот владелец сможет быстро подключить помощь, если проблема затронула несколько систем.

Сначала ставьте сигналы о влиянии на пользователя

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

Здесь помогает простой фильтр: этот сигнал говорит о вреде для пользователя или только о внутренней активности системы? Фоновые предупреждения тоже важны, но они редко заслуживают той же срочности, что и сломанный checkout или всплеск ошибок входа. Когда всё выглядит критично, pager теряет доверие.

Для многих продуктов небольшого набора пользовательских сигналов хватает почти на всё:

• резко растёт доля неудачных попыток входа
• падает успешность checkout или оплаты
• сильно растёт время загрузки страницы на основном пользовательском пути
• увеличивается уровень ошибок на самых популярных API-эндпоинтах
• внезапно падают регистрации, бронирования или отправка форм

Эти алерты работают, потому что ведут к действию. Если растут ошибки входа, кто-то проверяет auth, последние деплои, identity provider и лимиты по запросам. Если ломается checkout, команда смотрит ошибки у платёжного провайдера, создание заказа и блокировки инвентаря. Если время загрузки страницы удваивается, проверяют медленный эндпоинт, запросы к базе и всё новое в последнем релизе.

Резкие изменения важнее медленного дрейфа, когда вы решаете, кого будить. Диск базы на 78% обычно не требует действий этой ночью. А вот падение успешности оплаты с 97% до 81% за пять минут, скорее всего, требует. Оповещения на изменения помогают ловить живые инциденты, а не собирать мелочи.

Дашборды всё ещё нужны, просто позже. Они помогают людям исследовать проблему после срабатывания алерта. Но они не спасают слабый дизайн оповещений. Если сигнал не объясняет команде, что сломалось и что проверить первым, он ещё не готов будить людей.

Перестраивайте правила алертов по одному

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

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

Когда вы проверяете каждый алерт, задайте несколько прямых вопросов. Он привёл к понятному действию? Он попал к нужному человеку? Пользователи почувствовали проблему до того, как алерт сработал? Одна и та же проблема будила людей снова и снова? Эти вопросы обычно показывают, что оставить, что убрать и что перевести в дневную проверку.

Затем перепишите текст алерта. Каждое сообщение должно называть сервис, описывать симптом и подсказывать первую проверку. «Ошибки API checkout 12% в течение 10 минут. Проверьте последний деплой, затем задержку у платёжного провайдера» гораздо лучше, чем «Обнаружен высокий уровень ошибок».

Следите за правилами, которые объединяют разные проблемы. Медленная база, зависший worker очереди и таймаут у внешнего сервиса могут случиться одновременно, но реакция в каждом случае разная. Если первый шаг меняется, алерт нужно разделить.

Добавьте cooldown, чтобы одна и та же проблема не будила людей всю ночь. Повторяющиеся алерты приучают команду игнорировать pager. Один алерт, понятный владелец и разумное окно повторов обычно достаточно.

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

Реалистичный пример из небольшой команды

У команды SaaS из семи человек была типичная проблема. Их система мониторинга отправляла от 40 до 60 предупреждений по базе данных в обычный день, и почти все они выглядели серьёзно. Всплески CPU, медленные запросы, replica lag, неудачные повторы — каждая страница звучала срочно, поэтому люди перестали доверять pager.

Самый важный сигнал пришёл не от инженеров. Он пришёл от поддержки. Клиенты писали о проблемах со входом ещё до того, как кто-то открыл инцидент. У команды были алерты, дашборды и логи, но о боли пользователей они всё равно узнавали из входящих сообщений.

Тогда они на неделю перестали подстраивать пороги и нарисовали простую карту. Они сгруппировали алерты по сервисам: auth, app API, database и background jobs. Затем каждый алерт пометили по вероятному вреду для пользователя.

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

Разница проявилась сразу. До очистки первая страница часто будила не того человека из-за проблемы, которая началась в другом месте. После — первое оповещение уже содержало достаточно контекста для действия. «Уровень неудачных входов вырос на 8% за 10 минут» выигрывал у «высокие соединения к базе» каждый раз.

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

За две недели среднее время реакции упало примерно с 18 минут до 6. Они добились этого не благодаря ещё одному дашборду. Всё получилось потому, что первая страница наконец стала понятной первому человеку, который её получил.

Ошибки, которые поддерживают шум

Команды редко сохраняют шумные алерты, потому что им это нравится. Обычно это происходит потому, что одни и те же привычки переживают каждую чистку.

Одна частая ошибка — будить людей из-за технической нагрузки, которую пользователи вообще не чувствуют. Высокий CPU, короткие всплески нагрузки или полный диск у некритичного worker могут быть важны позже, но они не должны будить человека ночью, если продукт продолжает работать. Оставляйте такие сигналы на рабочее время, сводки или низкоприоритетные очереди, если они не связаны напрямую с клиентским сбоем.

Другая ошибка — отправлять один симптом сразу в несколько групп. Получается быстрый всплеск активности и медленный старт реальной работы. Все заходят в чат. Никто не владеет первым шагом. Если на вопрос «Кто должен действовать прямо сейчас?» ответ «зависит», правило, скорее всего, неверное.

Старые системы добавляют ещё один слой шума. Команды выводят сервис из эксплуатации, переносят задачу или объединяют два приложения, а потом забывают очистить правила и цепочки эскалации вокруг него. Спустя месяцы алерты всё ещё приходят людям, которые уже не работают с этой областью. Так и появляются ночные страницы по системам, у которых вообще нет владельца.

Нечёткий текст алерта делает всё это хуже. «Обнаружена проблема с базой данных» почти ничего не говорит дежурному. Полезный алерт указывает, какой сервис затронут, что видят пользователи, какой порог сработал и что проверить первым делом.

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

Быстрые проверки для следующего инцидента

Когда срабатывает алерт, скорость появляется из ясности, а не из большего числа графиков. Небольшая команда должна уметь быстро проверить ситуацию меньше чем за минуту и понять, кто действует первым.

Используйте эти проверки, прежде чем кто-то откроет три дашборда и начнёт гадать:

• Может ли кто-то назвать владельца сервиса за 10 секунд?
• Описывает ли алерт проблему пользователя, а не только внутреннюю метрику?
• Знает ли один человек первый шаг прямо сейчас?
• Отправит ли система оповещение об этом же инциденте дважды через разные правила?
• Может ли поддержка быстро подтвердить проблему по тому, что уже видит?

Если на первый вопрос ответ «нет», проблема в владении, а не в мониторинге. Сервис без понятного владельца медленнее реагирует, шумнее обсуждается в чате и чаще получает повторные страницы.

Если на второй вопрос ответ «нет», алерт слишком технический. «CPU на 92%» может быть важно, но пользователи не чувствуют CPU. Они чувствуют неудачные входы, медленный checkout, пропавшие письма или пустые страницы. Алерт должен говорить об этом простыми словами.

Третья проверка не даёт людям застыть. Один человек должен знать первый шаг, даже если он простой: перезапустить worker, поставить на паузу очередь задач, откатить последний деплой или проверить статус зависимости. В первую минуту не нужен полный фикс. Нужен понятный первый шаг.

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

Поддержка важнее, чем готовы признать многие инженерные команды. Если поддержка может подтвердить проблему за 30 секунд, она может остановить неверные догадки, успокоить клиентов и дать инженерам реальный симптом, с которым можно работать.

Что делать дальше

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

За одну короткую рабочую сессию сделайте четыре вещи. Назначьте одного владельца и одного резервного. Уберите, объедините или перенастройте алерты, которые редко приводят к действию. Добавьте два сигнала, связанных с влиянием на пользователя, например долю неудачного checkout или ошибки входа. Затем вместе с engineering, support и operations проверьте маршрут, чтобы первая страница доходила до нужного человека.

После очистки следите за следующей неделей страниц. Считайте, сколько алертов привели к действию, сколько ушли не тому человеку и сколько пользователей заметили проблему раньше команды. Это даст вам базовую точку для следующего сервиса.

Если вам нужен внешний взгляд, Oleg Sotnikov из oleg.is работает как Fractional CTO и startup advisor для малого и среднего бизнеса. Он помогает командам разобраться с владением сервисами, production-инфраструктурой и практичными AI-supported development workflows, что сильно упрощает такую очистку алертов без добавления нового шума.