Прежде чем строить пайплайн, нужны эти три вещи
Несколько месяцев назад я сидел на планерке, где команда с воодушевлением обсуждала свой новый CI/CD пайплайн. Они потратили недели на настройку инструментов, написание YAML-файлов и организацию автоматических тестов. Пайплайн был зелёным. Деплои — быстрыми. Все чувствовали себя отлично.
А потом кто-то спросил: «Чего мы вообще пытаемся этим добиться?»
В комнате повисла тишина. Кто-то говорил про более частые релизы. Другие упоминали уменьшение количества багов. Несколько человек сказали, что хотят сократить ручную работу. Единого ответа не было. Пайплайн работал, но никто не мог объяснить, как выглядит успех.
Эта команда построила пайплайн, не ответив предварительно на три фундаментальных вопроса. И именно поэтому их пайплайн, каким бы хорошо спроектированным он ни был, не решал правильных задач.
Начните с «Зачем»: бизнес-результат
У любой инженерной работы должна быть цель. Без неё команды дрейфуют. Они создают функции, которые никто не просил. Оптимизируют процессы, которые не имеют значения. Измеряют то, что красиво выглядит на дашбордах, но никак не связано с реальными результатами.
Бизнес-результат — это не список фич. Это не техническое задание. Это измеримый результат, который важен для людей, использующих ваш продукт или платящих за него.
Примеры бизнес-результатов:
- Новые пользователи могут завершить регистрацию менее чем за две минуты.
- Время формирования ежемесячных отчётов сокращается с трёх дней до одного часа.
- Количество обращений в поддержку, связанных с проблемами входа, снижается на 40 процентов.
Обратите внимание, чем это не является. Это не «мы внедрим OAuth» и не «мы мигрируем на Kubernetes». Это технические решения. Бизнес-результат описывает эффект, который вы хотите создать, а не то, как вы планируете его достичь.
Когда у команды есть чёткий бизнес-результат, решения становятся проще. Стоит ли добавить новую функцию или исправить проблему со стабильностью? Смотрим на бизнес-результат. Какой вариант приближает к цели? Без этого якоря каждая команда определяет успех по-своему. Фронтенд-команда измеряет время загрузки страницы. Бэкенд-команда — задержки API. Платформенная команда — аптайм. Все заняты. Никто не согласован.
Нанесите на карту поток: поток создания ценности
Как только вы знаете, чего хотите достичь, нужно понять, как работа на самом деле течёт от идеи до пользователя. Это ваш поток создания ценности (value stream).
Поток создания ценности — это не то же самое, что CI/CD пайплайн. Пайплайн — это техническая реализация. Поток создания ценности — это полный путь: от момента, когда кто-то пишет код, через тестирование, сборку, ревью, утверждение, деплой, верификацию и, наконец, до пользователя, который получает от этого ценность.
Поток создания ценности также включает то, что пайплайны часто игнорируют:
- Процессы ревью кода и утверждения
- Ручные шаги верификации
- Время ожидания между передачами
- Петли обратной связи, когда что-то идёт не так
- Коммуникационные накладные расходы между командами
Картирование потока создания ценности означает перечисление каждого шага, который происходит между «код написан» и «пользователь получил ценность». Для каждого шага задайте три вопроса:
- Что является результатом этого шага?
- Кто в нём участвует?
- Как мы узнаем, добавляет ли он ценность?
Многие команды обнаруживают, что половина шагов в их потоке создания ценности напрямую не способствует бизнес-результату. Они существуют, потому что «так сложилось исторически». Еженедельное совещание по утверждению, на которое никто не ходит. Ручная подпись, которая ставится автоматически. Этап тестирования, который выполняет те же проверки, что и автоматизированный пайплайн.
Эти шаги — потери (waste). Они замедляют поставку, не улучшая качество. Когда вы видите их в своём потоке, у вас есть два варианта: удалить их или перепроектировать.
Назначьте ответственного: команда
У вас есть цель и карта. Теперь нужны люди, которые будут двигаться.
Компонент «команда» касается того, кто владеет какой частью потока создания ценности. Это не про оргструктуру или подчинённость. Это про ясность ответственности.
У каждого шага в потоке создания ценности должен быть чёткий владелец. Этот владелец знает:
- За что он отвечает
- Как его результат связан с бизнес-результатом
- Кто зависит от его работы
- Что ему нужно от других для выполнения своей работы
Когда ответственность неясна, появляются разрывы. Команда приложения думает, что деплой — это задача инфраструктурной команды. Инфраструктурная команда думает, что деплой — это задача команды приложения. Новые версии неделями лежат в стейджинге, потому что никто не берёт на себя ответственность за финальный выкат в продакшн.
Разные организации структурируют команды по-разному. Где-то используют фича-команды, включающие разработчиков, тестировщиков и эксплуатацию в одной группе. Где-то есть отдельная платформенная команда, предоставляющая инфраструктуру и инструменты для команд приложений. Ни один из подходов не является изначально лучшим. Важно, чтобы у каждой части потока создания ценности был названный владелец, и чтобы этот владелец понимал, как его работа способствует бизнес-результату.
Как эти три компонента связаны
Бизнес-результат, поток создания ценности и команда не независимы. Они образуют систему.
Диаграмма ниже показывает, как эти три элемента образуют систему, которая определяет дизайн пайплайна.
- Бизнес-результат задаёт направление. Без него команды принимают решения, основываясь на личных предпочтениях или локальной оптимизации.
- Поток создания ценности показывает путь. Без него команды не видят, где скрываются задержки и потери.
- Команда обеспечивает возможность. Без чёткой ответственности работа проваливается в щели.
Когда одного из этих компонентов не хватает, остальным приходится туго. Команда, не знающая бизнес-результата, будет оптимизировать не то. Поток создания ценности, который не нанесён на карту, будет скрывать узкие места. Команда без чёткой ответственности создаст задержки при передаче и игры в перекладывание вины.
Только после того, как эти три компонента прояснены, стоит начинать говорить о платформах, пайплайнах и стратегиях деплоя. Инструменты и автоматизация ускоряют процесс. Но если сам процесс несогласован, ускорение только усугубит проблемы.
Быстрая проверка перед тем, как строить
Прежде чем проектировать следующий пайплайн или выбирать очередной инструмент для деплоя, пройдитесь с командой по этому короткому чек-листу:
- Может ли каждый назвать один-два главных бизнес-результата, к которым стремится команда?
- Нанесли ли вы на карту полный поток создания ценности от кода до пользователя, включая ручные шаги и время ожидания?
- Есть ли у каждого шага в этом потоке чёткий владелец?
- Может ли каждый владелец объяснить, как его работа связана с бизнес-результатом?
Если на любой вопрос ответ «нет», сначала исправьте это. Пайплайн подождёт.
Вывод
Пайплайн — это инструмент. Стратегия деплоя — это техника. Ни то, ни другое не заменяет ясности в том, чего вы пытаетесь достичь, как работа течёт для достижения этого и кто отвечает за каждую часть этого потока.
Начните с бизнес-результата. Нанесите на карту поток создания ценности. Назначьте чётких владельцев. А затем стройте пайплайн, который обслуживает эту систему, а не наоборот.