Плановое обслуживание с окном простоя: как объявить, провести и закрыть

MAATRIX

Обновление мажорной версии базы данных, замена диска без резервного узла, миграция на новый гипервизор — есть работы, которые нельзя провести на живую, и rollback-план тут не спасает, потому что часть шагов необратима по своей природе. Разница между «нормальным плановым обслуживанием» и «инцидентом, который сами себе устроили» почти никогда не в технике — она в том, предупредили ли пользователей заранее, был ли у команды пошаговый план с точкой невозврата и закрыли ли окно по-человечески, а не просто молча выключили баннер «идут технические работы». Ниже — рабочий регламент на три фазы: объявление, проведение, закрытие.

Когда простой действительно нужен, а когда его можно избежать

Прежде чем писать объявление, стоит трезво проверить: точно ли нужен полный простой, или задача решается без него. Часть работ, которые по привычке делают в окне простоя, на деле поддаются zero-downtime подходам — атомарный деплой через симлинки, миграции базы без блокировки таблиц, замена диска на живом RAID. Если у вас такой случай, дешевле разобраться с механикой без простоя, чем объявлять окно — подробный разбор техник есть в статье про безопасный деплой без простоя.

Реальный повод для планового окна с простоем — это когда откат назад в процессе либо невозможен, либо кратно дороже самой работы:

• смена мажорной версии СУБД (PostgreSQL 15 → 17, MySQL 5.7 → 8) с несовместимым форматом хранения;
• миграция между гипервизорами или облаками, где сеть на несколько минут неизбежно рвётся;
• физическая замена железа — диска, блока питания, целого сервера — без второго узла под рукой;
• смена схемы сети (IP, VLAN, маршрутизация), которую нельзя протестировать параллельно с боевой;
• работы, требующие остановки процесса, который не умеет в горячий рестарт (некоторые legacy-очереди, монолиты без graceful reload).

Если работа попадает в этот список — переходите к планированию окна. Если нет — вероятно, дешевле по времени и по нервам найти способ обойтись без объявления вообще, чем городить регламент вокруг простоя, которого не должно было быть.

Фаза 1: как объявить окно, не сея лишнюю тревогу

Объявление решает две задачи одновременно: даёт пользователям время подготовиться (не начинать критичную операцию именно в это окно) и снимает поток тревожных обращений в поддержку в момент самого простоя — люди, которые в курсе, не пишут «у вас всё упало».

За сколько объявлять. Единого правильного числа нет, но ориентир, который работает для большинства B2B/SaaS-сервисов:

Слишком раннее объявление (за месяц) так же плохо, как слишком позднее — люди забывают, и вы всё равно шлёте повторное напоминание за пару дней. Практика, которая работает: первое объявление в момент, когда дата и окно уже зафиксированы окончательно, и повторное напоминание за 24 часа до начала.

Где размещать. Одного канала недостаточно — часть аудитории читает статус-страницу, часть — только письма, часть вообще ничего не читает, пока сервис не откажет:

• публичная status-страница — заводите инцидент заранее со статусом «Scheduled», а не в момент начала работ;
• email всем активным пользователям (для B2B — отдельно ключевым клиентам с персональным письмом, не только массовой рассылкой);
• баннер в самом продукте, если у вас есть веб-интерфейс — многие вообще не читают почту, но видят баннер при следующем логине;
• канал в мессенджере/Telegram-группа комьюнити, если она у вас есть — для части аудитории это основной источник новостей о сервисе.

Как сформулировать, чтобы не напугать лишний раз. Формулировка балансирует между двумя крайностями. Слишком тревожная («Внимание! Критическое обслуживание! Возможны серьёзные сбои!») создаёт панику и лишние обращения в поддержку ещё до начала работ. Слишком расплывчатая («скоро небольшие технические работы») не даёт человеку понять, нужно ли ему вообще что-то планировать. Рабочая структура:

1. Что делаем — коротко и по-человечески, не «плановое техническое обслуживание инфраструктуры», а «обновляем версию базы данных, чтобы ускорить работу отчётов».
2. Когда и на сколько — точная дата, время начала в часовом поясе пользователя (или явно указанном UTC/МСК), ожидаемая длительность.
3. Что будет недоступно — конкретно: «сервис целиком», «только загрузка файлов», «API, веб-интерфейс останется читаемым».
4. Что делать пользователю — если нужно что-то предпринять заранее (сохранить черновик, не запускать долгую операцию перед окном) — сказать прямо.

