Практические примеры для IncidentRelay v2.3.1, проверены . Имена, идентификаторы и интервалы ниже приведены для иллюстрации; проверьте их на тестовом развёртывании до использования production-учётных данных.
Бизнес-пример · Настройка · Практический пример · Приёмочные проверки · Ограничения и отказы
Бизнес-пример: один ночной бэкап так и не завершился
Это модельная ситуация, а не история реального клиента. Метрики ниже предложены для вашего пилота: это не подтверждённая экономия и не утверждение, что все нужные отчёты встроены в IR.
Ситуация и риск. Компания создаёт резервные копии базы заказов на двух серверах до начала рабочего дня. Одно задание незаметно прекращает работу, второе завершается успешно. Один общий сигнал об успехе скрыл бы пробел. Бизнес-риск — обнаружить устаревшую или отсутствующую точку восстановления только тогда, когда данные уже понадобилось восстанавливать.
Процесс с IR. Задайте срок завершения и отслеживайте каждый ожидаемый сервер отдельно. Хост отправляет heartbeat только после выполнения задания и проверки успеха. Если сигнал не пришёл, создаётся алерт о просрочке для дежурного платформенной команды с эскалацией к резервному. Инженер разбирается в причине или перезапускает задание и фиксирует результат.
Какую пользу проверить. Превратите тихий сбой задания по расписанию в задачу с ответственным до начала следующей рабочей смены. Такой же подход подходит для плановой выгрузки или пакетной обработки, если сигнал завершения действительно означает успех.
Что измерять. Отслеживайте пропущенные сроки по каждому серверу, время от контрольного срока до подтверждения и возраст последнего проверенного бэкапа. Результаты проверки копий и тренировочного восстановления храните в системе резервного копирования или эксплуатационном отчёте, а не выводите из зелёного статуса heartbeat.
Ограничения. Heartbeat подтверждает получение сигнала, а не возможность восстановить данные. Он не гарантирует ни точку восстановления, ни время восстановления. Проверяйте восстановление отдельно и контролируйте сам IR извне его зоны отказа.
Эксплуатируйте систему оповещения как отдельный сервис
Представим платформенную команду, которая отвечает за production-кластер и ночные бэкапы баз данных. Она хочет разместить IR рядом с мониторингом, но теперь ей придётся обслуживать и систему, которая её будит. Назначьте ответственных за веб-сервис, планировщик, базу данных, секреты и процедуру восстановления.
В Docker-конфигурации релиза веб-сервис и планировщик работают отдельно. После развёртывания по инструкции в тестовой среде проверьте их из каталога исходников релиза:
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerВеб-процесс принимает входящие алерты; планировщик обрабатывает напоминания, эскалацию и периодические задачи. Не запускайте планировщик внутри каждого веб-воркера. Рабочая страница входа ещё не доказывает, что эскалация по времени работает.
Обнаружьте пропущенный бэкап на одном хосте
Создайте heartbeat с контролем завершения по расписанию: ежедневно к 03:00 UTC, с маршрутом, у которого источник — heartbeat. Включите отслеживание экземпляров; для фиксированного набора серверов задайте ожидаемые экземпляры статически, например db-1 и db-2. Подключите ротацию или политику платформенной команды и тестовые каналы.
После завершения бэкапа на хосте и проверки его успешности отправьте это тело на POST /api/heartbeats/ping/HEARTBEAT_TOKEN с типом содержимого JSON. Используйте секретный URL именно этого heartbeat, а не токен маршрута или административный API-токен.
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}Отправляйте отдельное значение instance с каждого хоста. Без отслеживания экземпляров успешный пинг одного сервера может скрыть пропущенный бэкап другого. Не отправляйте успешный пинг безусловно из обработчика завершения shell-скрипта после неудачной задачи. Скрывайте секретные URL пингов в логах прокси и заданий.
Проверяйте сбои, а не только запуск
- Отправьте пинги от обоих ожидаемых экземпляров, затем намеренно пропустите один в коротком тестовом расписании. Ожидайте алерт о просрочке именно для него; исправный экземпляр должен остаться в состоянии OK.
- Возобновите пинги пропавшего экземпляра. Если включено автоматическое разрешение, проверьте, что алерт о его просрочке закрывается, не закрывая проблему другого экземпляра.
- Остановите планировщик только в тестовом развёртывании. Посмотрите, как это влияет на задачи по времени, и убедитесь, что независимый мониторинг замечает сбой; затем запустите его обратно и проверьте обработку.
- Восстановите базу данных, конфигурацию и необходимые секреты в изолированной среде с заблокированными исходящими уведомлениями. Перед разрешением доставки проверьте старые активные группы, чтобы тренировка восстановления не разбудила production-дежурных.
Успешный пинг — ещё не проверка восстановления
Heartbeats обнаруживают отсутствие сигналов; это не активные HTTP/TCP-проверки, и они не доказывают пригодность бэкапа. IR также не может надёжно оповестить о собственной полной недоступности. Нужны внешняя проверка доступности и отдельный способ связи вне той же зоны отказа.
Самостоятельное размещение не устраняет зависимости от чата, почты, голосовой связи и сети. Выберите базу данных и модель развёртывания под нагрузку, зафиксируйте проверенный релиз и отработайте обновление с откатом. Эти примеры не обеспечивают высокую доступность и не гарантируют пропускную способность.
Осознанно настройте сроки хранения: по умолчанию история разрешённых алертов хранится бессрочно. Очистка может удалить и связанные комментарии с записями доставки, а размер файла базы данных при этом не обязательно уменьшится. Политика хранения не заменяет резервное копирование.