Выпуск программного обеспечения раньше означал окно обслуживания и скрещенные пальцы. Современные команды используют стратегии, которые делают релизы рутинными, и выбор сине-зеленое или канареечное развертывание — один из первых, с которыми вы столкнетесь. Оба снижают риск, но делают это противоположными способами: один готовит полную замену, а другой понемногу тестирует на реальных пользователях.

В этом руководстве объясняется, как каждый из них работает и сколько это стоит на практике. Мы выполнили небольшие примеры маршрутизации пользователей и отката в Python 3.13, и в результате этого запуска были получены выходные данные. Примеры Kubernetes носят иллюстративный характер, и мы их не запускали. Рассматривайте проценты и пороговые значения как отправные примеры для адаптации.

Короткий ответ

При сине-зеленом развертывании вы запускаете две идентичные производственные среды. Один обслуживает пользователей, пока вы развертываете и тестируете новую версию на другом, а затем переключаете весь трафик одним движением.

При canary-развертывании новая версия запускается рядом со старой. Вы отправляете ему небольшой процент реального трафика, сравниваете результаты и шаг за шагом увеличиваете долю, пока она не будет обслуживать всех. Название происходит от канареек-шахтеров, которые когда-то использовались в качестве раннего предупреждения об опасности.

Сине-зеленый против канарейки бок о бок

Как работает сине-зеленое развертывание

1. Blue работает и обслуживает весь трафик.
2. Разверните новую версию на зеленом, который не получает пользовательский трафик.
3. Тщательно протестируйте «зеленость» в реальной производственной среде, используя дымовые тесты и внутренних пользователей.
4. Переключите маршрутизатор, балансировщик нагрузки или DNS, чтобы направлять трафик на зеленый цвет.
5. Смотрите внимательно: синий все еще работает и готов.
6. Если что-то не так, переключитесь обратно. Если все в порядке, следующим местом ожидания станет синий цвет.

В Kubernetes вы можете выполнить переключение, изменив селектор службы, чтобы трафик перемещался к модулям с разными метками:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Сильные стороны: Это концептуально просто: вы можете протестировать точную производственную настройку до того, как ее увидят пользователи, а откат происходит практически мгновенно. Слабые стороны: Дублированная инфраструктура может быть дорогостоящей, ошибка, которая ускользает от ваших тестов, достигает всех сразу, а открытые сеансы и работа в реальном времени требуют осторожности во время перехода. Если вы используете DNS для переключения, кэшированные записи могут задержать его. Новое в концепциях? См. наше руководство по Kubernetes для начинающих.

Как работает канареечное развертывание

1. Разверните новую версию вместе со стабильной.
2. Направьте небольшую долю трафика, например 5%, на канарейку.
3. Сравните частоту ошибок, задержку и бизнес-показатели со стабильной версией.
4. Если здоров, увеличьте до 25%, затем 50%, затем 100%.
5. Если что-то ухудшится, отправьте весь трафик обратно в стабильную версию.

Многие команды начинают работу с внутренним персоналом, затем с регионом низкого риска и только потом с широкой общественностью.

Сильные стороны: Плохой релиз затрагивает только небольшую группу, и на реальном трафике вы узнаете, что ни одна тестовая среда не может полностью воспроизвести. Слабые стороны: Вам нужны процентные показатели маршрутизации и метрики для каждой версии, развертывание занимает больше времени, а две версии некоторое время работают вместе. Маленькая канарейка также может быть слишком тихой, чтобы подать значимый сигнал, особенно в периоды низкого трафика.

Стабильная маршрутизация пользователей

Случайный выбор версии при каждом запросе сбивает пользователей с толку, поскольку они могут переключаться между старым и новым. Распространенным решением является хеширование стабильного идентификатора пользователя в корзину, чтобы каждый пользователь всегда получал один и тот же ответ:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

Фактическая доля почти соответствовала целевому показателю. У этого метода есть еще два полезных свойства, и наш эксперимент подтвердил оба. Один и тот же пользователь всегда получал одну и ту же версию. И все в группе 5% по-прежнему были включены в группу 25%, поэтому никто из тех, у кого уже была новая версия, не был перемещен обратно по мере роста развертывания.

