Denis.Garcia
New member
За последние годы я собрал и переделал, наверное, с десяток пайплайнов: от крошечных проектов на пару сервисов до монорепозитория, где сборка грела серверы часами. И почти каждый раз история повторялась. Приходишь в команду, спрашиваешь — у вас есть CI/CD? Да, конечно, всё настроено, зелёные галочки, автодеплой по кнопке. А потом смотришь на календарь и видишь, что от мержа пул-реквеста до продакшена проходит три недели. Пайплайн есть, а скорость релизов не выросла ни на грамм. Вот об этом и хочу поговорить.
Первое узкое место, которое я встречаю чаще всего, — это подмена метрики. Команда оптимизирует время сборки, гордится, что уложилась в четыре минуты, и совершенно не смотрит на то, сколько времени изменения идут до пользователя в целом. Сборка — это лишь один участок длинной дороги, и ускорять его, когда бутылочное горлышко совсем в другом месте, — примерно как расширять шоссе перед светофором. Найти это просто: возьмите пять-десять реальных фичей за последний месяц и посчитайте полный путь каждой — от первого коммита до релиза. Удивление гарантировано.
Второе — зависимости и кэш. Я до сих пор вижу пайплайны, которые на каждом запуске честно скачивают весь npm или pip-мир заново. Плюс двадцать минут к каждому запуску, плюс нагрузка на сеть, плюс раздражение разработчиков, которые привыкают не смотреть на результаты сразу. Как искать: включите подробные логи по шагам и посмотрите, где реально уходит время. Обычно это не тесты и не компиляция, а установка зависимостей и скачивание базовых образов. Кэш по ключу с хэшем файла блокировки и более тонкий образ — самые дешёвые улучшения, которые я делал в жизни.
Третье место — флейки. Нестабильные тесты, которые падают раз в четыре прогона и проходят при перезапуске. Их принято лечить ретраями, и это ловушка: пайплайн становится зелёным, но доверие к нему умирает. Инженеры перестают смотреть на красный билд, потому что «наверное, опять флейк», а настоящая регрессия проскакивает мимо. Искать так: соберите статистику падений за месяц и посмотрите, какие тесты падают без изменения кода. Их не надо чинить все сразу — достаточно вести список и правило, что новый флейк либо чинится в неделю, либо удаляется.
Четвёртое, и самое болезненное, — люди. Пайплайн может быть молниеносным, но если деплой требует согласования трёх менеджеров, а ревью ждёт две пятницы, никакая автоматизация не спасёт. Я однажды посчитал: восемьдесят процентов времени релиза ждали не сервера, а аппрувы. Найти это легко, если вести журнал событий по изменениям и смотреть не на средние, а на медиану и девяносто пятый процентиль. Средние врут, они прячут хвосты, а именно хвосты и бесят команду.
Пятое узкое место — сам деплой и окружения. Миграции, которые запускаются руками, конфиги, которые правятся на сервере по ssh, «а мы это деплоим только по вторникам». Плюс полное отсутствие наблюдаемости: никто не знает, сколько релизов в неделю и как быстро откатываемся. Я завёл себе привычку смотреть на четыре вещи: частота деплоев, время до релиза, доля сломанных релизов и время восстановления. Когда эти цифры на виду, разговор о приоритетах перестаёт быть вкусовщиной.
Как искать узкие места системно, а не наугад? Я делаю так. Сначала измерения, потом мнения. Разбираю пайплайн на этапы и ставлю таймеры на каждый, чтобы видеть не общую цифру, а дерево времени. Потом смотрю на самый длинный этап и на этап с самой частой ручной работой. Улучшаю только одно место за раз и обязательно проверяю эффект на тех же метриках, иначе легко сделать быстрее то, что и так не тормозило. И держу в голове правило: автоматизировать надо не всё подряд, а только то, что реально стоит в очереди.
Читателям мой совет простой и слегка наглый: перестаньте верить дашборду сборки. Возьмите блокнот, выберите три последних релиза и распишите их путь по минутам и по людям. Почти уверен, что через полчаса вы найдёте одно узкое место, которое чинится за день, но месяцами портило жизнь всей команде. А теперь вопрос к вам, форумчане: какое узкое место в вашем CI/CD оказалось самым неожиданным и как вы его обнаружили?
Первое узкое место, которое я встречаю чаще всего, — это подмена метрики. Команда оптимизирует время сборки, гордится, что уложилась в четыре минуты, и совершенно не смотрит на то, сколько времени изменения идут до пользователя в целом. Сборка — это лишь один участок длинной дороги, и ускорять его, когда бутылочное горлышко совсем в другом месте, — примерно как расширять шоссе перед светофором. Найти это просто: возьмите пять-десять реальных фичей за последний месяц и посчитайте полный путь каждой — от первого коммита до релиза. Удивление гарантировано.
Второе — зависимости и кэш. Я до сих пор вижу пайплайны, которые на каждом запуске честно скачивают весь npm или pip-мир заново. Плюс двадцать минут к каждому запуску, плюс нагрузка на сеть, плюс раздражение разработчиков, которые привыкают не смотреть на результаты сразу. Как искать: включите подробные логи по шагам и посмотрите, где реально уходит время. Обычно это не тесты и не компиляция, а установка зависимостей и скачивание базовых образов. Кэш по ключу с хэшем файла блокировки и более тонкий образ — самые дешёвые улучшения, которые я делал в жизни.
Третье место — флейки. Нестабильные тесты, которые падают раз в четыре прогона и проходят при перезапуске. Их принято лечить ретраями, и это ловушка: пайплайн становится зелёным, но доверие к нему умирает. Инженеры перестают смотреть на красный билд, потому что «наверное, опять флейк», а настоящая регрессия проскакивает мимо. Искать так: соберите статистику падений за месяц и посмотрите, какие тесты падают без изменения кода. Их не надо чинить все сразу — достаточно вести список и правило, что новый флейк либо чинится в неделю, либо удаляется.
Четвёртое, и самое болезненное, — люди. Пайплайн может быть молниеносным, но если деплой требует согласования трёх менеджеров, а ревью ждёт две пятницы, никакая автоматизация не спасёт. Я однажды посчитал: восемьдесят процентов времени релиза ждали не сервера, а аппрувы. Найти это легко, если вести журнал событий по изменениям и смотреть не на средние, а на медиану и девяносто пятый процентиль. Средние врут, они прячут хвосты, а именно хвосты и бесят команду.
Пятое узкое место — сам деплой и окружения. Миграции, которые запускаются руками, конфиги, которые правятся на сервере по ssh, «а мы это деплоим только по вторникам». Плюс полное отсутствие наблюдаемости: никто не знает, сколько релизов в неделю и как быстро откатываемся. Я завёл себе привычку смотреть на четыре вещи: частота деплоев, время до релиза, доля сломанных релизов и время восстановления. Когда эти цифры на виду, разговор о приоритетах перестаёт быть вкусовщиной.
Как искать узкие места системно, а не наугад? Я делаю так. Сначала измерения, потом мнения. Разбираю пайплайн на этапы и ставлю таймеры на каждый, чтобы видеть не общую цифру, а дерево времени. Потом смотрю на самый длинный этап и на этап с самой частой ручной работой. Улучшаю только одно место за раз и обязательно проверяю эффект на тех же метриках, иначе легко сделать быстрее то, что и так не тормозило. И держу в голове правило: автоматизировать надо не всё подряд, а только то, что реально стоит в очереди.
Читателям мой совет простой и слегка наглый: перестаньте верить дашборду сборки. Возьмите блокнот, выберите три последних релиза и распишите их путь по минутам и по людям. Почти уверен, что через полчаса вы найдёте одно узкое место, которое чинится за день, но месяцами портило жизнь всей команде. А теперь вопрос к вам, форумчане: какое узкое место в вашем CI/CD оказалось самым неожиданным и как вы его обнаружили?