Пример рабочей формулировки:

Тема: Плановые работы 14 сентября, 02:00–04:00 МСК

14 сентября с 02:00 до 04:00 МСК мы обновляем версию базы данных.
В это время сервис будет недоступен полностью, ожидаемая
длительность — до 2 часов.

Время выбрано минимальной нагрузки по нашей статистике. Если у вас
запланированы фоновые задачи или интеграции на это время — 
рекомендуем перенести их на другое окно.

Следить за статусом работ можно на status.example.com — там же
появится уведомление о завершении.

Не стоит писать «извините за неудобства» три раза в одном письме и не стоит объяснять причину работ языком внутренней тикет-системы («патчим CVE-2026-XXXXX в компоненте X») — пользователю важно, что будет недоступно и когда, а не внутренние детали, если только это не тот случай, когда прозрачность про безопасность сама по себе ценна для аудитории (например, для инфраструктурного B2B-продукта).

Фаза 2: план работ по шагам

Между объявлением и стартом окна — отдельная внутренняя работа: письменный план по шагам, который дежурный инженер может выполнить, даже если не участвовал в его написании. «Мы примерно знаем, что делать» — недостаточно для окна с реальным простоем.

Структура плана:

1. Подготовка (до начала простоя, без него). Всё, что можно сделать заранее без остановки сервиса, делается заранее — это сокращает само окно. Например: скачать и проверить контрольные суммы новых пакетов, поднять staging-копию с той же миграцией, подготовить скрипты бэкапа и заранее протестировать их на копии данных.

1. Точка входа в простой. Явный шаг, после которого пользователи официально не имеют доступа — включение баннера недоступности, остановка балансировщика, вывод сервиса из ротации. Именно с этого момента считается заявленное время окна, и с этого же момента запускается таймер (см. ниже).

1. Резервная копия непосредственно перед изменением. Даже если ночной бэкап уже есть, критичное изменение (особенно необратимая миграция схемы) стоит сопроводить отдельным снапшотом или дампом прямо перед стартом — разница между бэкапом восьмичасовой давности и бэкапом пятиминутной давности при восстановлении может стоить часов простоя. Как проверить, что бэкап реально пригоден для отката, а не просто «файл создался» — отдельная тема, разобрана в статье как проверить, что бэкап рабочий.

1. Точка невозврата. Обязательно фиксируется явно в плане, отдельной строкой, а не подразумевается. Это шаг, после которого откат назад либо невозможен технически, либо требует кратно больше времени и риска, чем продолжение вперёд. Пример для миграции версии PostgreSQL: пока идёт pg_upgrade в режиме копирования — откат ещё дёшев (просто не удалять старый кластер); как только запущен pg_upgrade --link в режиме симлинков или старый каталог данных удалён — откат уже требует восстановления из бэкапа, а не «просто переключить обратно». Именно на этом шаге план должен явно спросить у исполнителя: «уверены? проверили контрольные метрики до этой строки?» — и лучше, если это буквально пункт чек-листа, а не то, что держится в голове.

1. Сами изменения — команды по шагам, с ожидаемым выводом на каждый шаг, чтобы отклонение было заметно сразу, а не через десять минут дальнейшей работы.

1. Проверка после изменений, но ещё внутри окна. Прогон smoke-теста — сервис стартует, отвечает на базовые запросы, критичные сценарии (логин, оплата, основной API-эндпоинт) работают. Это ещё не открытие доступа пользователям, а внутренняя проверка перед тем, как снять баннер.

Пример фрагмента такого плана в виде чек-листа (упрощённо, для миграции версии БД):

[ ] 01:45 — подготовка: снапшот диска сделан, проверен монтированием
[ ] 02:00 — баланс выведен из ротации, баннер недоступности включён
[ ] 02:02 — дамп базы снят (pg_dump), проверен размер файла (не 0 байт)
[ ] 02:10 — ТОЧКА НЕВОЗВРАТА: запуск pg_upgrade --link
            (после этого шага откат = восстановление из дампа 02:02,
             не "просто отменить команду")
[ ] 02:35 — pg_upgrade завершён без ошибок, новый кластер стартовал
[ ] 02:40 — smoke-тест: логин, создание заказа, чтение отчёта — все ОК
[ ] 02:45 — analyze_new_cluster.sh запущен (обязателен после upgrade)
[ ] 03:10 — финальная проверка метрик, план закрытия окна (см. фазу 3)

