Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf

Глава 5. Заблуждения и антишаблоны, относящиеся к devops
85
в другой среде. Принудительный «вброс»
1
процессов и инструментов в среду может привести к дополнительной изоляции и к появлению сопротивления изменениям.
В devops поощряется критическое мышление по отношению к процессам, ин- струментам и практикам. В самообучающейся организации требуется проведе- ние опросов и итеративный перебор процессов. При этом не принимаются на веру такие утверждения, как «единственно верный путь» либо «все уже было сделано до нас».
Не следует прислушиваться к людям, навязывающим свой способ внедрения devops. Нелишним будет повторить, что существует множество вариантов вне- дрения devops. Методология devops — это не набор жестко заданных правил, по- добно Scrum либо ITIL. Компании, которые наиболее успешно внедрили devops, добились этого путем создания комфортных условий для обучения и итеративного поиска наиболее эффективных инструментов и процессов.
Для внедрения devops нужно X недель/месяцев
Если для внедрения devops нужно согласие руководства, то обычно задается вопрос о том, сколько времени займет подобное преобразование. Дело в том, что многие считают, что состояние внедрения devops можно как-то оценить либо изме- рить. И как только это состояние будет достигнуто, работу по переходу на devops можно завершить.
В действительности же devops представляет собой непрерывный процесс, это пу- тешествие, а не конечная точка. Некоторые компоненты devops будут иметь фик- сированные конечные точки (например, настройка системы управления конфигу- рированием и управление всеми серверами компании с помощью этой системы), но текущее обслуживание, разработка ПО и использование системы управления конфигурированием — непрерывный процесс.
Поскольку движение devops является в большей степени культурным феноменом, затруднительно предсказать, сколько будут длиться некоторые из этих изменений, сколько потребуется времени людям, чтобы отказаться от привычки работать в оди- ночестве и получить навыки сотрудничества. Все это довольно сложно предугадать, но пусть это не остановит вас от реализации важнейших культурных преобразований.
Методология devops — это лишь инструменты
Методология devops не требует обязательного применения каких-либо конкрет- ных инструментов. Неверное представление об обязательности использования ин- струментов способствует формированию убежденности, что devops предназначен
1
Принудительный «вброс» (или карго-культ) описывает практику эмуляции наблюдаемых пове- дений или внедрения инструментов в среде без полного понимания причин или обстоятельств, которые ведут к успеху.

86
Часть I. Основы devops исключительно для стартапов, поскольку крупные компании зачастую не склонны внедрять новые технологии.
По своей природе devops является культурным движением. Инструменты, ис- пользуемые в определенной среде, также являются частью культуры. Прежде чем принять решение в пользу изменений, требуемых для внедрения devops-принци- пов, нужно идентифицировать инструменты, являющиеся частью существующей культуры, получить сведения об опыте использования этих инструментов отдель- ными сотрудниками, а также идентифицировать сходство и различие между этими инструментами. После получения этой информации вы сможете определиться с необходимыми изменениями.
Применяемые технологии влияют на скорость изменений и организационные структуры организации. Серьезные изменения, внесенные в набор используемых инструментов, могут привести к замедлению скорости развития организации в целом, особенно если эти инструменты представляют ценность для отдельных сотрудников или команды.
Принципы, рассматриваемые в книге, не требуют специального набора инстру- ментов и могут применяться к произвольному набору технологий. Существует довольно много общего между компаниями, которые практикуют devops, и ком- паниями, использующими контейнеры или провайдеров облачных услуг, но это вовсе не означает, что для внедрения devops нужны эти конкретные технологии.
Известны примеры компаний, которые успешно внедрили devops, не используя какие-либо инструменты. В части IV будут рассмотрены эффективные способы оценивания, выбора и внедрения инструментов.
Методология devops эквивалентна автоматизации
Благодаря совершенствованию инструментов, применяемых devops-командами, облегчается систематизация накопленной информации. Внедрение автоматизации позволяет улучшить взаимодействие между командами. Практические специа- листы делают упор на инструментах, устраняющих необходимость выполнения скучных повторяющихся задач. Примеры подобных инструментов — автоматиза- ция инфраструктуры и непрерывная интеграция. В этих случаях автоматизация является результатом применения улучшенной технологии.
Если для освобождения персонала от выполнения рутинной работы используется автоматизация, это приведет к росту эффективности труда. В некоторых случаях преимущества автоматизации очевидны. Например, создание автоматизированно- го сервера позволит системному администратору сэкономить драгоценное время, которое можно потратить на более интересную или интеллектуальную работу. Но если на внедрение автоматизации будет потрачено больше времени, чем сэконом- лено в результате этой же автоматизации, то вряд ли игра стоит свеч (рис. 5.1).
В свое время имели место многочисленные дискуссии о роли автоматизации в разных средах и о роли человеческого фактора в выборе типа автоматизации и способах ее внедрения. Эти дискуссии можно рассматривать в качестве примера

