Что делать, когда уведомления Astrina о доступности срабатывают во время запланированного обслуживания
Запланированное обслуживание может выглядеть шумным. Оповещение Astrina о доступности не всегда означает неожиданный сбой, и разница здесь важна: один сценарий ведёт к реагированию на инцидент, а другой — к аккуратной координации и чистому возврату к обычному мониторингу. Именно поэтому полезно заранее понимать, как отличить инцидент от планового обслуживания.
Начните с одного вопроса: ожидалось ли это оповещение? Если да, то оно является частью процесса обслуживания, а не отказом сервиса. Это не делает его безобидным. Это значит, что кто-то должен был определить окно работ, объём изменений и точные проверки, которые сработают во время выполнения.
Считать это инцидентом или ожидаемым сигналом обслуживания?
Сначала опирайтесь на план обслуживания. Если сервис недоступен, потому что был запланирован деплой, миграция, изменение правил фаервола или обновление базы данных, то оповещение может просто выполнять свою задачу. Его следует считать ожидаемым только тогда, когда проверка, время и затронутый сервис совпадают с утверждёнными примечаниями к работам.
Не думайте, что любое предупреждение можно спокойно игнорировать. Запланированный перезапуск всё равно может выявить не связанную с ним проблему — например, сбой DNS или некорректный сертификат, и это проявится одновременно с работами по обслуживанию. Одно неверное предположение может стоить часа.
Здесь помогает практическое правило. Если оповещение соответствует утверждённому окну изменений, правильному сервису и задокументированной цели работ, относитесь к нему как к ожидаемому сигналу обслуживания. Если хотя бы один из этих элементов не совпадает, считайте это инцидентом, пока не доказано обратное.
Ожидаемое не значит незаметное. Команда всё равно должна знать, что во время планового обслуживания сработали уведомления Astrina во время обслуживания, потому что эти уведомления показывают, какие проверки затронуты, а какие остаются в норме. Такое разделение полезно. Очень полезно.
Где определено окно обслуживания и актуально ли оно до сих пор?
Сначала найдите источник истины. У одних команд это change ticket, у других — страница статуса, у третьих — событие в календаре с указанным ответственным. Место хранения менее важно, чем правило: должен быть один источник, где зафиксировано текущее окно обслуживания.
Проверьте время начала, время окончания и часовой пояс. Окно, записанное на 02:00 в одном часовом поясе, может быть бессмысленным для дежурного в другом. Такое несоответствие вызывает лишнюю эскалацию, особенно когда работы начинаются около полуночи, а уведомление приходит в неудобный час.
Затем проверьте, не менялось ли окно. Запланированные работы нередко затягиваются, разбиваются на две фазы или сдвигаются, потому что поставщик присылает файлы позже или выпуск упирается в зависимость. Если окно было обновлено, а Astrina всё ещё показывает старое время, реакция на оповещение может оказаться неверной, даже если сами работы идут нормально.
Важен и владелец. Кто-то должен уметь ответить одной фразой, кто утвердил окно и кто может его продлить. Если этого человека нет на месте, команда может либо слишком широко заглушить уведомления, либо снять их слишком рано. И то и другое можно предотвратить.
Для команд, которые параллельно следят за состоянием сайта во время тех же изменений, полезно держать процесс мониторинга в одном месте. Короткая ссылка вроде как отслеживать доступность сайта поможет не упустить базовые вещи, пока идут работы по обслуживанию.
Какие правила оповещений нужно приостановить или сузить до начала обслуживания?
Настройте правила оповещений, напрямую связанные с запланированными работами. Если база данных будет недоступна 20 минут, приостановите проверки, зависящие от этой базы. Если затронут только один регион, сузьте охват, чтобы остальные регионы продолжали нормально отчитываться.
Не отключайте всё подряд. Это и есть самая простая ошибка, и она создаёт слепую зону. Оставьте активными проверки доступности, не связанные с изменением, чтобы система оповещений всё ещё могла поймать вторую проблему — например, сбой CDN, недоступность входа или сломанную зависимость, не связанную с обслуживанием.
Думайте слоями. Проверка главной страницы может быть слишком общей во время деплоя, а проверка состояния API — слишком узкой, если API обслуживает только часть сервиса. Один слой должен молчать; другой — оставаться громким. В этом и есть баланс.
Если в правилах оповещений используются пороги, рассмотрите возможность расширить их только для конкретной проверки на время обслуживания, а не для всей учётной записи. Таймаут в две минуты может быть уместен для живой проверки, но во время контролируемого перезапуска он может быть слишком чувствительным. Меняйте правило с максимально узким охватом.
Сохраняйте покрытие мониторинга для не связанных с работами сигналов. Эта фраза звучит очевидно, но команды всё равно заглушают все каналы, потому что так быстрее. Быстрее — не значит безопаснее.
Как временно заглушить только те уведомления, которые связаны с обслуживанием?
Используйте самый узкий доступный вариант mute в Astrina, если вам важно понять, как временно заглушить уведомления при maintenance. Если платформа позволяет заглушить одну проверку, заглушите одну проверку. Если можно заглушить по тегу, имени обслуживания или области действия, выберите это вместо полного пауза для всех уведомлений о доступности.
Предпочитайте mute с ограничением по времени. Отключение с чётким временем завершения снижает риск того, что кто-то забудет вернуть оповещения после закрытия окна обслуживания. Безвременный mute — это будущая проблема, которую в ночную смену кто-то обязательно обнаружит.
Если обслуживание затрагивает один канал, заглушите только этот канал. Например, можно отключить email-уведомления для конкретной проверки, сохранив chat-уведомления для не связанных с ней проверок. Так команда всё ещё увидит исключения, не утонув в ожидаемом шуме.
Задокументируйте точное действие: какая проверка была заглушена, какой охват был сужен и какой путь оповещения остался активным. Эта запись потом поможет, если кто-то спросит, почему сигнал молчал 18 минут или почему один регион продолжал отправлять page, а другой — нет.
Некоторые команды добавляют настройку агента в тот же окно изменений. Если это часть ваших работ, держите под рукой инструкцию по установке на *, чтобы часть мониторинга была привязана к правильному хосту и конфигурации проверки.
Что нужно задокументировать до подавления уведомлений?
Запишите цель обслуживания простыми словами. «Патч базы данных», «ротация сертификата» и «изменение балансировщика нагрузки» лучше, чем «рутинные работы». Чем конкретнее запись, тем легче следующему дежурному понять, зачем была скорректирована система оповещений.
Зафиксируйте время начала и окончания, а также часовой пояс. Укажите затронутые проверки, утвердившего изменения и план отката. Список кажется небольшим, но он устраняет самую частую путаницу: кто что изменил и кто должен это вернуть обратно.
Добавьте ещё одну строку для исключений. Если одна проверка должна оставаться активной, потому что зависимость у поставщика нестабильна, отметьте это явно. Если один путь приложения не входит в обслуживание, тоже укажите это. Чёткие исключения не дают командам по привычке заглушить не то.
Краткая заметка об обслуживании должна отвечать на четыре вопроса: что меняется, когда это начинается, когда заканчивается и кто отвечает за повторное включение. Если заметка не отвечает на эти вопросы, она не готова.
Держите запись рядом с самим изменением оповещений. Тикет в одной системе и mute в другой часто расходятся со временем. Одна заметка, одно изменение, один ответственный.
Что нужно проверять, пока обслуживание идёт?
Следите за тремя вещами. Во-первых, ожидаемые уведомления должны молчать. Во-вторых, не связанные с изменением оповещения должны продолжать срабатывать. В-третьих, все исключения должны быть видны тем, кому они нужны. Эти три факта показывают, работает ли изменение обслуживания так, как задумано.
Проверяйте живой поток событий или журнал оповещений в течение окна. Если целевая проверка всё ещё отправляет page после того, как её заглушили, возможно, выбран неверный scope mute. Если молчат и не связанные проверки, охват слишком широк. В обоих случаях это нужно исправить, пока обслуживание ещё идёт.
Следите за граничными условиями. Сервис может подняться частично, то есть один endpoint восстановится, а другой всё ещё будет падать. Именно такие случаи создают ложное чувство безопасности, если команда смотрит только на один сигнал.
Делайте обслуживание видимым для дежурных. Короткая заметка в канале инцидента, баннер на странице статуса или комментарий к изменению в Astrina могут сэкономить время, когда кто-то видит одно оповещение, но не видит другое. Краткая ясность лучше длинных объяснений.
Если нужен связанный пример того, как интерпретировать данные мониторинга во время изменений, как интерпретировать снижение показывает тот же подход: отделяйте ожидаемые движения от реальной проблемы, а затем проверяйте охват, прежде чем реагировать.
Когда и как снова включать уведомления о доступности после изменения?
Включайте оповещения сразу, как только выполнено условие завершения обслуживания, а не когда кто-то вспомнит об этом. Если обслуживание было запланировано на 30 минут и завершилось за 22, изменение настроек оповещений не должно ждать до исходного времени окончания, если только это не предусмотрено планом.
Используйте чек-лист после обслуживания. Верните обычные оповещения, убедитесь, что mute или suppression отключены, и проверьте, что у проверки снова стоят полные пороговые значения. Затем наблюдайте за потоком оповещений на предмет отложенных сигналов: некоторые системы присылают позднее уведомление уже после восстановления сервиса.
Подтвердите повторное включение в том же месте, где был создан mute. Если mute был привязан к одной проверке, проверьте именно её. Если он был завязан на тег, убедитесь, что этот тег больше не подавляет уведомления, связанные с обслуживанием. Не полагайтесь на память.
Следите за пропущенными уведомлениями в первые минуты после восстановления. Проверке, которая молчала во время обслуживания, может понадобиться один свежий сбой, прежде чем система вернётся к обычному поведению с page. Это не редкость и не обязательно ошибка. Это нужно проверить.
Для команд, которые параллельно отслеживают изменения в измерениях или аналитике во время обслуживания, важно учитывать недавнее поведение платформы. Заметка о том, что недавно изменилось в Privacy-First analytics, полезна, когда вы проверяете, что должно было измениться в том же окне обслуживания, а что — нет.
Если обслуживание включало миграцию продукта или сервиса, сделайте итоговую передачу краткой и однозначной. Тот, кто заглушил оповещение, должен сказать, когда оно было восстановлено, что проверили после этого и сработало ли какое-либо уведомление с задержкой. Последний пункт важнее, чем кажется.
И последний проверочный шаг: убедитесь, что какое-нибудь оповещение не осталось на паузе случайно. Одно забытое заглушение может скрыть следующий реальный простой, а это единственный риск, который не должен оставаться после плана обслуживания.
