Выкатка и откат: почему канарейка не помогает без нужного детектора

Что здесь на самом деле спрашивают

Лестница обычно такая:

1. «Какие бывают стратегии выкатки?» — разминка на перечисление.
2. «Чем канарейка лучше?» — здесь начинается суть.
3. «Как понять, что канарейка плохая?» — главный вопрос темы, и обычно его пропускают.
4. «Сколько держать канарейку?» — вопрос про выборку.
5. «Как быстро вы можете откатиться?» — вопрос, который важнее вопроса про выкатку.
6. «Что делать с миграцией базы?» — вопрос про то, что не откатывается.

Этот урок стоит на модели, а не на замере: стратегии выкатки описываются документацией отдельных продуктов, общего стандарта у них нет. Модель отвечает не на вопрос «сколько именно у вас», а на вопрос «от чего это зависит».

База: как вообще заменяют работающую версию

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

Пересоздание. Старую версию выключают, новую включают. Между ними — перерыв, во время которого сервиса нет. Способ честный и простой, и он вполне годится там, где перерыв заранее разрешён.

Постепенная замена. Экземпляры меняют по одному: выключили один со старой версией, подняли на его месте новый. Перерыва нет, зато какое-то время обе версии работают одновременно и обслуживают общий поток.

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

Канареечная. Новую версию получает небольшая доля трафика, всё остальное продолжает идти на старую. Если ничего плохого не происходит, долю постепенно увеличивают до полной.

Вот главное, что стоит вынести из этого списка: канарейка сама по себе — не «безопасная выкатка», а просто маленькая выборка новой версии. Она ничего не решает и ни от чего не защищает; она лишь уменьшает долю трафика, которая столкнётся с дефектом, пока кто-то не решит остановиться.

И отсюда — главный вопрос урока: кто и по какому сигналу решает остановиться? Безопасность появляется не от стратегии, а от того, что рядом со стратегией есть сигнал, по которому выкатку останавливают, и он срабатывает раньше, чем дефект успевает навредить. Без такого сигнала маленькая доля просто растягивает происходящее во времени.

Дальше модель сравнивает не в точности эти четыре способа, а те, между которыми обычно и выбирают, и называет их так, как они подписаны в прогонах: blue-green — сине-зелёная, rolling — постепенная замена, canary — канареечная. Пересоздания в модели нет: сервису с заранее разрешённым перерывом сигнал не нужен, останавливать нечего. Зато есть четвёртый участник, feature-flag, — флаг в коде: та же маленькая доля, что у канарейки, но переключает её не инфраструктура, а само приложение при обработке запроса.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования. Всё дальнейшее — про то, что происходит, когда сигнал есть, но подобран неудачно, и почему время возврата важнее времени выкатки.

Механизм 1: четыре стратегии при детекторе, который считает ошибки

Первый прогон: тревога поднимается, когда накопилось 200 ошибок; потом ещё минута на решение; потом откат.

1. DETECTION BY ERROR COUNT: 200 ERRORS RAISE THE ALARM
-------------------------------------------------------
        strategy   affected   detected, s   rolled back, s
      blue-green        520            39              104
         rolling       1820           139              499
          canary        645           324              414
    feature-flag        495           606              666

Результат неожиданный, и в этом главная ценность модели: канарейка (645) оказалась хуже переключения всего трафика разом (520).

Механизм такой. Канарейка держит на новой версии пять процентов трафика, а детектор ждёт двухсот ошибок. На маленькой доле они копятся в двадцать раз дольше, и тревога отстаёт: 324-я секунда против 39-й у переключения разом. Отставание не выросло вдвадцатеро только потому, что на 300-й секунде канарейка уже стала полной выкаткой. Осторожность превратилась в задержку.

Rolling — худший результат, 1820. Здесь виновата не выкатка, а откат: десять реплик, которые заменялись по одной, точно так же по одной и возвращаются. Между тревогой на 139-й секунде и завершённым откатом на 499-й проходит ровно шесть минут, и всё это время дефект работает на половине трафика и больше.

Механизм 2: тот же дефект, другой детектор

Второй прогон отличается одним: тревога поднимается не по числу ошибок, а по их доле — если доля ошибок на новой версии остаётся плохой тридцать секунд.

2. DETECTION BY ERROR RATE: 30 SECONDS OF A BAD SHARE
-----------------------------------------------------
        strategy   affected   detected, s   rolled back, s
      blue-green        470            29               94
         rolling       1270            29              389
          canary         29            29              119
    feature-flag          4            29               89

Теперь стратегии ведут себя так, как о них рассказывают: канарейка задевает 29 запросов, флаг — 4, а переключение разом — 470.

