Лекция «Стратегии выката и правило отката»

Около 85 минут на 25 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 75 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Двадцать пять тем о том, как довозят версию до пользователей и по какому числу возвращаются назад. Первая часть — два события и четыре способа. Развёртывание и релиз разнесены флагом функций, и от того, совпадают они или нет, зависит, занимает возврат минуты или секунды. Выкат разом ловит только то, что ломается сразу и у всех, зато исключает состояние двух одновременно работающих версий. Скользящее обновление это состояние создаёт всегда, а значения по умолчанию из справочника API Deployment не дают никакой выдержки: maxSurge 25 % округляется вверх, maxUnavailable 25 % вниз, minReadySeconds равен нулю, то есть экземпляр признаётся здоровым в ту же секунду, как ответила проба готовности, а превышение progressDeadlineSeconds в 600 секунд лишь выставляет признак ProgressDeadlineExceeded и не откатывает ничего. Схема двух сред разобрана по заметке Мартина Фаулера от 1 марта 2010 года вместе с тремя оговорками, которые называет он сам: транзакции, прошедшие мимо, раздельный выкат схемы базы и то, что среды не простаивают, а по очереди играют боевую, откатную и подготовительную роль. Утверждение о двойной стоимости железа Фаулеру приписано пересказом — про стоимость он не пишет. Вторая часть — канареечный выкат по главе Google SRE Workbook: определение, три обязательные части и центральная арифметика разбавления сигнала, где 5 % канарейки с 20 % ошибок дают 1 % на общем фоне, неотличимый от прочих источников ошибок. Отсюда требование разбивки метрик по версиям, компромисс между длительностью и размером, требование к окну наблюдения не короче интервала метрики, и список того, чего канарейка не ловит: нагрузочные дефекты вне пика, дефекты при неполной изоляции групп, риск в системах с состоянием при зеркалировании трафика и разницу между понедельником и выходными при сравнении «до и после». Организационные правила оттуда же: одна канарейка за раз, метрики из показателей качества обслуживания, не более дюжины, загрузка процессора как критерий отвергается. Никакой лестницы процентов 1 → 10 → 50 в первоисточнике нет. Третья часть — поэтапный выкат в разборе Azure Front Door, написанном самой Microsoft после двух аварий октября 2025 года: стадии pre-canary, canary и расширяющиеся волны, проверка здоровья, перепроверяющая и предыдущие стадии, снимок последней исправной конфигурации для возврата, три класса изменений с тремя скоростями — две-три недели для кода сервиса, более 12 часов выдержки для наборов данных защиты и 5–10 минут для клиентской конфигурации, откуда обе аварии и пришли. Девятого октября защита сработала и была обойдена вручную при обслуживании, двадцать девятого конфигурация прошла её насквозь, потому что опасная работа выполнялась асинхронно после отчёта стадии об успехе; падение командного управляющего процесса уложило обслуживающий слой, а восстановление потребовало загрузки сотен тысяч конфигураций и заняло около 4,5 часов. Цена исправлений названа числом: время распространения конфигурации выросло с 5–10 минут примерно до 45. Четвёртая часть — откат и состояние. Определение Комиссии по ценным бумагам и биржам США от 16 октября 2013 года фиксирует, что снятие нового кода с семи серверов, где он был развёрнут правильно, ухудшило аварию: старый код физически оставался на всех серверах, и семь исправных стали восьмым. Убыток превысил 460 млн долларов, штраф составил 12 млн, а 97 писем с текстом ошибки, ушедших до открытия рынка, не были задуманы как оповещения и не рассматривались. Откат возвращает код, но не возвращает данные, схему и побочные эффекты, поэтому несовместимость соседних версий обнаруживается не при выкате, а при откате. Пятая часть — флаги, критерий и регулирование. Флаг даёт единственный возврат за секунды и стоит медианных 734 дней жизни в Kubernetes против 185 в GitLab при отставании удалений от добавлений в 35 % и 13 % по работе на более чем 4000 событий. Критерий отката собирается из шести строк: метрика, порог, окно наблюдения, разбивка по версиям, действие при срабатывании и имя того, кто имеет право не откатывать. Автоматический возврат — отдельно построенная вещь, а не забытая настройка. И два российских документа, которые обычно пересказывают неверно: «две среды» по ГОСТ Р 57580.1 это сегмент разработки и тестирования с запретом сетевого взаимодействия по его инициативе, а не blue-green, и для третьего уровня защиты эти меры не применяются вовсе; методика ФСТЭК от 28 октября 2022 года пунктом 2.6 прямо допускает тестирование обновления безопасности в информационной системе, функционирующей в штатном режиме. Финальная тема собирает четырнадцать красных линий — от того, что ни одна стратегия не уменьшает вероятность дефекта, до того, что поэтапность не спасла Knight Capital.

Нет. Превышение progressDeadlineSeconds — по умолчанию 600 секунд — приводит ровно к одному действию: в статусе появляется условие с причиной ProgressDeadlineExceeded, а контроллер продолжает обрабатывать провалившееся обновление. Дословно в документации: «The deployment controller will continue to process failed deployments and a condition with a ProgressDeadlineExceeded reason will be surfaced in the deployment status». История прежних наборов при этом хранится — по умолчанию десять ревизий, — то есть возврат технически возможен, но команду на него отдаёт человек или внешний инструмент, который за статусом следит. Автоматический откат — это отдельно построенная цепочка «проверка провалилась → возврат на заведомо исправное состояние», и её кто-то проектирует и пишет. Пример такой цепочки в лекции разбирается: у Azure Front Door успешно пройденная стадия обновляет снимок последней исправной конфигурации, и возврат идёт именно на него. Отдельно стоит помнить про minReadySeconds со значением 0: экземпляр признаётся здоровым в ту же секунду, как ответила проба готовности, поэтому версия, падающая через минуту, успевает разъехаться по всем экземплярам раньше, чем упадёт первый.

Потому что в первоисточнике её нет. Глава «Canarying Releases» из Google SRE Workbook приводит ровно три числа: канарейка получает 5 % трафика, новая версия отдаёт 20 % ошибок, общий мониторинг видит рост до 1 %, который «might be indistinguishable from other sources of errors». Лестница процентов разошлась по пересказам и по дороге обзавелась авторитетным источником — это удобная, но выдуманная ссылка, и опереться на неё в разговоре с регулятором, аудитором или собственным руководителем нельзя. Вместо готовых процентов лекция даёт то, из чего числа выводятся самостоятельно: длительность канарейки зависит от частоты выкатов, интенсивности потока запросов и однородности запросов, а окно наблюдения не может быть короче интервала метрики, по которой вы судите, — тридцатиминутная канарейка на часовой метрике даёт, по формулировке авторов, «a very muddied signal». Свои проценты, обоснованные своими данными, честнее и полезнее чужих круглых чисел.