Джин Ким - Руководство по DevOps

Для закрепления и защиты механизмов существующих процессов используется много разных методов (специализация, сосредоточенность на эффективности и воспроизводимости, бюрократия, требующая одобрения всех процессов, и контроль для защиты от изменений). В частности, бюрократия невероятно устойчива и предназначена для выживания в неблагоприятных условиях — можно уволить половину чиновников, а процесс будет идти по-прежнему.

Хотя это хорошо для сохранения статус-кво, часто требуется изменить методы, чтобы приспособиться к изменяющимся условиям на рынке. Что, в свою очередь, требует инноваций и разрушения старых приемов. Возникает противоречие с интересами групп, в настоящее время отвечающих за повседневные операции и внутренние бюрократические механизмы и почти всегда выходящих победителями из внутренних конфликтов.

В своей книге The Other Side of Innovation: Solving the Execution Challenge, Виджей Говиндараджан и Крис Тримбл, преподаватели Такской школы бизнеса в Дартмутском колледже, описали тематические исследования по вопросу, как вводить инновации без разрушений, несмотря на мощную инерцию повседневной деятельности. Они документально фиксировали, как автомобильные страховки по методу «продвижение клиента» были успешно разработаны и продавались компанией Allstate, как прибыльный цифровой издательский бизнес был создан газетой Wall Street Journal, как модифицировались невиданные кроссовки для бега по пересеченной местности, разработанные компанией Timberland, и как развивался первый электромобиль компании BMW.

Основываясь на своих исследованиях, Говиндараджан и Тримбл утверждают: организациям необходимо создать специальную команду преобразований, способную работать без связи с остальными частями организации, несущими ответственность (они называют эти части «выделенная группа» и «двигатель производительности» соответственно).

Прежде всего мы будем возлагать на специализированную группу ответственность за достижение четко определенных и поддающихся измерению результатов на уровне системы (например, уменьшить время развертывания от «код зафиксирован в системе контроля версий» до «код успешно работает в производственной среде» на 50 %). Чтобы реализовать такую инициативу, выполним следующие действия.

• Назначим членов выделенной команды, чья деятельность будет направлена исключительно на усилия по трансформации DevOps (в отличие от распространенной практики вроде «все ваши текущие обязанности сохраняются, но 20 % вашего времени вы должны тратить на эту новую штучку DevOps»).

• Выберем среди членов команды специалистов широкого профиля, имеющих навыки в различных областях.

• Выберем членов команды, имеющих давние и взаимные связи с другими отделами организации.

• Выделим, если это возможно, специализированной команде отдельное помещение для максимального увеличения обмена информацией внутри команды и создания некоторой изоляции от остальных частей организации.

Если возможно, освободим команду преобразования от целого ряда правил и процедур, ограничивающих действия других отделов организации, как это сделали в компании National Instruments, описанной в предыдущей главе. В конце концов, сложившиеся в компании процессы — одна из форм коллективной памяти, и мы нуждаемся в специальной команде для создания новых процессов и знаний, необходимых для получения желаемых результатов и создания новой коллективной памяти.

Создание специализированной команды полезно не только для нее самой, но также и для «двигателя производительности». Формируя отдельную команду, мы создаем пространство для экспериментов с новыми методиками, одновременно защищая остальные части организации от возможных сбоев и отвлекающих факторов.

Одна из наиболее важных составляющих любой инициативы по улучшению — определение измеримой цели с четко заданным сроком достижения (от шести месяцев до двух лет). Она должна требовать значительных усилий, но быть все же реалистичной. И достижение цели должно создать очевидную ценность как для организации в целом, так и для клиентов.

Эти цели и сроки должны быть согласованы с руководителями и стать известны всем в организации. Мы также хотим ограничить число типов инициатив, реализуемых одновременно, чтобы они не стали чрезмерно обременительными для управленческих возможностей руководителей, занимающихся организационными изменениями, и для самой компании. В качестве примеров целей для улучшения можно привести следующие.

• Снизить процентную долю расходов на поддержку продуктов и незапланированные работы на 50 %.

• Обеспечить срок с момента фиксации кода до релиза его в производство не более недели для 95 % изменений.

• Обеспечить релиз кода в производство только в обычное рабочее время с нулевым временем простоя.

• Интегрировать все необходимые управляющие элементы контроля безопасности в конвейер развертывания, чтобы обеспечить проверку соответствия всем необходимым требованиям.

Когда все четко уяснят цель высокого уровня, командам следует принять решение о регулярном темпе работы по улучшению. Мы хотим, чтобы преобразования осуществлялись подобно тому, как ведется разработка продукта, то есть итеративно, с постепенным наращиванием результата. Длительность типичной итерации будет находиться в интервале от двух до четырех недель. При каждой итерации команды должны договориться о небольшом наборе целей, генерирующих ценность и создающих некоторый прогресс на пути к долгосрочной цели. В конце каждой итерации командам следует проанализировать достигнутый прогресс и установить новые цели для следующей итерации.

В любом проекте преобразования DevOps мы должны сохранить горизонты планирования близкими, как если бы речь шла о стартапе, выпускающем продукт или выполняющем разработку для клиента. Инициативы должны быть нацелены на создание измеримых улучшений или получение рабочих данных в течение нескольких недель (в крайнем случае — месяцев).

Продолжая планировать на небольшие интервалы времени и поддерживая короткие итерации, мы достигаем следующего:

• гибкости и способности быстро изменить приоритеты и планы;

• уменьшения интервала между временем, когда были затрачены усилия, и реализацией улучшений, что укрепляет петлю обратной связи и повышает вероятность того, что она упрочит желаемое поведение — когда инициативы по улучшению успешны, это поощряет дополнительные инвестиции;

• более быстрого обучения, начинающегося с первой итерации, что означает более быструю интеграцию выводов на следующем шаге;