Содержание
- Почему push-уведомления не работают для критичных сервисов
- Как работают оповещения звонком в Echobell
- Настройка оповещений звонком в вашем инструменте мониторинга
- Используйте существующий health-check
- Что включить в оповещение
- Как выбрать уровень срочности
- Масштабирование на несколько сервисов
- В чём реальная польза
- Связанные материалы
Падение вашего API в три часа ночи — не проблема. Проблема в том, что вы узнаёте об этом в девять утра, когда пользователи уже завалили обращениями вашу поддержку.
Большинство инструментов мониторинга отлично обнаруживают сбои. И совершенно не умеют добиваться того, чтобы кто-то увидел оповещение вовремя. Обычное push-уведомление лежит на заблокированном экране, пока кто-нибудь случайно не возьмёт телефон в руки. Сообщение в Slack тонет в канале, за которым ночью никто не следит. Письмо остаётся непрочитанным до утра понедельника.
Оповещения звонком меняют этот расклад. Когда health-check вашего API не проходит, телефон действительно звонит — так же, как при любом другом срочном вызове. Вы отвечаете, слышите, что сломалось, и начинаете чинить сразу, а не через несколько часов.
Почему push-уведомления не работают для критичных сервисов
Средний смартфон получает от 50 до 100 push-уведомлений в день. Ваше оповещение о сбое API конкурирует с обновлениями приложений, уведомлениями из соцсетей, новостными сводками и всеми остальными приложениями на устройстве. Когда срочно всё, срочным не кажется ничего.
Так складывается опасный сценарий:
- Инструмент мониторинга обнаруживает, что API отдаёт ошибки 500
- Он отправляет push-уведомление на ваш телефон
- Телефон лежит на столе экраном вниз, включено «Фокусирование»
- Оповещение молча лежит там, пока его кто-нибудь не заметит — через несколько часов
Для некритичного микросервиса такая задержка просто раздражает. Для платёжного API, сервиса аутентификации или бэкенда вашего основного продукта она стоит реальных денег и доверия.
Как работают оповещения звонком в Echobell
Echobell доставляет уведомления на трёх уровнях срочности:
- Обычное (Active): стандартное push-уведомление
- Срочное: пробивается через «Фокусирование» в iOS, но не звонит
- Звонок: телефон звонит как при обычном входящем вызове
Для сбоев API, которые затрагивают пользователей, уместен уровень «Звонок». Он повторяет то, как вы реагируете на любой другой срочный вызов: вы отвечаете, потому что телефон звонит.
Настройка простая:
- Создайте канал в Echobell
- Выберите тип уведомления Звонок
- Подключите инструмент мониторинга через вебхук
- Когда health-check не проходит, Echobell звонит вам на телефон
Настройка оповещений звонком в вашем инструменте мониторинга
Большинство платформ мониторинга умеют отправлять вебхук, когда проверка не проходит. Вот как это подключить.
Используйте существующий health-check
Если у вас уже есть эндпоинт проверки состояния (например, /health или /status), настройте мониторинг так, чтобы он опрашивал его через равные интервалы. Если ответ отличается от 200, вызывайте вебхук.
Echobell принимает payload вебхука с заголовком и телом сообщения:
curl -X POST https://hook.echobell.one/t/<channel-token> \
-H "Content-Type: application/json" \
-d '{
"title": "API DOWN: payment-service",
"body": "Health check failed - 500 error at 03:42 UTC",
"notificationType": "calling",
"externalLink": "https://your-dashboard.example.com/incidents/123"
}'Именно поле notificationType: calling заставляет телефон звонить.
Что включить в оповещение
Текст оповещения должен считываться с одного взгляда. Когда вы отвечаете на звонок в три часа ночи, проблему нужно понять мгновенно:
- Имя сервиса — какой API или микросервис отказал
- Тип ошибки — таймаут, 5xx, connection refused
- Время — когда начался сбой
- Ссылка — где сразу разбираться
Здесь не место многословным сообщениям. Задача — дать мгновенный контекст, чтобы вы решили: просыпаться окончательно или просто принять к сведению и лечь спать дальше.
Как выбрать уровень срочности
Не каждый сбой API требует звонка. Используйте оповещения звонком для:
- платёжных и биллинговых сервисов
- эндпоинтов аутентификации и входа
- основных API продукта, с которыми пользователи работают напрямую
- сервисов, от которых зависят другие критичные системы
Используйте срочные уведомления для:
- второстепенных сервисов — важных, но не влияющих напрямую на выручку
- сред разработки и staging
- тревожных признаков (высокая доля ошибок, которая ещё не стала полным отказом)
Используйте обычные уведомления для:
- некритичных фоновых задач
- информационных метрик, которые не требуют действий
Такой градуированный подход держит вас в курсе и не приводит к усталости от оповещений.
Масштабирование на несколько сервисов
Если у вас больше одного API, создайте отдельные каналы для каждого сервиса или группы сервисов:
production-payment-api— уровень «Звонок»production-user-api— уровень «Звонок»production-analytics-api— срочноеstaging-all— срочное
Так вы настраиваете срочность отдельно для каждого сервиса. Платёжный API заслуживает звонка; конвейер аналитики — скорее всего, нет.
В чём реальная польза
Ценность оповещений звонком не в самом звонке, а в том, как меняется поведение:
- вы быстрее устраняете проблемы, потому что узнаёте о них сразу
- вы спокойнее спите, зная, что если что-то сломается, вас действительно разбудят
- пользователи видят меньше простоя, потому что вы реагируете за минуты, а не за часы
Для критичных сервисов вся суть именно в этой разнице.