Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях
Шрифт:
Внимание уделено в первую очередь теории и принципам, выработанным за несколько десятилетий изучения рабочих сред, организации его высокой надежности, создания моделей управления с высоким уровнем доверия, положенных в основу методов DevOps. Получившиеся в результате принципы и схемы действий, а также их практическое применение для создания потока технологической ценности описаны в остальных главах книги.
Одна из фундаментальных концепций бережливого производства – поток создания ценности. Сначала мы определим это понятие в рамках промышленности, а затем экстраполируем на DevOps и технологический поток создания ценности.
Карен Мартин и Майк Остерлинг
В материальном производстве поток создания ценности легко увидеть, легко наблюдать за ним: он начинается, когда получен заказ от клиента, а сырье для производства поступило на склад. Чтобы обеспечить короткое и предсказуемое время выполнения заказа в любом потоке создания ценности, обычно фокусируются на плавном течении работы, используя такие приемы, как уменьшение размера партии, снижение объема незавершенного производства, недопущение переделок, чтобы исключить попадание дефектных деталей на конечных этапах и постоянно оптимизировать систему для движения в сторону глобальных целей.
Те же принципы и методы, обеспечивающие скорость выполнения работы в процессах материального производства, применимы и к области технологий (и вообще для любой деятельности, создающей знание). В DevOps поток создания технологической ценности обычно определяют как процесс, требующийся для преобразования бизнес-гипотез в технологический сервис, поставляющий ценность заказчику.
Исходные данные для процесса – формулирование бизнес-цели, концепции, идеи или гипотезы. Все начинается, когда мы принимаем задачу в области разработки, добавляя ее к уже имеющимся.
Таким образом, команда разработчиков, следующая типичному Agile- или итеративному процессу, скорее всего, сможет адаптировать эту идею в соответствии с пожеланиями пользователей, создав некоторую разновидность спецификации функциональных возможностей. Затем она реализует их в виде кода приложения или создаваемого сервиса и поместит его в репозиторий системы контроля версий, где каждое изменение интегрируется в основной код и тестируется вместе со всей системой.
Поскольку продукт создается, когда наши сервисы работают в производственной среде, следует обеспечить не только быстрый поток доставки, но и то, чтобы развертывание можно было выполнять без хаоса и перебоев: задержек в обслуживании, нарушения функционирования сервисов, требований безопасности или совместимости.
В остальной части книги сосредоточимся на такой составной части потока создания ценности, как сокращенное время развертывания. Начинается оно тогда, когда некий инженер [22] из команды потока создания ценностей (включающей разработчиков, тестировщиков, отделы эксплуатации и информационной безопасности) получает изменения от системы контроля версий. А заканчивается, когда изменение начинает успешно работать в производственной среде, создавая продукт для клиентов и генерируя обратную связь и телеметрию.
22
Здесь и далее слово «инженер» означает любого человека, работающего в команде, производящей поток ценности, а не только разработчиков. Прим. авт.
Первый этап включает проектирование и разработку. Он сродни бережливой разработке продуктов и характеризуется высокой изменчивостью и неопределенностью, часто требует творческого подхода к выполнению работы, которая может никогда не понадобиться. Это приводит к различной продолжительности данного
Мы не любители больших порций работы, последовательно проходящих через такие части потока создания ценности, как «проектирование и разработка», а затем через поток «тестирование и производство» (например, когда используется большой водопадный процесс или долго живущая функциональная ветвь кода). Напротив, мы стремимся, чтобы тестирование и производство выполнялись одновременно с проектированием и разработкой. Так обеспечиваются быстрый ход потока и высокое качество. Этот метод успешен, если исполнение осуществляется по небольшим частям и качество обеспечивается на каждом этапе потока создания ценностей [23] .
23
По правде говоря, при использовании таких методик, как разработка через тестирование, тестирование может начинаться еще до того, как будет написана первая строка кода. Прим. авт.
В Lean время выполнения заказа – одна из двух характеристик, обычно использующихся для измерения производительности потоков ценности. Другая характеристика – время производства (иногда его еще называют временем контактирования или временем выполнения задачи) [24] .
Если отсчет времени выполнения заказа начинается в момент оформления и заканчивается при выполнении, то время производства отсчитывается с момента, когда мы начинаем работу над заказом, точнее, не засчитывается тот период времени, когда заказ стоял в очереди на выполнение (рис. 2).
24
В этой книге термин «время производства» будет использоваться по той же причине, о которой говорили Карен Мартин и Майк Остерлинг: «чтобы минимизировать возможную путаницу, мы избегаем использовать термин “время цикла”, поскольку он имеет несколько значений, в том числе синонимичное для времени производства и темпа или частоты выдачи результатов, и это только некоторые». Прим. авт.
Рис. 2. Время выполнения заказа и время производства
Поскольку время выполнения заказа – самая важная характеристика для клиента, обычная цель – улучшить процессы, сократив вот этот параметр, а не время производства. Однако соотношение времени производства и времени выполнения заказа – важный критерий оценки эффективности: чтобы обеспечить быстрый ход работ и короткое время выполнения заказа, почти всегда требуется сократить время ожидания, пока дойдет очередь.
При ведении бизнеса обычными способами мы часто оказываемся в ситуации, когда развертывание занимает несколько месяцев. Особенно часто это происходит в больших сложных организациях, использующих тесно связанные друг с другом монолитные приложения, плохо интегрированные в среду для тестирования, со значительной продолжительностью тестирования и длительным временем развертывания в рабочей среде, высокой зависимостью от тестирования вручную и необходимостью одобрения многочисленными инстанциями в компании. Когда такое происходит, поток создания ценности начинает выглядеть, как показано на рис. 3.