Релиз, изменение и развёртывание — это три разные вещи
В ITIL 4 эти практики разделены по зонам ответственности:
- Change Enablement — разрешает изменение: оценивает риск, согласует, назначает окно. Отвечает на вопрос «можно ли и когда». См. Change Management.
- Release Management — планирует и собирает релиз: что входит в пакет, как его тестируют, как информируют пользователей, как откатывают. Отвечает на вопрос «что именно и как мы выпускаем».
- Deployment Management — технически переносит компоненты в среду (прод). Отвечает на вопрос «как физически доставить».
Можно развернуть (deploy) код на прод, но не «зарелизить» его для пользователей — например, выкатить за feature-флагом. И наоборот: один релиз для пользователей может состоять из нескольких развёртываний. Разделение этих понятий — основа зрелого процесса.
Стратегии выката
Как именно доставить новую версию пользователям — выбор между скоростью и риском:
- Big bang — всё и всем сразу. Просто, но рискованно: если что-то сломалось, сломалось у всех. Подходит для мелких или обязательных одномоментных изменений.
- Поэтапный (phased) — по группам пользователей/регионам/филиалам волнами. Проблему ловят на первой волне, не затронув остальных.
- Canary — сначала 5% пользователей, мониторинг метрик, затем расширение. Минимизирует радиус поражения.
- Blue-green — две идентичные среды; трафик переключается на новую мгновенно, при проблеме так же мгновенно возвращается на старую. Дорого по инфраструктуре, но даёт почти нулевой простой и мгновенный откат.
Для большинства корпоративных IT-сервисов оптимум — поэтапный выкат с явным планом отката. Big bang оставляют для случаев, когда поэтапность технически невозможна.
Release pipeline, окна обслуживания и откат
Зрелый релиз проходит через предсказуемый конвейер: сборка → тест на стейдже → согласование change → выкат в окне → smoke-проверка → закрытие. Два элемента, которые чаще всего забывают:
- Окно обслуживания (maintenance window). Заранее согласованный интервал, обычно в нерабочее время. О нём уведомляют пользователей и службу поддержки до, а не во время. На время окна часы SLA по затронутым услугам ставятся на паузу.
- План отката (rollback). Релиз без отрепетированного отката — это не релиз, а ставка. Перед выкатом фиксируется: как вернуть предыдущую версию, сколько это займёт, до какого момента откат возможен (точка невозврата — например, миграция БД).
Служба поддержки должна знать о релизе заранее: новая версия — частая причина всплеска инцидентов, и операторы должны связывать их с релизом, а не диагностировать с нуля каждый.
Метрики и связь с поддержкой
Качество процесса релизов измеряют:
- Change/Release failure rate — доля релизов, вызвавших инцидент или потребовавших отката. Цель — снижать.
- Deployment frequency — как часто выкатываете. Чаще и мельче безопаснее, чем редко и крупно.
- Lead time — от готовности изменения до его доставки пользователям.
- MTTR после релиза — как быстро откатываете/чините, если что-то пошло не так (см. метрики надёжности).
Связка с поддержкой двусторонняя: релизы порождают инциденты, а постоянные инциденты по одной услуге — сигнал, что в неё пора внести изменение через релиз. Замыкает цикл постмортем по неудачным выкатам: что в процессе релиза дало сбой и как починить сам процесс.
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Частые вопросы
Чем релиз отличается от изменения?
Изменение (Change) — это решение «можно ли и когда» вносить правку, с оценкой риска и согласованием. Релиз (Release) — это «что именно и как мы выпускаем»: состав пакета, тестирование, информирование, откат. Изменение разрешает, релиз доставляет.
Что такое развёртывание (deployment) в отличие от релиза?
Развёртывание — техническая доставка компонентов в среду. Релиз — это выпуск функционала для пользователей. Можно развернуть код за feature-флагом, не релизя его, и наоборот — один релиз может состоять из нескольких развёртываний.
Какую стратегию выката выбрать?
Для большинства корпоративных сервисов — поэтапный выкат по группам пользователей с планом отката. Big bang — только когда поэтапность невозможна. Canary и blue-green — для сервисов с высокими требованиями к доступности.
Зачем окно обслуживания, если можно выкатить ночью?
Окно — это согласованный и анонсированный интервал. О нём знают пользователи и поддержка заранее, а часы SLA на время окна ставятся на паузу. «Просто выкатить ночью» без анонса = неожиданные инциденты утром без объяснения причины.
Нужен ли план отката для каждого релиза?
Да. Релиз без отрепетированного отката — это ставка. Перед выкатом фиксируется: как вернуть предыдущую версию, сколько времени это займёт и где точка невозврата (например, необратимая миграция БД).