Культура DevOps

Рассуждая о внедрении DevOps (Development и Operations) в работу ИТ-подразделений, в первую очередь следует говорить о корпоративной культуре, требующей определенных видов практической деятельности, а также использования специфических инструментов. Культура DevOps формируется при взаимодействии ИТ-команд на пути к единой цели и основывается на свободном распространении информации между командами и подразделениями, а также использовании соответствующего пакета инструментальных средств [1]. Однако это не означает, что внедрение DevOps можно свести только к внедрению соответствующих инструментов — например, к системе контроля версий git для хранения конфигурационных файлов или системе Jenkins для автоматизированного тестирования. Само по себе использование тех или иных инструментов при сохранении традиционного противопоставления между разработкой и эксплуатацией не приводит к показателям, которые имеются в виду при упоминании DevOps (частота релизов, время внедрения изменений, среднее время восстановления после сбоя, доля успешных измнений).

Внедрение инструментов потребует внедрения соответствующих практик, а чтобы эти практики не превратились в бесполезные ритуалы, необходим должный культурный контекст — DevOps начинается не с внедрения инструментов, а с развития корпоративной культуры [2, 3].

Критерии DevOps

Невозможно двигаться к цели, если не удается оценить прогресс. По каким именно показателям следует судить об успехе внедрения культуры DevOps и об эффективности процессов эксплуатации ИТ-систем? Количественные критерии DevOps — это числовые показатели производительности процессов в ИТ-подразделениях и стабильности работы систем. Качественные — распространенность в работе коллектива тех или иных практик, которые используются высокоэффективными командами.

Частота релизов (deployment frequency). Такие практики, как непрерывная интеграция (continuous integration), управление конфигурацией (configuration management) и автоматизированное тестирование (automated testing), действительно позволяют часто выпускать релизы, что дает возможность быстрее получать обратную связь от пользователей, поддерживая Agile-методологии. Бизнес получает возможность мгновенно вносить изменения и проверять маркетинговые гипотезы сразу после появления идеи. Информационные потоки внутри компании ускоряются, ИТ-команды заранее получают информацию о сбоях и ошибках (благодаря непрерывной интеграции). Если можно выпускать релиз десятки раз в день, при этом сократив количество ошибок, ведущих к незапланированным простоям, то, скорее всего, вы на верном пути внедрения DevOps.

Время внедрения изменения (lead time for changes). Сколько времени должно уходить на реализацию бизнес-идеи и выпуск ее в виде изменения продукта? Насколько дорого обходится реализация и внедрение изменений, которые описывает одна строка кода? DevOps-практики позволяют свести время внедрения нового функционала к минимуму, сделав изменения дешевыми, а потому быстрыми и частыми.

Среднее время восстановления после сбоя (mean time to recover). Практика показывает, что количество сбоев не отражает реальной надежности систем — сбои были всегда и будут везде, где есть процессы изменения и такие ненадежные инструменты, как человек. Гораздо важнее то, как именно эти сбои влияют на бизнес-показатели. Согласно исследованиям, 80% времени восстановления после сбоя у компаний уходит на выявление изменения, приведшего к сбою, и лишь 20% — на его фактическое устранение. DevOps предлагает сократить время восстановления, ускорив поиск проблемных изменений за счет повышения доступности и актуальности информации об изменениях. Для DevOps важно не исключить сбои, а свести их влияние к минимуму. Именно поэтому важно измерять и фиксировать время восстановления после сбоя.

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

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

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

Внутренний контроль изменений. Изучение опыта передовых компаний показало, что производительность заметно страдает, если запрос на изменение требует внешнего согласования — любая внешняя экспертная оценка дороже внутреннего контроля (peer review). Очевидно, если контроль качества кода (а инфраструктура для DevOps — это тоже код) происходит внутри команды, то производительность будет расти. Исследователи заметили, что внешний контроль не только снижает производительность процессов, но и весьма незначительно отражается на количестве сбойных изменений (сhange fail rate), а на время восстановления после сбоя (mean time to recover) не влияет вовсе. Однако эффективный внутренний контроль невозможен без соответствующей корпоративной культуры, взаимного уважения и доверия.

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

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

Типы корпоративной культуры

В работе «A typology of organisational cultures» социолог Рон Веструм исследовал влияние корпоративной культуры на уровень безопасности в медицинских компаниях. Веструм предположил, что корпоративная культура напрямую влияет на степень безопасности и разделил компании на три типа в зависимости от того, как именно распространяется в них информация об угрозах. Поскольку для DevOps передача информации также является критичной, то можно рассмотреть эту типологию.

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

Три типа компаний

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

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

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

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

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

Очевидно, интенсификация информационных потоков сама по себе не является целью внедрения DevOps или других мер по развитию корпоративной культуры. Улучшение информационной прозрачности позволяет компаниям эффективнее достигать своих собственных целей. Такими целями могут стать, например, стабильность ИТ-системы или скорость ответа на запросы рынка.

Как внедрять?

Методология DevOps не говорит, что необходимо делать в конкретном случае, а лишь предлагает принять новые ценности, игнорируя старые подходы, тем не менее можно дать несколько советов руководителям [4, 5].

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

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

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

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

Внедрение инструментов. Развитие культуры предполагает постоянные эксперименты с новыми инструментами. Например, можно предложить заскучавшему разработчику изучить новый язык или фреймворк, даже если в данный момент в этом нет необходимости. Гораздо важнее понимать фундаментальные основы разработки ПО, чем иметь обширный опыт «собирания» систем из кубиков сторонних разработчиков. Повторение вузовского курса математической статистики может вывести на новый уровень понимание результатов работы системы мониторинга или анализ производительности приложения.

Вероятно, никому не нужно напоминать об автоматизации, но инструменты для непрерывной интеграции (continuous integration), управления конфигурацией (configuration management) и автоматизированного тестирования (automated testing) должны стать основными рабочими инструментами, с помощью которых должны быть автоматизированы наиболее проблемные, дорогие и важные для бизнеса операции.

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

Совершенствование системы мониторинга. Периодически слеует проверять, действительно ли собираются данные, которые требуются, и используются ли полученные данные по назначению. Отдача от продуманной системы мониторинга может стать основой для достижения ключевых показателей стабильности и производительности.

***

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

Литература

1. Леонид Черняк. Загадка DevOps // Открытые системы.СУБД. — 2014. — № 03. — С. 32–35. URL: http://www.osp.ru/os/2014/03/13040804 (дата обращения: 18.09.2014).
2. D. Scott. NSM: Often the Weakest Link in Business Availability. URL: https://www.gartner.com/doc/334197/nsm-weakest-link-business-availability (дата обращения: 01.09.2014).
3. R. Westrum. A typology of organisational cultures, Qual. Saf. Health Care 2004; 13; 22–27.
4. The 2014 State of DevOps Report by Puppet Labs, IT Revolution Press and ThoughtWorks. URL: http://puppetlabs.com/2014-DevOps-report (дата обращения: 05.08.2014).
5. Taylor, Jay R.; Allen, Julia H.; Hyatt, Glen L.; Kim, Gene H., Global Audit Technology Guide — Change and Patch Management Controls, 2005, — ISBN: 0-89413-574-0.

Святослав Верещак (sve@express42.com) — консультант, компания Express 42 (Москва).