У Netflix нашлась внутренняя библиотека с 73 версиями в обращении, и это хорошая иллюстрация того, почему автоматизация миграций кода перестала быть nice to have. Инженер Netflix Кейси Блайфер рассказала, как компания строит платформу, способную проталкивать изменения сразу через тысячи сервисов, и для русскоязычных платформенных команд тут сигнал простой: долгий хвост ручных обновлений уже слишком дорог даже для тех, у кого CI/CD вроде бы давно «в порядке».
О подходе Netflix по данным InfoQ Блайфер рассказала в докладе Confidently Automating Changes Across a Diverse Fleet. Задача звучит знакомо любому крупному продукту: команда выпускает новую версию библиотеки, первые месяцы adoption идет бодро, потом застревает на 75-85%, а через год старая версия все еще живет в проде. В результате платформенная команда тащит зоопарк релизов, а продуктовые команды вместо фич снова и снова возвращаются к миграциям. В Netflix сформулировали для себя жесткую цель: автоматизировать любые fleet-wide изменения максимум за неделю, а критические уязвимости закрывать за два дня.
Под это компания собрала event-driven платформу оркестрации. Внутри несколько базовых сущностей: campaigns, targets и paths. Кампания описывает миграцию, target обозначает конкретный объект изменения, а path задает цепочку шагов. Сами шаги сделаны как компонуемые блоки по принципу конструктора: трансформация кода, создание pull request, валидация, активация PR, слияние, проверка билда на main и мониторинг выката. Важная деталь: Netflix разделяет rollout и deployment. Платформа управляет порядком шагов и состояниями, но не подменяет собой систему доставки. Для деплоев она интегрируется с Spinnaker, слушает события, учитывает quiet periods и не лезет туда, где у команды уже есть свои ограничения.
Главная инженерная мысль здесь не в том, что «мы все автоматизировали», а в том, что автоматизация не должна ломать прод. Поэтому вокруг path добавили несколько страховок. Сначала draft PR должен пройти стандартные проверки, затем могут запускаться дополнительные валидации, включая canary-анализ от resilience-команды. Если канарейка не проходит, процесс останавливается. Дальше идут compliance checks: можно ли системе вообще автосливать изменения в этот репозиторий, не конфликтует ли это с правами доступа, находится ли PR в mergeable state. Поверх этого Netflix использует собственную confidence metric. Если уровень доверия к сервису и к самой автоматизации высокий, PR можно сливать автоматически. Если нет, система зовет человека.
Именно эта confidence metric оказалась центральной идеей. Блайфер прямо говорит: доверие здесь двустороннее. Нужно не только верить в платформу, но и понимать, насколько сами сервисы готовы к такой схеме. Есть ли у них тесты, canary, телеметрия, адекватный процесс выката, живые контакты владельцев? В компании насчитали более 4 тысяч сервисов, и пытаться за один заход охватить весь флот было бы слишком самоуверенно. Поэтому Netflix начал с малого: JVM-экосистема, сервисы из разных бизнес-юнитов и максимально безобидное изменение в коде, по сути логирование. Этот эксперимент получил имя Confidence Chimp, в духе внутреннего «зоопарка» Simian Army.
Первый прогон выглядел отрезвляюще. В эксперимент взяли 120 Java-сервисов, и даже такое относительно простое изменение доехало до финиша только за 86 дней. При этом 44% targets потребовали ручного вмешательства либо от команды платформы, либо от владельцев сервиса. После разбора причин выяснилось, что проблема не сводится к одному плохому скрипту. Где-то уведомления уходили в пустоту, потому что у сервиса не было нормальных contact metadata. Где-то pull request зависал на недели из-за flaky build, compliance-ограничений или просто потому, что его никто не замечал. Где-то тормозили деплой-пайплайны с ручными approval gates, которые исторически остались на месте, хотя уже почти ничего не отсеивали.
Исправления были вполне приземленные, и в этом, пожалуй, главное достоинство доклада. Netflix не продает магию, а показывает уборку технического и процессного мусора. Компания усилила требования к контактным данным сервисов, чтобы у каждой системы были on-call, Slack-канал и резервный e-mail. Для PR добавили более точное отслеживание состояний, автоматическое возобновление workflow, когда PR «выздоравливает», детект ручных merge и дополнительные напоминания по долго висящим изменениям. Вместе с delivery-командой пересмотрели ручные ворота в деплоях и убрали те, что статистически не давали заметного выигрыша по безопасности или надежности. Результат: число ручных вмешательств, связанных именно с deployment approvals, сократилось на 77%.
После нескольких итераций цифры стали выглядеть уже как системный прогресс, а не как разовая удача. Последняя завершенная кампания шла уже более чем по 2 тысячам targets. Срок выполнения удалось сократить с 86 до 26 дней, а долю targets с ручным вмешательством снизить с 44% до 21%. До исходной цели в неделю Netflix еще не добрался, и Блайфер это не скрывает. Но масштаб важен: стартовали примерно с 3% всего флота сервисов, а в последних упражнениях охватывали уже около 50% сервисов, включая Java и часть Python-сервисов с высоким уровнем confidence. По возможностям самой платформы планка еще выше: она уже способна работать примерно с 66% сервисов.
Для разработчиков и техдиров здесь есть неприятный, но полезный вывод. Автоматизация миграций кода упирается не столько в codemod, сколько в зрелость всего окружения: права в репозиториях, канарейки, качество билдов, частоту деплоя, контактные данные владельцев и готовность команд доверить платформе часть рутины. Если сервис не тестируется, не выкатывается месяцами и живет в режиме «кто последний трогал этот репозиторий, тот и владелец», никакая умная оркестрация не превратит его в образец управляемости. Зато там, где базовая гигиена есть, эффект уже очень прикладной: меньше хвоста старых библиотек, быстрее закрытие уязвимостей и меньше бессмысленных миграционных спринтов.
Netflix уже применяет платформу не только для учебных лог-изменений, но и для реальных миграций: JDK-обновлений, обновления delivery-конфигов, замены устаревшего ПО и даже GenAI-подсказанных преобразований кода. Следующий рубеж очевиден: дотянуть автоматизацию миграций кода до библиотек, job-репозиториев и более широких Python- и JavaScript-сценариев. Для крупных компаний вопрос уже не в том, нужна ли такая платформа, а в том, сколько еще лет они готовы оплачивать ручной хвост изменений.