Плановые работы без ложных алертов

Каждый релиз с перезапуском — это десяток ложных алертов: HTTP-монитор ловит 502, heartbeat не дождался пинга, Alertmanager шлёт InstanceDown, а эскалация уже набирает дежурному SMS. После пары таких ночей алерты начинают игнорировать — и пропускают настоящую аварию.

Окно обслуживания решает это штатно: на заданный интервал Notifly продолжает проверки, но не будит.

Что происходит в окне

Мониторы и heartbeat-ы проверяются и пишутся в историю, но алерт о падении откладывается. Если после окна проблема осталась — первая же проверка пришлёт алерт. Упал и поднялся внутри окна — вы не получите ничего.
Сообщения каналов (в том числе из Alertmanager, Grafana и Zabbix) создаются как обычно, но приходят беззвучно и не эскалируются на email, SMS, звонок и в мессенджеры.
Статус-страница показывает «Плановые работы», а провалы проверок внутри окна не портят аптайм за 30/90 дней.

Вариант 1. Регулярные работы — из админки

Мониторинг → Окна обслуживания → Создать окно:

Название:  Бэкап и VACUUM
Каналы:    prod-db   (☑ включая вложенные каналы)
Тип:       Еженедельное
Дни:       вт
Время:     02:00–04:00, Europe/Moscow

Окно через полночь тоже работает (23:00–01:00) — дни считаются по дню начала. Вместо целого канала можно выбрать отдельные мониторы и heartbeat-ы.

Вариант 2. Окно вокруг деплоя — из CI

Для разового окна нужен API-токен (префикс M) с правом write и без ограничения по каналам, а также id канала (его видно в адресе страницы канала или в ответе GET /application):

#!/usr/bin/env bash
# deploy-with-window.sh — окно на 30 минут вокруг выката
set -euo pipefail
API="https://api.notifly.ru"
AUTH="Authorization: Bearer $NOTIFLY_API_TOKEN"

start=$(date -u +%Y-%m-%dT%H:%M:%SZ)
end=$(date -u -d '+30 min' +%Y-%m-%dT%H:%M:%SZ)

id=$(curl -sf -X POST "$API/maintenance-window" -H "$AUTH" \
  -H "Content-Type: application/json" \
  -d "{\"name\":\"Деплой $(git rev-parse --short HEAD)\",
       \"channelIds\":[$NOTIFLY_CHANNEL_ID],\"includeSubtree\":true,\"monitors\":[],
       \"schedule\":\"once\",\"startsAt\":\"$start\",\"endsAt\":\"$end\",
       \"enabled\":true}" | jq -r .id)

sleep 30          # сервисы Notifly подхватывают новое окно до полуминуты
./deploy.sh

# выкат закончился раньше — закрываем окно, мониторинг снова в строю
curl -sf -X DELETE "$API/maintenance-window/$id" -H "$AUTH"

sleep 30 не лишний: мониторы и приём сообщений перечитывают окна примерно раз в полминуты, поэтому окно лучше заводить заранее, а не в момент начала работ.

Окно, тихие часы или пауза?

Инструмент	Чья тишина	Когда брать
Окно обслуживания	сервиса / канала	плановые работы: деплой, обновление, регламент
Тихие часы	человека	ночь и выходные: будить только срочным, остальное — дайджестом
Пауза монитора / heartbeat-а	одной проверки	разовый ремонт на неопределённый срок

Польза

Алертам снова верят: в канал не падают сотни «упало/поднялось» за каждый релиз.
Честный аптайм: плановые работы не портят цифры на статус-странице, а клиенты видят «Плановые работы», а не «Сбой».
Ничего не теряется: если после окна сервис так и не поднялся, алерт придёт первой же проверкой.

Что улучшить дальше

Держать окно и в самом Alertmanager (silence на время деплоя) — тогда алерты не придут даже беззвучно.
Вешать окно не на весь канал, а только на мониторы перезапускаемого сервиса — чтобы авария соседней системы во время релиза всё-таки разбудила.