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

Глава 16. Наведение мостов между культурами с помощью четырех столпов devops
361
Мне повезло работать в компании, которая с энтузиазмом внедряет ценности devops в повседневные рабочие процессы, не прибегая к громким словам и пре- зентациям. Мы практикуем разбор инцидентов без поиска виноватых, назначаем инженеров по надежности в команды разработки и по возможности обеспе- чиваем прозрачность. Например, наша инженерная организация управляется с помощью централизованной базы данных процессов, вклад в которую может сделать любой инженер. Все изменения в процессах отображаются в ежемесяч- ных рассылках.
Я знаю, что могу обсудить свой текущий проект с любым инженером из моей организации и найду людей, которые мне сочувствуют и готовы помочь при выполнении проекта. Поскольку каждая команда разработчиков участвует в де- журствах, мы все говорим практически на одном языке и поддерживаем успехи и неудачи друг друга. По сути, мы стремимся к приобретению универсальных навыков, когда разработчики могут устранять неполадки в Linux, а инженеры по надежности — создавать системные инструменты и веб-приложения.
Конечно, это не идеальное решение. Когда кто-то звонит вам в 3 часа ночи из-за ошибки в чужом коде, вам хочется послать его куда подальше. Но наличие офи- циальных процессов гарантирует, что никто не будет обижен в порыве чувств.
При наличии культуры, в которой интерес поддерживается дисциплиной, люди остаются в команде надолго. Ценность сбалансированных команд состоит в со- здании возможностей для выявления и реализации молодых талантов.
Если все вышесказанное и есть суть devops, то все сотрудники должны действо- вать в подобном ключе.
Теория и практика devops
Одно дело — обсуждать, как что-то работает в теории, и совсем другое — реализо- вать это на практике. Любой сотрудник, внесший изменение в программный про- дукт, в определенный момент говорит себе (или коллегам): «В теории оно должно работать». При этом он будет не уверен, как внесенное изменение проявит себя в производственной среде.
У всех нас есть свое видение мира и представление о том, как все должно рабо- тать. Независимо от того, осознаем мы это или нет (а чаще всего не осознаем), эти модели управляют нашими мыслями и поведением в повседневной жизни.
Все это называется используемой теорией, или, другими словами, все это способы проявления на практике теорий или моделей мышления. Тем не менее на вопросы о нашем видении мира или о предположительном поведении в той или иной си- туации мы зачастую даем другие ответы. Наше предположительное или желаемое поведение, так называемые проповедуемые теории, не всегда совпадает с нашими фактическими действиями.
Как правило, люди не ставят целью обмануть себя, когда проповедуемые теории отличаются от используемых теорий. Человеку свойственно верить в то, что его

362
Часть VI. Объединение культур devops действия лучше и более позитивны. Но когда он сталкивается с чем-то, что про- исходит на самом деле, результаты его действий будут гораздо хуже, чем в теории.
И если в теории менеджер позволяет своим подчиненным самостоятельно выби- рать способы разрешения конфликтной ситуации, на практике он контролирует каждый их шаг на бессознательном уровне.
Практика на основе примеров из реальной жизни
На страницах этой книги приводятся примеры из реальной жизни, демонстри- рующие практическое применение разнообразных теорий в процессе внедрения devops. Одно дело рассказывать о безупречной среде и совсем другое — создать эту среду в реальности.
Посещая конференции или знакомясь с публикациями в блогах, обращайте внимание на то, как другие организации внедряют devops, и сравнивайте со своей компанией. В процессе сравнения может оказаться, что культуры других организаций ушли далеко вперед. Тем не менее не стоит из-за этого расстра- иваться, ведь проповедуемые ими теории могут существенно отличаться от используемых теорий.
Многих раздражает, когда одни и те же люди или представители организаций рассказывают о том, что они делают, или когда другие говорят о них как об «ав- торитетах отрасли». В этой ситуации остается только порадоваться за них, но реалии таковы, что многое из этого просто не будет работать в вашей организации.
Процесс внедрения изменений может протекать сложнее в организациях со спе- цифическими проблемами.
В культуру организации можно внести гораздо больше изменений, чем могут пред- ставить себе сотрудники этой организации. Разные компании и отрасли выдвига- ют различные требования и ограничения, поэтому не каждое желаемое изменение возможно внедрить. Если, например, необходимо поддержать совместимость со стандартом безопасности PCI, есть определенные изменения процесса, касающи- еся таких аспектов, как серверы, обрабатывающие данные банковских карт, кото- рые невозможно применить. Также есть ограничения, которым нужно следовать для поддержания совместимости. Тем не менее для большинства организаций это не исключает возможности получения значимых результатов в других областях деятельности.
Учимся на историях
Холизм — это теория о том, что части целого находятся во взаимодействии и что целое больше, чем сумма его частей. Эта теория применима и к четырем прин- ципам эффективных devops-практик: эффективность внедрения и продвижения devops-практик зависит от взаимодействия этих четырех принципов.