Сравнение двух прогонов и есть суть урока:

3. THE SAME STRATEGY UNDER THE TWO DETECTORS
--------------------------------------------
        strategy   by count    by rate   times fewer
      blue-green        520        470          1.1x
         rolling       1820       1270          1.4x
          canary        645         29         22.2x
    feature-flag        495          4        123.8x

Чем меньше доля трафика на новой версии, тем больше зависимость от детектора. У переключения разом смена детектора почти ничего не меняет (1,1), у флага, который начинает с одного процента, — в 123,8 раза.

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

Механизм 3: откат важнее выкатки

Посмотрите на колонку «rolled back» в первом прогоне: 104, 499, 414, 666. Это момент, когда трафик полностью вернулся на старую версию.

У rolling самое раннее обнаружение из трёх осторожных стратегий (139 с) и самый долгий откат: между тревогой и концом (499 с) проходят пять минут возврата реплик. У флага обнаружение самое позднее (606 с), но конец наступает ровно в момент решения — через минуту после тревоги (606 → 666): возврат мгновенный.

Отсюда практический критерий, который стоит применять к своей системе: считать надо не только «как мы выкатываем», но и «за сколько мы возвращаемся»: дефект живёт от начала до конца отката, а не до момента обнаружения.

Как именно модель это считает, видно из четвёртого раздела того же прогона. В каждую секунду испорчено столько запросов: поток × доля трафика на новой версии × доля запросов, которые ломает дефект (100 × доля × 5 %). Ущерб — сумма этого по всем секундам до конца отката, а время до тревоги, минута на решение и сам откат идут друг за другом, поэтому их длительности складываются:

4. WHERE THE AFFECTED REQUESTS COME FROM: THE THREE TIMES ADD UP
----------------------------------------------------------------
                     run          phase  seconds  affected
         canary, by rate    until alarm       29      7.25
                               deciding       60     15.00
                           rolling back       30      7.50
                                    sum      119     29.75  -> 29 in table 1/2
        canary, by count    until alarm      324    195.00
                               deciding       60    300.00
                           rolling back       30    150.00
                                    sum      414    645.00  -> 645 in table 1/2
   feature-flag, by rate    until alarm       29      1.45
                               deciding       60      3.00
                           rolling back        0      0.00
                                    sum       89      4.45  -> 4 in table 1/2

У канарейки с детектором по доле ошибок доля трафика постоянна, и всё сводится к одной формуле: 100 × 5 % × 5 % × (29 + 60 + 30) с = 29,75, в таблице — 29. У детектора по числу ошибок доля трафика на 300-й секунде выросла с пяти процентов до ста, поэтому там сумма по секундам, а не одно умножение: 645. И это не произведение времён: у флага откат занимает 0 с, а задетые запросы всё равно есть — они случились до тревоги и во время решения. Модель при этом считает только испорченные ответы: необратимые записи, потерянные данные и деньги в неё не входят — о них раздел ниже.

И отсюда же — почему у ответа на вопрос «сколько держать канарейку» есть и нижняя, и верхняя граница. Слишком мало — детектор не наберёт выборку, и вы выкатите дефект дальше (первый прогон). Слишком долго — вы удлиняете время, в течение которого система живёт в двух версиях сразу, а это отдельный источник ошибок: несовместимые форматы, разные схемы, дублирующиеся фоновые задачи.

Глубже: что не откатывается

Последний раздел — про границу метода, и о ней стоит сказать самому.

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

Отправленные сообщения и внешние вызовы не отзываются: письмо ушло, платёж проведён, сообщение в очередь положено. Откат кода вернёт поведение, но не последствия.

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

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

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

Как отвечать на собеседовании

Короткий ответ: ущерб от плохой выкатки зависит от того, сколько трафика и как долго обслуживает дефектная версия, и от тяжести дефекта, а не от названия стратегии. При постоянных потоке и долях число испорченных запросов — это поток × доля трафика на новой версии × доля запросов, которые ломает дефект, × суммарное время воздействия, а время до тревоги, решение и откат в этом времени складываются. Поэтому канарейке нужен детектор, способный заметить проблему на маленькой выборке: в модели урока та же канарейка задела 645 запросов при детекторе, ждущем 200 ошибок, и 29 при детекторе по доле ошибок — разница в 22 раза.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

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

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

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона модели, а не придуман.

canary_count = simulate("canary", "count")
canary_rate = simulate("canary", "rate")
rolling_rate = simulate("rolling", "rate")
print(canary_count["affected"])
print(canary_rate["affected"])
print(rolling_rate["affected"])

645
29
1270

29
645
1270

645
29
120

520
29
1270

Проверка знаний