Обновления экосистемы без даунтайма

(Раздел: Экосистема и Сеть)

1) Цель и принципы zero-downtime

• Совместимость вперед/назад (backward/forward) на границах контрактов.
• Постепенность (progressive delivery) вместо «большого переключения».
• Наблюдаемость и обратимость: метрики, трассировки, быстрый откат.
• Идемпотентность и безопасные ретраи для сетевых и платежных потоков.
• Изоляция отказов: cell-архитектура, circuit-breakers, лимиты фан-аута.

2) Стратегии релиза без даунтайма

Blue-Green — два идентичных стека (Blue=prod, Green=new). Трафик переключается атомарно на уровне балансировщика с возможностью мгновенного отката.
Canary — поэтапная доля трафика (1%→5%→20%→50%→100%) с SLO-гейтами.
Rolling — поузловое обновление пула с проверкой готовности (readiness) и дренажом соединений.
Shadow/Traffic Mirroring — зеркалирование запросов на новую версию без влияния на ответы.
Feature Flags — бизнес-переключение фич поверх неизменного API (gradual rollout).
Dark Launch — включение скрытых веток логики для телеметрии и профилирования.

Рекомендация: для критичных сервисов — комбинация canary + rolling + feature flags; для шлюзов и API — blue-green с коротким переключением.

3) Контрактная совместимость (API/события/протокол)

API: версионирование по URI/заголовкам; добавление полей — допустимо, удаление/переименование — только через «депрекейт-окно».
События (event-bus): «только добавление» полей; ключи неизменяемы; новые типы — как новые темы/версии.
Схемы (Avro/JSON-Schema/Protobuf): схема-реестр, совместимость `BACKWARD|FULL`.
Протокол сети/P2P: version handshake и capability negotiation (узлы объявляют поддерживаемые версии/фичи).
Gateways: адаптеры между vN и vN+1 (transcoding/field mapping) на период миграции.

Политика депрекейта (пример): анонс → ≥90 дней предупреждения → флажок «deprecated» → удаление поля/эндпоинта.

4) Миграции данных без остановки (Expand → Migrate → Contract)

1. Expand — добавить новые структуры/индексы/колонки (nullable/с дефолтом), двузапись (dual-write) в старый и новый формат.
2. Migrate — фоновые миграции, backfill, валидаторы консистентности; чтение через адаптер, поддерживающий обе схемы.
3. Contract — отключить чтение/запись в старую схему, удалить технический долг после завершения «депрекейт-окна».

sql
-- Expand
ALTER TABLE payouts ADD COLUMN payout_ref TEXT NULL;
CREATE INDEX CONCURRENTLY ix_payouts_ref ON payouts(payout_ref);

-- Migrate (batch + idempotent)
UPDATE payouts SET payout_ref = concat('ref_', id) WHERE payout_ref IS NULL;

-- Contract (after compatibility window)
ALTER TABLE payouts ALTER COLUMN payout_ref SET NOT NULL;

Транзакционность событий: используйте Outbox (транзакция с записью события) + CDC для гарантированной доставки.

5) Долгоживущие соединения и дренаж

Graceful shutdown: SIGTERM → остановить прием новых запросов → выставить `readiness=fail` → дождаться дренажа WebSocket/HTTP2/QUIC-стримов → закрыть.
Connection draining на балансировщике: `deregister_delay` 30–120 с, sticky-сессии — через токены, а не IP.
Back-pressure: ограничить новые апстримы при росте p99_latency.

6) Версионирование SDK и клиентов

SemVer для SDK; LTS-ветка с расширенным окном поддержки (например, 12 месяцев).
Policy: «не менее двух активных минорных версий»; телеметрия на долю клиентов по версиям; автоматические предупреждения о необходимости апгрейда.
Критичные изменения (security): форсированный флаг отключения старых версий через шлюз после дедлайна.

7) Обновления протоколов и узлов сети

Soft-fork: расширение правил без нарушения старых узлов (capabilities).
Hard-fork: заранее объявленное окно, двойная валидация, «канареечные валидаторы», защита от «reorg/rollback» конфликтов, time-lock на активацию.
Кросс-цепные апдейты: мосты governance передают сигналы активации; в случае рассинхронизации — локальный circuit-breaker.

8) Конфигурации и секреты как данные

Централизованный config-service с версионированием, цифровыми подписями и откатом.
Secrets rotation без даунтайма: двойные ключи (old/new), поочередное включение; нулевые простои для KMS/PKI.
Feature-flags в отдельном сторе, аудит включений/отключений.