Глава 16. Наведение мостов между культурами с помощью четырех столпов devops
363
Благодаря историям можно узнать следующие моменты:

причину выбора тех или иных инструментов или технологий;

способы взаимодействия людей друг с другом и использования разных инструментов для достижения поставленных целей;

каким образом инструменты помогли (или не помогли) достичь целей, поставленных в реальности;

каким образом команды и организации работали над разными проблемами;

какие методы были наиболее действенными, и, что более важно, причины неэффективности методов.
В следующей главе рассматриваются различные формы знаний и обучения, ко- торые применяются в командах, группах или организациях, а также изменения, способствующие достижению близости и обучению.
Установление связи с историями
Помимо изучения взаимодействия между разными частями организации, важно еще разобраться, как мы связаны между собой как практикующие специалисты и как обычные люди. Нельзя отделять вопросы, связанные с программным обес- печением или технологиями, от их разработчиков и пользователей. Программные продукты создаются людьми и для людей, поэтому акцентирование внимания на технических аспектах и одновременное игнорирование межличностных отноше- ний свидетельствуют о недальновидности.
Истории способствуют налаживанию связей между людьми. Наши истории, изло- женные в главе 1, предоставляют читателям возможность связаться с нами для по- лучения более подробной информации о нас. Также читатели могут лучше понять нас, то, как мы прошли свой путь, и найти общее со своими историями. В процессе обмена историями мы общаемся друг с другом как реальные люди, а не безликая толпа, состоящая из логинов и мультяшных аватарок. Более того, мы начинаем взаимодействовать и проникаться чувствами друг друга.
Богатый опыт, извлеченный из этих историй, поможет читателям:

узнать о том, что разнообразный опыт других организаций влечет за собой разнообразие культур;

научиться задавать вопросы о соответствии организации, внедряющей devops-практики, ее собственным ожиданиям;

развить в себе чувство терпимости к точке зрения других людей;

изучить свой и чужой опыт, сравнивая различные точки зрения;

развить способность четко формулировать свои собственные убеждения и ценности.

364
Часть VI. Объединение культур devops
В следующих двух главах рассматриваются истории, которые способны повлиять на нас в личностном плане. Вы узнаете о том, какое воздействие они имеют на способы сотрудничества, а также что подразумевается под созданием здоровой и прочной организации, в которой могут процветать люди.
Выводы
Некоторых читателей, наверное, удивит тот факт, что в этой книге уделяется при- стальное внимание культурным факторам, а не техническим вопросам. Культура компании, определяемая ценностями, убеждениями, целями и практиками, разде- ляемыми ее сотрудниками, имеет большее влияние на внедрение devops-практик, чем инструменты или технологии.
Как уже упоминалось при формулировании devops-пакта, целью devops является выработка взаимопонимания и общих целей, позволяющих установить долговре- менные и прочные рабочие взаимоотношения между отдельными сотрудниками и командами. Подобно тому как сотрудник, хорошо владеющий основными ин- женерными концепциями, готов осваивать новые языки программирования, так и организации, имеющие четкое понимание культурных аспектов совместной работы, могут с легкостью адаптироваться к использованию различных инстру- ментов и технологий.
Чтобы выстроить отношения, необходимые для эффективного внедрения devops- практик, следует учиться друг у друга и поддерживать связи. Механизмы процес- сов обучения и взаимодействия хорошо описаны в разнообразных историях, пред- ставленных на форумах Usenet, рассказаны на первой конференции devopsdays, прошедшей в 2009 году, и изложены на страницах этой книги.

ГЛАВА 17
Объединение devops-культур:
обучение на основе историй
Истории являются важной частью учебного процесса как для рассказчиков, так и для слушателей. Учебный процесс можно рассматривать как освоение нового инструмента, изучение нового языка программирования либо совершенствование технических навыков. Не менее важен контекст, позволяющий ответить на вопро- сы о том, как и почему могут использоваться разные инструменты и технологии.
Истории представляют собой отличное средство распространения культурного контекста, связанного с применением инструментов в культурной среде. Напри- мер, инструмент Chaos Monkey от Netflix (http://techblog.netflix.com/2012/07/
chaos-monkey-released-into-wild.html) явно проверяет работоспособность производ- ственной среды при сбоях, вызывающих случайные отказы виртуальных серверов.
Истории, посвященные использованию инструментов Chaos в Netflix, освещают ценности организации, в том числе:

