Мониторинг ботов и сервисов: что проверять и когда будить человека
Бот перестал отвечать в час ночи, вебхук отвалился после обновления, у внешнего сервиса закончился баланс — а узнали об этом утром от клиента. Мониторинг нужен не для красивых графиков, а чтобы о сбое первым узнавал дежурный, а не заказчик. Разберём, что именно проверять у бота и небольшого сервиса, чем отличаются проверки снаружи и метрики изнутри, и когда сигнал должен будить человека.
Коротко
- В опросе Uptime Institute 2025 года 57% респондентов сказали, что последний крупный простой стоил дороже $100 тыс., каждый пятый — дороже $1 млн. Это данные операторов дата-центров, но порядок потерь показателен и для сервисов поменьше.
- New Relic (2024, 1 700 специалистов из 16 стран): медиана годового простоя от серьёзных сбоев — 77 часов, а у команд с полной наблюдаемостью 70 часов против 338 у остальных, то есть на 79% меньше.
- Google в книге SRE советует начинать с четырёх сигналов: задержка, трафик, ошибки, насыщение. При цели 99,9% доступности это не более 9 часов простоя в год, и проверки раз в 1–2 минуты для неё достаточно.
- Алерт будит человека только тогда, когда он срочный, действенный и требует решения. Если ответ всегда один и тот же («перезапусти»), это работа для автоматики, а не для дежурного.
- Первые три шага: внешняя проверка ключевого сценария, подтверждение сбоя второй проверкой и один канал с явно назначенным дежурным. Это дешевле любой платформы наблюдаемости.
Что ломается у бота и небольшого сервиса
У бота набор отказов короче, чем у большого распределённого приложения, но заметить их сложнее: процессы запущены, порты открыты, а результата нет. Типичные поломки выглядят так:
- Процесс жив, но зависла очередь сообщений — новые приходят и не обрабатываются.
- Истёк токен или ключ доступа: внешний API отвечает 401 или 403, бот молчит.
- У провайдера модели или SMS закончился баланс — ответы перестали формироваться.
- Отвалился вебхук: платформа присылает события, а ваш обработчик отвечает ошибкой.
- Заполнился диск от логов, и запись в базу падает.
- Истёк сертификат, и часть клиентов вместо ответа видит ошибку соединения.
- Всё работает, но медленно: ответ приходит за сорок секунд, и человек уходит.
Ни один из этих сбоев не виден по зелёной лампочке на главной странице. Проверка должна повторять то, что делает клиент: отправить сообщение и дождаться осмысленного ответа за отведённое время. Мы в инженерных проектах начинаем именно с этого списка сценариев, а не с выбора инструмента, и в кейсах видно, что чаще всего ломается не сервер, а связка между сервисами.
Четыре сигнала, которых обычно хватает
В книге Google про SRE есть простая рамка: если можете измерять только четыре вещи о пользовательском сервисе, берите задержку, трафик, ошибки и насыщение. Для бота и небольшого сервиса эти четыре сигнала переводятся в конкретные проверки.
| Сигнал | Что означает | Как проверить у бота | На что смотреть |
|---|---|---|---|
| Задержка | Сколько идёт ответ, отдельно для успешных и неуспешных запросов | Время от сообщения до ответа бота, время ответа внешнего API | 95-й и 99-й процентиль, а не среднее |
| Трафик | Сколько запросов приходит и с какой интенсивностью | Сообщений в час, вызовов API в минуту | Падение до нуля — тоже сбой, а не тишина |
| Ошибки | Доля неуспешных запросов, включая «код 200, но ответ неверный» | Коды 5xx, отказы внешнего API, ответы «не понял» | Порог по доле ошибок, а не по одной ошибке |
| Насыщение | Насколько заполнен самый узкий ресурс | Диск, память, длина очереди, остаток баланса | Предупреждать до того, как упрётся в предел |
Средние значения обманывают. Если средняя задержка 100 мс при тысяче запросов в секунду, один процент запросов вполне может идти по пять секунд — и именно эти клиенты уходят. Поэтому на рисунках и в алертах смотрим хвост распределения, а не среднее.
Проверки снаружи и метрики изнутри
В SRE разделяют чёрный и белый ящик. Проверка чёрного ящика смотрит на сервис глазами клиента: отправили сообщение — получили ответ. Белый ящик смотрит внутрь: очередь, память, коды ответов внешних API, остаток баланса. Для бота нужны оба, но роли у них разные.
- Снаружи проверяем результат: бот отвечает, заявка создаётся, оплата проходит. Это единственный способ заметить «работает, но неправильно».
- Изнутри видим приближение сбоя: очередь растёт, диск заполняется, баланс кончается. Снаружи этого ещё не видно, а через сутки сервис встанет.
- Снаружи плохо видна причина, изнутри — плохо видно, страдает ли клиент. Поэтому алерт ставится на симптом, а метрики нужны для разбора.
Путь сигнала до дежурного
Сама проверка — только начало. Между «проверка сработала» и «человек начал разбираться» есть несколько шагов, и на каждом сигнал может потеряться.
Сколько стоит час простоя
Uptime Institute в отчёте об авариях 2026 года приводит данные своего опроса 2025-го: 57% респондентов сказали, что последний крупный простой обошёлся дороже $100 тыс., каждый пятый — дороже $1 млн, а примерно один из десяти назвал последствия серьёзными или тяжёлыми. Выборка — операторы дата-центров, то есть инфраструктура крупнее вашей; переносить суммы на бота нельзя, но вывод о порядке потерь держится.
New Relic в обзоре наблюдаемости за 2024 год оценивает иначе: медиана годового простоя от серьёзных сбоев — 77 часов, а стоимость часа доходит до $1,9 млн у крупных организаций. Команды тратят около 30% рабочего времени на разбор сбоев и прерываний, то есть примерно 12 часов из 40-часовой недели. Исследование вендорское, цифры — самооценка респондентов.
Свою цену часа простоя надо считать отдельно, и она редко похожа на миллион. Для бота на двести сообщений в день это несколько потерянных заявок, час работы человека, который разбирает переписку вручную, и репутация у тех, кто не получил ответ. Считается это за десять минут: сколько заявок в час, сколько стоит потерянная заявка, сколько стоит час разбора. Если сумма меньше стоимости настройки — начинать всё равно стоит с внешней проверки, она почти бесплатна.
Алерты и дежурство: кого будить
Google в книге SRE прямо говорит: будить человека дорого. Если алерты приходят слишком часто, сотрудники начинают переспрашивать, просматривать их по диагонали или игнорировать — и пропускают настоящий сбой среди шума. Отсюда несколько правил, которые работают и в команде из трёх человек.
- Каждый алерт действенный: понятно, что делать, и это нельзя отложить до утра.
- Алерт требует решения, а не действия по инструкции. Если ответ всегда «перезапусти сервис», это задача для автоматики.
- Один сбой — один алерт. Пять сообщений об одном и том же не ускоряют реакцию, а мешают.
- Почтовые уведомления — не алерты: их почти не читают. Для несрочного нужен дашборд или утренняя сводка.
- Порог ставится по влиянию на клиента, а не по красоте метрики.
В той же главе описан случай Bigtable: алерты срабатывали так часто, что команда тратила время на их разбор и пропускала проблемы, которые действительно задевали пользователей. Помогло не улучшение алертов, а временное снижение планки: часть уведомлений отключили и занялись причиной. Мораль простая — количество алертов это тоже метрика, и её надо держать под контролем.
Кто встаёт ночью
Мониторинг без дежурного — это журнал наблюдений. Нужен ответ на три вопроса: кто смотрит, в какие часы и что считается поводом звонить. Как мы устраиваем это в своих проектах:
- Часы: днём дежурный следит в чате, ночью поднимают только при полном отказе сервиса, а не при каждой ошибке.
- Эскалация: 15 минут без реакции — звонок второму, 30 минут — руководителю. Это наши ориентиры для небольшой команды.
- Ложное срабатывание — повод поправить порог. Привычка игнорировать алерты обходится дороже любого сбоя.
- Один канал: все алерты в одном месте, иначе часть теряется в личных переписках.
Что автоматизировать первым
Соблазн начать с «умной» платформы понятен, но порядок работ лучше определять по эффекту и сложности. Простое и заметное делается на этой неделе, сложное и заметное планируется, простое и слабое — попутно, сложное и слабое — не начинать.
Как понять, что стало лучше
Смысл мониторинга не в том, что алерты появились, а в том, что сократилось время между началом сбоя и реакцией. Четырёх метрик достаточно, чтобы это увидеть.
- Время до обнаружения: от начала сбоя до первого алерта. Считается по журналу, обычно это оценка снизу.
- Время до восстановления: от алерта до работающего сервиса.
- Доля сбоев, о которых узнали раньше клиента. Самая честная метрика; цель — не 100%, а рост от месяца к месяцу.
- Доля ложных алертов. Если выше трети, дежурные перестают реагировать, и это уже сбой процесса, а не техники.
Разбор после каждого заметного сбоя занимает минут пятнадцать и состоит из трёх вопросов: что сломалось, почему не заметили раньше, какую проверку добавить. Записанный разбор полезнее ещё одной метрики: он превращает сбой в изменение настройки, а не в историю про тяжёлый день. Если хотите разобрать свой контур и посмотреть, где сигнал теряется, — напишите нам.
С чего начать на этой неделе
- Выписать три сценария, которые бот обязан выполнять: принять сообщение, ответить по делу, создать заявку.
- Поставить внешнюю проверку на каждый: раз в одну-две минуты, с ожиданием ответа и таймаутом.
- Добавить вторую проверку с другого места, чтобы не путать сбой сервиса с сетью площадки.
- Настроить один канал и назначить дежурного; записать пороги реакции и эскалации.
- Завести журнал: время алерта, время реакции, причина. Через месяц посчитать время обнаружения и долю сбоев, о которых узнали раньше клиента.
Разберём, что проверять у вашего бота или сервиса и где сейчас теряются сигналы.
Получить диагностикуИсточники
- Uptime Institute — Uptime Announces Annual Outage Analysis Report 2026 (13.05.2026) — пресс-релиз к 8-му ежегодному отчёту об авариях: в опросе 2025 года 57% респондентов сказали, что последний крупный простой стоил дороже $100 тыс.; второй год подряд каждый пятый называл сумму свыше $1 млн; около одного из десяти последствия были серьёзными или тяжёлыми; частота аварий на площадку снижается пятый год подряд, но темп улучшения замедлился; растут отказы из-за волоконно-оптических линий и связи; главная причина — электропитание; среди причин, связанных с человеком, лидирует несоблюдение установленных процедур; за девять лет наблюдений около двух третей публично известных аварий пришлось на сторонних поставщиков ИТ-услуг и дата-центров. Выборка — операторы дата-центров, а не малый бизнес и не боты
- New Relic — 2024 Observability Forecast: IT Outages Cost Businesses Up to $1.9M Per Hour (22.10.2024) — опрос 1 700 специалистов из 16 стран, апрель — май 2024, проводила ETR; медиана годового простоя от сбоев высокого влияния — 77 часов, стоимость часа — до $1,9 млн; 30% рабочего времени уходит на разбор сбоев (12 часов из 40-часовой недели); причины сбоев за два года: отказ сети 35%, отказ сторонних и облачных сервисов 29%, человеческий фактор 28%; у команд с полной наблюдаемостью 70 часов простоя в год против 338 (на 79% меньше), стоимость часа $1,1 млн против $2,1 млн (на 48% ниже), на 51% чаще узнают о сбоях раньше; медианные расходы на наблюдаемость $1,95 млн при оценённой ценности $8,15 млн. Исследование вендорское, цифры — самооценка респондентов, связи корреляционные
- Google — Site Reliability Engineering, глава 6 «Monitoring Distributed Systems» (Rob Ewaschuk, 2016) — четыре золотых сигнала: задержка, трафик, ошибки, насыщение; цель 99,9% годовой доступности соответствует не более чем 9 часам простоя в год, и проверять код ответа чаще одного-двух раз в минуту при такой цели избыточно, а заполнение диска достаточно смотреть раз в 1–2 минуты; алерты должны быть срочными, действенными и требовать решения, почтовые уведомления почти не читают; при слишком частых страницах сотрудники начинают пропускать настоящие сбои; пример Bigtable — поток алертов съедал время команды. Книга описывает практику Google и масштаб крупной компании