9) Pipeline релиза и автоматические «гейты»

Стадии: build → unit → security scan → e2e/stage → shadow → canary → 100%.

• Error-budget burn-rate, p95/p99 latency, error-rate, снижение success-rate событий/платежей, рост dead-letter очередей.
• Авто-откат при нарушении SLO в любом из этапов.

yaml release:
strategy: canary steps:
- name: shadow traffic_mirror: 5%
gates: [no_data_loss, no_pii_leak]
- name: canary_1 traffic: 1%
gates: [error_rate<0. 2%, p99<400ms]
- name: canary_2 traffic: 10%
gates: [slo_ok_1h, zero_deadletters]
- name: rollout traffic: 100%
gates: [stability_6h]
- name: bake duration: 24h action: finalize_or_rollback

10) Наблюдаемость и SLO для релизов

• p95/p99 latency по эндпоинтам; error-rate (5xx + фатальные 4xx); success-rate событий; доля ретраев; лаг очередей; доля «relay» в P2P; доля клиентов по версиям.

• p99 API ≤ 400 мс; error-rate ≤ 0.2%; success-rate событий ≥ 99.5%; лаг очереди ≤ 2 с; MTTR отката ≤ 15 мин.
• Дашборды релиза: сравнение «до/после», канареечные графы, карта зависимостей (service map), алерты burn-rate 1ч/6ч.

11) Откаты и «kill-switch»

Авто-откат: храните последние «хорошие» артефакты и конфиги; «1-кнопочный» rollback на балансировщике (Blue←Green).
Partial rollback: фичефлаг выключает новую логику при сохранении бинаря.
Data rollback: только для «read-paths»; для «write-paths» — защищенные миграции (никогда не удаляйте старые колонки до окончания окна).
Kill-switch: централизованный флаг для отключения нестабильной подсистемы.

12) Тестирование без простоя

Контрактные тесты прод против стаба клиентов (consumer-driven).
Схемные тесты с проверкой совместимости (schema-compat).
Chaos-тесты в стейджинге: выход из строя % узлов/регионов, деградация DHT/TURN/KMS/DNS, «шторм ретраев».
Нагрузочные/ремаркет тесты: канареечные регионы и «горячие» маршруты.

13) Регламенты коммуникаций и комплаенс

Релиз-ноты: что меняется, влияние, окна/дедлайны депрекейта, действия для партнеров.
SLA ответов на инциденты: MTTA ≤ 5 мин, первый апдейт статуса ≤ 15 мин, пост-мортем ≤ 72 ч.
Аудит следов: привязка всех конфиг-изменений и релизов к заявкам/пропоузалам, подписи артефактов.

14) Специальные случаи

Платежные/финансовые потоки: строгая идемпотентность, дедуп по idempotency-key, outbox+CDC, «неразрушающие» миграции только.
WebSocket/стримы: версия протокола в handshake, реконнект с резюмированием (resume tokens).
Кэш/edge: `stale-while-revalidate`, двойные версии кэша, TTL-гигиена в период релиза.
Мобильные клиенты: поэтапный rollout в сторах, принудительный апдейт на security-выпусках.

15) Чек-лист zero-downtime

1. Контрактная совместимость и схема-реестр настроены.
2. Expand→Migrate→Contract описан и автоматизирован.
3. Balance/Ingress поддерживает blue-green и дренаж соединений.
4. Canary-пайплайн с SLO-гейтами и авто-откатом.
5. Feature-flags и kill-switch доступны 24/7.
6. Outbox+CDC и идемпотентность включены для всех write-путей.
7. Дашборды «релиз-здоровья» и алерты burn-rate активны.
8. Коммуникации и депрекейт-политика объявлены партнерам заранее.
9. Еженедельная репетиция отката; ежеквартальный chaos-day.

16) Глоссарий

Progressive delivery — поэтапный выпуск фич с контролем рисков.
Schema registry — хранилище версий схем с политиками совместимости.
Outbox/CDC — шаблон гарантированной публикации событий из транзакций.
Blue-Green — параллельные стеки с атомарным переключением трафика.
Canary — постепенное наращивание доли трафика на новой версии.
Graceful shutdown / draining — корректное завершение активных соединений.

Итог: нулевой даунтайм — это не один трюк, а система: контракты, совместимость схем, поэтапные стратегии релиза, наблюдаемость, безопасные миграции и гарантированный откат. Следуя этому фреймворку, экосистема обновляется быстро, предсказуемо и без боли для пользователей и партнеров.