Rolling Update для банков с высокой нагрузкой

Детальное описание процедуры Rolling Update (Поэтапное обновление)

1. Определение и цель

Rolling Update — это стратегия обновления программного обеспечения, при которой старые версии компонентов (поды/контейнеры) постепенно заменяются новыми без остановки работы сервиса в целом.

Цель для compliance: Обеспечить непрерывность оказания финансовых услуг (SLA 99.99%) во время вывода нового релиза, исключить финансовые потери из-за простоя и минимизировать риски воздействия на смежные АБС (Автоматизированные Банковские Системы).

2. Принципы работы при высоких нагрузках (14 000 RPS)

Для нагрузки 14 000 запросов в секунду стандартный механизм "поднял новый — убил старый" не подходит. Процесс должен быть итеративным и контролируемым:

1. Недеструктивность: Новые экземпляры приложения получают трафик только после успешного прохождения health-проверок.
2. Незаметность для клиента: Длительность переключения (перерыва в обслуживании конкретной сессии) должна стремиться к нулю (механизм graceful shutdown).
3. Контроль скорости: Обновление идет волнами (батчами). Например, обновляется по 10% инстансов, затем следует пауза для анализа метрик.

3. Детальное описание шагов процедуры (для регламента)

Этап 1: Pre-check (Подготовка и аудит)

Действие: Перед запуском обновления система автоматически проверяет доступность ресурсов и текущее состояние кластера.

• Проверка квот CPU/RAM в кластере (должен быть запас на поднятие новых подов).
• Проверка статуса реплик (все текущие инстансы должны быть Ready).
• Проверка работы механизма Pod Disruption Budget (PDB).
  Настройка: minAvailable: 75% (мы не можем позволить упасть доступности ниже 75% в любой момент времени).
• Compliance-нота: Фиксация в логах аудита: кто инициировал обновление, хэш коммита, версия Docker-образа.

Этап 2: Инициация обновления и стратегия

Действие: Система оркестрации (Kubernetes) получает команду на обновление образа.

• Стратегия (RollingUpdate):
  maxSurge: 25% (Количество новых подов, которое можно создать сверх желаемого количества. При 100 подах — можно создать +25 новых, прежде чем удалять старые).
  maxUnavailable: 0 (Категорически запрещено уменьшать количество работающих подов ниже номинала. Старый под удаляется только после того, как новый полностью запустился и начал принимать трафик).

Этап 3: Создание "Здорового" инстанса

1. Запуск: Оркестратор создает под с новой версией.
2. Readiness Probe (Проверка готовности): Нагрузка 14 000 RPS требует тщательной проверки бэкенда.
   Действие: Пока новый под не ответит на запросы к эндпоинту /ready (проверка соединения с БД, кэшем (Redis/Kafka), прогрева кэша), он не получает трафик от балансировщика.
   Таймаут: Прогрев может занимать до 60-120 сек (загрузка ML-моделей или кэша в память).
3. Добавление в балансировку: После успешной проверки под получает статус Ready и начинает получать трафик.

Этап 4: Terminaton (Завершение работы старого инстанса)

Критично для банковских операций: Нельзя рвать соединение во время проведения транзакции.

1. Сигнал SIGTERM: Оркестратор посылает сигнал старому поду о скором завершении.
2. Исключение из балансировки: Пода перестает поступать новый трафик (балансировщик убирает его из ротации).
3. Grace Period (Период завершения):
   Приложение ждет 30-50 секунд (настраивается через terminationGracePeriodSeconds).
   За это время приложение должно обработать все текущие запросы и закрыть соединения с базами данных. Если запросы обрабатываются долго (платежи), приложение должно удерживать процесс до их завершения, но не дольше таймаута.
4. Принудительное завершение: Если под не завершился сам, он уничтожается принудительно (это считается ошибкой, требует мониторинга).

Этап 5: Мониторинг волны (Wave Control)

Ключевое отличие Highload: Автоматическая пауза после обновления N подов.

• Canary-анализ: После обновления первых 10-20% подов система анализирует:
  Латентность (Latency) ответов (не выросла ли задержка).
  Количество 5xx ошибок (не упали ли новые поды с ошибками).
  Ошибки валидации транзакций.
• Условие: Если ошибки превысили порог (например, > 0.1%), процесс Rolling Update автоматически стопится (Pause) и инициируется откат (Rollback).

Этап 6: Завершение

Действие: Процесс повторяется, пока все старые поды не будут заменены новыми.

4. Меры безопасности и комплаенс (Для отчетности перед Банком)

4.1. Непрерывность обслуживания (Business Continuity)

• SLA: Процедура гарантирует отсутствие downtime (время простоя = 0) при условии, что новые версии приложения проходят startup-проверки.
• Сохранность данных: Благодаря graceful shutdown и удержанию соединений, исключена ситуация "потерянного платежа", когда клиент отправил запрос, а сервер упал.

4.2. Безопасность (НСД и уязвимости)

• ImagePullPolicy: Всегда Always для прода. Гарантирует, что будет загружен именно тот образ, который прошел сканирование уязвимостей в реестре (Vulnerability Scanner).
• Secret Management: При обновлении конфигурации (configmap/secrets) новые версии подов подхватывают актуальные ключи шифрования, старые — дорабатывают с теми, что были на момент старта.

4.3. Аудит и Traceability

• Все этапы логируются в центральную систему сбора логов (ELK/Splunk).
• Обязательная маркировка спанов в трассировке (Jaeger/Zipkin) для запросов, обработанных во время обновления, чтобы отследить возможные аномалии.

5. Действия при сбое (Rollback Strategy)

Если на этапе Canary (10% подов) или в процессе обновления обнаружена критическая ошибка:

1. Автоматическая остановка (Halt): Пайплайн CI/CD блокирует дальнейшее применение maxSurge.
2. Инициация отката: Выполняется команда rollout undo.
3. Схема отката:
   Новые "проблемные" поды начинают получать сигнал на завершение (termination).
   Старые "стабильные" поды, которые еще не были удалены, остаются в работе и принимают на себя всю нагрузку (14 000 RPS).
   Если стабильных подов недостаточно (в процессе отката они уже были удалены), система запускает новые экземпляры старой версии из образа, который помечен как stable.

7. Заключение для Compliance

Предлагаемая стратегия Rolling Update полностью соответствует:

1. Требованиям ЦБ РФ по непрерывности: Отсутствие окон простоя.
2. Стандартам безопасности платежных систем (PCI DSS): Graceful shutdown гарантирует, что платежные транзакции не будут прерваны принудительно.
3. Политике управления изменениями (Change Management): Процесс автоматизирован, контролируем (Canary deployments) и обеспечивает быстрый откат без вмешательства человека в случае деградации сервиса.

Страховка на собеседовании

Знание есть, но стресс мешает?
Бесплатное сообщество для прокачки карьеры в IT

Подпишись на https://t.me/IT_Interview_Partner_Bot

Подпишись на https://t.me/LyakhovEugene