Операции и Управление → Циклы релизов и обновлений

Циклы релизов и обновлений

1) Назначение

• снижает неопределенность и стоимость координации,
• уменьшает риск инцидентов и откатов,
• синхронизирует технику с бизнес-событиями (маркетинг, спорт, фин. отчетность),
• повышает throughput команды без роста CFR (Change Failure Rate).

2) Модели релизов: какую выбрать

1. Release Train (поезда) — фиксированные слоты (например, вт/чт 10:00 EET).

Подходит для многокомандных монолитов и «тяжелых» доменных изменений.

2. Continuous Delivery (по запросу) — каждый merge, прошедший quality-гейты, может идти в прод.

Подходит для микросервисов и feature-flag культуры.

3. Гибрид — продуктовые фронты по поездам, backend-сервисы «по запросу».

Критерии выбора: зрелость тестов/обсервабилити, зависимость от внешних партнеров (PSP/KYC), требования комплаенса, размер организации.

3) Релизный календарь и окна

Единый календарь (company-wide): слоты релизов, миграции БД, маркетинговые кампании, крупные спортивные события, отчетные периоды.
Freeze-периоды: четко определенные окна, когда допускаются только hotfix P1 (например, финал ЛЧ, Black Friday, налоговая отчетность).
Региональные волны: сначала «теплые» рынки/низкий трафик, затем — основные; ночные окна локальных TZ.
Политика пересечений: запрет одновременных изменений по одному критичному пути (платежи, KYC, авторизация).

4) Ветвление и версионирование

Trunk-based + short-lived branches (feature ветки ≤ 3–5 дней).
Release-ветка — только для поездов/долгих верификаций; жесткий back-merge в `main`.
SemVer: `MAJOR.MINOR.PATCH` для библиотек/SDK; теги артефактов и окружений.
Контракты: схемы (Avro/Protobuf) с back/forward совместимостью; миграции — двухфазные.

5) Канвееры качества (гейты)

1. Static + SAST/DAST + линтеры

2. Unit/Contract/Component тесты

3. E2E/Performance smoke (на стейдже)

4. Security/Compliance checks (секреты, лицензии, политика территорий)

5. Release Candidate → подпись, SBOM, артефакты

6. Progressive rollout с авто-гардрейлами (см. §7)

Все гейты — код и политика (Policy-as-Code), результаты — в артефактах релиза.

6) Среды и промоуты

Dev → Int → Stage → Prod, для данных: Sandbox/Data-Stage.
GitOps промоуты, immutable образы, запрет «ручных» правок в проде.
Параметризация: регионы, лимиты, провайдеры — через конфиги (аудитируемые).

7) Стратегии раскатки

Canary: 1%→5%→25%→100% (или per-region).
Blue-Green: параллельные среды + атомарное переключение.
Feature Flags: функциональные включатели/kill-switch; A/B и shadow.
Staged Rollout Mobile/Web: по версиям клиента/каналам доставки (Store/OTA).

Гардрейлы (auto stop): p95 latency ↑ >25%, error% > 2%, падение авторизаций/депозитов, рост чарджбеков, burn-rate SLO за 1-часовое окно > порога.

8) Согласование с бизнесом и партнерами

Маркетинг/События: релизы функционала к кампаниям с запасом ≥ 48 ч.
Партнеры (PSP/KYC/Game providers): слоты для сертификаций/обновлений SDK, двойные эндпоинты на период миграции.
Поддержка: макросы/FAQ на изменения UX, страницы статуса, каналы эскалации.

9) Обновления данных и схем

Additive first: сначала добавить, потом переключить чтение/запись, в конце — убрать старое.
Индексы и большие миграции — ночные окна, по батчам, с чекпойнтами и прогрессом.
Версионирование витрин и словаря метрик: обновления синхронно с релизом, миграции BI — отдельно от продовых окон.

10) Коммуникации и артефакты

Release Notes (что/зачем/риски/rollback), ChangeLog по сервисам.
Календарные инвайты стейкхолдерам, шаблоны объявлений (до/во время/после).
War-room канал на время поездов/крупных релизов, частота апдейтов: P1 — каждые 15–20 мин.

11) Метрики эффективности

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
Backout Rate по типам изменений.
SLO Compliance % до/после релизов.
Release Debt: «висящие» флаги, незавершенные миграции, старые зависимости.
Business Impact: конверсия, KYC TTV, PSP success, GGR/NGR drift в окно релиза.

12) Анти-паттерны

Big-bang: «все и сразу» без флагов/канареек.
Релиз в пик трафика/событий без freeze-исключений.
Без авто-гардрейлов: ручной мониторинг «на глаз».
Долгоживущие ветки: болезненные слияния и скрытые регрессии.
Ручные шаги в проде: нет аудита и предсказуемости.
Флаги без TTL и владельцев: «вечные» ветвления.

13) Чек-листы

Перед релизом

• RFC/тикет, риск и blast-radius оценены
• Пройдены гейты CI/CD, артефакты подписаны
• План раскатки + стоп-критерии + backout готов
• Согласование с календарем, freeze и партнерами
• Дашборды/алерты привязаны к версии, war-room создан

Во время релиза

• Канареечные ступени и авто-стоп активны
• Метрики p95/error%, бизнес-сигналы (auth, KYC, PSP) на мониторе
• Коммуникации по расписанию, статус-страница обновляется

После релиза

• Release Notes и ChangeLog опубликованы
• Удалены флаги/временные исключения (TTL)
• Пост-мортем при отклонениях ≤ 5 раб. дней
• Обновлены плейбуки и документация

14) Мини-шаблоны

• Дата/время: Вт, 10:00–12:00 EET
• Округ: EU (10%→50%→100%), затем LATAM (10%→100%)
• Стоп-критерии: error%>2% 10 мин, p95>+25% 10 мин, PSP success<97%
• Backout: переключение трафика на предыдущую версию + откат флагов
• Контакты: @RelEng, @SRE-on-call, @Support

• Что нового / Зачем
• Влияние на пользователей и партнеров
• Риски и известные ограничения
• План раскатки / Стоп-критерии / Backout
• Метрики для мониторинга
• Контакты и каналы поддержки

15) Интеграции с соседними дисциплинами

Управление изменениями: классификация standard/normal/emergency, CAB, аудит.
Снижение последствий инцидентов: готовые фича-флаги, квоты, шеддинг.
Аудит конфигураций: все промоуты через Git, drift-детект и журнал применений.
Политики исполнения: лимиты/таймауты/ретраи — как код, с принуждением.

16) Итог

Циклы релизов — это управляемый ритм между скоростью и надежностью. Фиксированные слоты там, где нужна координация; «по запросу» там, где зрелость автоматизации. Везде — один календарь, флаги и канареечные раскатки, автоматические гардрейлы и прозрачные коммуникации. Так релизы становятся предсказуемыми, безопасными и экономными.