практику устранения проблем в рабочее время, а не ночью, когда все спят;

стандарт написания программ, допускающий ухудшение рабочих характе- ристик, но не сбои;

ожидание сбоя как еще одного режима работы программного обеспечения.
В этой главе будут рассмотрены различные аспекты культурного контекста, кото- рый явно или неявно демонстрирует ценности команды или организации. Будут представлены способы поощрения обучения между командами и даже организа- циями. Также будут рассмотрены методы внедрения подобного обучения в вашей собственной среде.
Что могут поведать истории о культуре
Как упоминалось в главе 1, большую часть культуры составляют ценности, нор- мы и знания, разделяемые группами людей. Но одно дело говорить о культуре,

366
Часть VI. Объединение культур devops а другое — увидеть и услышать, каким образом эта культура проявляется в еже- дневной работе.
В этом разделе рассматриваются пять ключевых аспектов культуры: ценности, запреты, мифы, ритуалы и идеи. Мы рассмотрим, каким образом эти аспекты учи- тываются в повседневной работе, а также предложим способы их внедрения в ва- шей собственной культуре. Один из подобных аспектов заключается в способах обучения других людей основам вашей культуры независимо от того, являются ли они новыми сотрудниками вашей организации или аудиторией, слушающей ваш доклад на конференции.
Важно иметь в виду, что культурные аспекты следует не только учитывать в рассказываемых вами историях, но и обращать на эти аспекты внимание при прослушивании историй и самообучении. Что вы можете узнать о культуре рассказчика в процессе неформального или формального прослушивания историй? Какие компоненты культуры являются неявными по отношению к заявляемым явно? Благодаря выбору наиболее ценных элементов культур- ного контекста вы сможете лучше учиться на основе историй, рассказанных другими людьми, а также лучше учить других людей.

Глава 17. Объединение devops-культур: обучение на основе историй
367
армии к сексуальным домогательствам со стороны командного состава. Дэвид от- метил, что одно дело — осудить подобное поведение, но если подобное поведение не влечет негативных последствий, оно становится общепринятым.
То же самое можно сказать о рабочих местах. Согласно Моррисону, ответствен- ность за выработку и укрепление стандартов поведения сотрудников ложится на плечи руководителей и людей, занимающих ответственные позиции в организа- ции. В результате ответственность за инциденты несут руководители всех рангов, имеющие власть и отвечающие за наказания и контроль за поведением, а не жерт- вы инцидентов.
Вышесказанное не означает, что в случае плохого поведения высказываться могут исключительно менеджеры или руководители. Как отмечалось в части III, пове- дения и связанные с ними последствия, реализуемые на уровне группы, являются наиболее эффективными для обеспечения взаимовыгодного стандарта поведения в целом. Это означает, что любой человек, способный безопасно устанавливать и укреплять ценности, должен этим заниматься. В результате предотвращаются ситуации, когда ответственность за плохое поведение сотрудников несут люди из недостаточно представленных или маргинальных групп. Как правило, эти люди обладают недостаточными полномочиями или поддержкой, чтобы нести ответст- венность подобного рода.
Еще один способ выражения ценностей заключается в отношении к разным коман- дам в организации. Как также упоминалось в части III, в стартапах обычно больше ценятся технические команды (особенно специализирующиеся в области раз- работки интернет-приложений и приложений для мобильных устройств), чем нетехнические команды. Обычно подобное отношение явно не декларируется, а проявляется косвенным образом. Как правило, инженеры получают возможность работать по гибкому графику либо удаленно. Они также получают большую зар- плату, больше возможностей для обучения и поездок, а также большее признание заслуг.
Различия между командными и организационными ценностями
В процессе перехода от общих ценностей организации на более детальный уровень может обнаружиться, что разным командам присущи свои ценности. Это может вызвать конфликты на уровне организации. Ранее мы уже упоминали о том, что различные ценности послужили причиной проблем, которые привели к заро- ждению движения devops. В качестве примеров различных ценностей, присущих инженерным командам, можно рассматривать быструю поставку и обеспечение стабильности сайта. Но на уровне команд и организаций следует учитывать не только порядок выполнения и оценки работы, но и другие ценности. В следующем списке приведены примеры таких ценностей.

«Двигайся быстро, ломай все» — движение вперед является наивысшей ценностью.