Контроль времени. У окна есть заявленная длительность, и превышение её — само по себе небольшой инцидент доверия, даже если технически всё в порядке. Практические приёмы:

• закладывайте в заявленное время запас 30–50% сверх реалистичной оценки — люди прощают «закончили раньше», но плохо прощают «не уложились и молчат»;
• назначьте контрольные точки внутри плана («если к 03:00 мы не на шаге 6 — это триггер для решения, продолжать или готовиться к откату»), а не ждите естественного конца окна, чтобы понять, что не успеваете;
• если по контрольной точке ясно, что не укладываетесь — обновите статус-страницу сразу, а не постфактум; молчание в момент, когда что-то идёт не по плану, — худшее, что может сделать команда на связи с пользователями.

Если работа в принципе может пойти по двум сценариям — быстро или с осложнениями, — держите отдельно готовый план Б (не только «точку невозврата», но и то, что делать, если что-то ломается уже после неё, например резервный узел для восстановления из дампа). Более подробно логика выбора между продолжением и откатом разбирается в статье про план отката миграции — многое из неё применимо и к плановому окну, не только к миграции между серверами.

Фаза 3: как правильно закрыть окно

Закрытие — не «работы закончились, идём спать», а отдельная последовательность действий, которую тоже стоит держать в чек-листе, потому что именно здесь чаще всего забывают снять баннер или пропускают финальную проверку.

1. Полная проверка перед открытием доступа. Smoke-теста из фазы 2 обычно достаточно для внутренней проверки «работы завершены технически», но перед официальным открытием доступа стоит прогнать более широкий набор проверок: основные пользовательские сценарии, интеграции с внешними API, фоновые задачи (крон, очереди) — они могли встать на паузу на время окна и должны корректно продолжить работу, а не повиснуть. Отдельно стоит проверить, что мониторинг снова видит сервис как здоровый, а не показывает старые тревожные значения из-за кэша метрик.

2. Снятие статуса недоступности — везде, а не в одном месте. Список тот же, что при объявлении, только в обратную сторону: статус-страница переводится в «Resolved» с указанием фактического времени завершения (не заявленного — если закончили раньше или позже, статус-страница должна отражать правду), баннер в продукте снимается, если было отдельное письмо с объявлением — часто уместно короткое письмо «работы завершены, всё восстановлено» тем же адресатам, особенно если окно вышло за заявленное время.

3. Мониторинг после закрытия — не сразу расслабляться. Первые 30–60 минут после открытия доступа — время повышенного внимания к метрикам и логам ошибок, даже если smoke-тест прошёл гладко: реальная нагрузка от живых пользователей вскрывает то, что не всегда видно на синтетической проверке (например, просевший кэш, который прогревается заново, или неожиданный всплеск запросов от накопившихся за время простоя фоновых задач).

4. Короткий пост-мортем — даже если всё прошло идеально. Это тот пункт регламента, который обычно первым выпадает под давлением «ну всё же получилось, что тут разбирать» — и зря. Даже гладкое окно стоит зафиксировать письменно, коротко, минут на 15 работы: сколько заняло по факту против заявленного, была ли точка невозврата пройдена по плану без сюрпризов, что в следующий раз можно сделать быстрее или безопаснее. Если что-то пошло не по плану — даже без реального сбоя для пользователей — это тем более повод для короткого разбора, а не только для инцидентов с реальным ущербом; подробная методика есть в статье как писать разбор инцидента, и для планового окна тот же формат подходит в сокращённом виде — хронология, что прошло не так, конкретные action items на следующее окно.

Практический смысл этого пункта — со временем регламент планового обслуживания перестаёт быть общими словами и обрастает вашей собственной практикой: «в прошлый раз analyze после апгрейда забыли — теперь это отдельный пункт чек-листа», «в прошлый раз недооценили время на прогрев кэша — в следующий раз закладываем на полчаса больше». Без этой короткой записи опыт каждого окна теряется, и следующее готовится с нуля.

Чек-лист коммуникации: кому и что писать на каждом шаге

Сводная таблица, что происходит на статус-странице и в рассылках на каждом этапе — удобно держать перед глазами, чтобы не забыть шаг в горячке окна:

Частые вопросы