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

• Компания Etsy (2009 г.).В 2009 г. компания Etsy имела 35 сотрудников и приносила доход в размере 87 миллионов долларов, но, после того как она едва выжила в сезон предрождественских распродаж, она начала преобразования практически по каждому направлению деятельности, в итоге превратившись в одну из наиболее уважаемых компаний, использующих DevOps, и создала условия для успешного размещения своих акций на бирже в 2015 г.

Исследовательская компания Gartner недавно популяризировала понятие «двухуровневые IT», ссылаясь на широкий спектр услуг, которые поддерживает типичное крупное предприятие. В рамках двухуровневого IT существуют системы записей , подобные ERP. Благодаря им функционирует наш бизнес (например, MRP, HR, системы финансовой отчетности), где корректность транзакций и данных имеет первостепенное значение, и системы совместной работы , включающие работу с клиентами и с сотрудниками (системы электронной торговли и приложения, обеспечивающие высокую производительность).

Системы записей обычно меняются медленнее и нередко должны соответствовать нормативным требованиям (например, закону Сарбейнза — Оксли). Компания Gartner называет такие системы «тип 1»; организации, их использующие, уделяют основное внимание установке «делать правильно».

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

Может оказаться удобным разделить системы на эти категории, однако мы знаем, что коренной, хронический конфликт между «делать правильно» и «делать быстро» можно разрешить, используя DevOps. Данные из докладов State of DevOps, которые готовит компания Puppet Labs, — следуя урокам бережливого производства — показывают: высокопроизводительные организации имеют возможность одновременно обеспечивать как производительность, так и надежность.

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

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

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

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

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

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

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

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

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

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