Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

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

Скотт Праф, вице-президент отдела разработки компании CSG, отметил: «Мы приняли философию, отвергающую двухуровневое IT, поскольку все клиенты заслуживают и скорости, и качества. Это означает, что нам необходимо техническое совершенство, будь то группа поддержки 30-летнего приложения для мейнфрейма, приложения Java или мобильных приложений».

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

Начиная с сочувствующих и новаторских групп

В каждой организации обязательно найдутся команды и отдельные сотрудники с широким диапазоном стремлений и способностью воспринимать новые идеи. Джеффри Мур первым обозначил этот диапазон как форму жизненного цикла внедрения технологий в книге «Преодоление пропасти. Маркетинг и продажа хайтек-товаров массовому потребителю»[42], где «пропасть» — классическая невозможность достучаться до тех, кто не относится к новаторам или первопроходцам (рис. 9).

Рис. 9. Кривая внедрения технологий (источник: Мур и Маккена. Преодоление пропасти. Маркетинг и продажа хайтек-товаров массовому потребителю, Crossing The Chasm, 15)

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

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

Распространение DevOps на всю организацию

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

Генерируя успехи, мы получаем право расширить масштабы инициативы DevOps. Мы хотим продвигаться по безопасной последовательности, повышающей уровень доверия к нам, степень нашего влияния и получаемой поддержки. Приведенный ниже список позаимствован из курса лекций доктора Роберто Фернандеса, адаптированного Уильямом Паундсом, профессором менеджмента Массачусетского технологического института. Здесь описаны идеальные фазы, применяемые, чтобы побуждать ответственных лиц создавать и расширять коалиции и обеспечивать базу поддержки преобразований.

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