В реальных системах эту маршрутизацию обычно обрабатывает сервисная сетка, балансировщик нагрузки или такой инструмент, как Argo Rollouts или Flagger, поэтому вам не нужно писать ее самостоятельно. По-прежнему полезно понимать, что они делают.

Автоматизация принятия решения

Канарейка работает только в том случае, если кто-то действительно сравнивает версии. Автоматизированные проверки надежнее, чем человек, наблюдающий за графиками. Вот основная идея — сравнение частоты ошибок Canary со стабильной версией:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

Обратите внимание на первый случай. Частота ошибок выглядит высокой, но всего лишь 100 запросов — это еще недостаточно доказательств. Реальные инструменты применяют более точную статистику и рассматривают несколько сигналов вместе:

Проблема с базой данных

Код приложения можно поменять за считанные секунды, а данные — нет. Обе стратегии обычно используют одну базу данных, поэтому во время развертывания и после отката старая и новая версии должны работать с одной и той же схемой.

Стандартный ответ — шаблон расширения и сужения. Предположим, вы хотите переименовать name в full_name:

1. Развернуть: добавьте новый столбец. Старый код не затрагивается.
2. Миграция: выпустите код, который записывает данные в оба столбца и заполняет старые строки.
3. Switch: код выпуска, который считывает из нового столбца.
4. Контракт: если старый столбец не используется, удалите его в более поздней версии.

Для этого потребуется несколько релизов, но каждый шаг можно безопасно откатить. Запуск RENAME COLUMN ​​за один раз приведет к поломке той версии, которая ожидала другого имени. Будьте осторожны с долговременными изменениями схемы, поскольку они могут удерживать блокировки. Подробнее об этом читайте о транзакциях SQL.

Роллинг и другие стратегии

Развертывание Kubernetes по умолчанию выполняет скользящее обновление, что подходит для многих сервисов. Прокатное обновление также смещается постепенно, но его доля привязана к количеству экземпляров, и оно само по себе не анализирует результаты и не делает паузу на плохих показателях.

А как насчет флагов функций?

При развертывании код размещается на серверах, а релиз делает функцию доступной для пользователей. Флаги функций разделяют их, позволяя вам включить функцию для выбранных пользователей, не развертывая ничего. Они очень хорошо работают с обеими стратегиями: развернуть со снятым флагом, а затем постепенно включать его. Они не заменяют эти стратегии, поскольку флаг не может защитить вас от сбоя выпуска при запуске. Не забудьте удалить старые флаги, так как они накапливаются как технический долг.

Как выбрать

Их также можно комбинировать. Некоторые команды развертывают зеленую среду, а затем постепенно переносят туда движение транспорта, получая чистую среду и ограниченный радиус взрыва. Что бы вы ни выбрали, автоматизируйте это с помощью конвейера CI/CD, как объясняется в нашем руководстве по действиям GitHub.

Распространенные ошибки

• Внесение критических изменений в схему. Откат не помогает, если старый код не может прочитать данные.
• Отсутствие критериев отката. Решите, что означает «плохо», до начала выпуска, а не во время инцидента.
• Позволить окружающей среде дрейфовать. Если зеленый цвет отличается от синего, ваши тесты докажут меньший результат. Определите оба с инфраструктурой как кодом.
• Измерение только технических показателей. Релиз может быть безошибочным, но все равно нарушать проверку.
• Никогда не практикуйте откат. Репетируйте это, чтобы оно работало, когда вы находитесь под давлением.
• Забываем о фоновых заданиях. Рабочим и запланированным задачам также требуется план во время переключения.

Итоги

Сине-зеленый обеспечивает чистое и быстрое переключение. Canary дает вам небольшую, размеренную экспозицию. Если ваш мониторинг по-прежнему базовый, начните с чередующихся обновлений или сине-зеленых и инвестируйте в метрики для каждой версии, прежде чем пробовать канарейки. Затем порепетируйте откат следующей версии, включая базу данных. Это единственное упражнение, как правило, показывает, что действительно нуждается в исправлении.

Часто задаваемые вопросы

Продолжайте учиться