Убейте DevOps

Между дзен-буддизмом и DevOps прослеживается интересная параллель, которую лучше всего проиллюстрировать понятием коана — короткого повествования, диалога, вопроса или утверждения, используемого в практике дзен-буддизма для порождения у учеников сомнения и проверки того, какого прогресса они добились в понимании сути учения. «Если встретишь на дороге Будду, убей его» — призывал один из коанов. Он восходит к старому коану мастера дзен-буддизма Линьцзи, основавшего школу Риндзай. Насилие — последнее, с чем ассоциируются дзен и буддизм, и такие призывы не следует воспринимать буквально. Путь разгадки коана ведет к Пробуждению или Просветлению. Встреча с Буддой заставляет вас думать, что вы достигли своей цели. Но реальность — всего лишь призрачный мираж, и, пребывая в статическом состоянии, вы никогда не достигнете желаемого. Нужно продолжать медитировать и искать.

Итак, какое же отношение DevOps имеет к школе буддизма? Он похож на культ мечтателей, где на любого, у кого нет косички, кто не одет в футболку и не держит в руках iPad, смотрят с подозрением. Да, здесь много любителей пошутить, и, если вы когда-нибудь посещали мероприятие DevOps, вы понимаете, о чем я говорю. Одни только постоянные споры об определении DevOps уже заставляют провести параллель с дзен-буддизмом. В пресловутой неповоротливой «Википедии» упоминается лишь о методе разработки программного обеспечения, однако это не так. Кто-то ассоциирует понятие DevOps с организационной структурой. Кто-то — с определенными инструментами. Гораздо проще сказать, чем DevOps не является, а то, что останется, поможет понять, о чем идет речь на самом деле. Уже само по себе это напоминает дзен-буддизм. И мы пока находимся лишь в самом начале.

Один из лучших источников для определения или описания DevOps — статья Джина Кима «11 главных вещей, которые вам нужно знать о DevOps». Будучи одним из авторов революционной книги «The Phoenix Project», Ким рассматривает DevOps как «развивающееся профессиональное движение, нацеленное на укрепление производственных отношений между разработчиками и специалистами подразделения эксплуатации и ускорение выполнения запланированных работ (так называемое быстрое развертывание) с одновременным повышением надежности, стабильности, устойчивости и безопасности производственной среды». Мне нравится слово «движение». Помимо формирования группы людей, совместно работающих над реализацией общих идей, это предполагает еще и проведение постоянных изменений.

В «The Phoenix Project» описываются три основополагающих принципа, на базе которых и возникла концепция DevOps. Они закладывают ценности и философию, которые определяют процессы, процедуры, практики и предписывающие шаги. К указанным трем принципам относятся:

• cистемное мышление;
• усиление обратной связи;
• культура непрерывного обучения и экспериментов.

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

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

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

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

***

Большинство информационных систем предприятий представляют собой сочетание унаследованных и современных технологий с тесно переплетенными интерфейсами между различными компонентами. Системы поддерживаются столь же неоднородным и взаимосвязанным сочетанием внутренних и внешних организационных функций ИТ. Такое сочетание системного ландшафта и организационной экосистемы зачастую настолько сложно, что его устойчивость нельзя гарантировать. Предпочтительной стратегией в этом случае является стремление к обеспечению устойчивости посредством сочетания технических и организационных мер. Ситуация, когда все находится в постоянном движении, требует постоянных экспериментов и изучения, это совершенно необходимо для последующего адекватного реагирования. DevOps — часть такого решения. Но здесь никогда не будет однажды созданного или возникшего состояния, которое в дальнейшем останется неизменным. Так что, если вы думаете, что нашли такое состояние, «убейте» его и продолжайте экспериментировать. Единственное желательное устойчивое состояние — это постоянно развивающееся состояние ума.