В своих попытках устранить ненадежный человеческий фактор разработчики автоматизированных систем управления невольно создали возможности для появления новых типов ошибок, которые могут быть более серьезными, чем те, которых они стремятся избежать.
По мере усложнения систем и распространения общих услуг автоматизация приобретает критическое значение. Но если при внедрении автоматизации не используется общий контент и не учитываются интересы персонала, появляется дополнительный риск. Несомненно, благодаря автоматизации ускоряется выполнение работы, но чтобы это выполнение стало более эффективным, нужно увеличить степень прозрачности, сотрудничества и понимания.
Методология devops вышла из моды
Подобно тому как методология devops не привязана жестко к используемой технологии, инструменту или процессу, нельзя сказать, что она устарела или нуждается в замене. Движение, направленное на повышение эффективности деятельности организации и создание хорошего настроения для каждого сотрудника, может стать привычным и незаметным, но вряд ли когда-либо устареет.
Одно из основных различий между devops и такими методологиями, как ITIL и гибкая разработка (Agile), заключается в том, что последние имеют строгие определения, им присущ постепенно добавляемый контент. С другой стороны, devops – это движение, основанное на историях и идеях, которыми делятся отдельные люди, команды и организации. Это движение выливается в повторяющиеся беседы, эволюцию процессов и идей, которые приводят к росту и изменениям организаций.
В сообществе пользователей devops имела место дискуссия о том, потеряла методология devops вектор развития или нет. Критики этого движения утверждают, что оно слишком сильно зависит от отрицательных факторов, что оно уже не то, чем было ранее. Они также утверждают, что devops не является уникальным, что это всего лишь ребрендинг идей, которые существовали ранее, и от devops откажутся, как только появятся новое имя или тренд.
Многие из идей, лежащих в основе движения devops, действительно витали в воздухе в течение некоторого времени и под разными названиями, но дух devops является чем-то большим, чем простая сумма составляющих частей. Конечно же, люди выступали против функциональной изоляции еще до появления devops, высказываясь в пользу самообучающихся организаций, в защиту человеческих ценностей и автоматизации.
Движение devops объединило эти идеи и смогло достичь значимого успеха (http://bit.ly/2015-state-of-devops). Обобщение и использование эффективных методик devops приведет к росту и эволюции инструментов, технологий и процессов в вашей организации.
В этом разделе будут определены некоторые дополнительные термины, которые помогут лучше осознать суть devops. Но в отличие от терминов, определенных в предыдущей главе, эти понятия, как правило, трактуются как антишаблоны, продвигающие идеи, которые идут вразрез с концепциями devops.
Культура, основанная на обвинениях
Культура, основанная на обвинениях (упречная культура), проявляет склонность к обвинениям и наказаниям людей, совершивших ошибку (как на индивидуальном, так и на организационном уровне). В рамках этой культуры анализ первопричин не включается в постмортем или ретроспективу, используемые для идентификации причины сбоя или инцидента. Если анализу подвергаются действия человека, служащего «первопричиной» инцидента, он будет обвинен, ему будет объявлен выговор или его даже уволят из-за неприглядной роли в происшедшем инциденте. Этот вид культуры часто имеет место там, где нужно давать ответы внешним аудиторам либо нужно повысить производительность в соответствии с запланированными показателями.
В сильно изолированных или сегментированных средах, в которых уделяют недостаточно внимания прозрачности, пышным цветом расцветает культура, основанная на обвинениях. Если менеджмент стремится обвинить сотрудника или группу людей в каждом происшедшем инциденте и избавиться от «гнилого яблока», отдельные сотрудники будут пытаться переложить вину на других сотрудников или посторонних лиц. Хотя стремление к самосохранению вполне объяснимо в подобной среде, оно несовместимо с культурой открытости и сотрудничества. Более чем вероятно, что в подобной ситуации люди начнут скрывать информацию о происшедших событиях, особенно возникших вследствие их собственных действий, чтобы попытаться избежать обвинений.
Если не рассматривать реагирование на инциденты, культура, основанная на обвинениях, в попытках повышения производительности сотрудников будет способствовать формированию атмосферы враждебности между коллегами, в которой каждый сотрудник будет пытаться избежать ответственности. Если люди только и думают о том, чтобы не подвергнуться наказанию, они в меньшей степени нацелены на обучение и сотрудничество.
Барьеры
С помощью модели барьера на уровне отдела или организации описывается менталитет команд, которые не делятся своими знаниями с другими командами внутри одной и той же организации. Вместо того чтобы иметь общие цели и обязанности, группы, находящиеся за барьерами, исполняют разные и сегрегированные роли. В сочетании с культурой, основанной на обвинениях, это может привести к накоплению секретной информации о порядке выполнения той или иной работы («Если я единственный, кто знает, как выполнить X, они не смогут меня уволить»). Подобная атмосфера может привести к затруднениям в работе или к затягиванию работы, выполняемой несколькими командами, а также к ухудшению морального климата, когда команды или люди, находящиеся за барьерами, начинают видеть друг в друге противников.
Зачастую в барьерной среде можно найти разные команды, применяющие совершенно разные инструменты или процессы для выполнения идентичных задач. В этой среде сотрудники используют несколько уровней управленческой цепочки команд для получения ресурсов или информации от членов другой группы и достаточно часто перекладывают ответственность на другую команду.
Для устранения проблем и решения вопросов, связанных с организационными барьерами, потребуются время, усилия и культурные изменения. Наличие отдельных барьеров для разработчиков программ, системных администраторов и инженеров из группы эксплуатации, а также предпринимаемые попытки исправления ошибок, допущенных при разработке программного обеспечения, привели к возникновению движения devops. Основная причина появления барьеров заключается не в тотальном разделении обязанностей, а в отсутствии общения и сотрудничества между командами. Именно эти проблемы способно устранить движение devops.
Анализ первопричин
Анализ первопричин (Root Cause Analysis; RCA) – это метод идентификации причин возникших событий либо опасных ситуаций и выработки комплекса мер, направленных на предотвращение рецидивов. Это повторяющийся процесс, который продолжается до тех пор, пока не будут идентифицированы все организационные факторы либо пока не будут исчерпаны все данные. Организационный фактор – это фактор, который осуществляет контроль над системой на любом этапе жизненного цикла: проектирование, разработка, тестирование, техническое обслуживание, эксплуатация и списание.
Один из методов идентификации первопричин известен под названием «5 почему». При использовании этого способа вопросы «почему» задаются до тех пор, пока не будут идентифицированы основные причины. При этом требуется, чтобы лица, отвечающие на вопрос «почему», располагали объемом информации, достаточным для ответа на вопрос должным образом. Второй, более систематический подход заключается в создании диаграммы Ишикавы. Разработанная в 1968 году Каору Ишикавой, эта причинно-следственная диаграмма помогает командам визуализировать и группировать первопричины в основные категории, чтобы идентифицировать причины изменчивости, выявлять взаимосвязи между источниками и обеспечивать понимание процесса.
Зачастую метод RCA применяется для идентификации единственной первопричины. Инструменты, которые поддерживают управление событиями, часто допускают единственное назначение ответственности. Это ограничивает степень полезности метода RCA, поскольку внимание акцентируется на непосредственных причинах, а дополнительные элементы упускаются из виду. В методе анализа первопричин имеет место неявное предположение, что сбой или успех системы происходит в соответствии с линейным законом, что некорректно в случае достаточно сложных систем.
Человеческие ошибки
При использовании метода анализа первопричин в качестве основной причины сбоя указывается человеческая ошибка. Зачастую за этим утверждением следует вывод, что другой человек не совершил бы подобной ошибки. Это типично для культур, основанных на обвинениях, когда кому-то нужно объявить выговор за роль в происшедшем инциденте. Опять же, это слишком упрощенное представление, используемое в качестве точки остановки при проведении расследования. Предполагается, что человеческие ошибки совершаются из-за простой небрежности, усталости или некомпетентности. При этом из виду упускаются мириады факторов, которые способствовали принятию решения либо выполнению действия.
В культуре, основанной на обвинениях, обсуждение завершается после того, как будет найден человек, совершивший ошибку. При этом упор делается на самой ошибке и ее последствиях. В безупречной культуре или в самообучающейся организации человеческая ошибка рассматривается в качестве отправной точки, а не завершающего этапа. Появление ошибки приводит к дискуссии о контексте, связанном с принятием ошибочного решения, и о его смысле в данной ситуации.
Знакомство с терминами, рассмотренными в главе, обеспечит вам углубленное понимание остального материала книги. Вооруженные основной терминологией и концепциями, рассмотренными в предыдущей главе, а также сведениями из главы 3, вы получите более четкое представление о современном состоянии devops. На основе этого представления можно определить и более подробно рассмотреть четыре столпа эффективных devops-методов, что и будет сделано в следующей главе.