Глава 5. Заблуждения и антишаблоны, относящиеся к devops
87
Рис. 5.1. Карикатура на потраченное и сэкономленное время согласно представлению карикатуриста из XKCD (https://xkcd.com/ 1205); изначально была опубликована со следующим текстом: «Не забывайте о том, что на поиск диаграммы, которая позволит узнать, сколько вы сэкономите, тратится время. Также вы тратите время на чтение напоминания о потраченном времени. И тратите время на выяснение разных фактов. Помните о том, что вы тратите секунды вашей жизни на выполнение разных действий, и делаете это сейчас»
межотраслевой близости. Если даже автоматизация применяется в других областях промышленности, вы сможете перенять чужой опыт и творчески его переосмыслить.
РАННИЕ ПРИМЕРЫ АВТОМАТИЗАЦИИ В АВИАЦИИ
В 1977 году при рассмотрении состояния дел в американской авиапромышлен- ности Комитет палаты представителей по науке и технике пришел к выводам о том, что автоматизация кабины пилотов негативно влияет на авиационную безопасность. В результате проведенных исследований выяснилось, что автома- тизация кабины привела практически к полной атрофии критического мышле- ния пилотов. Они утратили способность к ориентированию в пространстве без использования карты, отображаемой на дисплее, не могут выбрать следующее действие либо распознать сбой прибора. Как видите, применение автоматизации способно изменить поведение и способ мышления.
В июле 2013 года рейс 214 компании Asiana Airlines врезался в дамбу в между- народном аэропорту Сан-Франциско. В результате этого авиационного про- исшествия получили смертельные травмы 3 человека. В ходе расследования этого инцидента, проводимого Национальным советом по безопасности на тран- спорте (National Transportation Safety Board, NTSB), был выявлен ряд причин,

88
Часть I. Основы devops способствующих катастрофе. Среди этих причин — недостаточный контроль ско- рости воздушного судна из-за чрезмерной зависимости от автоматизированных систем, показания которых не всегда корректно интерпретировались пилотами.
В своих попытках устранить ненадежный человеческий фактор разра- ботчики автоматизированных систем управления невольно создали воз- можности для появления новых типов ошибок, которые могут быть более серьезными, чем те, которых они стремятся избежать.
Джеймс Рисон, Managing the Risks of Organizational Accidents
По мере усложнения систем и распространения общих услуг автоматизация при- обретает критическое значение. Но если при внедрении автоматизации не исполь- зуется общий контент и не учитываются интересы персонала, появляется допол- нительный риск. Несомненно, благодаря автоматизации ускоряется выполнение работы, но чтобы это выполнение стало более эффективным, нужно увеличить степень прозрачности, сотрудничества и понимания.
Методология devops вышла из моды
Подобно тому как методология devops не привязана жестко к используемой техно- логии, инструменту или процессу, нельзя сказать, что она устарела или нуждается в замене. Движение, направленное на повышение эффективности деятельности организации и создание хорошего настроения для каждого сотрудника, может стать привычным и незаметным, но вряд ли когда-либо устареет.
Одно из основных различий между devops и такими методологиями, как ITIL и гиб- кая разработка (Agile), заключается в том, что последние имеют строгие определе- ния, им присущ постепенно добавляемый контент. С другой стороны, devops — это движение, основанное на историях и идеях, которыми делятся отдельные люди, команды и организации. Это движение выливается в повторяющиеся беседы, эво- люцию процессов и идей, которые приводят к росту и изменениям организаций.
В сообществе пользователей devops имела место дискуссия о том, потеряла мето- дология devops вектор развития или нет. Критики этого движения утверждают, что оно слишком сильно зависит от отрицательных факторов, что оно уже не то, чем было ранее. Они также утверждают, что devops не является уникальным, что это всего лишь ребрендинг идей, которые существовали ранее, и от devops откажутся, как только появятся новое имя или тренд.
Многие из идей, лежащих в основе движения devops, действительно витали в воз- духе в течение некоторого времени и под разными названиями, но дух devops является чем-то большим, чем простая сумма составляющих частей. Конечно же, люди выступали против функциональной изоляции еще до появления devops, высказываясь в пользу самообучающихся организаций, в защиту человеческих ценностей и автоматизации.

Глава 5. Заблуждения и антишаблоны, относящиеся к devops
89
Движение devops объединило эти идеи и смогло достичь значимого успеха (http://
bit.ly/2015-state-of-devops). Обобщение и использование эффективных методик devops приведет к росту и эволюции инструментов, технологий и процессов в ва- шей организации.
Антишаблоны devops
В этом разделе будут определены некоторые дополнительные термины, которые помогут лучше осознать суть devops. Но в отличие от терминов, определенных в предыдущей главе, эти понятия, как правило, трактуются как антишаблоны, продвигающие идеи, которые идут вразрез с концепциями devops.
Культура, основанная на обвинениях
Культура, основанная на обвинениях (упречная культура), проявляет склонность к обвинениям и наказаниям людей, совершивших ошибку (как на индивидуаль- ном, так и на организационном уровне). В рамках этой культуры анализ перво- причин не включается в постмортем или ретроспективу, используемые для иден- тификации причины сбоя или инцидента. Если анализу подвергаются действия человека, служащего «первопричиной» инцидента, он будет обвинен, ему будет объявлен выговор или его даже уволят из-за неприглядной роли в происшедшем инциденте. Этот вид культуры часто имеет место там, где нужно давать ответы внешним аудиторам либо нужно повысить производительность в соответствии с запланированными показателями.
В сильно изолированных или сегментированных средах, в которых уделяют недо- статочно внимания прозрачности, пышным цветом расцветает культура, основан- ная на обвинениях. Если менеджмент стремится обвинить сотрудника или группу людей в каждом происшедшем инциденте и избавиться от «гнилого яблока», отдельные сотрудники будут пытаться переложить вину на других сотрудников или посторонних лиц. Хотя стремление к самосохранению вполне объяснимо в подобной среде, оно несовместимо с культурой открытости и сотрудничества.
Более чем вероятно, что в подобной ситуации люди начнут скрывать информацию о происшедших событиях, особенно возникших вследствие их собственных дейст- вий, чтобы попытаться избежать обвинений.
Если не рассматривать реагирование на инциденты, культура, основанная на обвинениях, в попытках повышения производительности сотрудников будет спо- собствовать формированию атмосферы враждебности между коллегами, в которой каждый сотрудник будет пытаться избежать ответственности. Если люди только и думают о том, чтобы не подвергнуться наказанию, они в меньшей степени наце- лены на обучение и сотрудничество.

90
Часть I. Основы devops
Барьеры
С помощью модели барьера на уровне отдела или организации описывается мента- литет команд, которые не делятся своими знаниями с другими командами внутри одной и той же организации. Вместо того чтобы иметь общие цели и обязанности, группы, находящиеся за барьерами, исполняют разные и сегрегированные роли.
В сочетании с культурой, основанной на обвинениях, это может привести к на- коплению секретной информации о порядке выполнения той или иной работы
(«Если я единственный, кто знает, как выполнить X, они не смогут меня уволить»).
Подобная атмосфера может привести к затруднениям в работе или к затягиванию работы, выполняемой несколькими командами, а также к ухудшению морального климата, когда команды или люди, находящиеся за барьерами, начинают видеть друг в друге противников.
Зачастую в барьерной среде можно найти разные команды, применяющие совер- шенно разные инструменты или процессы для выполнения идентичных задач.
В этой среде сотрудники используют несколько уровней управленческой цепочки команд для получения ресурсов или информации от членов другой группы и до- статочно часто перекладывают ответственность на другую команду.
Для устранения проблем и решения вопросов, связанных с организационными ба- рьерами, потребуются время, усилия и культурные изменения. Наличие отдельных барьеров для разработчиков программ, системных администраторов и инженеров из группы эксплуатации, а также предпринимаемые попытки исправления оши- бок, допущенных при разработке программного обеспечения, привели к возникно- вению движения devops. Основная причина появления барьеров заключается не в тотальном разделении обязанностей, а в отсутствии общения и сотрудничества между командами. Именно эти проблемы способно устранить движение devops.
Анализ первопричин
Анализ первопричин (Root Cause Analysis; RCA) — это метод идентификации причин возникших событий либо опасных ситуаций и выработки комплекса мер, направленных на предотвращение рецидивов. Это повторяющийся процесс, который продолжается до тех пор, пока не будут идентифицированы все органи- зационные факторы либо пока не будут исчерпаны все данные. Организационный фактор — это фактор, который осуществляет контроль над системой на любом этапе жизненного цикла: проектирование, разработка, тестирование, техническое обслуживание, эксплуатация и списание.
Один из методов идентификации первопричин известен под названием «5 поче- му». При использовании этого способа вопросы «почему» задаются до тех пор, пока не будут идентифицированы основные причины. При этом требуется, чтобы лица, отвечающие на вопрос «почему», располагали объемом информации, доста- точным для ответа на вопрос должным образом. Второй, более систематический подход заключается в создании диаграммы Ишикавы. Разработанная в 1968 году