Глава 5. Заблуждения и антишаблоны, относящиеся к devops
91
Каору Ишикавой, эта причинно-следственная диаграмма помогает командам ви- зуализировать и группировать первопричины в основные категории, чтобы иден- тифицировать причины изменчивости, выявлять взаимосвязи между источниками и обеспечивать понимание процесса.
Зачастую метод RCA применяется для идентификации единственной перво- причины. Инструменты, которые поддерживают управление событиями, часто допускают единственное назначение ответственности. Это ограничивает степень полезности метода RCA, поскольку внимание акцентируется на непосредствен- ных причинах, а дополнительные элементы упускаются из виду. В методе анализа первопричин имеет место неявное предположение, что сбой или успех системы происходит в соответствии с линейным законом, что некорректно в случае доста- точно сложных систем.
Человеческие ошибки
При использовании метода анализа первопричин в качестве основной причины сбоя указывается человеческая ошибка. Зачастую за этим утверждением следует вывод, что другой человек не совершил бы подобной ошибки. Это типично для культур, основанных на обвинениях, когда кому-то нужно объявить выговор за роль в происшедшем инциденте. Опять же, это слишком упрощенное представ- ление, используемое в качестве точки остановки при проведении расследования.
Предполагается, что человеческие ошибки совершаются из-за простой небрежно- сти, усталости или некомпетентности. При этом из виду упускаются мириады фак- торов, которые способствовали принятию решения либо выполнению действия.
В культуре, основанной на обвинениях, обсуждение завершается после того, как будет найден человек, совершивший ошибку. При этом упор делается на самой ошибке и ее последствиях. В безупречной культуре или в самообучающейся ор- ганизации человеческая ошибка рассматривается в качестве отправной точки, а не завершающего этапа. Появление ошибки приводит к дискуссии о контексте, связанном с принятием ошибочного решения, и о его смысле в данной ситуации.
Выводы
Знакомство с терминами, рассмотренными в главе, обеспечит вам углубленное понимание остального материала книги. Вооруженные основной терминологией и концепциями, рассмотренными в предыдущей главе, а также сведениями из гла- вы 3, вы получите более четкое представление о современном состоянии devops.
На основе этого представления можно определить и более подробно рассмотреть четыре столпа эффективных devops-методов, что и будет сделано в следующей главе.
1 2 3 4 5 6 7 8 9 10 ... 39
ГЛАВА 6Четыре столпа devopsПо мнению Патрика Дебуа, devops является чисто человеческой проблемой (
http://bit.ly/debois-devops-culture). Это означает, что в каждой организации фор- мируется собственная devops-культура, которая является уникальной для людей, принимающих в ней участие. Хотя и не существует универсального «единственно верного» способа внедрения devops во всех организациях, мы идентифицировали четыре общих компонента, с которыми придется иметь дело команде или органи- зации, выделяющей время и ресурсы на внедрение devops.Внедрение эффективных devops-методик зиждется на следующих четырех стол- пах:сотрудничество;близость;инструменты;масштабирование.Благодаря комбинации этих четырех факторов учитываются как культурные, так и технические аспекты вашей организации. Можно, конечно, начать изменения в организации, опираясь на один или два столпа, но лишь использование комби- нации всех четырех столпов позволит внедрить эффективные изменения в орга- низации на длительной основе.Не следует игнорировать первые два столпа, которые охватывают нормы и ценно- сти культур и межличностных взаимодействий, опираясь лишь на использование инструментов. Конечно, для проведения успешной devops-трансформации необ- ходимы эффективные инструменты, но только их недостаточно. Если бы можно было ограничиться одними инструментами, мы могли бы просто составить список успешных devops-практик и на этом успокоиться. Но на самом деле без разреше- ния межличностных и межгрупповых конфликтов, возникающих в организации, невозможно наладить устойчивые отношения, которые и приводят к формирова- нию devops-среды.
Глава 6. Четыре столпа devops
93
Сотрудничество
Сотрудничество — это процесс достижения поставленной цели с помощью взаимо- действия между несколькими людьми. Руководящим принципом движения devops стала кооперация между командами по разработке и эксплуатации программного обеспечения. Прежде чем организовать успешное взаимодействие между команда- ми, имеющими разные цели, нужно наладить групповую работу в одной команде.
Если в командах не налажена работа на индивидуальном и групповом уровне, вряд ли будет успешным взаимодействие между командами.
Близость
Помимо развития и поддержки отношений сотрудничества между отдельными людьми, группами и отделами внутри организации, важны прочные взаимоотно- шения в отрасли. Близость — это процесс формирования взаимоотношений между командами, способствующий свободе выбора разных целей или показателей при сохранении общих целей организации. При этом облегчается развитие эмпатии и обучение в разных группах. Близость может проявляться на уровне взаимоот- ношений между организациями, позволяя им делиться историями и учиться друг у друга. В результате создается коллективная база культурных и технических знаний.
Инструменты
Инструменты — это стимулятор изменений, реализуемых на основе текущей куль- туры и целей. Отнеситесь серьезно к выбору инструментов. Важно понимать, как правильно выбрать инструменты, как они воздействуют на существующие структу- ры, чтобы предотвратить появление скрытых проблем в командах и организациях.
Невозможность выявления проблем, связанных с ценностями, нормами и органи- зационной структурой, в случае отсутствия развития культуры ведет к формирова- нию условий для появления скрытых сбоев. Если выбранные инструменты (или их отсутствие) мешают работать отдельным сотрудникам, ваша инициатива по внедре- нию devops будет обречена на провал. И если цена налаживания сотрудничества и так высока, то отсутствие инвестиций в инструменты (либо, что еще хуже, инвести- ции в плохие инструменты) приведет к дальнейшему росту этой цены.
Масштабирование
Масштабирование концентрируется на процессах и движущих силах, которые должны использовать организации на протяжении всего жизненного цикла. По- мимо заметной роли масштабирования в процессе внедрения devops в больших
94
Часть I. Основы devops корпорациях, оно также позволяет управлять другими столпами эффективных devops-методик на уровне организаций. Это управление осуществляется по мере роста, достижения зрелости и даже сокращения организаций. Имеют место раз- ные соображения, как технические, так и культурные, связанные с организациями разного масштаба. В части V мы рассмотрим, каким образом применяются эти соображения в организациях, которые не попадают в категорию «типичных» devops-культур.
Выводы
Благодаря использованию четырех столпов эффективных devops-методик вы можете устранить культурные и технические проблемы, влияющие на разработку программного обеспечения. Эти столпы будут подробнее рассмотрены в каждой из следующих четырех частей книги. Примеры использования этих методик, позаим- ствованные из практики реального бизнеса, относятся к самым разным компани- ям — от веб-стартапов до крупных корпораций. Хотя и необязательно читать главы книги по порядку, но мы все же рекомендуем вам прочесть все главы книги. Это позволит вам осознать, каким образом гармоническое сочетание четырех столпов devops позволит devops-методологии стать по-настоящему эффективной.
Часть II
СОТРУДНИЧЕСТВО
ГЛАВА 7
Совместная работа
Формирование устойчивых и долговременных взаимоотношений является кри- тически важным для людей, проводящих долгие часы в совместной работе. Со- трудничество — это процесс получения определенных результатов с помощью взаимодействий, вклада и поддержки множества людей. Один из примеров со- трудничества, и далеко не единственный, — парное программирование. Суть этой методики, появившейся в рамках концепции гибкой разработки программного обеспечения, заключается в одновременной работе двух человек над одним фраг- ментом кода.
Еженедельные совещания
в компании Sparkle Corp
«Я действительно думаю, что у нас есть отличная возможность создать наш новый сервис по работе с отзывами на базе MongoDB. Я прочел отличное руководство по этой системе, где рассказывается, как можно быстро и легко разработать нужный нам компонент, не неся бремя административных расходов, как в случае с другими решениями», — сказал Джорди, разработчик внешних клиентских интерфейсов в компании Sparkle Corp.
Заразившись энтузиазмом Джорди, Дженераль прикинула потенциальные выгоды от включения MongoDB в стек инструментов Sparkle Corp. «У кого-нибудь есть какие-либо соображения или опасения по поводу MongoDB?» — обратилась она к группе разработчиков.
«В нашем стеке мы уже поддерживаем MySQL и связанные с ним компоненты.
Мы уже вложили достаточно много усилий в интеграцию MySQL. Использова- ние MongoDB приведет к дополнительным затратам на поддержку и техническое обслуживание. Может ли MongoDB дать нам что-то полезное, компенсирующее
Глава 7. Совместная работа
97
дополнительные затраты?» — спросила Элис, старший разработчик из компании
Sparkle Corp.
Разногласия подобного рода часто проявляются в команде. Каким образом сотруд- ники могут ухудшить или улучшить отношения в команде? Давайте углубимся в devops-пакт и изучим способы налаживания сотрудничества между коллегами.
Определение сотрудничества
Являясь одним из базовых столпов devops, сотрудничество относится к интен- циональным процессам и к общим целям отдельных сотрудников. Практические примеры сотрудничества приведены в следующем списке:
асинхронный анализ кода;
документирование;
выпуски обновлений и отчеты об ошибках;
демонстрация еженедельного прогресса;
регулярное обновление статуса;
парная работа.
Важно распознавать ценность и назначение разных форм сотрудничества.
Один вид коллективной работы выполняется совместно с другими сотрудни- ками. При этом каждый сотрудник несет ответственность за свою часть работы, которую он выполняет на пути к достижению общей цели. Другой тип коллек- тивной работы выполняется непрерывно, двумя или большим количеством сотрудников, которые работают вместе для достижения общей цели. Выбор формы сотрудничества зависит от характера работы и окружающего контента.
И помните о том, что зацикливание на единственном типе совместной работы подобно утверждению о том, что бег — это единственная форма физических упражнений.
В январе 2015 года Анита Вулли и ее коллеги представили результаты проведен- ного анализа деятельности команд в статье «Why Some Teams Are Smarter Than
Others» (http://www.nytimes.com/2015/01/18/opinion/sunday/why-some-teams-are-
smarter-than-others.html?_r=0), опубликованной в New York Times. В терминологии, предлагаемой Вулли, умные команды отличаются от прочих команд следующими характеристиками:
связь;
равное участие;
модель психического состояния человека.
98
Часть II. Сотрудничество
Другими словами, эффективное сотрудничество включает такие компоненты, как связь, равное участие и модель психического состояния человека (Theory of Mind;
ToM). Компонент ToM — это способность идентифицировать свою перспективу и признать факт, что другие сотрудники имеют иные перспективы в силу индиви- дуальных отличий. Осознание различий между людьми и влияние этих различий на потенциальную перспективу поможет расширить свою собственную модель ToM, сформировать взаимное понимание и помочь разрешить конфликты, что критически важно для devops-пакта. Все это поможет усилить коллективный разум команды.
Индивидуальные различия и навыки
Каждому из нас присущи собственные навыки и уникальный опыт, которые обу- словливают выбор и порядок выполнения работы. Благодаря уважительному отношению к индивидуальным различиям облегчается формирование взаимо- понимания и разрешение конфликтов способом, который критически важен для devops-пакта. Благодаря использованию разных команд вы выиграете в креатив- ности, скорости устранения проблем и производительности, но проиграете из-за повышенной вероятности возникновения краткосрочных межличностных кон- фликтов, возникающих как на персональном, так и на профессиональном уровне.
Профессиональные навыки
Профессиональные навыки либо опыт, полученный на предыдущей работе и применяемый на новом рабочем месте, могут быть самыми разными. И хотя нам кажется, что мы судим о человеке лишь по результатам текущей работы, на самом деле это не так. На наше мышление, наши взаимоотношения и наши усилия по налаживанию сотрудничества между коллегами большое влияние оказывает пре- дыдущий опыт работы.
Зависимость профессиональных навыков от размера компании
Причина различий между профессиональными навыками может заключаться в размере компаний, в которых работали раньше носители этих навыков. В мире стартапов предпочитают нанимать и работать с людьми, имеющими опыт работы в стартапах. Подобная практика имеет смысл на ранних стадиях стартапов. В этом случае проще достичь успеха, поскольку на ключевых должностях находятся люди, имеющие успешный опыт запуска стартапов. Но не следует относиться предвзято к людям с опытом работы в больших компаниях. Если человек имеет опыт работы в крупной корпорации, это вовсе не означает, что он будет плохо справляться со своими обязанностями в малой компании. Поэтому не относитесь к таким сотрудникам предвзято — далеко не каждый сотрудник крупной компании относится к категории «динозавров», не способных приспособиться к изменив- шимся условиям. Избегайте предвзятого отношения к людям и эйджизма.