Руководство по DevOps - [15]
В Lean время выполнения заказа — одна из двух характеристик, обычно использующихся для измерения производительности потоков ценности. Другая характеристика — время производства (иногда его еще называют временем контактирования или временем выполнения задачи)[24].
Если отсчет времени выполнения заказа начинается в момент оформления и заканчивается при выполнении, то время производства отсчитывается с момента, когда мы начинаем работу над заказом, точнее, не засчитывается тот период времени, когда заказ стоял в очереди на выполнение (рис. 2).
Рис. 2. Время выполнения заказа и время производства
Поскольку время выполнения заказа — самая важная характеристика для клиента, обычная цель — улучшить процессы, сократив вот этот параметр, а не время производства. Однако соотношение времени производства и времени выполнения заказа — важный критерий оценки эффективности: чтобы обеспечить быстрый ход работ и короткое время выполнения заказа, почти всегда требуется сократить время ожидания, пока дойдет очередь.
При ведении бизнеса обычными способами мы часто оказываемся в ситуации, когда развертывание занимает несколько месяцев. Особенно часто это происходит в больших сложных организациях, использующих тесно связанные друг с другом монолитные приложения, плохо интегрированные в среду для тестирования, со значительной продолжительностью тестирования и длительным временем развертывания в рабочей среде, высокой зависимостью от тестирования вручную и необходимостью одобрения многочисленными инстанциями в компании. Когда такое происходит, поток создания ценности начинает выглядеть, как показано на рис. 3.
Рис. 3. Поток технологической ценности при продолжительности внедрения длиной в три месяца (пример взят из вышедшей в 2015 г. книги Дэмона Эдвардса DevOps Kaizen)
При большой продолжительности развертывания сверхусилия требуются практически на каждой стадии потока создания ценности. Может оказаться, что при завершении проекта, когда все результаты труда инженеров собраны воедино, все перестанет работать, код не будет собираться правильно или перестанет проходить тесты. Исправление любой проблемы, определение, кто именно «сломал» код и как это исправить, потребует нескольких дней или даже недель, а в результате отдача для клиентов окажется невысокой.
В идеальном случае при работе с DevOps разработчики постоянно быстро получают обратную связь, что дает им возможность быстро и независимо внедрять, интегрировать и валидировать код, а также обеспечивать развертывание кода в производственной среде (это могут делать как они сами, так и другой отдел).
Это достигается за счет постоянной проверки небольших изменений в коде, производимых в репозитории системы контроля версий, выполнения автоматического и пред-производственного тестирования изменений, а затем развертывания в реальной производственной среде. Что и позволяет нам быть твердо уверенными: сделанные изменения после развертывания будут функционировать так, как задумано, и любая возникшая проблема будет быстро обнаружена и исправлена.
Наиболее легко это достигается, когда архитектура модульная, хорошо инкапсулированная, в ней отсутствуют тесные связи между компонентами, так что небольшие группы имеют возможность работать с высокой степенью автономности, возникающие сбои оказываются небольшими и с ограниченными последствиями, не вызывающими глобальных нарушений работоспособности системы.
При таком сценарии время развертывания измеряется минутами или в худшем случае часами. Получившаяся карта потока ценности должна выглядеть примерно так, как показано на рис. 4.
Рис. 4. Технологический поток создания ценности с развертыванием за минуты
Помимо времени выполнения заказа и времени производства для оценки технологического потока создания ценности применяется и третий показатель — доля завершенной и правильной работы (percent complete and accurate — %C/A). Этот показатель отражает качество выполнения на каждом этапе потока создания ценности. Карен Мартин и Майк Остерлинг утверждают: «показатель %C/A можно получить, опросив клиентов, как часто в количественном выражении они получали продукт, пригодный к использованию сразу. Подразумевается, что они используют результат без необходимости его корректировать, добавлять пропущенную информацию или пояснения к имеющейся, если она недостаточно понятна».
В книге The Phoenix Project «три пути» представлены как основополагающие принципы. Из них выводится DevOps и его методы (рис. 5).
Рис. 5. «Три пути» (пример взят из текста Джина Кима The Three Ways: The Principles Underpinning DevOps, размещенного в блоге Revolution Press blog по адресу: http://itrevolution.com/the-three-ways-principles-underpinning-devops/, доступ осуществлен 9 августа 2016 г.)
Первый путь обеспечивает быстрое течение потока слева направо от разработки к эксплуатации, а затем к клиентам. Чтобы сделать это течение как можно более интенсивным, необходимо сделать результаты видимыми, уменьшая размеры заданий и интервалы между ними, обеспечивая качество путем предотвращения попадания дефектов на конечные этапы и постоянно занимаясь оптимизацией для достижения глобальной цели организации.
