Эксплуатация — часть архитектуры продукта
Если live-продукт нельзя безопасно выкатить при активных соединениях, решение ещё не готово. Команда заранее определяет backward compatibility, rollout window, telemetry и rollback path. Это такие же требования, как API contract или макет состояния.
| Вопрос команды | Что фиксируем | Что считаем ошибкой |
|---|---|---|
| Что видит пользователь? | Явные состояния и переходы | Необъяснимый скачок или «вечный loading» |
| Кто источник истины? | Контракт клиента, API и внешнего источника | Два слоя считают себя финальными |
| Как деградируем? | Fallback, stale policy, retry и stop condition | Скрытый partial сбой |
Долгоживущие потоки требуют мягкого завершения соединений
При rolling deploy экземпляр перестаёт принимать новые соединения, но существующим даёт окно завершить работу. Клиент получает reconnect jitter и совместимый protocol version. Массовый мгновенный disconnect превращает обычный release в пользовательский incident.
Наблюдаемость должна говорить языком пользовательского качества
CPU и error rate нужны, но недостаточны. Для live UX важны freshness lag, reconnect success, quote reject rate, stale exposure, time-to-paint и доля sessions, которым пришлось перейти в degraded state.
Регламент действий фиксирует решение до аварии
Для provider degradation заранее определяются сегменты, thresholds, действия suspend/stale, owner и критерий восстановления. В момент инцидента команда не должна впервые решать, можно ли показывать данные трёхминутной давности.
Разбор инцидента проверяет защитные барьеры, а не ищет виноватого
Полезный разбор отвечает: какой инвариант нарушился, почему автоматические проверки не остановили изменение, какой сигнал заметил пользователь и какой guardrail добавляется. Так incident превращается в изменение системы, а не в историю о неосторожном инженере.
Контрольные точки релиза, которые видит продуктовая команда
Release gate должен отвечать на вопрос «можно ли безопасно изменить поведение живого продукта», а не только «собрался ли контейнер». Перед rollout полезно связать технический сигнал с пользовательским последствием и заранее определить stop condition.
| Gate | До rollout | Stop condition |
|---|---|---|
| Protocol compatibility | Старая и новая версия клиента читают контракт | Рост schema/parse errors |
| Live continuity | Drain и reconnect проверены на long-lived sessions | Reconnect loop или резкий рост disconnect |
| Freshness | Есть baseline lag от ingest до UI | Stale exposure выше принятого порога |
| Critical commands | Idempotency и unknown outcome проверены | Duplicate/ambiguous operations |
После успешного rollout ADR обновляется фактическими результатами: какой риск подтвердился, какая метрика оказалась полезной и что нужно изменить в следующем релизе.
Что должно остаться после релиза
Хороший release оставляет после себя обновлённый operational knowledge: фактические thresholds, новые сбой observations и решение о том, какие guards переносятся в постоянную автоматизацию. Если всё знание осталось в чате incident-комнаты, следующий rollout снова начнётся с нуля.
- ADR addendum: что подтвердилось в production и что изменилось в решении.
- Runbook delta: новый сигнал, owner и stop/recovery condition.
- Dashboard change: только метрика, которая реально помогает принять действие.
- Regression check: сценарий, который воспроизводит пользовательский симптом инцидента.
Так delivery замыкает product loop: эксплуатационный опыт возвращается в state model и контракт следующей версии.
Условие остановки нужно определить до первого процента поэтапного релиза
Команда должна заранее знать, какой сигнал остановит выкладку: рост reconnect loop у новой версии, stale exposure в конкретном спорте, увеличение unknown outcome или рассинхрон схемы telemetry. Иначе во время релиза зелёные инфраструктурные графики легко спорят с красными пользовательскими симптомами.
У stop condition есть владелец и следующее действие: pause, rollback, отключение функции или перевод сегмента в degraded state. Для длинных соединений это особенно важно; разбор rolling release с SSE/WebSocket показывает, почему readiness и drain должны быть частью самого продуктового решения.
Эксплуатация не заканчивается в момент деплоя
Для live-продукта релиз — это не точка, а переход в режим наблюдения. Команда должна понимать, какие сессии уже живут в системе, какие потоки обновлений нельзя обрывать и как быстро можно отличить локальную ошибку интерфейса от системного сбоя интеграции. В этом смысле delivery всегда связан с тем, что происходит после публикации, — например, с безопасным релизом long-lived streams без обрыва живых сессий.
Не менее важен и слой продуктовой телеметрии. Если после релиза нет понятного telemetry contract, команда видит только шум и слишком поздно замечает сломанную воронку, повторный retry или незавершённое пользовательское действие. Поэтому delivery-track на ITNAN всегда связывается с практикой версирования telemetry-событий между frontend и backend, а не только с чек-листом деплоя.
Поддерживающие материалы
Ниже — подробные разборы отдельных решений: от состояния интерфейса и границ компонента до интеграции и поведения при отказе.