Название книги в оригинале: Дэниелс Кэтрин. Философия DevOps. Искусство управления IT

A- A A+ Белый фон Книжный фон Черный фон

На главную » Дэниелс Кэтрин » Философия DevOps. Искусство управления IT.





Читать онлайн Философия DevOps. Искусство управления IT. Дэниелс Кэтрин.

Дженнифер Дэвис, Кэтрин Дэниелс

Философия DevOps. Искусство управления IT

 Сделать закладку на этом месте книги

Jennifer Davis

Katherine Daniels

Effective DevOps. Building a Culture of Collaboration, Affinity, and Tooling at Scale


© 2016 Jennifer Davis, Katherine Daniels

© Перевод на русский язык ООО Издательство «Питер», 2017

© Издание на русском языке, оформление ООО Издательство «Питер», 2017

© Серия «Бестселлеры O’Reilly», 2017


* * *

Вступительное слово

 Сделать закладку на этом месте книги



Иван Евтухович


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




Александр Титов


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




Никита Борзых


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

Наша компания с первых дней своего существования является проводником методологии DevOps. И конечно, мы очень рады, что книга «Философия DevOps» теперь доступна и на русском языке.

Ищите новые подходы, становитесь более гибкими, быстрыми и эффективными! Делитесь своими открытиями, используйте мировой опыт и участвуйте в развитии профессионального DevOps-сообщества России – DevOpsRU.com.


Иван Евтухович 

Александр Титов 

Никита Борзых 

Управляющие партнеры «Express 42» 

https://express42.com/ 

+7 495 088 42 84 

Вступительное слово Джона Оллспоу

 Сделать закладку на этом месте книги

В настоящее время мы являемся свидетелями качественных изменений в подходах к разработке программного обеспечения. Эти фундаментальные изменения затрагивают все, что связано с проектированием, разработкой и использованием программ. Практически все успешные компании осознали, что программное обеспечение – это не просто код, который можно разрабатывать и запускать на выполнение. На самом деле любая программа – это некий объект, с которым осуществляется взаимодействие.

Новый подход к разработке программного обеспечения является более универсальным, целостным и лучше отражает действительность, с которой ежедневно сталкиваются команды разработчиков ПО. Давно ушли в прошлое те времена, когда для описания разработки и поддержки программ применялись производственные метафоры. Когда-то считалось, что программы, как и любые другие товары, проектировались, планировались и, наконец, запускались в производство. Теперь же слово «наконец» к описанию процесса разработки ПО не применяется. Этот процесс представляет собой бесконечный цикл адаптации, изменения и обучения.

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

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

В 2009 году на конференции Velocity 09, проводимой издательством О'Reilly, я и мой друг Пол Хэммонд представили презентацию «10+ Deploys a Day: Dev and Ops Cooperation at Flickr». Несмотря на то что часть материала презентации была посвящена вопросам непрерывного развертывания, многие зрители обращали больше внимания на часть «10+ развертывание», а не на часть «Сотрудничество». Я считаю, что было бы ошибкой полагать, что технологии или «железо» нужно рассматривать отдельно от социального или культурного «софта». Эти компоненты неразрывно связаны и в одинаковой степени важны для достижения успеха. Другими словами, люди, процессы и программное обеспечение связаны между собой гораздо сильнее, чем принято думать.

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

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

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


Джон Оллспоу, технический директор, Etsy, Бруклин, Нью-Йорк 

Вступительное слово Николь Форсгрен

 Сделать закладку на этом месте книги

В 2003 году Николас Карр в своей работе «IT Doesn’t Matter» заявил о том, что информационные технологии не являются стратегически важными для бизнеса. И поскольку эта статья была опубликована в журнале Harvard Business Review , она получила признание в корпоративной среде. Но с тех пор много воды утекло. Начиная с 2009 года наиболее инновационные команды и компании продемонстрировали, что технологии могут играть ключевую роль в создании реальной стоимости и обеспечении конкурентного преимущества. Эта технологическая революция получила название DevOps. После прочтения книги вы узнаете о том, как влиться в ряды инновационных компаний и начать создавать стоимость с помощью технологий.

Авторы книги являются известными экспертами в сообществе пользователей DevOps и имеют большой опыт работы в инновационных компаниях. Они знают, что именно нужно предпринять, чтобы сделать подход DevOps (или, как его называют авторы, «devops») действительно эффективным. Авторы книги делятся с читателями уникальными знаниями и опытом. И поскольку эти знания и опыт получены при работе с разными компаниями и отраслями, они будут полезны любому читателю. И независимо от занимаемой вами должности или величины вашей компании эта книга поможет вам добиться успеха.

Советы и рекомендации, изложенные в книге, коррелируют с моим опытом работы, полученным за последние десять лет. Как известный специалист в этой области и как ведущий исследователь State of DevOps Reports , я знаю, что ключевым компонентом любой трансформации в направлении DevOps является сильная организационная культура. Она служит фактором, задающим переход от традиционной ИТ-структуры к DevOps, а также ставит во главу угла информационный поток. На основе данных, предоставленных более чем 20 тысячами профессионалов в области DevOps, можно прийти к выводу о том, что сильная организационная культура способствует продвижению ИТ-организации и росту ее производительности в целом. Лучшим ИТ-организациям присуща удвоенная производительность, большая рентабельность и доля рынка по сравнению с конкурентами. И вовсе не случайно книга начинается дискуссией, посвященной аспектам культуры, общения и доверия. Значительная часть книги посвящена обоснованию важности вклада этих факторов в процесс трансформации в сторону DevOps. Нам, как технарям, нравится начинать с использования инструментов и, возможно, даже процессов. Но время от времени практика показывает, что культура, наравне с упомянутыми ранее ИТ и производительностью организации, имеет большое значение для успешного применения инструментов и технологий. Обязательно прочитайте части II–III, посвященные сотрудничеству и близости соответственно, независимо от того, начинаете ли вы трансформацию DevOps и хотите знать, что нужно реализовывать и что требуется отслеживать, или же вы поднимаете существующую практику DevOps на новый уровень и ищете способы оптимизации и устранения проблем.

Работая консультантом в наиболее инновационных компаниях, я пришла к выводу о том, что наиболее трудная часть реализации и составления предварительного плана технологической трансформации DevOps заключается в невозможности дать однозначный ответ, который подходил бы для всех ситуаций. Все зависит от того, что именно считается корректным для вашей команды и вашей организации. Поэтому мне нравится, что именно эта мысль постоянно подчеркивается в книге. Не существует единственного простого решения всех проблем. Чтобы внедрить собственное решение DevOps и добиться успеха, нужно использовать подходящие инструменты и компоненты. Помимо частей II–III обязательно обратитесь к части IV, в которой описаны инструменты, необходимые для выполнения произвольной трансформации DevOps. Особенно мне нравится, что при описании инструментов идет речь не только о технологических аспектах, но и о ключевых компонентах культуры, в рамках которой эти инструменты используются.

Одна из наиболее приятных особенностей книги заключается в ее доступности для разной аудитории. Часть V, посвященная масштабируемости, особенно полезна для рядовых участников и руководителей команд. Я использую материал, изложенный в этой части, в качестве справочника для себя и своих клиентов. Главы 4 и 11, включающие описание терминологии и обзор экосистемы, соответственно будут полезными как для технарей (в качестве терминологической базы), так и для руководителей, нуждающихся в актуальном справочном пособии. Эта книга является позитивным и полезным введением в DevOps, включающим сведения, которые отсутствуют в университетских учебниках. Я была бы просто счастлива, если бы в свое время могла использовать подобное пособие в своей преподавательской деятельности.

Мы живем и работаем в поистине удивительные времена, когда интеграция технологий в бизнес привела к превращению каждой фирмы в софтверную компанию. Благодаря современным технологиям потребители могут использовать новые способы получения доступа к требуемым средствам, причем этот доступ осуществляется с невиданной ранее скоростью. Компаниям приходится прилагать максимум усилий, чтобы не отставать от конкурентов. На основе своего опыта работы с компаниями, внедрявшими DevOps, я пришла к выводу, что прежние методы (итеративная и каскадная модели) не позволяют поддерживать необходимую скорость обмена данными в организации. Авторы книги рассматривают проблемы технологической трансформации, выполняемой с помощью устаревших способов, и захватывающие возможности, открывающиеся в результате внедрения DevOps. Читайте книгу и выбирайте собственный путь! Повторяйте, учитесь, растите и выбирайте свой путь перехода к DevOps!


Николь Форсгрен, доктор философии, директор компании Chef Software, Сиэтл, Вашингтон 

Предисловие

 Сделать закладку на этом месте книги

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

Столкнувшись с подобными проблемами, менеджмент организации принимает решение о devops-трансформации. Для реализации этого решения нанимается несколько сотрудников, формирующих новую devops-группу. Члены этой группы исполняют обязанности по вызову, то есть к ним обращаются члены эксплуатационной группы в случае возникновения неразрешимых проблем. Члены devops-группы являются экспертами в своей предметной области и лучше подготовлены к решению проблем. Но если у членов эксплуатационной группы нет ни времени, ни возможностей для получения новых навыков, одни и те же проблемы будут возникать снова и снова.

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

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


Первое знакомство с devops

В чем причина появления проблем в описанной ситуации? Вроде бы внедрение «devops» являлось хорошей идеей, но создание devops-группы привело к негативным последствиям. Что нужно изменить, чтобы добиться значительного улучшения ситуации и реального устранения проблем? На протяжении всей книги вы увидите, как можно выполнить эффективные преобразования на основании devops-мышления.

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

Результативность является следствием того, что «делаются нужные, правильные вещи». А эффективность является следствием того, что «правильно создаются эти самые вещи».

– Питер Ф. Друкер

Эффективность определяется как способность делать правильные вещи и достигать желаемых результатов. Чтобы делать правильные вещи, нужно осознать поставленные задачи и выявить связь между конкретными краткосрочными целями и поставленными задачами.

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

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


КАК ПРАВИЛЬНО ПИСАТЬ СЛОВО «DEVOPS»?

У нас были жаркие споры по поводу использования заглавных букв при написании термина «devops». В результате проведения простого интерактивного опроса выяснилось, что подавляющее большинство пользователей выбрали написание «DevOps». Пользователи также поддерживают написание терминов «Dev» и «Ops», используемое для обозначения групп в составе организации. На основе этих терминов создаются производные термины, такие как «DevSecOps» и «DevQAOps», тогда как термин «DevOps» подразумевает исключительное использование терминов «Dev» и «Ops».

В итоге мы выбрали написание «devops», поскольку оно соответствует оригинальному хэштегу в Твиттере, используемому для объединения людей, которые хотят изменить слоган «мы против них» на «делаем бизнес» с применением устойчивых рабочих практик, ориентированных на людей.

Успешные проекты требуют вклада, усилий, понимания и сотрудничества со стороны сотрудников организации. Проблемы, возникающие в организации, могут быть присущи не только разработчикам или группам поддержки. Мы сознательно решили использовать запись термина с помощью символов в нижнем регистре «devops» по всей книге. Это отражает нашу точку зрения, которая заключается в том, что devops является инклюзивным движением, а не эксклюзивной единицей.


Для кого предназначена книга

Эта книга в первую очередь предназначена для менеджеров и рядовых сотрудников, которые исполняют роли лидеров и сталкиваются с проблемами в своих организациях. Благодаря этой книге они смогут предпринять конкретные реальные действия, направленные на реализацию или улучшение devops-культуры в рабочей среде. Рядовые сотрудники, занимающие различные должности, найдут здесь практические предложения, позволяющие ослабить болевые точки благодаря выполнению действенных рекомендаций.

Читатели этой книги исполняют разные профессиональные роли, поскольку devops является профессиональным и культурным движением, ориентированным на поддержку повторяющихся усилий, направленных на открытие доступа к организационной информации, отслеживание отношений и устранение недопонимания, возникающего между группами в организации.

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

Мы рекомендуем вам отказаться от жестко заданных и быстро сформулированных определений и настроиться на восприятие принципов devops, которые, по нашему мнению, являются наиболее эффективными.

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


Структура книги

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

Эта книга состоит из нескольких частей. В части I рассматривается общая картина, которая детализируется до уровня идей, определений и принципов, имеющих отношение к devops. В частях II–V рассматриваются четыре фундаментальные концепции, лежащие в основе эффективного внедрения devops. В части VI завершается дискуссия, посвященная построению связей между отдельными людьми, группами и организациями.

• Часть I. «Основы devops».

• Часть II. «Сотрудничество».

• Часть III. «Близость».

• Часть IV. «Инструменты».

• Часть V. «Масштабирование».

• Часть VI. «Объединение культур devops».

Части II–V завершаются главой, в которой обсуждаются различные заблуждения, относящиеся к той или иной концепции, лежащей в основе внедрения devops. В этой главе также рассматриваются некоторые универсальные сценарии по устранению неполадок, относящиеся к данной теме. Читатели, занимающиеся внедрением devops в своих организациях, в главе «Заблуждения и устранение проблем» найдут также ряд практических советов, которые будут полезными в работе.

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

Читайте главы книги в наиболее удобном для себя порядке, действуйте в стиле «выбор своего собственного приключения». Концепции, заложенные в основу devops, переплетаются и тесно связаны между собой, поэтому при чтении книги вы будете неоднократно возвращаться к ранее прочитанному материалу, чтобы освежить в памяти ту или иную концепцию.


Методология практик

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

Также вниманию читателей представляется комбинация более формальных практик, неформальных историй и нашего личного опыта. Все это делается в целях демонстрации разнообразия способов, посредством которых devops может оказать влияние на принятие решений и нарративы.

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


Соглашения, используемые в книге

В книге приняты следующие типографские соглашения:


Курсив 

Используется для обозначения новых терминов, адресов URL, адресов электронной почты, имен файлов и расширений.


Моноширинный шрифт

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


Моноширинный полужирный шрифт

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


Моноширинный наклонный шрифт 

Обозначает текст, который должен замещаться фактическими значениями, вводимыми пользователем или определяемыми из контекста.


Использование примеров кода

У книги есть сайт, где можно найти список опечаток, дополнительные истории и другой сопутствующий материал. Все это доступно по следующему адресу: https://effectivedevops.net .

Эта книга призвана помочь вам в решении задач. По большей части вы можете использовать код из книги в своих программах и документации. Вам не нужно связываться с нами по поводу получения разрешения на это, если только вы не начнете копировать достаточно существенные фрагменты кода. Например, написание программы, в которой используется несколько фрагментов кода из этой книги, не требует разрешения. А вот продажа или распространение компакт-дисков с примерами из книг издательства O’Reilly требует разрешения. Ответы на вопросы с использованием цитат из этой книги и приведением примеров не требуют получения разрешения. А вставка существенных объемов кода примеров из этой книги в документацию потребует разрешения.

Мы приветствуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание названия, автора, издательства и ISBN. Например: «Философия DevOps. Искусство управления ИТ», Дженнифер Дэвис и Кэтрин Дэниелс (O’Reilly), 978–1-491–92630-7».

За получением разрешения на использование значительных объемов программного кода примеров из этой книги обращайтесь по адресу [email protected] .


Safari® Books Online

Safari Books Online  – это виртуальная библиотека, содержащая авторитетную информацию в виде книг и видеоматериалов, созданных ведущими специалистами в области технологий и бизнеса.

Профессионалы в области технологий, разработчики программного обеспечения, веб-дизайнеры, а также бизнесмены и творческие работники используют Safari Books Online как основной источник информации для проведения исследований, решения проблем, обучения и подготовки к сертификационным испытаниям.

Библиотека Safari Books Online предлагает широкий выбор продуктов и тарифов для организаций, правительственных и учебных учреждений, а также физических лиц.

Подписчики имеют доступ к поисковой базе данных, содержащей информацию о тысячах книг, видеоматериалов и рукописей от таких издателей, как O’Reilly Media, Prentice Hall Professional, Addison-Wesly Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, и сотен других. За подробной информацией о Safari Books Online обращайтесь по адресу: https://www.safaribooksonline.com/ .


Благодарности

Написание книги Философия DevOps. Искусство управления ИТ  было бы невозможным без помощи и содействия со стороны многих друзей, коллег и членов семьи. Мы хотели бы выразить благодарность всей команде издательства О’Reilly, особенно Кортни Нэшу (Courtney Nash), который всячески стимулировал нас на написание книги. Мы благодарны нашему редактору, Брайану Андерсону (Brian Anderson), оказавшему нам безусловную поддержку. Мы также благодарны сотрудникам издательства, которые помогли выбрать тотемных животных для книги и которые благословили нас на использование изображения волосатого яка в качестве символа книги. Мы также благодарны всем тем, кто помог нам написать эту книгу. Мы также признательны Джону Оллспоу (John Allspaw), Ларе Хоган (Lara Hogan) и Джону Кови (Jon Cowie) из Etsy; Николь Форсгрен (Nicole Forsgren) и Ивонн Лам (Yvonne Lam) из Chef; Бриджит Кромхаут (Bridget Kromhout) из Pivotal; Тому Лимончелли (Tom Limoncelli) из Stack Exchange за помощь, поддержку и вдохновение.

Спасибо участникам наших тематических исследований: Алексу Ноберту (Alex Nobert), Бриджит Кромхаут (Bridget Kromhout), Тиму Гроссу (Tim Gross,) Тине Донбек (Tina Donbeck) и Федре Маршалл (Phaedra Marsha


убрать рекламу







ll).

Спасибо всем, кто поделился своими историями, в том числе Давиде Марион (Davida Marion), Линде Лаубенхаймер (Linda Laubenheimer), Холли Кей (Hollie Kay), Николь Джонсон (Nicole Johnson) и Элис Голдфасс (Alice Goldfuss).

Спасибо нашим техническим рецензентам, которые помогли довести текст книги до совершенства: Элис Голдфасс (Alice Goldfuss), Дастину Коллинзу (Dustin Collins), Эрнсту Мюллеру (Ernest Mueller), Мэтью Скэлтону (Matthew Skelton), Оливье Жаку (Olivier Jacques), Бриджит Кромхаут (Bridget Kromhout), Ивонн Лам (Yvonne Lam) и Питеру Нилону (Peter Nealon).

Спасибо Энди Парофф за Эда, нашего великолепного яка, изображение которого красуется на сайте и на обложке.


Благодарности от Кэтрин

Спасибо руководству Etsy за предоставленную мне возможность работать над книгой, выступать на множестве конференций и за великолепное место для работы. Дополнительные благодарности хочу выразить команде веб-поддержки за помощь и проявленное во время осуществления проекта терпение. Благодаря работе с вами я никогда не забывала о том, за что я люблю эту работу. Я хочу выразить особую благодарность Майку Римбетси (Mike Rembetsy), который ни разу мне не сказал «нет» в ответ на мои вопросы, Джону Оллспоу (John Allspaw) за вдохновение и веру в мои силы, а также Лори Диннесс (Laurie Denness) и Джону Кови (Jon Cowie) за предоставленную поддержку и информацию, которые помогли мне повысить квалификацию как инженеру службы поддержки.

Спасибо Лоре Хоган (Lara Hogan), Бриджит Кромхаут (Bridget Kromhout), Хэйт Хьюстон (Cate Huston) и Меллисе Сантос (Melissa Santos) за то, что они отличные друзья, великолепные ролевые модели и просто веселые девушки. Благодаря знакомству и беседам с вами я черпала силы даже в безнадежных ситуациях. Ваша поддержка просто бесценна.

Спасибо Джеймсу Тернбуллу (James Turnbull) за общение в Твиттере все эти годы, благодаря которому я попала в сообщество профессионалов в области технической поддержки. Я ценю знакомство с вами, вашу поддержку, мудрость и вдохновение на писательский труд.

Спасибо Джейсону Диксону (Jason Dixon) за высланное мне первое приглашение на конференцию. Он был убежден, что мне есть что сказать на конференции, хотя я тогда совсем не была уверена в этом.

Спасибо сообществу профессионалов в области техподдержки и devops-сообществу в целом, и особенно сообществу профессионалов в области техподдержки из Нью-Йорка за предоставленную помощь, новые возможности и друзей, вместе с которыми можно наслаждаться великолепным пивом Sysdrink.

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

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


Благодарности от Дженнифер

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

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

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

Спасибо Ивонн Лам (Yvonne Lam), Бриджит Кромхаут (Bridget Kromhout), Доминике Де Грандис (Dominica DeGrandis), Мэри Грейс Ченгволл (Mary Grace Thengvall), Эми Скаварда (Amye Scavarda), Николь Форсгрен (Nicole Forsgren) и Шери Элджин (Sheri Elgin) за проявление поистине бесценных дружеских чувств. Ваше мнение и поддержка помогли мне многое понять и выработать свою собственную точку зрения на разные вещи. Благодаря вашей помощи я стала активнее и сильнее.

Спасибо Кэтрин Дэниелс (Katherine Daniels), моей подруге и соавтору, за вдумчивые и вдохновляющие часы, проведенные в размышлениях. Она постоянно вдохновляла меня на писательский труд и редактирование ранее написанного текста. Мы прошли вместе все этапы этого проекта, иллюстрируя на практике мысли по поводу devops. Для меня было большой честью работать с тобой над книгой, посвященной devops.

Спасибо моей бабушке, учителю начальной школы Frances Wadsworth Hayes, которая вдохновляла меня делиться своими историями и учиться на протяжении всей жизни. Эта книга никогда бы не появилась на свет, если бы не любовь и поддержка моей семьи, Брайана Бреннана и Джорджа.


От издательства

Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты [email protected]  (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

Подробную информацию о наших книгах вы найдете на веб-сайте издательства: https://www.piter.com .

Часть I. Основы devops

 Сделать закладку на этом месте книги

Глава 1. Первое знакомство

 Сделать закладку на этом месте книги

По сути devops – это способ мышления и работы. Это своего рода каркас, служащий для того, чтобы делиться историями и развивать эмпатию. Благодаря devops отдельные люди и группы могут эффективно и непрерывно развивать свои навыки. Это часть культурной «ткани», которая формирует способы выполнения работы, а также создает мотивацию для этой работы. Многие представляют devops как некий набор специфических инструментов, таких как Chef или Docker, но на самом деле devops не ограничивается ими. Инструменты превращаются в «devops» благодаря способу их применения, а не в силу характеристик самих инструментов.

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

Обратите внимание, что devops – это не просто еще одна методология разработки ПО. Несмотря на то что devops связан и даже в какой-то мере зависит от таких методик разработки ПО, как Agile или XP, а devops-практики могут включать способы разработки или такие средства, как автоматизация инфраструктуры или непрерывная доставка, на самом деле devops – это нечто большее, чем просто сумма составных компонентов. Хотя вышеупомянутые концепции связаны и часто реализуются в devops-средах, сосредоточение исключительно на них приведет к тому, что вы пропустите самое главное – культурные и межличностные аспекты, которые придают devops его мощь.


Культура развертывания ПО

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

Инженер, принятый на работу в Etsy, начинает свой первый рабочий день за ноутбуком, на котором установлена подготовленная виртуальная машина для ведения разработки. Для него уже созданы соответствующие учетные записи, позволяющие подключиться к этой машине и пройти авторизацию. Склонированы наиболее популярные репозитории GitHub, предварительно созданы системные ссылки и указатели для соответствующих инструментов. Также на рабочем столе новоиспеченного инженера имеется руководство, включающее ссылки на другие корпоративные ресурсы. Благодаря стандартизации инструментов и применяемых практик для различных групп облегчается подключение к процессу новых людей, независимо от того, в состав какой группы они входят. Каждая команда также может настроить применяемые инструменты и практики на свое усмотрение.

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

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

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

После прохождения внутренних и пробных тестов разработчик присоединяется к очереди магазинного типа Etsy, чтобы выполнить развертывание изменений в производственной среде. Если несколько разработчиков готовы развернуть изменения одновременно, для координирования развертывания изменений в системе управления очередью используется Internet Relay Chat (IRC) и IRC-бот. Как только подходит очередь Кэтрин, она подтверждает изменения в мастер-ветви репозитория, в которой она работает. Для развертывания изменений на сервере QA в Etsy используется среда Deployinator. Благодаря применению этой среды выполняется автоматическое создание QA-сервера и выполняется полный набор тестов CI.

После успешного завершения создания QA-сервера и прогона тестов Кэтрин выполняет быструю ручную проверку QA-версии сайта и журналов, чтобы идентифицировать проблемы, которые не были обнаружены в результате выполнения автоматизированных тестов. На этом этапе Кэтрин также использует среду Deployinator, чтобы развернуть код на производственной платформе и убедиться в отсутствии проблем с тестами и журналами. Если же в результате выполнения тестов проблемы не идентифицированы, выполняется дополнительная проверка с помощью одной из многочисленных графических панелей либо программы мониторинга Nagios. В случае обнаружения проблем с помощью этих средств пользователи получат соответствующее уведомление. Помимо этого, во многих группах выполняются собственные проверки, реализуемые в запланированном режиме с помощью Nagios. В результате обеспечивается слаженная работа всех членов группы. Если даже возникают какие-то проблемы, коллеги работают совместно над их устранением, учатся на своих ошибках, не обвиняя других постфактум в возникших проблемах.

Процесс развертывания кода настолько хорошо оптимизирован, что на его выполнение тратится около 10 минут в среднем (от начала до завершения), и инженерный персонал Etsy проделывает эту операцию до 60 раз в день. Благодаря наличию документации и наставничеству опытных сотрудников, объясняющих подробности процесса, начинающий инженер запускает код в производство за один день. Даже сотрудники, не относящиеся к инженерному персоналу, поощряются к участию в процессе в рамках программы First Push Program. Под руководством инженеров они развертывают небольшие изменения, такие как публикация фотографий на странице персонала веб-сайта. Помимо использования для регулярного развертывания ПО, процессы тестирования и Deployinator могут применяться для развертывания чего угодно – от инструментов, применяемых разработчиками для построения виртуальных машин, до панелей Kibana, применяемых для поиска журналов, от проверок программы мониторинга Nagios до самого процесса Deployinator.


Эволюция культуры развертывания ПО

История с компанией Etsy резко контрастирует с практикой, которая имела место еще несколько лет назад. В те времена применялся менее прозрачный и более подверженный ошибкам процесс развертывания, который занимал до четырех часов. Разработчики вместо виртуальных машин использовали физические блейд-серверы. Но эти серверы были недостаточно мощными для выполнения полного набора автоматизированных тестов. Для полного прогона тестов, выполняемого в рабочей среде, требовалась пара часов, и даже это не гарантировало хорошего результата.

Группы, сформированные в инженерной организации, были разрознены. Многие разработчики имели склонность «перебрасывать» код через «метафорические стены» эксплуатационной группе, которая несла исключительную ответственность за мониторинг и поддержку этого кода. В результате появлялась склонность к слишком частому изменению кода. Разработчики создавали код, вызывали на выполнение вручную написанные сценарии, чтобы создать новую SVN-ветвь. При этом развертывание выполнялось с помощью средства svn merge. Этот довольно сложный в применении инструмент применялся для слияния всех изменений, выполненных разработчиками, в одной ветви развертывания. Затем разработчики сообщали об используемой ветви инженеру из службы эксплуатации, наделенному полномочиями по выполнению развертывания ПО. Как видите, процесс развертывания был весьма кропотливым и занимал много часов (рис. 1.1). По причине сложности этот процесс выполнялся раз в две-три недели.

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

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




Рис. 1.1. До появления среды Deployinator процесс развертывания был сложным и полным ошибок




Рис. 1.2. После появления среды Deployinator пользователи получили доступ к простому веб-интерфейсу, доступному каждому


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

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

Чтобы создать необходимые инструменты и сформировать культуру их применения, общего доступа и сотрудничества, требуется вовлеченность со стороны менеджмента, свобода экспериментов, работа с кодом, невидимым для заказчиков, и доверие между разными группами разработчиков.

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


Истории пути к успеху

Все мы думаем на языке наших собственных мыслей. А делимся концепциями.

– Стивен Тулмин. Человеческое понимание

Эта книга включает тематические исследования и истории, рассказанные группами и отдельными людьми. Если же обратиться к существующим книгам, посвященным devops, то вы обнаружите, что в них описываются инструменты и абстрактные культурные практики, а историям из реальной жизни уделяется не столь много внимания. Одно дело говорить о том, как что-то должно работать, в теории, и совсем другое – реализовать это на практике. Мы хотим поделиться с вами историями применения теоретических знаний на практике, рассказать о том, что было сделано, а что не сделано, поделиться идеями, лежащими в основе принятия решений. Это позволит вам получить максимум информации, применяемой в процессе внедрения практик devops.


История Кэтрин

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

Некоторые организации более восприимчивы к изменениям и новым идеям, чем другие. Но помимо того, что мой стартап совершенно не подвергался изменениям, руководство не желало прислушиваться к высказываниям юного системного администратора. Чтобы не прислушиваться к моим идеям, мне просто говорили следующее: «Ты не настоящий системный администратор». И у них даже не было денег, чтобы купить мне пару книг. Мне пришлось самой купить книги Тома Лимончелли Practice of System and Network Administration  и Time Management for System Administrators . Я уже молчу о том, что мне не светило попасть на конференции LISA, Velocity и на devopsdays (Нью-Йорк) в ближайшие несколько лет.

К счастью, я начала искать devops-сообщества в Интернете и оказалась в состоянии общаться и учиться у людей, которые разделяли мою увлеченность вопросами эксплуатации. Благодаря совместной учебе и работе я просто воспряла духом. Джеймс Тернбулл, который в настоящее время является техническим директором компании Kickstarter, в то время работал в компании Puppet. Он нашел меня в Твиттере, завязал со мной разговор и отправил мне копию своей великолепной книги Pro Puppet . Это случилось в тот момент, когда я сражалась с 200 унаследованными серверами от компании Snowflake, не располагая даже простейшим bash-сценарием для управления этими серверами. Благодаря этой книге я познакомилась с растущим и процветающим сообществом людей, которые подарили мне надежду на то, что в один прекрасный день я смогу стать членом этого сообщества.

Как отмечает в своей истории Дженнифер, трудно добиться изменений, если вы уже «выгорели». Если уже прошел год в бесплодных попытках изменить и улучшить родную компанию, но меня никто не слушает в силу отсутствия опыта, хотя он растет каждый день. И я сделала выбор и пошла дальше. Я продолжала учиться и совершенствовать свои навыки, но все еще не чувствовала себя полностью сроднившейся с рабочим местом. Мне все казалось, что я сражаюсь со своими коллегами и организациями, вместо того чтобы работать с ними.

В январе 2013 года я попала на свою первую конференцию devopsdays (Нью-Йорк). Я впитывала как губка все разговоры и пыталась слушать как можно больше, даже если понимала, что вряд ли смогу что-либо добавить к сказанному. Я жила под воздействием хэштега #VelocityConf в Твиттере. В октябре того же года у меня было короткое выступление на второй конференции devopsdays (Нью-Йорк), на которой я встретилась с Майком Римбетси, одним из организаторов конференции. Он пригласил меня работать в Etsy, но я подумала, что он шутит, поскольку не считала себя профессионалом в этой области. Я следовала кодексу Code as Craft и придерживалась практики эксплуатационной группы Etsy в Интернете с тех пор, как открыла для себя devops-сообщества, но я не считала себя столь профессиональной, чтобы присоединиться к ним.

Когда я поняла, что ошибалась, меня просто переполнило счастье. Моя карьера в области эксплуатации началась как путешествие через несколько разных организационных структур и способов разработки, эксплуатации, а иногда даже через группы «devops», с которыми я работала. Располагая опытом работы с такими компаниями, как стартап, состоящий из 25 человек, и огромная корпорация, существующая десятки лет на рынке, с сотней тысяч сотрудников, я видела множество в разной степени эффективных способов разработки и поставки программных продуктов и систем.

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


История Дженнифер

В 2007 году я связалась с руководством Yahoo по поводу позиции, которая относилась «немного к разработке» и «немного к эксплуатации». Речь шла о вакансии старшего сервисного инженера, ответственного за создание и обслуживание мультиарендованного, размещенного на хосте, распределенного и географически реплицированного хранилища данных типа «ключ/значение» под названием Sherpa.

В качестве сервисного инженера в Yahoo я совершенствовала свои навыки в программировании, поддержке и в управлении проектами. Я работала вместе с группами по разработке и обеспечению качества Sherpa, координировала усилия с командами центров обработки данных, группами по поддержке сетей и хранилищ данных, а также группами обеспечения безопасности. В 2009 году, когда слухи о devops проникли в Yahoo, я знала реальную цену этой методики, поскольку фактически ею овладела!

Летом 2011 года Джефф Парк принял на себя бразды правления моей группой. Он помог взрастить группу профессионалов, благодаря чему у нас появилось несколько сервисных инженеров в США и в Индии. Этого было недостаточно, и Джефф беспокоился о том, что мне приходилось работать в непрерывном режиме, практически в одиночестве оказывая сервисные услуги. Он также проявлял беспокойство по поводу бизнеса и хотел добавить больше отказоустойчивости в модель эксплуатации путем найма избыточного персонала. В декабре этого же года он посоветовал мне взять настоящий отпуск, не читать электронную почту и отключить мобильный телефон.

В ответ я заявила ему, что чувствую, как будто бы что-то происходит неправильно, что-то работает не так, как ожидалось. Он сказал, что просто уволит меня, если я не уйду в отпуск. При этом он заверил меня, что все будет хорошо. И вечером накануне отпуска я настроила простую визуализацию соответствующих метрик с помощью сценария JavaScript и Perl, управляемого с помощью cron. Я посчитала, что этого будет достаточно, поскольку в случае возникновения каких-либо проблем отображались соответствующие уведомления.

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

Джефф отвел меня в сторонку и заявил о том, что знал о существовании высокого риска возникновения сбоев во время моего отпуска. Также имели место дополнительные риски, связанные с тем, что моя группа полностью полагалась на меня. Мой героизм на работе  помогал маскировать сбои, присущие системе.

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

Это событие сплотило эксплуатационную группу Sherpa, поскольку мы попытались скорректировать сервис и понять, что же произошло. Мы разделились на кросс-функциональные группы в целях устранения разных компонентов проблемы: обработчики сбоев, коммуникационная группа, инструментальная группа и группы по мониторингу и очистке. Также всегда были доступны ключевые менеджеры, готовые к принятию жестких решений. Эти решения помогут сократить время простоя.

Сбои – это ужасно, но они чему-то учат.

– Боб Саттон, инструктор из Stanford Management

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


убрать рекламу







к группа сервисного инжиниринга. Мы способствовали возникновению дискуссий между потребителями и поставщиками услуг, которые помогли бы в выявлении слабых мест в системе.

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

Я была готова к внедрению devops. Для меня ценность devops заключалась не в мантре «разрабатываем X и поддерживаем Y, либо разработка и поддержка», а в том, чтобы делиться историями, решать проблемы, возникающие в производстве, на основе принципов сотрудничества и укреплять ряды сообщества. Открытая среда для совместной работы превратилась в новую систему поддержки, которая укрепила основы устойчивых рабочих практик и способствовала развитию взаимоотношений между людьми.

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

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


Истории, иллюстрирующие devops-практики

Мы выбрали различные тематические исследования, чтобы проиллюстрировать разные способы проявления культуры эффективных devops-практик. Цель этих историй заключается не в предоставлении шаблонов, которым нужно точно следовать, слепо копируя структуру, используемую в другой организации, либо задействуя индивидуальные практики для всех обстоятельств и выбранных вариантов.

Рассматривайте эти истории как иллюстрации или руководства к действию. Мы надеемся, что в процессе чтения этих историй вы увидите отражение нашего опыта – возможно, нынешнего, а возможно, опыта, который будет иметь место в будущем. Мы включили истории из разных источников, как формальные тематические исследования, так и неформальные личные рассказы. Здесь вы найдете истории, относящиеся к хорошо известным организациям. Но вместе с тем мы намеренно включили истории из менее известных источников, чтобы продемонстрировать все разнообразие существующих devops-практик.

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

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

Глава 2. Определение devops

 Сделать закладку на этом месте книги

Devops – это культурное движение, изменяющее отношение людей к работе и к ее результатам. Благодаря внедрению devops в организации формируются интенциональные процессы, ускоряющие эффективность бизнеса. Это способствует скорейшему появлению результата от социальных и технических нововведений. Благодаря новым способам мышления и работы отдельные сотрудники и организации могут развивать и поддерживать устойчивые рабочие практики. Devops представляет собой культурный субстрат, ускоряющий формирование эмпатии между коллегами и облегчающий обмен опытом. В результате закладывается прочный фундамент, обеспечивающий эффективное приложение усилий в процессе работы со стороны отдельных сотрудников и команд.


Рецепт формирования культуры

Devops является необходимым условием для формирования культуры, но не достаточным. Ни одно культурное движение в мире не существует само по себе, поскольку культура неразрывно связана с социальной структурой. На культуру оказывают влияние много факторов. Это иерархические структуры, сформированные внутри организаций, связи между организациями и эффекты, вызванные глобализацией. Также на формирование культуры воздействуют ценности, нормы, убеждения и артефакты, связанные с упомянутыми выше факторами. Например, программное обеспечение варьируется в зависимости от того, кто его разрабатывает и использует. Благодаря devops появились способы адаптации и совершенствования социальной структуры, культуры и технологии, что, в свою очередь, способствует более эффективной работе.


Уравнение devops

Существует опасность, что движение, которое расценивает себя как новое, будет пытаться охватывать все, что не является старым.

– Ли Рой Бич и др., Naturalistic Decision Making and Related Research Lines

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

Хотя термин devops  образован на основе слов «development» (разработка) и «operations» (эксплуатация), принципы devops могут и должны применяться на всех стадиях рабочего процесса, реализуемого в организации. Устойчивый и успешный бизнес представляет собой нечто большее, чем совокупность, состоящую из команд разработчиков и эксплуатации. Если же вы будете ограничиваться исключительно этими командами, вы окажете бизнесу, налаженному в вашей организации, «медвежью услугу».


Использование «devops» в качестве народной модели

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

Люди зачастую тратят много времени на споры о природе «devops». Они также обсуждают народные модели вместо того, чтобы сосредоточиться на идеях, представляющих собой реальную ценность[1]. Порой для обхода проблем, вызываемых попытками точного определения devops, и стимулирования обсуждения соответствующих концепций и принципов преувеличивается значимость «плохого» поведения. Это делается для того, чтобы сконцентрироваться на «хорошем» поведении, которое подается в качестве «devops». Чтобы перейти к обсуждению эффективного сотрудничества в команде, можно воспользоваться примером фиктивной компании, в которой создана devops-команда. Эта команда выступает исключительно в качестве посредника между командами разработчиков и техподдержки (см. предисловие). Этот пример является в какой-то мере искусственным, но зато иллюстрирует более серьезные и практические концепции, чем обычные определения.


Прежний и новый взгляд

Если в компании складывается практика взаимных обвинений и преследований за совершенные ошибки, формируется атмосфера страха. В результате между сотрудниками компании появятся «стены», препятствующие общению. А теперь представьте себе идеальную среду, в которой все проблемы решаются сообща и расцениваются в качестве возможности для обучения как отдельных людей, так и организации в целом. Профессор Сидни Деккер в своей книге Field Guide to Understanding Human Error [2] характеризует эти ситуации как «прежний взгляд» и «новый взгляд» на человеческие ошибки.

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

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

«Новый взгляд» является ключом к пониманию движения devops. Этот взгляд поощряет нас делиться опытом, который представляет собой прекрасную возможность для обучения сотрудников.

Если вы поделитесь опытом применения devops, то это:

• приведет к увеличению степени прозрачности и доверия в группе;

• поможет вашим коллегам понять, как избежать ошибок, чреватых серьезными потерями;

• предоставит больше времени на решение новых задач, благодаря чему появятся дополнительные инновации.

Как только истории об опыте применения devops станут всеобщим достоянием, они окажут влияние на отрасль в целом. В результате появятся новые возможности и знания, а также станет возможным обмен знаниями.


Devops-пакт

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


Пример пакта

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

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

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

При восхождении используется набор словесных ключей, позволяющих проверить готовность к процессу восхождения. Сначала восходитель спрашивает у напарника: «На страховке?» Напарник отвечает: «На страховке». Затем восходитель говорит: «Подъем!», сигнализируя о готовности к началу восхождения. И наконец, напарник подтверждает осведомленность о готовности восходителя, произнося слово «подъем».

Для обеспечения работоспособности этого пакта применяются следующие принципы:

• общие четко сформулированные цели;

• непрерывное общение;

• динамическая настройка и коррекция понимания.

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


Пример devops-пакта

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

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

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

Как Дженераль, так и Джорджу присуще понимание общих целей:

• внедрение нового инструмента, увеличивающего ценность для заказчиков компании Sparkle Corp;

• поддержка безопасности и доверия при осуществлении взаимного обмена информацией.

В изолированной среде, не использующей принципы devops, понимание общих целей отсутствует. Это может привести к тому, что, например, Дженераль попытается приступить к кодированию, не убедившись в том, что Джордж понял суть требований. В этом случае совместная работа возможна, но без обмена информацией о намерениях шансы на успех уменьшаются.

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

На протяжении всей книги мы будем использовать идею о devops-пакте. Мы также продемонстрируем, каким образом технологические и культурные аспекты devops становятся способами развития и поддержки общего взаимопонимания.

Глава 3. История devops

 Сделать закладку на этом месте книги

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


Разработчик в качестве оператора

Изначально разработчик программ являлся оператором. На исходе Второй мировой войны правительство США обратилось к ведущим математикам с призывом создать «компьютеры». Эти устройства должны были применяться для расчета баллистических таблиц, используемых при стрельбе. На этот призыв откликнулись женщины-математики, и среди них была Джин Бартик. Она пренебрегла возражениями своего преподавателя колледжа, который считал, что решение повторяющихся задач не столь важно, как продолжить семейную традицию и получить классическое образование.

Иногда полезно выслушать совет и сделать по-своему. Джин Бартик оказалась на нужном месте в нужное время и стала одним из первых программистов компьютера ENIAC.

Используя анализ аппаратных и логических схем, Бартик и пять ее коллег-программистов смогли научиться программировать на компьютере ENIAC, и это при полном отсутствии сопровождающей документации. Программирование на этом компьютере, работающем на 18 тысячах радиолампах, осуществлялось путем вращения дисков и изменения кабельных подключений с помощью 40 управляющих панелей.

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


Появление программной инженерии

В 1961 году президент США Джон Кеннеди провозгласил амбициозную лунную программу. В рамках этой программы в течение ближайших десяти лет должен был состояться полет человека на Луну с последующим благополучным возвращением на Землю. Учитывая сжатые сроки и отсутствие специалистов, которые могли бы создать необходимое программное обеспечение, NASA объявило о наборе профессиональных программистов. Проект NASA по разработке ПО возглавила математик из Массачусетского технологического института Маргарет Гамильтон[3].

Как вспоминает Гамильтон:

Процесс генерирования новых идей превратился в настоящее приключение. Везде царили самоотверженный труд и ответственность. Атмосфера взаимного уважения способствовала комфортной работе. Поскольку процесс разработки ПО носит мистический характер, являясь чем-то вроде «черного ящика», топ-менеджмент предоставил нам полную свободу и оказал абсолютное доверие. Мы должны были найти эффективный способ создания программ, и мы сделали это. Оглядываясь назад, я хочу сказать, что мы были счастливейшими людьми в мире. У нас не было другого выбора, кроме как стать первыми в мире, и не было времени на то, чтобы пребывать в состоянии «чайников»[4].

Поскольку Гамильтон была известна стремлением к созданию сложного программного обеспечения, ей приписывают создание термина программная инженерия . Она также разработала приоритетные дисплеи , программное обеспечение, предупреждающее астронавтов о наличии информации, которая требует реагирования в режиме реального времени. Маргарет разработала набор правил по сбору требований, один из пунктов которого заключался в обеспечении качества как одного из методов программного инжиниринга. Список методов программной инженерии включал следующие позиции:

• отладка всех отдельных компонентов;

• тестирование отдельных компонентов до этапа сборки;

• интеграционное тестирование.

В 1969 году во время осуществления миссии «Аполлон-11» произошел сбой бортового компьютера из-за большого объема выполняемых вычислений. Команда разработчиков предусмотрела возможность вмешательства астронавтов в процесс управления модулем в обход бортового компьютера. Это позволило Нейлу Армстронгу в критической ситуации взять управление лунным модулем на себя.

Благодаря свободе и доверию, предоставленным менеджерами группе инженеров-разработчиков ПО, а также взаимному уважению, царившему в группе разработчиков, стало возможным создание программного обеспечения, способствующего достижению величайших технологических успехов, таких как высадка Нейла Армстронга на Луну. Если бы в среде разработки ПО отсутствовало взаимное доверие, вряд ли была бы реализована критически важная функция ручного управления лунным модулем. Если бы не эта функция, вряд ли лунная эпопея завершилась бы благополучно.


ПРОБЛЕМЫ, СВЯЗАННЫЕ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ

В 60-е годы XX века космические полеты были не единственной областью, в которой применялось программное обеспечение. По мере того как оборудование стало более доступным, начало вызывать тревогу постоянно усложняющееся программное обеспечение. Эта сложность не соответствовала стандартам, принятым в других инженерных дисциплинах. Быстрый рост сложности систем и возрастающая зависимость от них начали беспокоить пользователей.

В 1967 году Научный комитет НАТО, в состав которого входили ученые из разных стран и отраслей промышленности, организовал проведение дискуссий, посвященных состоянию программной инженерии. Осенью 1967 года была сформирована исследовательская группа по компьютерным наукам. Цель этой группы заключалась в привлечении внимания к проблемам, связанным с программным обеспечением. Были приглашены 50 экспертов в разных областях, которые в составе трех рабочих групп сосредоточили внимание на разработке, производстве и поддержке программного обеспечения. При этом предпринимались попытки определить, описать и приступить к решению проблем в области программной инженерии.

В 1968 году на конференции НАТО, посвященной программной инженерии, были сформулированы ключевые проблемы программной инженерии, перечисленные в следующем перечне:

• определение и оценка степени успеха;

• создание сложных систем, требующих больших инвестиций, с непредсказуемым внедрением;

• разработка систем в соответствии с графиком и спецификацией;

• оказание экономического давления на производителей, создающих определенные продукты.

Благодаря идентификации этих проблем облегчается определение и формирование областей деятельности для отрасли на ближайшие годы.


Появление закрытого программного обеспечения и стандартизация

До 1964 года существовала практика создания компьютеров, которые были весьма специфичными и соответствовали требованиям конкретного заказчика. Оборудование и программное обеспечение были не стандартизованы и не взаимозаменяемы. В 1964 году компания IBM анонсировала семейство компьютеров System/360. Компьютеры, входящие в это семейство, имели разные размеры и предназначались для использования в коммерческих и научных целях.

Благодаря созданию этого семейства компьютеров снизилась стоимость разработки, производства и обслуживания, в то же время клиентам стало проще обновлять оборудование по мере необходимости. Семейство мэйнфреймов System/360 заняло господствующее положение, обеспечивая своим пользователям возможность начать с использования небольших вычислительных ресурсов, а потом наращивать их по мере необходимости. Эти компьютеры также обеспечивали гибкость в работе, позволяя отдельным сотрудникам изучать возможности оборудования и программного обеспечения. При этом они получали необходимые рабочие навыки, которые могли успешно использовать в другом месте.

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


Сетевая эра

В 1979 году появилась всемирная система групп новостей Usenet, которую создали студенты из Университета Дьюка Том Трескотт и Джим Эллис. Изначально Usenet представляла собой простой сценарий оболочки, который автоматически вызывал разные компьютеры, искал изменения в файлах, находящихся на этих компьютерах, а потом копировал изменения с одного компьютера на другой с помощью набора программ UUCP. Этот набор обеспечивал передачу файлов и выполнение команд на удаленных компьютерах. Эллис выступил с докладом Invitation to a General Access UNIX Network [5] в группе пользователей Unix, известной как USENIX. Это был один из первых и быстро развивающихся способов коммуникации и обмена знаниями между организациями, имеющими компьютеры.

Хотя этот инструмент способствовал обмену знаниями между университетами и корпорациями, в те времена многие детали, связанные с деятельностью компаний, были засекречены. Было не принято обсуждать проблемы за стенами офиса компании, поскольку подобная информация рассматривалась как конкурентное преимущество. На основе подобных сведений конкуренты могли делать выводы о неэффективности компании. Это привело к появлению барьеров на пути к сотрудничеству и к ограничению эффективности доступных коммуникационных каналов. Подобная культурная изоляция приводила к появлению сложностей на пути к росту компаний.

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

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

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


Истоки глобального сообщества

В то время как взаимосвязанные сети позволили программистам и ИТ-практикам обмениваться идеями в Интернете, обычные люди также стали искать способы обмена идеями. Начали появляться новые и все более популярные пользовательские группы, предназначенные для обсуждения разных вопросов практиками и пользователями различных технологий. В те времена одной из самых больших пользовательских групп была DECUS (Digital Equipment Computer Users’ Society, Сообщество пользователей цифрового компьютерного оборудования), основанная в 1961 году. В основной состав этой группы входили программисты, создающие или поддерживающие код для компьютеров DEC.

Американское отделение DECUS проводило различные технические конференции и организовывало локальные пользовательские группы в США, тогда как отделения, действующие в других странах, проводили соответствующие мероприятия у себя. Результаты этих конференций и событий начали публиковаться в форме сборников трудов DECUS. Эти сборники были доступны для членов сообщества в качестве средства обмена информацией. Они стимулировали рост общего объема знаний сообщества и усиливали степень сплоченности членов этого сообщества.

КОММЕРЧЕСКИЕ СЕКРЕТЫ И КОНФИДЕНЦИАЛЬНАЯ ИНФОРМАЦИЯ

Информация, которая неизвестна широкой публике, является засекре


убрать рекламу







ченной. Это делается для обеспечения экономических или бизнес-преимуществ. Подобные закрытые сведения расцениваются как коммерческий секрет. Информация, которая является собственностью компании, либо информация, на использование которой компания имеет эксклюзивные права, считается конфиденциальной. Примеры конфиденциальной информации компании – программное обеспечение, процессы, методы, структура зарплаты, организационная структура и списки заказчиков. Например, исходный код собственного программного обеспечения обычно недоступен для конечных пользователей. Все коммерческие секреты являются конфиденциальными, но далеко не вся конфиденциальная информация является секретной.

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

Аналогичное сообщество, объединившее в своих рядах системных администраторов, было создано в USENIX. Это сообщество представляло собой группу пользователей со специальными интересами и получило название System Administrators Group (группа системных администраторов). Позднее эта группа называлась SAGE, сейчас же она известна как группа пользователей со специальными интересами LISA (Large Installation System Administration, Администрирование установки больших систем). Эта группа проводит ежегодные конференции под названием «Large Installation System Administration»[6]. Кроме того, встречи NSFNET «Regional-Tech» эволюционировали в группу North American Network Operators’ Group (NANOG). Это сообщество специально предназначено для организации сотрудничества между сетевыми администраторами, стремящимися внести свой вклад в улучшение Интернета.

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


Эра приложений и Интернета

Один из первых примеров успешной кооперации в рамках одной организации – суперпопулярный HTTP-сервер Apache (https://httpd.apache.org/ABOUT_APACHE.html ), появившийся в 1995 году. Этот сервер был основан на бесплатном http-сервере NCSA HTTPd и разработан студентом Иллинойского университета (Урбана-Шампейн) Робертом Маккулом. Благодаря использованию модульного программного обеспечения Apache любой пользователь может быстро развертывать веб-сервер, выполнив лишь минимальную конфигурацию. Это ознаменовало начало эпохи использования решений с открытым программным кодом. Программы с открытым исходным кодом предоставляют пользователям лицензии на чтение, изменение и распространение исходного кода. Эти программы начинают конкурировать с собственными программными решениями, имеющими закрытый программный код.

Учитывая доступность различных дистрибутивов операционной системы Linux и рост популярности языков написания сценариев, таких как PHP и Perl, возрастающая популярность программ с исходным открытым кодом привела к распространению стека LAMP (Linux, Apache, MySQL и PHP) в качестве средства создания веб-приложений. Система управления реляционными базами данных MySQL, появившаяся в 1995 году, наравне с инструментами написания серверных сценариев PHP позволила разработчикам создавать динамические веб-сайты и приложения. Эти сайты и приложения быстро обновлялись и динамически генерировали контент. Учитывая ту простоту, с которой могли создаваться новые веб-приложения, в конце 1990-х годов отдельным программистам и коллективам приходилось работать быстрее и проявлять большую гибкость, чтобы быть конкурентоспособными.

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

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


Развитие методологий разработки программного обеспечения

В 2001 году в сообществе активных и деятельных приверженцев экстремального программирования и в других подобных сообществах было разослано приглашение принять участие в дискуссии, посвященной разработке программного обеспечения. Экстремальное программирование – это одна из форм гибкой разработки программ, которая более чутко реагировала на изменяющиеся требования, чем предыдущие методологии разработки программного обеспечения, такие как короткие циклы выпуска, интенсивное тестирование и парное программирование. В ответ на это предложение 17 инженеров-программистов собрались в Сноуберде (штат Юта). Они обсудили свои общие ценности, позволяющие включить адаптивность и реагирование на изменения в процесс разработки программного обеспечения с явным выделением человеческого фактора. Эти ценности были изложены в манифесте гибкого программирования, который положил начало движению сторонников гибкого программирования.

В 2004 году программист Алистер Кокберн, являющийся одним из соавторов манифеста гибкого программирования (Agile Manifesto), описал методологию разработки ПО Crystal Clear[7]. Эта методология основана на десятилетнем опыте изучения успешных команд и предназначена для небольших групп разработчиков. Алистер описал три основных метода, используемых в Crystal Clear:

• Быстрая доставка полезного кода, переход от больших и редких развертываний кода к меньшим и более частым развертываниям.

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

• Осмотическая коммуникация, осуществляемая между разработчиками. Если разработчики находятся в одной комнате, информация воспринимается ими неформально, как фоновый шум. Этот процесс напоминает явление осмоса.

Эта методология развивалась несколько лет, приобретая все большее влияние. В этот период времени системный администратор Марсель Вегерманн написал эссе, посвященное использованию принципов разработки программного обеспечения Crystal Clear, Scrum и Agile в области системного администрирования. В дополнение к блиц-докладу по теме, в котором были предложены такие идеи, как контроль версий для каталога /etc операционной системы Linux, парное администрирование системы и операционные ретроспективы, в 2008 году Марсель также создал список рассылки Agile System Administration.


Приложения с открытым исходным кодом и собственные услуги

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

В 2006 году компания электронной коммерции Amazon.com, Inc., которая ранее была известна своим сайтом по продаже книг и других товаров, предназначенных для широкого круга потребителей, запустила два сервиса: Amazon Elastic Compute Cloud (EC2) и Amazon Simple Storage Service (S3). Эти сервисы представляли собой первую попытку реализации виртуальных компьютерных экземпляров и виртуального хранилища с помощью собственной службы. В результате пользователи получили доступ к вычислительным ресурсам без предварительных инвестиций в оборудование. Также можно было запрашивать дополнительные ресурсы по мере необходимости. Как и в случае появления компьютеров из семейства System/360, этот сервис был быстро принят пользователями, став стандартом «де факто» благодаря простоте использования, невысоким начальным затратам и гибкости.

По мере роста и развития веб-технологий появлялись новые способы коммуникации и сотрудничества в Интернете. В 2006 году появился онлайновый сетевой сервис Твиттер. Изначально этот сервис применялся пользователями, которые хотели делиться информацией, представленной в сокращенном формате. Эта информация использовалась в качестве средства привлечения внимания как простыми пользователями, так и знаменитостями. Но в 2007-м популярность Твиттера буквально взлетела до небес благодаря конференции South by Southwest Interactive (SXSW). Эта конференция транслировалась в режиме реального времени с помощью твитов на экранах, установленных в холлах.

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


Гибкая инфраструктура

На конференции Agile 2008, проходящей в Торонто, системный администратор и ИТ-консультант Патрик Дебуа в своем докладе «Agile Operations and Infrastructure: How Infra-gile are You?» рассказывал о включении методологии Scrum в эксплуатационную работу. Патрик работал с командами по разработке и эксплуатации над проектом по тестированию передачи информации в центр обработки данных. И он предпочитал один день работать в команде разработчиков, а на следующий день – в эксплуатационной команде. Если же переключаться между выполнением двух задач в течение одного дня, теряется примерно 20 % от обычной производительности[8].

На этой же конференции бывший программист Эндрю Клэй Шафер, который начал проявлять большой интерес к связанным с ИТ проблемам, предложил провести сеанс гибкой инфраструктуры (Agile Infrastructure). Эндрю почему-то считал, что предложенная им тема никого не заинтересует, поэтому пропустил собственноручно объявленный сеанс. Когда Патрик увидел это, он понял, что кроме него есть другие люди, интересующиеся гибким системным администрированием. После этого Патрик связался с Эндрю и предложил ему подробнее обсудить данную концепцию.

Отдельные компании начали не только добиваться больших успехов во внедрении процессов, позволивших им идти в ногу с постоянно ускоряющимися изменениями Интернета, но и делиться своим опытом в сообществах. Эти сообщества формировались вокруг таких популярных конференций, как O’Reilly Velocity Conference (https://conferences.oreilly.com/velocity ).

Одной из таких компаний является Flickr, популярное интернет-сообщество фотографов. После приобретения компанией Yahoo в 2005 году Flickr потребовалось переместить все сервисы и данные из Канады в США. Джон Оллспоу, энтузиаст в области эксплуатации веб-приложений с многолетним опытом работы по техобслуживанию систем, присоединился к компании Flickr в качестве ведущего инженера по эксплуатации. Его цель заключалась в оказании помощи при масштабировании нового проекта по миграции данных. В 2007 году к группе разработчиков Flickr присоединился Пол Хэммонд. В 2008 году Пол стал техническим директором Flickr, возглавив отдел разработки ПО вместе с Оллспоу.

На конференции Velocity Santa Clara 2009 Хэммонд и Оллспоу совместно представили доклад «10+ Deploys per Day: Dev and Ops Cooperation at Flickr». В этом докладе они описали революционные изменения, которые позволят команде быстро продвигаться вперед. Они не предлагали ломать барьеры между сотрудниками либо формировать большое профессиональное и культурное движение. Они просто делились своим опытом совместной работы в Flickr, который серьезно отличался от опыта предыдущей работы Оллспоу в компании Friendster, где брали верх эмоции и моральное давление, а сотрудничество между членами команды практически отсутствовало.

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

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


Конференции devopsdays

Не ограничивайтесь простым «нет», относитесь уважительно к проблемам других людей… #velocityconf #devops #workingtogether

– Эндрю Клэй Шафер (@littleidea)

Этот твит, созданный 23 июня 2009 года Эндрю Клэй Шафером, побудил Патрика Дебуа пожаловаться в Твиттере на то, что он не сможет посетить лично ежегодную конференцию Velocity. Прис Нэсрат, который в то время выполнял обязанности ведущего системного интегратора в Guardian, отправил ответное сообщение в Твиттере. В этом сообщении он спросил о том, почему бы не организовать собственную конференцию Velocity в Бельгии. Вдохновленный этими словами Патрик поступил практически в полном соответствии с данным советом. Он организовал локальную конференцию, на которой разработчики, системные администраторы, системные программисты и другие специалисты, работающие в этой области, могли обмениваться информацией. В октябре этого же года в Генте прошла первая конференция devopsdays. Двумя неделями позже Дебуа писал следующее:

Я буду откровенен, когда скажу, что за последние несколько лет, когда я посещал некоторые конференции Agile, я ощущал себя проповедником в пустыне. Мне казалось, что идея о совместной работе разработчиков и персонала из отдела эксплуатации попахивает авантюризмом. Но в наши дни эти идеи начали завоевывать популярность.

Первая конференция devopsdays воспламенила пороховую бочку с неудовлетворенными потребностями людей, изолированных друг от друга. Эти люди испытывали разочарование в связи со статусом-кво, отождествляемым с devops, и способом описания работы, которую, по их мнению, они уже выполняют. По мере того как отдельные энтузиасты организовывали локальные конференции в новых уголках мира, росли масштабы и количество участвующих в этих конференциях людей. Благодаря возможности коммуникаций в режиме реального времени с помощью Твиттера потенциал роста этих конференций практически безграничен, а хэштег #devops просто обречен на популярность.


Текущее состояние devops

За шесть лет, прошедших с момента проведения первых devopsdays в Бельгии (под руководством Патрика Дебуа), движения devops ушло далеко вперед. В отчете «2015 State of Devops Report» (https://puppet.com/resources/white-paper/2015-state-devops-report ), опубликованном компанией Puppet, отмечается, что компании, использующие devops, имеют лучшие показатели, чем компании, которые не применяют devops. На убедительном языке цифр продемонстрированы факты, о которых многие люди догадывались на интуитивном уровне. Отдельные сотрудники и команды, которые эффективно сотрудничают друг с другом, работают лучше, чем группа сотрудников, находящихся в одной комнате и не умеющих работать вместе. Высокоэффективные devops-организации чаще развертывают код, реже допускают ошибки, быстрее восстанавливаются после сбоев, а сотрудники этих организаций – более счастливые люди.

Количество конференций devopsdays выросло с одной в 2009 году до двадцати двух в 2015 году (во всем мире). Каждый год знаменуется новыми событиями devopsdays, проходящими в разных городах и странах. Эти конференции не связаны с такими центрами развития технологий, как Силиконовая долина или Нью-Йорк. Существуют десятки локальных групп, объединяющих в своих рядах тысячи членов, которые буквально разбросаны по всему земному шару, не говоря уже о множестве бесед на эту тему, происходящих ежедневно в Твиттере.


Выводы

Размышляя о нашей истории, мы видим склонность к концентрации на результатах, а не на людях и процессах. Многие вещи были позаимствованы из презентации Джона Оллспоу и Пола Хэммонда «10+ Deploys a Day», в которой подчеркивается, что важно развертывать более 10 программ в день. Ну а подзаголовок «Dev & Ops Cooperation at Flickr» многие просто не замечали.

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

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

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

Глава 4. Основные термины и концепции

 Сделать закладку на этом месте книги

Чтобы создать прочный фундамент, необходимый для внедрения эффективных devops-методов, следует обсудить некоторые ключевые термины и понятия. Некоторые из этих концепций могут быть знакомы читателям, многие были упомянуты в контексте истории программной инженерии либо хорошо известны читателям, имеющим опыт работы с различными методологиями разработки программного обеспечения.

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

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


Методологии, применяемые при разработке программного обеспечения

Процесс разбиения деятельности по разработке ПО на отдельные фазы называется методологией разработки программного обеспечения .

Обычно выделяются следующие фазы:

• спецификация конечных результатов работы или артефактов;

• разработка и верификация кода в соответствии со спецификацией;

• развертывание кода в финальной потребительской или производственной среде.

Рассмотрение абсолютно всех методологий, применяемых при разработке программного обеспечения, выходит за рамки этой главы, поэтому коснемся лишь тех из них, которые в какой-то степени связаны с devops.


Каскад

Каскадная методология (или модель) представляет собой процесс управления проектом, в котором выделяется последовательная прогрессия от одной стадии процесса до другой. Изначально эта методология использовалась в обрабатывающей и строительной промышленности, позднее в аппаратной инженерии, ну а для разработки программного обеспечения начала применяться в первой половине 1980-х годов[9].

Изначально стадии каскадной модели назывались следующим образом: спецификация требований, проектирование, внедрение, интеграция, тестирование, установка и техническое обслуживание. Эти этапы показаны на рис. 4.1 (в форме диаграммы).

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

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




Рис. 4.1. Каскадная модель


Гибкая методология разработки ПО

Эпитет «гибкий» (agile) относится к целой группе методологий, применяемых при разработке программного обеспечения. Эти методологии являются более «легкими» и гибкими по сравнению с более ранними методиками (например, с каскадной моделью). В 2001 году был опубликован Agile-манифест (см. главу 2), в котором были изложены основные принципы гибкого программирования.

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

• отдельных людей и взаимодействий выше ценности процессов и инструментов;

• рабочей документации выше ценности исчерпывающей документации;

• сотрудничества с заказчиками выше ценности переговоров, проводимых в процессе заключения контракта;

• реагирования на изменение ситуации выше ценности точного следования плану.

Как видите, компоненты, находящиеся в левой части списка, оцениваются выше компонентов, расположенных в правой части списка.

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

ЯВЛЯЕТСЯ ЛИ DEVOPS ПРОСТО ОЧЕРЕДНОЙ ГИБКОЙ МЕТОДОЛОГИЕЙ?

Методология devops имеет много общего с гибкими методиками разработки программного обеспечения, особенно если учитывать фокус на отдельных людях, взаимодействиях и сотрудничестве. В связи с этим у вас, наверное, уже возник вопрос о том, не является ли devops просто «ребрендингом» гибких методик. Несомненно, методология devops сформировалась на основе гибких методик, но все же она является самостоятельным культурным движением. Это движение связано с историей компьютерной индустрии и включает гораздо больше, чем разработчики программ. Движение devops адаптирует и расширяет принципы гибкой разработки программ и применяет их на уровне организации в целом, а не только в процессе разработки программ. Как будет подробно показано в следующих главах, devops приводит к культурным последствиям, выходящим за пределы области гибкой разработки. Изменения, вызванные внедрением devops, гораздо шире, чем банальное увеличение скорости доставки новых версий программ.


Scrum

В середине 1990-х годов Кен Швабер и доктор Джефф Сазерленд, принимавшие участие в создании Agile-манифеста, объединили усилия с целью формирования нового процесса создания программного обеспечения под названием Scrum. В методологии Scrum основной упор делается на максимизации способностей команды разработчиков к быстрому реагированию на изменение требований к самому проекту и со стороны заказчиков. При этом используются предопределенные циклы разработки, называемые спринты . Обычно длина циклов варьируется от одной недели до одного месяца. Процесс разработки ПО начинается с совещания по планированию спринтов, на котором определяются цели, выполняется обзор спринтов и производится ретроспектива спринтов. Это нужно для оценки степени выполнения спринтов и каких-либо проблем, которые могут возникнуть в процессе выполнения спринта.

Одна из ключевых особенностей методологии Scrum – проведение ежедневных Scrum-встреч  либо ежедневных собраний , на которых члены команды как можно быстрее дают ответы на следующие три вопроса:

• Что из того, что я сделал, помогло команде достичь целей спринта?

• Что я планирую сделать сегодня, чтобы помочь команде достичь этих целей?

• Что делать в том случае, когда какое-либо препятствие мешает мне или команде достичь целей?

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


Методологии эксплуатации

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


ITIL

Методология ITIL, ранее известная как Information Technology Infrastructure Library (Библиотека инфраструктуры информационных технологий), представляет собой набор методов, предназначенных для управления ИТ-услугами. Эта методология изложена в пяти книгах. В этих книгах описываются способы осуществления процессов, процедур и задач, а также составления контрольных списков, необходимых при эксплуатации. Эта методология позволяет установить соответствие разработанных программ сформулированным критериям, а также оценить прогресс на пути к достижению целей. Методология ITIL сформировалась на основе практических методик, применявшихся в 1980-х годах во многих ИТ-организациях.

Британское


убрать рекламу







центральное компьютерное и телекоммуникационное агентство разработало набор рекомендаций по стандартизации этих практических методик. Первая публикация методологии ITIL имела место в 1989 году, а последняя – в 2011 году. За это время она эволюционировала с пяти основных разделов до многотомного собрания и теперь включает описание стратегии техобслуживания, проектирования услуг, перехода к услугам, выполнения услуг и непрерывного улучшения услуг.

ИТ-аналитик и консультант Стивен Манн отмечает, что наряду со многими преимуществами, которые дает ITIL-стандартизация и наличие более 1,5 млн ITIL-сертифицированных специалистов во всем мире, существуют и проблемы. Одна из основных проблем – недостаточное внимание к отдельным практическим областям. Согласно утверждению Манна, методология ITIL чаще является реактивной, а не проактивной, поэтому организациям, использующим ITIL, рекомендуется уделить больше внимания проактивному планированию и заказчикам.


COBIT

Методология COBIT (Control Objectives for Information and Related Technology; Задачи управления для информационных и смежных технологий) представляет собой каркас ISACA, предназначенный для управления информацией и технологиями. Эта методология была впервые обнародована в 1996 году. Основной принцип COBIT заключается в согласовании бизнес-целей с ИТ-целями.

Методология COBIT основана на следующих пяти принципах:

• удовлетворение нужд заинтересованных сторон;

• полный охват предприятия;

• применение простого интегрированного каркаса;

• обеспечение целостного подхода;

• отделение управления от менеджмента.


Системные методологии

Некоторые методики сосредоточиваются на системах в целом, а не на более конкретных областях, таких как разработка программного обеспечения либо техобслуживание компьютеров. Навыки системного мышления критически важны для тех, кто работает со сложными системами, такими как многие современные программы. Читателям, желающим получить представление о системном мышлении в целом, рекомендуется обратиться к книгам Thinking in Systems  (Donella Meadows) и How Complex Systems Fail  (Dr. Richard Cook).


Бережливость

По итогам пятилетнего изучения тенденций в развитии автомобильной промышленности и производственной системы «Тойоты» (TPS) Джеймс П. Вомак, Дэниел Т. Джонс и Дэниел Рус ввели термин «бережливое производство»[10]. Вомак и Джонс выработали следующие пять принципов бережливого мышления[11]:

• ценность;

• процесс создания ценности;

• поток;

• вытягивание;

• совершенствование.

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

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

В бережливых методологиях разработки ПО и оказания ИТ-услуг появляются следующие отходы:

• невостребованные функции программного обеспечения;

• задержки при общении;

• замедленный отклик приложения;

• бюрократические процессы.

Отходы в контексте бережливости противоположны ценностям. Мэри Поппендик и Томас Поппендик сопоставили отходы бережливого производства с отходами производства программного обеспечения. В результате появился следующий список[12]:

• частично выполненная работа;

• дополнительные возможности;

• переучивание;

• ненужные передачи обслуживания;

• переключение между задачами;

• задержки;

• дефекты.

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


Концепции разработки, релиза и развертывания ПО

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


Контроль версий

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

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


Разработка через тестирование

При выполнении разработки через тестирование (Test Driven Development; TDD) разработчик начинает с написания проверяемого функционал-теста, применяемого для проверки функциональности нового кода. После этого создается сам код, затем начинается тестирование этого кода. Благодаря тестированию гарантируется безупречная работа новых функций, а также становится более очевидным назначение кода.

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


Развертывание приложений

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

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


Непрерывная интеграция

Непрерывная интеграция (Continuous Integration; CI) – это процесс интегрирования нового кода, написанного разработчиками, в основной код или ветку «мастер», осуществляемый в течение рабочего дня. Этот подход отличается от методики, в соответствии с которой разработчики работают с независимыми ветками неделями или месяцами, выполняя слияние кода в основную ветку только после полного завершения работы над проектом. Длительные периоды времени между слияниями приводят к тому, что в код вносится очень много изменений, что повышает вероятность появления ошибок. При работе с большими пакетами изменений гораздо труднее изолировать и идентифицировать фрагмент кода, который вызвал сбой. Если же используются небольшие наборы изменений, для которых часто выполняется слияние, поиск ошибок значительно упрощается. Постарайтесь избежать проблем, связанных с интеграцией, которые неизбежно появятся при слиянии больших наборов изменений.

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


Непрерывная доставка

Методология непрерывной доставки (Continuous Delivery; CD) представляет собой набор общих принципов по разработке программного обеспечения, которые позволяют часто создавать новые релизы программного обеспечения с привлечением автоматизированного тестирования и непрерывной интеграции. Эта методология тесно связана с непрерывной интеграцией и часто воспринимается как расширение непрерывной интеграции. Это позволяет убедиться в том, что новые изменения могут быть интегрированы без обращения к автоматическим тестам. В случае непрерывной доставки обеспечивается развертывание изменений .


Непрерывное развертывание

Непрерывное развертывание (Continuous deployment; CD) – это процесс развертывания изменений при разработке путем создания тестов и проверок, позволяющих свести риск ошибок к минимуму. В то время как непрерывная доставка позволяет гарантировать развертывание новых изменений, непрерывное развертывание означает, что выполняется развертывание изменений в производственном цикле.

Чем быстрее изменения программного обеспечения внедряются в производство, тем быстрее сотрудники увидят результаты своей работы. Благодаря «прозрачности» возрастает степень удовлетворенности работой, появляются позитивные эмоции, что, в свою очередь, способствует росту производительности. Также появляются возможности для быстрого обучения. Если в коде функции или в дизайне программы допущена серьезная ошибка, ее легче обнаружить и исправить путем просмотра недавно измененного рабочего контента.

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

С тех пор как методологии непрерывной доставки и непрерывного развертывания завоевали популярность в среде разработчиков, многократно обсуждались различия между ними. Джез Хамбл, автор концепции непрерывной доставки, определил эту методологию как общий набор принципов, который может применяться к произвольному проекту разработки ПО, включая Интернет вещей (IoT, internet of things) и внедренное программное обеспечение, в то время как непрерывное развертывание относится к веб-приложениям. Чтобы получить больше сведений о различиях между этими двумя концепциями, обратитесь к дополнительным ресурсам.


Минимально жизнеспособный продукт

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

Минимально жизнеспособный продукт (Minimum Viable Product; MVP) – это прототип готового продукта, который можно проверить на соответствие требованиям с приложением минимальных усилий. Создание минимально жизнеспособного продукта целесообразно в тех случаях, когда высока вероятность внесения серьезных изменений в готовый продукт. При этом вы сэкономите значительный объем времени и усилий. В минимально жизнеспособном продукте отключены некоторые второстепенные функции или расширенные настройки, которые не нужны для оценки базовых концепций, либо делается упор на функциях, а не на дизайне или производительности. Подобно методологиям бережливой разработки и непрерывной доставки, минимально жизнеспособный продукт позволяет быстрее осуществлять рабочие итерации и улучшать продукт, уменьшая затраты и количество отходов.


Концепции, относящиеся к инфраструктуре

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


Управление конфигурацией

В 1950-х годах Министерство обороны США в качестве технической дисциплины менеджмента разработало методологию управления конфигурацией (Configuration Management; CM). Позднее эта методология была принята во многих других областях. Управление конфигурацией – это процесс установления и поддержки согласованности между функциональными и физическими атрибутами, а также управление производительностью на протяжении всего жизненного цикла. Эта методология включает политики, процессы, документацию и инструменты, требуемые для реализации согласованной производительности, функциональности и атрибутов.

Различные организации и органы по стандартизации, такие как ITIL, IEEE (Institute of Electrical and Electronics Engineers, Институт инженеров по электротехнике и электронике), ISO (International Organization for Standardization, Международная организация по стандартизации) и SEI (Software Engineering Institute, Институт программной инженерии) предложили стандарт управления конфигурированием, который используется в индустрии разработки программного обеспечения. Как и в случае с другими народными моделями, появление подобного стандарта привело к некоторой путанице с применяемыми ранее определениями.

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


Облачные вычисления

Облачные вычисления, которые часто называют просто «облако», – это совместно выполняемые интернет-вычисления. Заказчики могут приобретать и использовать общие компьютерные ресурсы, предлагаемые разными провайдерами облачных вычислений. Облачные вычисления и хранилища позволят организациям сэкономить на приобретении, установке и поддержке своего собственного оборудования.

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

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


Автоматизация инфраструктуры

Автоматизация инфраструктуры – это способ создания систем, позволяющий уменьшить нагрузку на персонал, связанную с управлением системами и относящимися к ним службами. Благодаря автоматизации повышается качество, точность и корректность сервиса, предоставляемого заказчикам. Автоматизация в целом представляет собой способ уменьшения количества повторяющихся операций, что позволяет свести к минимуму ошибки и сэкономить время и энергию операторов-людей.

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


Управление артефактами

Артефакты создаются в результате выполнения любого этапа в процессе разработки программного обеспечения. В зависимости от используемого языка под артефактами могут подразумеваться разные объекты, включая файлы JAR (архивные файлы Java), WAR (архивные файлы веб-приложений), библиотеки, ресурсы и приложения. Управление артефактами может быть столь же простым, как управление веб-сервером с контролем доступа, обеспечивающим управление файлами вручную. Управление файлами также может быть сложным и предусматривать использование разных расширенных средств. Как и в случае с рассмотренным раньше контролем версий для исходного кода, управление артефактами может выполняться разными способами, с учетом возможностей вашего бюджета.

В общем случае хранилище артефактов может выступать в качестве:

• центрального пункта управления бинарными файлами и зависимостями;

• настраиваемого прокси-сервера, установленного между организацией и общественными хранилищами;

• интегрированного хранилища, предназначенного для продвижения разработанного в организации программного обеспечения.


Контейнеры

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

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


Культурные концепции

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


Ретроспектива

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

Что произошло? 

Каковы были цели проекта и что мы получили после его завершения.

Что было сделано хорошо? 

Что было успешного в этом проекте, что в проекте особенно нравится команде разработчиков и что можно использовать в будущих проектах.

Что пошло не так? 

Что было сделано неправильно, с какими ошибками пришлось столкнуться, насколько были сорваны сроки и чего нужно избегать в будущих проектах.


Постмортем

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

Что случилось? 

Хронология инцидента от начала до конца, часто вместе с журналами общения или системных ошибок.

Опрос 

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

Что нужно исправить? 

Что нужно исправить, чтобы улучшить безопасность системы и избежать повторения в будущем подобных инцидентов.

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


Безупречность

Концепция безупречности является противоположной культуре, основанной на обвинениях. Несмотря на то что эта концепция обсуждалась уже несколько лет, в основном Сидни Деккером и его сторонниками, настоящую известность она получила после появления поста Джона Оллспоу, посвященного постмортемам, не содержащим упреков (https://codeascraft.com/2012/05/22/blameless-postmortems/ ). Суть этого поста заключается в том, что ретроспектива инцидента будет более эффективной в случае акцента на обучении, а не на наказании.

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


Организационное обучение

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

– Karen E. Watkins and Victoria J. Marsick, Partners for Learning

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

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


Выводы

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

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

Глава 5. Заблуждения и антишаблоны, относящиеся к devops

 Сделать закладку на этом месте книги

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


Общие заблуждения, связанные с devops

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


Devops – это лишь разработчики и системные администраторы

Несмотря на то что название «devops» произошло от слов dev elopment (разработка) и op erations (эксплуатация), оно скорее является напоминанием об источниках происхождения движения devops, чем строгим определением. И хотя на конференциях devopsdays звучит слоган «Конференция, которая объединяет разработку и эксплуатацию», на самом деле концепции и идеи devops охватывают все роли в организации. Не существует единого исчерпывающего списка, регламентирующего, как и какие люди и команды должны быть вовлечены в движение devops. Также отсутствует единый универсальный подход к внедрению devops.

Идеи, которые помогают группам разработчиков и специалистам эксплуатации лучше общаться и более эффективно работать вместе, могут применяться на уровне компании в целом. Можно повысить эффективность любой группы в составе организации, будь то служба безопасности, отдел контроля качества, отдел эксплуатации или юридический отдел. Например, эффективные devops-процессы, внедренные на уровне юридического и коммерческого отделов, позволят реализовать автоматическое формирование контрактов на основе постоянного обновляемого каталога товаров.

Обратите внимание, что благодаря использованию принципов devops выигрывают любые две или большее число команд, поэтому не ограничивайте потенциальную аудиторию пользователей devops и не изолируйте группы сотрудников. В части III будут изложены соображения по эффективному привлечению групп сотрудников к использованию devops.


Devops – это команда

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


убрать рекламу







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

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

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

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


Devops как профессия

Толкование профессии «devops-инженер» является неоднозначным. Некоторые из толкований приведены в следующем списке:

• системный администратор, который знает, как писать программный код;

• разработчик ПО, владеющий навыками системного администрирования;

• мифический десятикратный инженер (производительность этого сотрудника в 10 раз выше производительности других сотрудников, хотя это скорее образное выражение), который может за одну зарплату выполнять обязанности системного администратора и разработчика ПО с наивысшим качеством работы.

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

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

Несмотря на все, что сказано выше, должность «devops-инженер» действительно существует. В соответствии с данными, опубликованными в отчете 2015 DevOps Salary Report от Puppet (https://puppet.com/resources/white-paper/2015-devops-salary-report ), у инженеров, в названии должности которых присутствует слово «devops», зарплата выше, чем у обычных системных администраторов. Конечно, эти оценки весьма приблизительны, поскольку в разных организациях devops-инженеры исполняют самые разные роли. Скажите на милость, кто бы отказался от звания devops-инженера за прибавку в 10 тыс. долларов к зарплате?

В отчете 2015 DevOps Salary Report отмечается, что «большинство devops-инженеров работают более 50 часов в неделю, системные инженеры работают от 41 до 50 часов в неделю, а системные администраторы работают менее 40 часов в неделю». Как видите, никто даром деньги не платит. Если вы получаете высокую зарплату, будьте готовы пожертвовать своим личным временем и здоровьем.


Методология devops связана только с веб-стартапами

Основной продукт интернет-компаний – веб-приложения, с которыми имеют дело пользователи при просмотре веб-сайта компании. Эти сайты часто могут быть реализованы без использования информации, которая хранится где-либо между сеансами взаимодействия пользователей с сайтом (то есть сеансы без отслеживания состояния). Обновление сайта можно выполнить либо поэтапно, либо путем переноса «живого» трафика на новую версию сайта. При этом облегчается процесс непрерывного развертывания.

Несложно понять, почему devops-методики имеют такое значение для интернет-компаний. Это движение помогает разрушить барьеры, которые стоят на пути разработки и развертывания программного обеспечения. Если процессы, реализованные в интернет-компании, настолько медленны, что требуется несколько недель на устранение мелкой ошибки, скорее всего, эта компания не сможет конкурировать с организациями, в которых используются новые гибкие подходы к разработке и развертыванию приложений.

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


Devops нужно сертифицировать

Поскольку devops-методики в большой степени связаны с культурой, сертификация в этом случае вряд ли применима. Невозможно провести 60-минутный экзамен и по его результатам сертифицировать эффективность общения с другими людьми, оценить степень налаженности командной работы в вашей организации и сделать выводы о порядке обучения в организации. Сертификацию имеет смысл применять по отношению к высоким технологиям, использование которых потребует серьезного уровня знаний о таких вещах, как специфическое программное обеспечение или оборудование. Благодаря подобной сертификации компании могут получить представление о знаниях отдельных сотрудников в данной области.

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


Благодаря devops можно сократить персонал

Некоторые полагают, что благодаря devops можно получить разработчика ПО и инженера из службы эксплуатации в одном лице, но не платить ему двойной оклад. Мало того что это мнение ошибочно, оно еще и очень вредно. Многие стартапы предлагают сотрудникам бонусы, такие как трехразовое питание и прачечная на рабочем месте, в надежде стимулировать сотрудников подольше задерживаться на работе, но это приводит к негативным эффектам. Многие инженеры проводят на работе по 60–80 часов в неделю, люди перестают соблюдать баланс между работой и отдыхом, что ведет к переработке и переутомлению.

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

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


Не существует единственно верного пути внедрения devops

Практики и специалисты по внедрению devops, работавшие во времена появления этой методологии, особенно хорошо известные в этой области, например Netflix и Etsy, часто назывались «единорогами»[14]. Они монополизировали рынок «правильных» способов внедрения devops. Другие компании, стремящиеся ощутить преимущества devops-культуры, иногда стремятся подражать этой практике.

Тот факт, что компания представляет собственную успешную devops-стратегию, вовсе не означает, что те же самые процессы позволят корректно внедрить практики devops в другой среде. Принудительный «вброс»[15] процессов и инструментов в среду может привести к дополнительной изоляции и к появлению сопротивления изменениям.

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

Не следует прислушиваться к людям, навязывающим свой способ внедрения devops. Нелишним будет повторить, что существует множество вариантов внедрения devops. Методология devops – это не набор жестко заданных правил, подобно Scrum либо ITIL. Компании, которые наиболее успешно внедрили devops, добились этого путем создания комфортных условий для обучения и итеративного поиска наиболее эффективных инструментов и процессов.


Для внедрения devops нужно X недель/месяцев

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

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

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


Методология devops – это лишь инструменты

Методология devops не требует обязательного применения каких-либо конкретных инструментов. Неверное представление об обязательности использования инструментов способствует формированию убежденности, что devops предназначен исключительно для стартапов, поскольку крупные компании зачастую не склонны внедрять новые технологии.

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

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

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


Методология devops эквивалентна автоматизации

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

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

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




Рис. 5.1. Карикатура на потраченное и сэкономленное время согласно представлению карикатуриста из XKCD (https://xkcd.com/ 1205); изначально была опубликована со следующим текстом: «Не забывайте о том, что на поиск диаграммы, которая позволит узнать, сколько вы сэкономите, тратится время. Также вы тратите время на чтение напоминания о потраченном времени. И тратите время на выяснение разных фактов. Помните о том, что вы тратите секунды вашей жизни на выполнение разных действий, и делаете это сейчас»


РАННИЕ ПРИМЕРЫ АВТОМАТИЗАЦИИ В АВИАЦИИ

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

В июле 2013 года рейс 214 компании Asiana Airlines врезался в дамбу в международном аэропорту Сан-Франциско. В результате этого авиационного происшествия получили смертельные травмы 3 человека. В ходе расследования этого инцидента, проводимого Национальным советом по безопасности на транспорте (National Transportation Safety Board, NTSB), был выявлен ряд причин, способствующих катастрофе. Среди этих причин – недостаточный контроль скорости воздушного судна из-за чрезмерной зависимости от автоматизированных систем, показания которых не всегда корректно интерпретировались пилотами.

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

Джеймс Рисон, Managing the Risks of Organizational Accidents

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


Методология devops вышла из моды

Подобно тому как методология devops не привязана жестко к используемой технологии, инструменту или процессу, нельзя сказать, что она устарела или нуждается в замене. Движение, направленное на повышение эффективности деятельности организации и создание хорошего настроения для каждого сотрудника, может стать привычным и незаметным, но вряд ли когда-либо устареет.

Одно из основных различий между devops и такими методологиями, как ITIL и гибкая разработка (Agile), заключается в том, что последние имеют строгие определения, им присущ постепенно добавляемый контент. С другой стороны, devops – это движение, основанное на историях и идеях, которыми делятся отдельные люди, команды и организации. Это движение выливается в повторяющиеся беседы, эволюцию процессов и идей, которые приводят к росту и изменениям организаций.

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

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

Движение devops объединило эти идеи и смогло достичь значимого успеха (https://bit.ly/2015-state-of-devops ). Обобщение и использование эффективных методик devops приведет к росту и эволюции инструментов, технологий и процессов в вашей организации.


Антишаблоны devops

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


Культура, основанная на обвинениях

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

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

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


Барьеры

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

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

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


Анализ первопричин

Анализ первопричин (Root Cause Analysis; RCA) – это метод идентификации причин возникших событий либо опасных ситуаций и выработки комплекса мер, направленных на предотвращение рецидивов. Это повторяющийся процесс, который продолжается до тех пор, пока не будут идентифицированы все организационные факторы либо пока не будут исчерпаны все данные. Организационный фактор – это фактор, который осуществляет контроль над системой на любом этапе жизненного цикла: проектирование, разработка, тестирование, техническое обслуживание, эксплуатация и списание.

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

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


Человеческие ошибки

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

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


Выводы

Знакомство с терминами, рассмотренными в главе, обеспечит вам углубленное понимание остального материала книги. Вооруженные основной терминологией и концепциями, рассмотренными в предыдущей главе, а также сведениями из главы 3, вы получите более четкое представление о современном состоянии devops. На основе этого представления можно определить и более подробно рассмотреть четыре столпа эффективных devops-методов, что и будет сделано в следующей главе.

Глава 6. Четыре столпа devops

 Сделать закладку на этом месте книги

По мнению Патрика Дебуа, devops является чисто человеческой проблемой (https://bit.ly/debois-devops-culture ). Это означает, что в каждой организации формируется собственная devops-культура, которая является уникальной для людей, принимающих в ней участие. Хотя и не существует универсального «единственно верного» способа внедрения devops во всех организациях, мы идентифицировали четыре общих компонента, с которыми придется иметь дело команде или организации, выделяющей время и ресурсы на внедрение devops.

Внедрение эффективных devops-методик зиждется на следующих четырех столпах:

• сотрудничество;

• близость;

• инструменты;

• масштабирование.

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

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


Сотрудничество

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


Близость

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


убрать рекламу







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


Инструменты

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


Масштабирование

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


Выводы

Благодаря использованию четырех столпов эффективных devops-методик вы можете устранить культурные и технические проблемы, влияющие на разработку программного обеспечения. Эти столпы будут подробнее рассмотрены в каждой из следующих четырех частей книги. Примеры использования этих методик, позаимствованные из практики реального бизнеса, относятся к самым разным компаниям – от веб-стартапов до крупных корпораций. Хотя и необязательно читать главы книги по порядку, но мы все же рекомендуем вам прочесть все главы книги. Это позволит вам осознать, каким образом гармоническое сочетание четырех столпов devops позволит devops-методологии стать по-настоящему эффективной.

Часть II. Сотрудничество

 Сделать закладку на этом месте книги

Глава 7. Совместная работа

 Сделать закладку на этом месте книги

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


Еженедельные совещания в компании Sparkle Corp

«Я действительно думаю, что у нас есть отличная возможность создать наш новый сервис по работе с отзывами на базе MongoDB. Я прочел отличное руководство по этой системе, где рассказывается, как можно быстро и легко разработать нужный нам компонент, не неся бремя административных расходов, как в случае с другими решениями», – сказал Джорди, разработчик внешних клиентских интерфейсов в компании Sparkle Corp.

Заразившись энтузиазмом Джорди, Дженераль прикинула потенциальные выгоды от включения MongoDB в стек инструментов Sparkle Corp. «У кого-нибудь есть какие-либо соображения или опасения по поводу MongoDB?» – обратилась она к группе разработчиков.

«В нашем стеке мы уже поддерживаем MySQL и связанные с ним компоненты. Мы уже вложили достаточно много усилий в интеграцию MySQL. Использование MongoDB приведет к дополнительным затратам на поддержку и техническое обслуживание. Может ли MongoDB дать нам что-то полезное, компенсирующее дополнительные затраты?» – спросила Элис, старший разработчик из компании Sparkle Corp.

Разногласия подобного рода часто проявляются в команде. Каким образом сотрудники могут ухудшить или улучшить отношения в команде? Давайте углубимся в devops-пакт и изучим способы налаживания сотрудничества между коллегами.


Определение сотрудничества

Являясь одним из базовых столпов devops, сотрудничество относится к интенциональным процессам и к общим целям отдельных сотрудников. Практические примеры сотрудничества приведены в следующем списке:

• асинхронный анализ кода;

• документирование;

• выпуски обновлений и отчеты об ошибках;

• демонстрация еженедельного прогресса;

• регулярное обновление статуса;

• парная работа.

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

И помните о том, что зацикливание на единственном типе совместной работы подобно утверждению о том, что бег – это единственная форма физических упражнений.

В январе 2015 года Анита Вулли и ее коллеги представили результаты проведенного анализа деятельности команд в статье «Why Some Teams Are Smarter Than Others» (https://www.nytimes.com/2015/01/18/opinion/sunday/why-some-teams-are-smarter-than-others.html?_r=0 ), опубликованной в New York Times . В терминологии, предлагаемой Вулли, умные команды отличаются от прочих команд следующими характеристиками:

• связь;

• равное участие;

• модель психического состояния человека.

Другими словами, эффективное сотрудничество включает такие компоненты, как связь, равное участие и модель психического состояния человека (Theory of Mind; ToM). Компонент ToM – это способность идентифицировать свою перспективу и признать факт, что другие сотрудники имеют иные перспективы в силу индивидуальных отличий. Осознание различий между людьми и влияние этих различий на потенциальную перспективу поможет расширить свою собственную модель ToM, сформировать взаимное понимание и помочь разрешить конфликты, что критически важно для devops-пакта. Все это поможет усилить коллективный разум команды.


Индивидуальные различия и навыки

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


Профессиональные навыки

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


Зависимость профессиональных навыков от размера компании

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

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


Влияние технического и гуманитарного образования

У людей, имеющих техническое и гуманитарное образование, могут возникать трения. Это может проявиться на уровне компании, когда инженерно-технический персонал расценивается как более ценный для компании. А с персоналом из отделов поддержки, продаж и маркетинга будут обращаться как с людьми второго сорта. Если подобные настроения овладеют умами всех менеджеров, например инженерами-соучредителями стартапа на ранних стадиях, это может привести к воцарению уныния среди обслуживающего персонала. Персонал должен ощущать адекватную оценку его труда.


Иерархии ролей

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

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


Способы получения инженерной специальности

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

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

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


Опыт работы

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

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


Личные качества

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

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

Подобные изменения могут быть достаточно простыми, например выбор другого стиля обращения членов команды друг к другу. Скажем, вместо приветствий в стиле «Привет, парни», «Как дела, чувак?» или «Господа» используйте более нейтральное приветствие, например «Привет, народ». Не позволяйте себе двусмысленных шуток, которые, вместо того чтобы снять напряжение, приведут к его нагнетанию. Также не забывайте о распределении рабочих часов и о соблюдении баланса между работой и личной жизнью. Представьте себе команду, состоящую из молодых одиноких людей, которые привыкли засиживаться на работе допоздна, а потом еще и пропускать рюмочку-другую. И вот в эту команду попадает одинокий отец, которому нужно забирать ребенка из детского садика в 6 часов вечера. Естественно, он не сможет принимать участие в бурной жизни своих коллег и будет исключен из социальных отношений.

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

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

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


Цели

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

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

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

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


Когнитивные стили

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

• как они думают о разных вещах;

• как они учатся и усваивают новую информацию;

• как они мысленно связаны со своей работой, своей средой и окружающими людьми.

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

Интроверт, амбиверт и экстраверт 

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

Спрашивающий или догадливый 

Культура вопросов и догадок ведет свое начало от поста на интернет-форуме, написанного в далеком 2007 году. В этой публикации шла речь о различных способах, используемых людьми для получения информации от других людей. Те, кто спрашивают, предпочитают задавать вопросы в большинстве ситуаций, даже если понимают, что могут получить ответ «нет». Ну а любители догадок предпочитают получать информацию самостоятельно, избегая задавать вопросы, если не уверены, что получат ответ «да».

Разъяснение и документирование стиля общения, ожидаемого от членов команды, может помочь им прийти к взаимопониманию и избежать проявлений недовольства.

Стартер или финишер 

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

Аналитики, критики и универсалы 

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

Пуристы или прагматики 

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

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

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


Возможности по достижению конкурентных преимуществ

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

Наставничество 

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

Спонсорство 

Помимо наставников пользу персоналу организации также приносят спонсоры, которые оказывают поддержку и защищают своего протеже. Спонсоры также инвестируют развитие отношений, приводящих к формированию взаимовыгодного альянса. Спонсоры способствуют продвижению своего протеже по службе, делают его своим фаворитом, способствуют росту самосознания своего протеже, а также обеспечивают связи с высшим руководством. На основе исследования карьеры 12 тысяч мужчин и женщин в Великобритании и США экономист Сильвия Энн Хьюлетт пришла к выводу, что для достижения ощутимых успехов в карьере спонсорство важнее наставничества (https://www.nytimes.com/2013/04/14/jobs/sponsors-seen-as-crucial-for-womens-career-advancement.html?_r=0 ). В каждой организации следует разработать комплексную программу по обучению сотрудников навыкам, необходимым для осуществления спонсорства, способам оценки потенциального протеже и методикам поиска и оценки спонсоров.

Образование 

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

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

– Ричард Бренсон

Наставничество

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


Наставничество молодежи старшими

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


Наставничество старших со стороны старших

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


Наставничество старших со стороны младших

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


Наставничество младшего со стороны младшего

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


Знакомство с образом мышления

Образ мышления – это наши представления о себе и о том, как мы используем наши возможности. После нескольких лет исследований в области мотивации доктор философии Кэрол С. Двек описала фиксированный образ мышления и образ мышления роста[16]. Под фиксированным образом мышления  пони


убрать рекламу







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


Культивирование правильного образа мышления

Джейсон Мозер, доцент кафедры психологии в Университете штата Мичиган, в 2011 году опубликовал статью, посвященную исследованию нервных механизмов, которые лежат в основе образа мышления (https://cpl.psy.msu.edu/wp-content/uploads/2011/12/Moser_Schroder_Moran_et-al_Mind-your-errors-2011.pdf ). Он отметил, что при выполнении задач и совершении ошибок у лиц с фиксированным образом мышления наблюдается меньшая активность мозга, чем у лиц с образом мышления роста. Эти выводы согласуются с заключениями о том, что образ мышления роста связан с адаптивными ответами на ошибки. Изменение способа мышления буквально изменяет функционирование мозга и его реагирование на ошибки.

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


Фиксированный образ мышления

Фиксированный образ мышления исходит из предположения о том, что навыки и черты характера являются врожденными и неизменными. Этот образ мышления заставляет людей постоянно доказывать что-то другим. Если кто-то считает, что характеристики являются врожденными, а люди являются либо умными, либо не слишком умными, он будет постоянно доказывать себе и окружающим, что попадает в категорию умных.

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

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


Образ мышления роста

Обладатель образа мышления роста гораздо больше поддается индивидуальному обучению и воздействию учебной среды. Человек, обладающий образом мышления роста, полагает, что его знания и навыки изменяются со временем. Если он в данный момент не осведомлен о той или иной области, то при наличии достаточного количества времени, усилий, обучения и практики может устранить этот недостаток. Конечно, это вовсе не означает, что любой человек может стать Альбертом Эйнштейном или Марией Кюри, но любой навык может до какой-то степени улучшиться.

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


Индивидуальный рост

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


Изучите основы

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

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

Также, если мы долго занимаем какую-то должность, мы не всегда замечаем, как она изменилась за этот период времени. Но если мы постоянно осваиваем основные навыки и умения, то будем всегда соответствовать занимаемой должности.

Для начала нужно ответить на вопрос, кто и что делает и почему. Вряд ли вам захочется в случае возникновения каких-либо проблем выяснять, кто и за что несет ответственность. Узнайте эти основные моменты заранее, чтобы в случае возникновения чрезвычайной ситуации не тратить драгоценное время.

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

Для отслеживания происходящих событий гораздо полезнее обычная записная книжка, чем ноутбук. Записывайте в записную книжку, кто что делает и почему. Например, в случае какого-либо происшествия запишите фамилию сотрудника, ответственного за этот участок работы. Зафиксируйте результаты выполнения работ по устранению возникших проблем. Это даст возможность в будущем гораздо быстрее и лучше устранять подобные проблемы.

Согласно данным исследований, записывание способствует запоминанию и лучшему усвоению нового материала[17].


Развивайте свою нишу

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

Этот новый навык не должен быть непосредственно связан с тем, что вы сейчас делаете, а направлен на устранение «узких мест» в организации. Например, если вы работаете в эксплуатационном отделе и отвечаете за поддержку хранилища данных, можете приступать к осваиванию других алгоритмов работы с хранилищами данных, такими как LevelDB (быстрая библиотека «ключ/значение», написанная Google).

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

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

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


Признайте свои сильные стороны и оцените свой прогресс

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

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

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

Yo soy yo y mi circunstancia. (Я – это я и мои обстоятельства.)

– Хосе Ортега-и-Гассет

В конце 1960-х годов в процессе изучения индивидуальной производительности программистов Сакмен, Эриксон и Грант обнаружили, что производительность некоторых инженеров существенно превышает показатели «общей серой массы». Со временем идея более производительного инженера превратилась в мантру некоторых компаний: «Мы берем на работу только 10x инженеров».

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

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


Закрепляйте обучение качественной практикой

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

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

Второй способ выполнения неосознанной практики – метод автопилота. Многие люди с многолетним опытом вождения действуют на автопилоте. Даже если мы стареем, что приводит к изменению наших возможностей, все равно не стоит злоупотреблять этим методом. Нужно уметь вовремя распознать изменение среды и не позволять себе застревать на стадии рутинной практики, следует стремиться к постоянному развитию.

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


Выработайте свой рабочий стиль

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

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

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

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


Расширение командного стиля

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

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


Образ мышления и обучающие организации

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

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

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


Роль обратной связи

В результате многолетних исследований Кэрол Двек обнаружила, что ключевым фактором развития является обратная связь с людьми независимо от того, обладают ли они фиксированным образом мышления или образом мышления роста. Если кто-то за хорошую работу получает похвалу (хорошая работа, ты очень умный), это приводит к формированию фиксированного образа мышления. Такой человек вряд ли возьмется за решение сложных задач либо выполнение работы, которая может поставить под сомнение его высокие умственные способности. С другой стороны, если сотрудник получит похвалу в следующей форме: «Хорошая работа, вам было очень тяжело», он свяжет свои успехи с затраченными усилиями, а не со своими врожденными качествами. Такие люди склонны к решению более сложных задач и к устранению проблем.

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

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

Учитывайте оба этих подхода во время совещаний с сотрудниками и сеансов обратной связи. Если кто-то предоставляет обратную связь в качестве руководителя или сотрудника, ему следует сосредоточиться на усилиях и действиях сотрудника, на работе и мыслях. При этом обращайте внимание на то, что может делать сотрудник, а не на него самого. В результате вы поспособствуете развитию у него образа мышления роста.

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

Фиксированный образ мышления 

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

Образ мышления роста 

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

Как же Элис ответила на эту обратную связь? Несмотря на то что сообщение «хорошо разбирается в распределенных системах, требуется улучшение работы с людьми» воспринимается вполне однозначно, ответы на него могут сильно отличаться. Ответы, присущие людям с фиксированным образом мышления, звучат так: «умный человек», «интуитивно понимает», «это не тот человек». Эти фразы предполагают наличие врожденных черт характера и неизменных фактов, относящихся к Элис. Ответы, присущие людям с образом мышления роста, имеют следующий вид: «огромный объем работы», «эти усилия показывают», «найти способы, чтобы поделиться знаниями». Эти фразы относятся к работе и действиям Элис, к тому, что она делала в прошлом и планирует делать в будущем.


Обзоры и рейтинги

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


Частота обратной связи

В соответствии с данными, приведенными в статье журнала Wall Street Journal  (https://www.wsj.com/articles/SB10001424053111903895904576542962030419874 ), опубликованной в 2011 году, 51 % компаний выполняют рабочие обзоры ежегодно, а 41 % делают это два раза в год. Со временем все больше компаний начинают понимать, что обратная связь и обзоры будут иметь большее значение в случае более частого проведения. При этом обратная связь должна быть полезной для тех, на кого она направлена. Очевидно, что если обратная связь не включает новые или полезные данные, вряд ли стоит проводить ее чаще. Если же обратная связь является полезной и актуальной, повышение ее частоты ведет к большим преимуществам как для отдельных лиц, так и для организаций.

Если кто-то отклоняется от верного пути при выполнении каких-либо действий, длительное ожидание следующего ежегодного обзора вряд ли устроит заинтересованных лиц. Скорее всего, они будут думать, что все делают правильно, ну а публикация очередного обзора станет неприятным сюрпризом. Психология, связанная с получением обратной связи, показывает, что люди обычно реагируют на подобные сюрпризы эмоционально, а не интеллектуально. Этот феномен известен под названием захват миндалины  (amygdala hijacking)[19]. В результате люди не могут полностью понять и быть в состоянии действовать адекватно в ответ на обратную связь.

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


Система рейтингов

В более или менее крупных организациях часто применяются разные системы ранжирования для категоризации или классификации производительности сотрудников. Одно из самых больших изменений, имевших место в последние годы, заключалось в отказе от группового ранжирования , которое также известно как принудительное ранжирование  или принудительное распределение . Эта практика активно продвигалась в 1980-е годы тогдашним генеральным директором компании General Electric  Джеком Уэлчем. Эта методика основывалась на утверждении о том, что лучшие 20 %  сотрудников являются наиболее продуктивными и выполняют 70 % всей работы. Худшие 10 % сотрудников должны быть уволены. Эта практика часто упоминается как метод «ранга и пинка». Подобная практика ранжирования заставляла сотрудников всячески избегать попадания в худшие 10 %.

Когда отдельные люди, находящиеся в системе, вынуждены конкурировать с другими людьми, это приводит к появлению дополнительных проблем на пути к эффективному сотрудничеству. Очевидно, что «прозрачные» коммуникации не воспринимаются в качестве ценности людьми, которые опасаются, что попадание информации в чужие руки может повлиять на получение наград, продвижение по службе и даже на наличие самой работы. Групповое ранжирование, особенно в том случае, когда особенности этого процесса плохо объяснены окружающим, может привести к падению производительности вместо ее повышения, но в последние годы многие организации отказываются от этой методики[20].

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

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

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


Проблемы, порождаемые звездами и суперстаей

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

В выпуске TED Talk, вышедшем в июне 2015 года (https://www.ted.com/talks/margaret_heffernan_why_it_s_time_to_forget_the_pecking_order_at_work?language=en ), представитель международной компании Маргарет Хеффернэн воспользовалась термином «суперкурица» для описания способа найма элитных профессионалов. Выбор этого термина основывался на результатах исследований эволюционного биолога Уильяма Мьюира из Университета Пердью.

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

Подобное можно наблюдать и в рабочей среде. В результате исследований про


убрать рекламу







изводительности и творческих подходов к решению проблем, проводимых Массачусетским технологическим институтом (https://hbr.org/2012/04/the-new-science-of-building-great-teams ), обнаружилось, что наиболее продуктивные и творческие команды не состояли сплошь из «суперинженеров». Ум и инженерный талант вовсе не гарантировали создания наилучших команд. Скорее наилучшие команды характеризовались повышенной социальной чувствительностью, уделяли больше времени для общения друг с другом и включали больше женщин. Было неясно, каким образом преобладание женщин в команде влияет на формирование более высокой чувствительности к состоянию психики других сотрудников и на рост числа разговоров (женщины зачастую более чуткие, больше слушают, чем говорят, и реже перебивают собеседника). С другой стороны, очевидно, что решающими факторами роста производительности команды были повышенная социальная чувствительность либо способность распознавать и понимать чувства других людей, общие социальные представления и общение в команде.


Значение социального капитала для команды

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

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


Стили общения и разрешения конфликтов

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

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


Результативное общение

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

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


Углубление понимания

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

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

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


Утверждение влияния

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


Получение признания

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

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


СООБЩЕСТВО ПРАКТИКОВ И СООБЩЕСТВО ПО ИНТЕРЕСАМ

Сообщество практиков – это группа людей, которые исполняют одну и ту же роль или озабочены общими проблемами и регулярно встречаются с целью улучшения работы на уровне организации. Каждая роль в организации обладает потенциалом для формирования сообщества практиков. В результате может формироваться сообщество разработчиков, сообщество специалистов по качеству и сообщество scrum-мастеров. Сообщества практиков могут также формироваться на основе определенных инструментов или языков, но в любом случае они не ограничиваются одним проектом или командой. Эти сообщества обычно работают лучше всего, если не создаются принудительно менеджерами, а могут расти и меняться естественным образом. Деятельность сообщества характеризуется всплесками и провалами по мере исполнения ролей и выполнения проектов. Важно отметить, что сообщество практиков ограничено людьми, которые активно исполняют роли, актуальные для сообщества, поэтому обучение и дискуссии будут происходить с носителями знаний и жизненного опыта.

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


Построение сообщества

Благодаря укреплению личных связей наравне с улучшением общения облегчается формирование сообщества. Согласно выводам, полученным в результате проводимых Массачусетским технологическим институтом исследований (https://hbr.org/2012/04/the-new-science-of-building-great-teams ), команды с большими показателями ToM и более равноправным общением являются более творческими и продуктивными. Аналогичные характеристики важны для формирования сообщества. В командах, члены которых регулярно общаются на темы, не предусмотренные жестким рабочим регламентом, формируется более высокий уровень доверия и эмпатии. На уровне группы эти команды будут более продуктивными и стрессоустойчивыми. Люди зачастую лучше общаются на индивидуальном уровне, если они видят друг в друге личностей, а не перечень адресов электронной почты или записи в каталоге персонала компании.

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

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


Выбор способа общения

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

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


Средства осуществления общения

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


Таблица 7.1. Средства и методы общения




А теперь рассмотрим записи в столбцах таблицы подробнее.

• Безотлагательность  – скорость установления связи. Например, личный визит имеет высокую степень безотлагательности, поскольку вы можете похлопать кого-то по плечу и вмешаться в разговор, в то время как электронная почта имеет низкую степень безотлагательности, поскольку вы не можете контролировать частоту проверки почтового ящика вашим собеседником. Собрания имеют низкую степень безотлагательности, поскольку планирование приглашенных людей и мест для встречи может занимать очень много времени.

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

• В столбце Инвестиции  описывается количество времени и усилий, требуемых от людей для использования выбранного средства общения. Совещаниям присущ наибольший объем инвестиций, поскольку люди должны прерваться, прийти на место проведения совещания или же выбрать удаленное участие. Электронная почта, книги, сообщения в блогах требуют среднего объема инвестиций, поскольку нужно найти время на чтение. А вот такие средства общения, как чат или Твиттер, требуют небольшого объема инвестиций.

• В столбце Требуемый контекст  описан объем контекста, требуемый для выбранного средства общения. Если требуемый объем контекста не обеспечивается, это приведет к определенному недопониманию. Твиттер, чат и сообщения электронной почты требуют большой объем контекста, поскольку, чем короче фразы, тем проще извратить их смысл, что ведет к появлению недопонимания. При проведении видеоконференций требуется меньший объем контекста, поскольку собеседники воспринимают язык тела, слышат голос и тон, что позволяет им быстро устранить возникшее недопонимание.

• В столбце Организация  описано, как должны быть организованы мысли и идеи, циркулирующие в среде. Совещаниям присуща высокая степень организации, поскольку требуется повестка дня, чтобы не тратить впустую время участников. Электронная почта характеризуется средней степенью организации, поскольку людям нужно немного упорядочить свои мысли перед отправкой сообщений. Благодаря скорости обмена сообщениями и краткой форме чат и Твиттер характеризуются низкой степенью организации.

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


Переговоры и стили разрешения конфликтов

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

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

• Аккомодация , когда кто-то соглашается на удовлетворение потребностей другого человека за счет своих личных интересов. Иногда целью оказания помощи человеку является установление отношений с ним. Например, один сотрудник может принять решение оказать поддержку другому сотруднику в надежде, что тот запомнит оказанное благодеяние и ответит «добром на добро».

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

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

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

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


Контекст общения и неравноправие позиций

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


Контекст и местоположение

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

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

Один из способов избежать описанных в предыдущем абзаце проблем – внедрить практику общения в форме «удаленный по умолчанию». Это означает использование дружественных к удаленным сотрудникам методов общения, преимущественно по электронной почте или с помощью группового чата. Эти способы по возможности используются в первую очередь. Если вместо того, чтобы подойти с вопросом к рабочему столу коллеги, сотрудник отправит сообщение в комнату чата команды, удаленные сотрудники получат шанс научиться чему-то новому и принять участие в дискуссиях, что раньше было невозможно. Это приведет к большему количеству информации и лучшей ее видимости для всей команды, и это может стать аргументом в пользу групповых чатов вместо общения «с глазу на глаз» или использования приватных комнат чатов для обмена открытой или представляющей всеобщий интерес информацией. И наконец, возможность создавать записи бесед будет просто бесценной.


Неравноправие позиций

Контекст также часто включает сведения о неравноправии позиций, которое может иметь место в организации в силу самых разных причин. Эти причины могут быть столь же простыми, как и дополнительные полномочия, предоставляемые, например, менеджерам, которые наделены б́ольшими полномочиями, чем старшие инженеры. Ну а старшие инженеры наделены б́ольшими полномочиями, чем рядовые сотрудники. Неравноправие позиций может принимать и более тонкие формы: например, члены групп, недостаточно хорошо представленных в сфере высоких технологий (женщины, представители расовых меньшинств либо приверженцы однополой ориентации). Эти люди обладают меньшими полномочиями, чем члены лучше представленных или доминантных групп.

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

АНТИШАБЛОНЫ DEVOPS: ОБЩЕНИЕ И ПЕРЕБИВАНИЕ ДРУГ ДРУГА

Хотя следующее высказывание – «делать X означает внедрять devops» – практически неосуществимо, зачастую можно идентифицировать основные факторы этого движения, наблюдая за антишаблонами. В этом случае более уместна следующая фраза: «если вы делаете Y, вы не внедряете devops». На страницах этой книги мы проиллюстрируем, по необходимости, некоторые из этих антишаблонов. При этом будут использованы примеры или мини-практики, которые помогут продемонстрировать причины неэффективности некоторых типов поведения или практик.

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

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

Например, исследования показали (https://fortune.com/2014/08/26/performance-review-gender-bias/ ), что когда женщины произносят те же фразы, что и мужчины, они воспринимаются более «жестко», «остро» или «агрессивно». Мужчины же за подобные фразы награждаются такими эпитетами, как «прямолинейный» и «держащий все под контролем». С другой стороны, женщины часто смягчают негативные оценки, используя уменьшительные суффиксы или такие слова-паразиты, как «секундочку». Если они перебивают собеседника столь же часто, как и коллеги-мужчины, они расцениваются как «нежелательные». Но если женщины не перебивают своих коллег, их мнение вряд ли будет услышано. Подобные виды контекста могут оказывать огромное влияние на успешность нашего общения. Это следует иметь в виду при работе над улучшением разнообразия и инклюзивности команды.


Эмпатия и доверие

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

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


Развитие сопереживания

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

И хотя чувство сопереживания обычно развивается в детстве, существует много способов вызвать и развить его в зрелом возрасте. Рассмотрим некоторые из наиболее распространенных и эффективных способов, а также методы их применения на рабочем месте.


Выслушивание

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

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

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


Задавайте вопросы

Задавание вопросов после выслушивания является отличным способом формирования понимания и разъяснения смысла (как часть активного слушания). Помимо задавания вопросов другим людям можно также задавать вопросы самому себе. Культивирование люб


убрать рекламу







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

Вопросы могут принимать следующую форму: «Не могли бы вы объяснить, что имели в виду, когда сказали…?» или же иметь более теоретический характер, например «Где находится поезд, на котором едет наш гость? Какие сайты он просматривает на своем смартфоне?». Также вопросы могут представлять некоторую форму самоанализа, например: «Какие бессознательные факторы влияют на мое мнение по этому поводу?» В сочетании с прослушиванием ответов, которые мы получим либо от других сотрудников, либо от самих себя, задавание вопросов может быть очень мощным инструментом для формирования сопереживания.


Представьте себя на месте других людей

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


Оценка индивидуальных различий

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

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


Развитие доверия

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

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

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

Для увеличения степени доверия могут использоваться разные стратегии, но прежде всего следует создать обстановку, которая обеспечивала бы реальное и надежное сотрудничество. Один из факторов, отличающий настоящую команду от простой группы, – наличие доверия. В следующих разделах будут рассмотрены такие стратегии: быстрое доверие; самораскрытие; доверяй, но проверяй; ощущение справедливости.


Быстрое доверие

Быстрое доверие формируется в краткосрочных или короткоживущих группах или организациях. Такая форма предполагает изначальную установку доверительных отношений с последующей коррекцией с течением времени. Эту форму доверия впервые исследовала специалист в области организационного поведения д-р Дебра Мейерсон[21]. Подобное доверие часто имеет место в быстро созданных группах или командах в условиях дефицита времени. Это время требуется на развитие доверия способом, обычно применяемым в условиях долговременных отношений (в данном случае подразумеваются любые отношения между людьми, а не только романтические отношения). В силу ограниченного запаса времени изначально предполагается, что члены команды заслуживают доверия. Позднее это отношение может пересматриваться, в зависимости от действий членов команд.


Самораскрытие

Согласно результатам исследований, проводимых в течение некоторого времени (https://hbr.org/2012/06/instantaneous-intimacy-skillfu ), самораскрытие является одним из признаков наличия доверительных отношений. Если вы достаточно открыты, чтобы поделиться с окружающими сведениями личного характера, это будет способствовать росту чувства доверия и близости между людьми, а также приведет к усилению взаимодействия и сотрудничества. Конечно, существует баланс самораскрытия на рабочем месте, который не рекомендуется нарушать. Если самораскрытие недостаточно, это приводит к росту подозрений. У людей могут возникать вопросы о возможном сокрытии какой-то информации, что, в свою очередь, приводит к кризису доверия. Но и чрезмерное самораскрытие тоже вредит. Разглашение сведений личного характера может подорвать авторитет и тоже привести к кризису доверия.


Доверяй, но проверяй

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


Ощущение справедливости

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

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


Персонал и кадровые ресурсы

Одно из последних соображений, которое следует учитывать при рассмотрении сотрудничества, – стоимость «человеческого капитала», задействованного в создании и поддержке ПО. Зачастую от этих людей требуется постоянная доступность в режиме 24/7/365. Одним из движущих факторов, приведших к появлению devops, были неблагоприятные последствия, к которым привела господствующая в то время практика разработки программного обеспечения. Суть этой практики заключалась в создании отдела техобслуживания и выделении серверов, на которых выполнялось программное обеспечение. После появления методик непрерывной интеграции и инфраструктуры, а также использования улучшенного кода положение дел в этой области улучшилось, хотя и остались определенные нюансы.


Доступность и техническая поддержка

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

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

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


Баланс между работой и личной жизнью

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

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


Выбор размера команды

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

В подобной компании несколько команд (обычно три) распределены по всему миру. Каждая команда отрабатывает свой рабочий день. Эти команды находятся настолько далеко друг от друга, что начало рабочего дня одной команды совпадает с завершением рабочего дня другой команды. Благодаря этому обеспечивается круглосуточная доступность команд, которым к тому же не приходится работать ночами.

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

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

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


Эффективное сотрудничество в компании Sparkle Corp

После быстрого просмотра заметок, относящихся к дискуссии о применении MongoDB и MySQL, Дженераль заметила, что еще не все выразили свое отношение к MongoDB. Кроме того, она не владела достаточной информацией, необходимой для одобрения конкретной стратегии. «Элис, я хотела бы видеть тебя и Джорди, чтобы узнать о возможностях и преимуществах MongoDB либо услышать доводы в пользу дальнейшего использования MySQL. Возможно, вы сможете продемонстрировать что-нибудь простенькое на сеансе еженедельной демонстрации, который состоится на этой неделе? Мы вернемся к этой дискуссии на следующей неделе, перед продолжением внедрения конкретного решения. Если кто-то желает что-то добавить, пожалуйста, отправьте предложение по электронной почте всем членам команды», – сказала Дженераль.

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

У меня есть опыт работы с MongoDB. Если эту систему использовать для выполнения не слишком сложных транзакций, она обеспечивает быструю разработку приложений и проста в применении. Я полагаю, что контролирующая служба реализует этот сценарий на основе нашего текущего понимания проекта. Я чувствую, что мы должны синхронизироваться с менеджером проекта, чтобы достичь исчерпывающего понимания наших ожиданий. Нам также следует включить эксплуатационную команду, которая будет предоставлять нам отчеты о затратах на управление программным обеспечением. У меня есть немного времени, чтобы выполнять необходимые экспертные оценки.

Джози чувствует себя более комфортно, излагая свои мысли в автономном режиме, с последующей отправкой в письменном формате средствами электронной почты. Как и многие интроверты, она рассылает письма членам команды, ставя их в известность о своих планах. В соответствии с культурой «отвечать всем», принятой в Sparkle Corp, Элис и Джорди вступили в дискуссию, а Элис добавила эксплуатационную команду в обсуждение.


Выводы

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

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

Хотя следующее утверждение может показаться нелогичным для людей, у которых создается впечатление о высокотехнологичной природе devops, но все же именно оно заложено в основу концепции devops. Изначально цель движения devops заключалась в формировании двух разных команд, которые свободно общались бы между собой. В качестве способа начать этот диалог, который продолжается и развивается в наши дни, использовались события devopsdays. В части III мы генерализуем эти идеи с отдельных сотрудников на команды, а затем – на организации в целом.

Глава 8. Сотрудничество: заблуждения и устранение проблем

 Сделать закладку на этом месте книги

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

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


Заблуждения, связанные с сотрудничеством

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


Невозможно научить старого сисадмина новым трюкам

Считается, что люди, привыкшие к изоляции, никогда не смогут работать в более открытой или кросс-функциональной среде. Ярким примером может служить карикатурный образ угрюмого системного администратора, так называемого «чертова ублюдка» (Bastard Operator From Hell; BOFH), упомянутого в главе 3. С другой стороны, среди практиков с большим опытом работы, например представителей «старой школы» UNIX, часто возникает стремление стать разработчиком, чтобы не потерять работу. Весьма часто люди испытывают опасение, что при переходе в коллаборативную среду devops от них могут потребоваться новые навыки.

На самом деле освоение новых навыков доступно практически каждому человеку, причем независимо от того, идет речь о новых технологиях или о более «мягких» навыках, например наставничестве или сопереживании коллегам. Конечно, освоение новых навыков потребует времени и усилий, – вряд ли вы сможете научиться чему-либо мгновенно.

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

Если же вы сами ищете работу и переживаете о том, что ваш набор навыков вскоре устареет, примите к сведению, что, несмотря на появление новых облачных технологий и повсеместное распространение контейнеризации, работодатели по-прежнему ищут сотрудников с обширным набором навыков. В данном случае ключ к успеху заключается в поиске подходящей команды или позиции. Человек, владеющий навыками администратора выделенного сервера UNIX или сетевого инженера, вряд ли найдет место в только что созданном стартапе, планирующем выпустить свой первый продукт, поскольку подобная компания обычно использует веб-службу хостинга Amazon EC2. Но когда идет речь о более крупной и зрелой компании или центре обработки данных, подобную вакансию найти вполне реально. Тем более что, несмотря на все разговоры, крупные компании не собираются исчезать в ближайшее время.


Чтобы обеспечить быстрый рост, нужно нанять «звезд»

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

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


В разнородных командах невозможно эффективное сотрудничество

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

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


Устранение проблем, связанных с сотрудничеством

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


Не все участники команды справляются со своими обязанностями

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

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


ОЖИДАНИЯ ОТ РОЛЕЙ

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


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

Помимо этих более контекстных причин, существуют личные причины невыполнения работы надлежащего качества или в достаточном объеме:

• индивидуальное или семейное здоровье;

• недостаток самостоятельности;

• отсутствие вознаграждений;

• несоответствие работы и ожиданий от вхождения в состав команды;

• быстро изменяющиеся цели или

• изменяющаяся работа.

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

• удаленная работа;

• гибкое планирование;

• переоценка задач и разделение труда;

• обучение;

• наставничество;

• общественное признание или

• регулярные тренинги по мере необходимости.

Тщательно отслеживайте признаки выгорания, поскольку физическое и психическое здоровье сотрудников имеет большое значение. Выгорание – это не только отдельная проблема, но и признак возникновения проблем в производственных условиях.


Мы должны решить, нужно ли кому-то уйти

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


убрать рекламу







ник прошел как минимум один курс обучения или тренинга, дайте ему достаточно времени на работу (обычно не меньше шести месяцев). Если обучение осуществляется лишь в одном стиле, это может существенно сказаться на прогрессе в освоении нового материала.

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

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

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

СООТВЕТСТВИЕ КУЛЬТУРЕ

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


У меня переутомление, стресс и выгорание

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


Кратковременные стратегии

В краткосрочной перспективе найдите как можно больше способов, чтобы поддержать себя и выделить пространство для восстановления:

• Откажитесь от проверки рабочей электронной почты и перестаньте заходить в чат.

• Делегируйте задачи или временно откажитесь от работы.

• Обратитесь за помощью к профессионалу, ведь психическое здоровье не менее важно, чем физическое.


Долговременные стратегии

Будет нелишним проанализировать ваши текущие обязанности:

• Для каждой из обязанностей попытайтесь оценить возможность по уменьшению нагрузки.

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


Идентифицируйте единые точки ответственности

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

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

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


Некоторые участники команды чувствуют неуважительное отношение к себе

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

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

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

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

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


Недостаточный уровень общения

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

Если создается впечатление, что отдельные люди не склонны общаться между собой, это может быть связано с недостаточным доверием на рабочих местах. Это сплошь и рядом бывает в культурах, основанных на упреках. В подобных культурах принято искать виновников и наказывать их по полной программе. По вполне понятным причинам люди, работающие в подобных организациях, начнут бояться высказываться и будут скрывать информацию. Но такой культурный сдвиг требует определенного времени, поэтому вовремя принятые меры дадут свои результаты. Если люди увидят, что высказывания поощряются, а не наказываются, они начнут общаться. Также может помочь детальный разбор происшедших инцидентов. Главное, чтобы в этих словах не содержались упреки, адресованные виновникам инцидентов.

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

Также могут вступать в игру разные культурные и личные разногласия. В международных командах, в которых имеют место разные культурные традиции, некоторые люди кажутся более сдержанными или немногословными, чем другие. Подобная манера общения и поведения объясняется культурными и национальными особенностями. На стиль общения оказывают влияние рабочие стили и свойства личности. Поэтому некоторые люди обычно более сдержанны, чем другие. Они не рассказывают открыто о своей работе или достижениях, поскольку боятся прослыть хвастунами. Есть и такие, кто предпочитает общаться на стороне, за пределами своей команды. Предоставляйте людям возможность рассказать о своих предпочтениях. И если эти предпочтения различаются, организуйте в командах дискуссии о среде, в которой можно наладить общение.


Сотрудник (или соискатель) – технический гений и асоциальный тип

Все мы тратим массу времени и сил на проведение отбора и интервьюирования, чтобы избежать ошибок при найме людей на работу. Но порой сотрудники службы персонала идут на все, чтобы обосновать необходимость приема на работу хорошего специалиста, обладающего сомнительными моральными качествами. Например, на работу берут классного инженера, негативно настроенного по отношению к социуму. Подобное решение аргументируется тем, что вклад такого человека в общую работу будет перевешивать негативные последствия межличностного общения. Ярким примером такого инженера является Линус Торвальдс. Ему прощают резкие высказывания только за то, что он создал Linux.

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

• Сколько людей хотят уйти из вашей организации, поскольку не могут работать вместе с этим человеком?

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

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

• Сколько времени было потрачено на поиск подхода к человеку, который негативно влияет на производственный процесс?

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


Я не ощущаю карьерного роста в моей команде/организации

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

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

Учитывайте различия между наставничеством  и спонсорством . На эту тему уже много чего сказано, но лучше всех выразилась Кейт Хьюстон, начальник отдела по мобильным разработкам в компании Ride. Она сказала (https://www.catehuston.com/blog/2014/04/16/sponsors-mentors-and-allies/ ), что спонсорство присуще людям, обладающим соответствующими полномочиями, которые они используют по отношению к людям с меньшими полномочиями. Наставники предоставляют консультации и дают советы, а спонсоры защищают своих подопечных. Благодаря хорошему спонсору можно защитить свое доброе имя и получить поддержку, нужную для продвижения.

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

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

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


Никто меня не слушает

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

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

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

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


Реорганизация или сокращение

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

Задайте себе следующие вопросы.

Знаете ли вы причины реорганизации или сокращения? 

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

В какой форме было сообщено о реорганизации или сокращении? Было ли это сообщение своевременным? 

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

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

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

Испытали ли вы несколько реорганизаций за последние 12 месяцев? В жизненном цикле компаний регулярно наступает фаза сокращения .

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

Действительно ли у вашей команды недостаточно ресурсов? 

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

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

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

Часть III. Близость

 Сделать закладку на этом месте книги

Глава 9. Формирование близости между отдельными сотрудниками и командами

 Сделать закладку на этом месте книги

Независимо от выполняемых обязанностей, например составления должностных инструкций или рабочих отчетов, многие люди выполняют работу внутри одной команды. Однако между командами, организационными единицами и даже компаниями существуют отношения, которые влияют на скорость выполнения и ценность результатов труда. Американский психолог Марк Грэноветтер в своей статье The Strength of Weak Ties  («Сила слабых связей»), вышедшей в 1973 году, описал важность этих отношений, комбинации сильных и слабых связей между людьми, а также способа распределения информации по этим связям[22].


Демонстрационный пример по разработке программ в компании Sparkle Corp

Благодаря опыту работы с MongoDB Джози помогла Элис и Джорди быстро запустить несколько виртуальных машин, применяемых для сравнения и демонстрации MongoDB и MySQL. Они создали демонстрационный пример в виде простого сетевого фотоприложения, позволяющего выставлять рейтинг фотографий с помощью звездочек.

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

«Мне действительно понравилась скорость разработки приложений с помощью MongoDB. Многие средства, которые мы обсуждали при обзоре платформы, существуют на базе фреймворка JavaScript, который может беспроблемно использоваться в MongoDB. Благодаря этому мы экономим время, которое потратим на предотвращение домогательств и травли», – с энтузиазмом заявила Элис.

«Я понял, что было затрачено много сил и средств, чтобы спроектировать и спланировать требуемую топологическую структуру, а также обновлять и отслеживать MySQL. Элис действительно помогла мне осознать преимущества, которые мы получим от повторного использования MongoDB в координации с эксплуатационной командой», – прокомментировал Джорджи.

На этой стадии проекта группа разработчиков из компании Sparkle Corp могла принять решение об использовании MySQL. Совместно с эксплуатационной командой они могли бы провести исследование в целях изучения стоимости внедрения нового программного обеспечения. Они могли бы передать полномочия по принятию решений Хедвигу, руководителю проектов, которому известны ожидания заказчиков. Давайте рассмотрим подробнее, каким образом формирование близости может усилить организацию и помочь в принятии критически важных решений.


Сети

Марк Грэноветтер описал три разных вида межличностных связей – сильные, слабые и отсутствующие. Сила связи определяется комбинацией времени, эмоционального напряжения, степенью близости и взаимности для каждой связи. Марк отметил, что хотя комбинация сильных и слабых связей объединяет общество в целом, слабые связи играют намного большую роль в общем доступе к ресурсам и информации, чем считалось ранее. Например, в результате опроса соискателей работы он пришел к выводам, что более половины участников опроса нашли работу через знакомых, используя слабые связи. Это были просто знакомые, а не друзья, с которыми они виделись не чаще двух раз в неделю.

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


Факторы создания команды

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

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


Функции команд

Функции, выполняемые командами, разбиваются на следующие пять категорий[23]:

Ответная реакция 

Работа, которая осуществляется в ответ на что-то (например, ответ на входящие сообщения электронной почты или действие, выполняемое после предъявления входных билетов), а не предварительные действия.

Планирование 

Прикладывание усилий к планированию и приоритизации выполняемой работы.

Процедуры 

Работа по обслуживанию, например отслеживание отправленных сообщений электронной почты или заполнение отчетов о расходах.

Уязвимость 

Работа, выполняемая в рамках устранения собственной уязвимости, например проверка личной и организационной репутации в Интернете.

Устранение проблем 

Работа, требующая творческого подхода и внимательности.


Определение близости

Существует пятая категория функций, называемая рабочими отношениями. Это социальный катализато


убрать рекламу







р, облегчающий работу. Благодаря налаженным рабочим отношениям сокращается время выполнения работы, убираются барьеры на пути к общению и формируется доверие между сотрудниками. Благодаря близости оценивается качество отношений между отдельными людьми, командами, бизнес-единицами и целыми компаниями. Этот показатель невероятно трудно точно измерить.

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

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


Межличностные связи в командах

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

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

Как уже отмечалось ранее, сила межличностных связей может оцениваться несколькими факторами:

Совместно проведенное время 

Обычная совместная работа может помочь укрепить отношения на рабочем месте.

Интенсивность отношений 

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

Обмен историями 

Делиться личными победами и поражениями – отличный способ лучше узнать друг о друге.

Взаимная поддержка 

Поддержка друг друга, которая проявляется в совместном отмечании праздников, в подмене сотрудников, находящихся в отпуске, либо в ежедневной помощи друг другу на рабочем месте.

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

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


Командная культура

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

Четко сформулированные общие ценности могут сплачивать вместе членов команды. Осознание ценностей всеми членами командами открывает путь к предотвращению или к разрешению межличностных конфликтов. Например, конфликты могут возникать между участниками группы, выполняющей проект с быстро приближающимся сроком завершения. Одни говорят, что нужно сдавать «сырой», толком не протестированный проект, поскольку самое главное – соблюсти сроки сдачи проекта. Другие же считают, что самое главное – сдать проект, отвечающий определенным стандартам качества. Кто «прав» в подобной ситуации, в значительной степени зависит от ценностей, исповедуемых в команде.

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

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


АНТИШАБЛОНЫ DEVOPS: КУЛЬТУРНАЯ АДАПТАЦИЯ

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

Если соискатели рабочих мест успешно проходили интервью, их приглашали на ланч для проверки культурной совместимости. По мере роста влияния «партии любителей пива» процесс культурной подгонки выродился в поиск ответа на следующий вопрос: «Нравится ли нам выпивать с этим человеком»? Дженераль видела, как команда забраковала несколько хороших кандидатур только за то, что они не заказали пиво вместе с ланчем. По мнению членов команды, подобные кандидаты не впишутся в команду, поскольку не склонны к коллективным попойкам.

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


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

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

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

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

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

Согласно исследованию, проведенному в 2004 году, члены команд, разделяющие между собой и руководителем общие ценности, формируют более доверительные отношения[24]. Благодаря доверительным отношениям, установленным между коллегами и руководителем, повышается как командная, так и индивидуальная производительность. Сильные связи, которые порождает подобный тип доверительных отношений, являются одним из наибольших конкурентных преимуществ команды или организации в целом. Чтобы поддерживать безупречную, основанную на обучении среду, требуется соответствие между ценностями и культурой команды.


Единство команды

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

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

Благодаря солидарности команда становится мотивированной и чувствует себя единым организмом, но здесь важно не переусердствовать. Для характеристики чрезмерной солидарности социолог Уильям Грэм Самнер использует термин «этноцентризм»[25]. Этот термин относится к «представлению о группе как о центре всего сущего». Если подобные представления господствуют на рабочих местах, они могут вызвать враждебность между командами, причиной которой является конкуренция за ограниченные ресурсы, такие как бюджет.

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


Теория «в группе/вне группы»

Десятилетиями господствовала идея о том, что внешние конфликты приводят к росту внутренней сплоченности. Эта идея часто называется теорией «в группе/вне группы» и, возможно, лучше всего объясняется Самнером: «Миролюбивые и товарищеские отношения в группе коррелируют с враждебными и воинственными отношениями между группами. Мир внутри коллектива воцаряется в случае войны с посторонними»[26]. Социолог Георг Зиммель, возможно, лучше других исследовал эту тему, изложив основные положения в статье The Persistence of Social Groups  («Постоянство социальных групп»)[27], увидевшей свет в 1898 году.

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

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

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

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

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


Исследование членства в группах

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

Эти политики применялись непоследовательно и на разных платформах. Причем для знаменитостей часто делались исключения: наиболее яркие примеры – Боно или Мадонна. Подобные политики оказывали негативное влияние на группы людей, находящихся в опасности, и на маргиналов. К тому же они оказались малопригодными для борьбы со спамом, для снижения количества фальшивых профилей или предотвращения преступлений в Интернете.

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

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

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


Расширение членства в группах

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

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

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


Разнообразие

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


Преимущества разнообразия

Наличие разнообразия необходимо для внедрения инноваций. Различные идеи, перспективы и точки зрения, которые рождаются в разных средах, критически важны для генерирования новых идей[28]. Благодаря уникальному опыту, накопленному разнообразными командами, можно создавать продукты, рассчитанные на работу с более широкой клиентской базой. Чем теснее сотрудничают разные люди или группы, тем большая степень креативности будет им присуща. Техническая отрасль весьма однородна и в основном состоит из гетеросексуальных цисгендерных белых мужчин, которых намного больше, чем в популяции в целом[29]. В результате уменьшается степень инноваций и креативности.

Сила заключается не в сходстве, а в различиях.

– Стивен Кови

В 2006 году доктор Самьюэла Соммерс, директор лаборатории по изучению разнообразия и межгрупповых отношений (Diversity & Intergroup Relations Lab) в университете Тафтса, провела исследование зависимости производительности от расового состава групп. Она пришла к выводу, что группы, которые включают представителей разных рас, работают лучше, чем группы, сформированные представителями белой расы[30]. В разнородных группах обсуждается более широкий круг вопросов и происходит более интенсивный обмен информацией, чем в однородных группах. К тому же представители белой расы лучше работают в смешанных группах. Также проводились исследования по влиянию полового состава группы на производительность. Результаты этих исследований показали, что группы, состоящие из мужчин и женщин, работают лучше, чем чисто мужские группы. Причем это улучшение проявляется как на индивидуальном, так и на групповом уровне.

Преимущества разнородных групп становятся еще более явными, когда приходится работать над креативными задачами либо когда нужно вступать в отношения с членами других групп или организаций. В последнем случае может оказаться полезным дивергентное мышление. Если, например, команды общаются с заказчиками, то большая степень разнообразия будет способствовать увеличению степени удовлетворенности заказчиков. В соответствии с данными исследования, проведенного в 2000 году исследователем и преподавателем в области менеджмента Орландо С. Ричардом, культурное разнообразие приводит к повышению производительности компании в периоды роста как самой компании, так и бизнеса[31].

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


Формы разнообразия и интерсекциональности

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

Разнообразие может принимать разные формы. Среди них:

• пол и гендерная представленность;

• расовая и этническая принадлежность;

• национальная принадлежность;

• сексуальная ориентация;

• возраст;

• наличие статуса ветерана;

• нетрудоспособность;

• религия;

• семейный статус.

Если вы развиваете лишь одно направление, это вовсе не означает, что в вашу компанию будет привнесено подлинное разнообразие либо она станет по-настоящему безопасным местом работы для разных людей. И здесь следует учитывать наличие интерсекциональности. Этот термин предложила адвокат Кимберл Креншо, он означает исследование пересечений между разными формами притеснения или дискриминации, а также связей между этими формами[32].

Разнообразие, подобно любой другой devops-практике, не является настолько простым, чтобы его можно однажды реализовать, а потом вычеркнуть из списка запланированных дел. Это итеративный процесс, который должен отслеживаться и оцениваться. От степени вашей заинтересованности в разнообразии зависят прилагаемые усилия. Если вы реально заинтересованы в улучшении условий жизни и труда сотрудников вашей компании и сообщества в целом, создайте среду, которая не только была бы продуктивной, но и включала всех людей, которые могут стимулировать производительность.


НЕОСОЗНАННЫЕ ПРЕДУБЕЖДЕНИЯ

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


Соблюдайте толерантность при найме на работу

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

• Следите за стилем сообщений о найме на работу. Избегайте фраз, имеющих маскулинную или милитаристскую окраску. Не допускайте откровенно сексистских, расистских или гомофобских высказываний в рекламных объявлениях о поиске сотрудников и в общении с потенциальными сотрудниками. Если поиском сотрудников для вашей компании занимаются независимые агентства по найму, они должны особенно тщательно соблюдать нормы общения, принятые в вашей организации. Дополнительные сведения по этой теме будут приведены в примере.

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

• Если вам сложно подобрать разнообразный персонал, обратитесь за помощью к профессионалам – к рекрутерам и консультантам, которые специализируются на формировании разных команд.

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


Поддержка толерантной среды

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

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

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


убрать рекламу







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

Представителям меньшинств помимо своих непосредственных обязанностей зачастую приходится выполнять работу, направленную на увеличение степени разнообразия компании. Они просматривают объявления о найме на работу на предмет наличия расистских или сексистских высказываний либо представляют компанию на публичных мероприятиях. Этих людей часто просят представлять группы, к которым они относятся. Но тут нужно иметь в виду, что ни одна женщина не может представлять всех женщин в группе и ни один гей не может выступать в качестве представителя всего ЛГБТ-сообщества. Это справедливо для всех групп, которые обычно плохо представлены в технической отрасли.

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

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

На первый взгляд может показаться, что подключаться к дополнительной деятельности сложно, а обязательная деятельность не вызывает энтузиазма у сотрудников. Например, во многих компаниях, особенно в стартапах, принято отмечать окончание рабочего дня. И если вы не выпиваете по вечерам в компании коллег, то можете получить ярлык «белой вороны». Убежденный трезвенник, попавший в подобную компанию, будет испытывать неловкость, объясняя причины своего «отрыва от коллектива». Чтобы поддерживать толерантную среду для всех сотрудников, укомплектуйте офисный бар алкогольными и безалкогольными напитками и предоставьте сотрудникам право выбора напитка.


УГРОЗА ВЛИЯНИЯ СТЕРЕОТИПОВ

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

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

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


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

• Убедитесь в том, что все рекрутеры, с которыми вы работаете, осведомлены о ваших целях по достижению разнообразия и толерантности.

• Отправляйте сотрудников на семинары Ally Skills Workshop (семинар по развитию навыков сотрудничества) для преодоления неосознанных предубеждений.

• Подайте пример, осудив проблемную речь или проблемное поведение. Не перекладывайте эту задачу на плечи меньшинства.

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

• Проведите аудит рабочей среды. Определите, каким образом доступные основные элементы окружающей среды воздействуют на сотрудников (помимо требований, выдвигаемых на уровне государственных органов).

• Если вы просите людей проверить ваши объявления о поиске сотрудников на предмет толерантности, оплатите эту работу.

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

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


Командная и организационная структура

По мере продвижения от уровня отдельных команд до уровня организаций отношения между людьми становятся все более неустойчивыми. Британский антрополог Робин Данбар теоретически обосновал предельное количество людей, с которыми человек может поддерживать стабильные социальные отношения. На основе экспериментов с приматами, изучения размеров и мощности неокортекса он пришел к выводам, что максимально возможное количество людей, с которыми можно поддерживать стабильные отношения, равно 150. Эта величина называется числом Данбара[33]. Также для поддержания сплоченных команд в группах и организациях должны использоваться строгие правила, законы и нормы. Поэтому в больших организациях наблюдается засилье бюрократии.

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

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

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


Поиск точек соприкосновения между командами

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

В процессе сближения разных команд могут возникать следующие затруднения:

• различия в целях;

• разные способы оценки успеха;

• различные методики осуществления лидерства;

• различия в стилях общения.

Различные команды часто имеют разные цели (по крайней мере, декларируемые). Хотя, безусловно, цель каждой команды заключается в том, чтобы помочь компании добиться успеха. Беда в том, что каждая команда для достижения цели использует собственные методы, которые часто противоречивы.

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

Даже если цели разных команд не конфликтуют, противоречия могут породить способы, применяемые командами для оценки достигнутого успеха. Ключевые показатели эффективности (KPI, key performance indicators), используемые для оценки прогресса и успеха организации, могут привести к падению производительности. Это произойдет в том случае, когда не учитываются факторы, способствующие развитию бизнеса (например, заказчики, без которых успех бизнеса немыслим).

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

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

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

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

Несмотря на упомянутые в этом разделе различия, существуют способы поиска точек соприкосновения между командами и группами, которые будут рассмотрены в следующих разделах.


Переход от конкуренции к сотрудничеству

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

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

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

Учтите, что чрезмерная конкуренция может принести больше вреда, чем пользы. В данном случае наблюдается так называемая трагедия общин (tragedy of the commons), когда интересы отдельных людей вступают в противоречие с интересами группы, владеющей небольшим ресурсом общего пользования. Эта фраза использовалась в качестве названия эссе, написанного в 1968 году экологом Гарретом Хардином[34]. В этом эссе описывались последствия неупорядоченного выпаса овец на общинных или общественных землях. Отсюда и был позаимствован термин «общины».

Этот пример часто используется в теории игр, представляющей собой изложение принципов рационального выбора в условиях проблем, связанных с участием нескольких сторон, выполнения коллективных действий и принятия интерактивных решений. В 2012 году Флориан Дикерт, занимающийся исследованиями в области человеческих взаимоотношений и экономики, опубликовал статью «The Tragedy of the Commons from a Game-Theoretic Perspective» (Трагедия общин с точки зрения теории игр). В этой статье он утверждает, что этот сценарий с «трагедией общин» не соответствует реальному положению дел[35]. Флориан отмечает, что хотя в подобной ситуации сотрудничество затрудняется (особенно при увеличении доли акций, находящихся в собственности акционеров), трагедия, вызванная неограниченной индивидуальной свободой, не является неизбежной.

Американский специалист в области политэкономии и нобелевский лауреат Элинор Остром выявила несколько факторов, которые критически важны для успеха совместных усилий в сценарии с «трагедией общин»[36]. Она утверждает, что для успешного сотрудничества должны выполняться следующие условия:

• наличие средств управления членством во всей группе;

• доступ к социальным сетям;

• заметные действия со стороны всех вовлеченных в процесс;

• возможность применения постепенно нарастающих санкций;

• наличие ресурса, который не является чересчур изменчивым.

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

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

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

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


Формирование эмпатии в команде

Благодаря эмпатии инженеры из эксплуатационной группы могут оценить возможность быстро и без суеты «нажать нужную кнопку». Эмпатия позволяет разработчикам оценить проблемы, вызванные написанием слишком громоздкого, медленного или небезопасного кода. Благодаря эмпатии производители и операторы программ могут помогать друг другу в обеспечении наилучших возможных функциональных свойств и работоспособности, требуемых пользователями[37].

– Джефф Сассна

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


Выделенные инженеры эксплуатации

Вот уже много лет инженеры эксплуатации и системные администраторы рассматриваются отдельно от других сотрудников компании. Эти угрюмые неприятные люди смотрят на всех свысока и в ответ на любые вопросы предпочитают говорить «нет». Чтобы добиться успеха, нужно искоренять подобное «токсичное» поведение и вырабатывать нетерпимое отношение к его носителям. Это особенно важно для современного бизнеса, когда деятельность ИТ-отдела и эксплуатационного отдела критически важна для успешного выпуска продуктов. Давно ушли в прошлое те времена, когда единственный системный администратор уединялся в серверной комнате и поддерживал сеть, используемую для обмена электронной почтой и обеспечения доступа к принтерам.

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

Чтобы улучшить положение дел, можно назначить инженеров эксплуатации, уполномоченных для работы с командами. Если команда постоянно нуждается в оперативной поддержке, потребуется выбрать контактное лицо в эксплуатационной команде. Например, такой человек понадобится команде, разрабатывающей библиотеки API или интернет-приложения. В связи со спецификой работы эта команда нуждается в выполнении мониторинга, настройки производительности и планировании мощностей. Если же обязанности контактных лиц исполняют случайные люди, им придется объяснять суть возникших проблем, знакомить с контентом, выполнять ранее проделанные действия и т. п. Инженер из эксплуатационного отдела, ответственный за поддержание связей с командой, обычно приходит на собрания либо отслеживает ситуации, требующие оказания дополнительной поддержки. Пример подобной ситуации – разработка новых конечных точек API, которые создают дополнительную нагрузку на кластер API. Если в этом случае понадобится новое оборудование, лучше, чтобы эксплуатационный отдел был поставлен в известность как можно раньше.

Чтобы заставить этот подход реально работать, нужно принять во внимание несколько ключевых моментов.

Назначение не эквивалентно всецелому посвящению 

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

Численность эксплуатационной команды 

Если ваша компания не настолько мала, чтобы ограничиваться одной инженерной группой малой или средней численности, желательно не экономить на эксплуатационной команде. Как только вам придется выполнять дополнительную работу, выходящую за рамки рутинных проектов и обязанностей, кадровые резервы окажутся нелишними. Подобный подход практикуется в компании Etsy. Здесь на несколько сотен обычных инженеров приходится около 15 эксплуатационных инженеров, хотя для выполнения текущей работы хватило бы 2–3 человек.

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

Уделяйте внимание эксплуатационному персоналу 

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

Учеба – это улица с двусторонним движением 

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

Программа назначения специалистов не только позволяет осуществлять эксплуатацию, но и обеспечивает другие преимущества. Например, назначенные команды по дизайну или пользовательскому опыту помогут гарантировать простоту и интуитивную понятность в использовании создаваемых продуктов. Команда, разрабатывающая внутренние инструменты, создает средства, которые будут использоваться на уровне всей организации. Если эта команда, как это часто бывает, состоит из людей, которые имеют опыт системного или серверного администрирования, скорее всего, они разработают инструмент командной строки, который будет привычен и понятен для них, но не для обычных пользователей. При наличии назначенного дизайнера или UX-специалиста можно создать инструмент, который был бы востребован широким кругом пользователей. Еще одна область, в которой могут принести пользу назначенные в команду инженеры, – обеспечение безопасности. Подобно эксплуатационным работам, процедуры по обеспечению безопасности не воспринимаются широкой общественностью. Тем не менее они должны внедряться на протяжении всего жизненного цикла продукта, а не в последний момент.


Учебные лагеря и ротации

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

Термин «учебный лагерь» используется для описания следующего подхода. Сотрудникам, только что принятых в команду, в течение нескольких недель приходится работать с другими командами. Как правило, сотрудники работают вместе с командами, тесно связанными с базовой командой. Например, разработчик одну неделю работает вместе с эксплуатационной командой, а еще одну неделю – вместе с командой обеспечения безопасности. Преимущества подобного подхода заключаются в том, что новички обычно не участвуют в проектах, связанных со многими людьми, поэтому отсутствуют жесткие ограничения по времени. Также у новичков отсутствует предвзятое мнение о других командах или о «типичных способах решения проблем». Благодаря непредвзятому взгляду на проблемы в командах, с которыми работают новички, генерируются новые идеи. Эти идеи вряд ли появились бы при других условиях.

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

Работа в другой команде обеспечивает те же преимущества, что и программа назначения специалистов из других команд. Но в этом случае создается более серьезный фундамент для эмпатии и понимания. Также формируются точки соприкосновения между разными членами группы. Если руководство не дает добро на проведение полномасштабной ротации, возможно, оно согласится на выполнение локальной ротации. Например, можно в течение нескольких часов создать возможности для парной работы над проектами, задействовав людей из разных команд. Например, на основе согласия, полученного от сотрудников, можно организовать парную работу инженеров над списком требований к ПО или над малобюджетными программами из категории внутренних продуктов или проектов с открытым кодом. Эти программы используются в компании либо поддерживаются этой компанией.


Ротации во вспомогательных командах

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


убрать рекламу







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

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

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

Для уменьшения текучести кадров рекомендуется выполнять ротацию службы поддержки . В рамках ротации участники других команд по несколько часов в неделю отвечают на письма пользователей, адресованных службе поддержки, либо реагируют на жалобы заказчиков. Обычно в службу поддержки обращаются с однотипными вопросами, поэтому при наличии хорошей документации и заранее созданных шаблонов ответов работа в службе поддержки значительно упрощается. Конечно, это не означает, что не понадобятся навыки и терпение. Все это понадобится, если придется оказывать помощь в сложных ситуациях. Благодаря наличию документации и шаблонов работать в службе поддержки могут представители других групп, особенно при наличии инженерного образования. Участники других команд, работающие в службе поддержки пользователей, получат представление о типичных пользовательских проблемах. Как правило, эти проблемы отличаются от проблем, «живущих» в представлении разработчиков. Также они смогут осознать ценность службы поддержки для компании в целом и для выполняемой работы.

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

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

Для организаций, ищущих способы улучшения эмпатии как в целом, так и между командами, важно исследовать не только способы взаимодействия разных команд и групп, но и ценности, как реальные, так и воспринимаемые разными группами. Традиционно такие отделы, как ИТ и поддержка, рассматриваются как центры затрат, которые не приносят прямую прибыль, а лишь увеличивают затраты на управление компанией. Хотя движение devops начало улучшать отношение к эксплуатационным командам в целом, для осуществления кардинальных перемен в этой области нужно пройти длинный путь. Сотрудники центра затрат часто занимают неблагодарные рабочие места и получают более низкую зарплату. Центры затрат характеризуются более высокими показателями товарооборота и повышенным риском сокращения во времена кризиса. И хотя центры затрат воспринимаются как нижние ступеньки на корпоративной лестнице, при наличии нужных людей, обучения и ресурсов они могут давать невероятную прибыль в таких областях, как потребительская лояльность или стабильность инфраструктуры.

Расширяя понятие devops в целях учета этих команд и их воздействия на бизнес в целом, необходимо отказаться от иерархической лестницы. Эта лестница является чрезмерно упрощенной моделью, которая не только приводит к неверным представлениям о служебном росте, но и затрудняет проявление эмпатии к другим людям, которые находятся «ниже» по лестнице. Как уже упоминалось в других главах, перемещение из инженерного отдела в отдел менеджмента является изменением в карьере, а не карьерным ростом. Такая модель игнорирует способы, с помощью которых группы связаны и взаимозависимы.

А теперь представим вместо лестницы веревочную пирамиду, которую иногда устанавливают на детских площадках. Эта пирамида представляет собой набор натянутых разноцветных канатов, по которым могут подниматься и играть дети (рис. 9.1). Несмотря на то что эта модель является иерархической, с ее помощью легче вообразить такие роли, как ИТ и поддержка, которые находятся в основании других частей пирамиды. При рассмотрении этой модели нетрудно понять, что без прочной основы стабильность и успешность структуры находятся под угрозой. Лестница может утратить нижнюю ступень и по-прежнему применяться по назначению. Поэтому нижние ступени лестницы рассматриваются как центры затрат, от которых нужно избавляться в первую очередь. Но прежде чем избавляться, нужно обращать внимание на связанные с ними ценности, которые далеко не всегда оцениваются в денежном выражении. Но если вы обрежете один из нижних канатов веревочной пирамиды, вся конструкция потеряет стабильность.




Рис. 9.1. Иерархия, представленная в виде лестницы и пирамиды


Улучшение общения между командами

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

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

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

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

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

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


Общение в кризисных ситуациях

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

Кросс-функциональное общение 

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

Ассертивное общение 

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

Специфические критические языковые методики 

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

Создавать комфортные условия для общения особенно важно во время кризиса, когда ставки намного выше, чем в обычной ситуации. В этом случае используется стратегия CUS [38], которая поощряет людей говорить, когда они:

• озабочены чем-то;

• не уверены в чем-то;

• не уверены в безопасности.

Альтернативная методика SBAR  предлагает рекомендации, позволяющие убедиться в том, что проблемы или критические замечания выражаются продуктивным образом. Чтобы общаться, нужно убедиться в наличии следующих данных:

• ситуационная информация, описывающая происходящее;

• справочная информация или контент;

• оценка сути проблем;

• рекомендации по выполнению действий.

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

Теперь, когда мы исследовали способы улучшения близости, рассмотрим преимущества, которые она может дать организациям в реальном мире.


Практика: ведомство по патентам и товарным знакам США

Чтобы увидеть, как выглядит devops-трансформация в правительственной организации, поговорим с Тиной Донбек, исполняющей функции заведующей отделом конфигурации систем и автоматической доставки. Этот отдел относится к канцелярии начальника информационного управления, относящейся к ведомству по патентам и товарным знакам США (USPTO)[39]. Это ведомство (OCIO) гарантирует выполнение клиентами своей работы изо дня в день. Суть этой работы заключается в просмотре, утверждении и рассмотрении заявок на патенты и товарные знаки, поступающие от американской общественности. При этом гарантируется рабочее состояние технологий и инструментов, применяемых для выполнения этой работы.


Предпосылки и направления

Помимо прочего, Тина Донбек также является ветераном морской пехоты и проповедником принципов devops в своей организации. Обладая степенями в области психологии и развития организации, полученными после завершения службы в морской пехоте, она потратила несколько лет на поддержку Департамента военно-морского флота. Она занималась развитием ИТ-кадров, будучи начальником отдела безопасности информационных систем и менеджером программных проектов. На протяжении своей карьеры она непрерывно занималась улучшениями: «Я действительно наслаждаюсь выявлением неработающих процессов и выяснением причин, которые движут людьми, мотивируют их».

Тина Донбек возглавляет команду, которая разработала, внедрила и эксплуатирует платформу непрерывной доставки, на базе которой USPTO разрабатывает системы нового поколения. Эта платформа затрагивает практически каждый аспект жизненного цикла разработки программ в организации. Поэтому команда под руководством Тины тесно сотрудничает с другими командами, которые также вовлечены в этот цикл. Наиболее тесные связи налажены с подразделением Platform Services Devision, работающим с программным обеспечением RedHat CloudForms, и с командами, разрабатывающими программное обеспечение.

Несмотря на довольно интенсивное использование системы управления облачными вычислениями CloudForms от RedHat и выпуски платформ автоматизации, организация стремится выбирать инструменты с открытым кодом. Это позволяет избежать заключения дорогостоящих лицензионных соглашений и привязки к одному поставщику. В число этих инструментов входят Subversion, предназначенный для управления исходным кодом, сервер непрерывной интеграции Jenkins, система управления проектами и качеством Sonar, система управления репозиторием Nexus, а также системы управления конфигурацией Puppet и Ansible. Основную часть ценности, связанной с этими продуктами, образуют сообщества пользователей. Причем эта ценность формируется как в виде возможности отвечать на вопросы и оказывать поддержку, так и в форме непрерывной разработки новых средств и виджетов.

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


Поощрение сотрудничества и близости

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

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

Хотя некоторые процессы, такие как требуемые обзоры кода, являются жестко заданными, Тина Донбек отмечает, что экспериментирование с разными инструментами и решениями не только допускается, но и активно поощряется. «Наша команда любит повозиться, к тому же у нас есть песочница, в которой мы пробуем разные инструменты, виджеты и т. п. Если мы хотим подтолкнуть к активным действиям как можно больше пользователей, мы должны пройти через процесс обзора нашей корпоративной архитектуры. Это позволит нам убедиться в том, что инструмент или продукт соответствует всем правительственным требованиям, а также требованиям к безопасности». В результате обеспечивается необходимый уровень гибкости и инноваций, а также соответствие всем требованиям, связанным со статусом правительственного агентства.

Тина успешно создала сообщество, которое характеризуется сильными внутренними связями и сотрудничеством, а также обменом информацией с внешними организациями. Команда под ее руководством заняла конференц-зал и превратила его в командное «рабочее пространство devops». Как говорит Тина, «нередко в этом зале собиралось более двух десятков людей… вместе работают разработчики, тестеры, специалисты по поддержке платформы. Это действительно здорово, когда ощущаешь столько энергии в этой комнате». Благодаря подобному рабочему пространству обеспечивается активная совместная работа команды и привлекаются сотрудники из других команд, которые принимают участие в совместной работе, не дожидаясь общих собраний. Тина призывает команды работать в целях достижения общепринятого конечного состояния (в данном случае имеется в виду более быстрые высококачественные развертывания), а также оказывать взаимное доверие и уважение друг к другу. В пространстве сообщества можно организовывать дискуссии и споры, не опасаясь их негативного влияния на среду.

Агентство USPTO является первым федеральным агентством, организовывающим devops-встречи. На стартовой встрече присутствовало более 100 участников. Организации-участники также провели день отрасли, на который в пространство devops были приглашены различные поставщики, рассказывавшие о своих продуктах, идеях и лучших практиках. Это мероприятие также посетили представители более 100 компаний, разделяющие devops-идеи. Организации, относящиеся к агентству USPTO, также были принимающей стороной и спонсором devopsdays-конференции DC 2015, в которой приняли участие представители государственных и отраслевых организаций. Эти события вместе с учебными семинарами, предназначенными для выработки технических и программных навыков, рекомендованы сотрудникам организации как способ стимулирования совместного роста и развития.


Балансирование между разными точками зрения

Как и в любой крупной организации, в агентстве прилагаются усилия по интеграции многих точек зрения и рабочих стилей в единую стратегию организации. Поскольку devops иногда трактуется как некая совокупность идей, принадлежащих разным людям, среди них имеются идеи о том, как должны выглядеть зрелые или успешные devops-организации. Как отметила Тина Донбек, «успех интерпретируется разными людьми по-разному. Одно дело – разработчики, которые постоянно находятся под гнетом необходимости производить качественную продукцию в условиях жестко заданных сроков. Другое дело – инженеры из эксплуатационной команды техподдержки, которым приходится изо дня в день выполнять рутинные операции по техподдержке, поддерживать бесперебойную работу оборудования и совершенствовать способы техобслуживания. Это лишний раз подтверждает, что нам нужно выработать единое понимание определенных критериев успеха. И хотя мы все движемся к общей цели, успех в каждой функциональной области определяется по-своему».

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

Некоторые люди сопротивляются изменениям к общей культуре. Другие люди и команды не могут общаться с глазу на глаз. Причина – прошлый опыт пребывания в менее открытой и более упречной культурной среде. Поэтому нужно прилагать усилия на всех уровнях, чтобы избавиться от пережитков упречной культуры, устранить путаницу, связанную с изменяющимися ролями и обязанностями, и сформировать более открытую и основанную на сотрудничестве культуру. Например, наш директор по информационным технологиям приобрел маленькие безделушки с надписями «DevOps Doer Mementos» (напоминалки создателям devops), а потом вручил их сотрудникам организации, которые начали двигаться по пути внедрения devops-культуры.

Создается впечатление, что некоторые компоненты организации изменяются быстрее, чем другие, но в целом все равно остается ощущение прогресса, даже если он временами замедляется. Благодаря поддержке и согласию с предлагаемыми изменениями со стороны руководства и менеджмента организации, а также усилиям со стороны команд, вовлеченных в повседневную работу, обеспечивается успешная работа Тины Донбек и ее организации. Помимо этого создается пример для подражания для других организаций.

Независимо от размеров организации, скорости протекания рабочих процессов или сложности важно понимать, что нужно выработать общее видение, цели и критерии успеха для успешного внедрения каких-либо существенных культурных или технологических изменений. Все это тесно связано с идеей devops-пакта, рассмотренного в главе 1. При отсутствии общего понимания или согласия маловероятно, что какое-либо изменение будет эффективным или долговременным. И хотя выработка общего понимания потребует некоторого времени, даже соглашение о необходимости достижения понимания и активная работа в этом направлении будут критически важным первым шагом.


Преимущества усиленной близости

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


Сокращение времени цикла

Время цикла  и время выполнения  – это единицы измерения работы и производительности, которые позаимствованы из системы канбан. Эта система планирования бережливого производства была разработана в компании «Тойота» в 1950-х годах[40]. Время выполнения – это время, прошедшее от момента создания запроса до момента получения заключительного результата. Этот показатель соответствует ощущениям пользователя, ожидающего завершения какого-либо процесса. Время цикла также завершается после получения конечного результата, но начинается после фактического начала работы в соответствии с полученным запросом, а не после получения запроса. Показатель времени цикла больше показателя скорости завершения или способности системы к выполнению работы. Уменьшение показателя времени цикла говорит о сокращении напрасных трат времени, которые имеют место, когда запрос уже получен, а работа еще не началась.

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

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

– Михай Чиксентмихайи

Концепция потока  часто используется в дискуссиях, посвященных оценке работы и производительности труда. Теоретик в области социологии Михай Чиксентмихайи ввел концепцию потока для описания психического состояния человека, который полностью поглощен работой, получает от нее энергию и полностью сосредоточен на ней. На протяжении многих лет исследований Чиксентмихайи идентифицировал шесть факторов, которые отличают поток от других психических состояний[41]. Эти факторы перечислены в следующем списке:

• интенсивная и целенаправленная концентрация на настоящем;

• объединение действий и повышение осведомленности;

• отсутствие самосознания;

• персональный контроль или надзор над ситуацией;

• изменяющееся субъективное восприятие времени;

• адекватное вознаграждение.

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

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


убрать рекламу







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

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


Устранение барьеров на пути к общению

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

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

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

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

Технологии сами по себе не могут создавать или усиливать связи. Такие сервисы, как Twitter, Facebook, IRC или Slack, позволяют людям общаться друг с другом, но им самим придется укреплять слабые связи для усиления формируемых отношений. Возможности этих сервисов определяются потенциалом команд, которые их создают. Продуктам, которые создаются более разнообразными командами, присущи более широкий диапазон понимания и возможность распространения через более разнообразные барьеры на пути к общению. В то время как любой из этих инструментов общения может помочь в усилении связей, контекст полностью зависит от того, как его используют и кто его использует.


Формирование и укрепление доверия

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

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

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

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


Внедрение инноваций

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

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

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


Требования к близости

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


Простой

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

Наличие запланированных простоев также критически важно для выполнения переменной работы. Этот термин относится к любой незапланированной работе или к работе с открытой датой завершения. Чтобы определить величину простоя, сначала нужно оценить время, необходимое для выполнения различной работы, а затем добавить небольшой резерв. Если, например, приходится тратить 20 часов в неделю на выполнение незапланированной работы, запланируйте выделение дополнительных 20 часов в неделю, требуемых на общение по социальным сетям и индивидуальный рост. Если вам приходится тратить 20–30 часов в неделю на выполнение незапланированной работы, нужно выделить больше времени на простои.

Джордж и Дженераль совместно со своим менеджером определили объем работы, посильный для группы, состоящей из двух человек. После месяца использования процессов канбан и назначения категорий задач, выполняемых в рамках незапланированной работы, они приступили к исследованию показателей рабочего потока. В результате исследований выяснилось, что каждую неделю нужно 20 часов отводить на незапланированную работу. Учитывая время, выделяемое на работу в сети, личное образование и незапланированную работу, они решили выделить 40 часов в неделю на простои. Также 40 часов в неделю выделяется на выполнение запланированной работы.

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


Явно декларируйте ценности и цели

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

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

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

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

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


Комнаты для совещаний

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

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

К сожалению, далеко не все компании располагают большими офисными площадями, позволяющими выделить отдельную комнату для совещаний. И не все располагают возможностями и ресурсами, необходимыми для оборудования подобных комнат. Но даже в подобных случаях не все так печально, поскольку эти комнаты могут иметь различные размеры и конфигурации. Например, в качестве подобной комнаты может применяться одноместная телефонная будка, из которой можно звонить коллегам и поставщикам, не беспокоя находящихся рядом коллег, либо 20-местный конференц-зал. Также могут применяться двухместные комнаты, используемые в качестве «открытого пространства». Эти комнаты доступны в любое время. Благодаря подобной свободе действий люди могут выбирать подходящие стили совместной работы. Более того, предоставление людям времени и места для совместной работы способствует формированию более глубокой привязанности к организации.

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


Сотрудничество и кооперация

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

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

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

Все перечисленные в приведенных выше разделах факторы могут работать вместе, чтобы сформировать высокоэффективную среду сотрудничества и близости.


Оценка степени близости

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


Навыки и оценки сотрудников

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

Совершенно очевидно, что в этой области качество общения имеет намного большее значение, чем количество, а обратная связь с коллегами может быть весьма полезной. Например, рассмотрим ситуацию, когда сотрудникам требуется информация или помощь друг от друга. Знают ли они, кому нужно задавать вопросы? Действительно ли они готовы задать вопросы нужным людям, даже если они не входят в состав вашей команды? Правда ли, что они не желают обращаться за помощью, даже если этот отказ приведет к замедлению собственного прогресса или заблокирует что-либо еще? Срывают ли они встречи, анализ кода либо обсуждение в почте, приводя аргументы, которые большинство людей считают неважными или контрпродуктивными?

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

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


Взаимодействие между командами

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

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

• Сколько команд участвует в данном проекте?

• Какова разбивка работы между командами? Насколько равномерно распределяется работа? Имеют ли смысл подобные разбивки или же одна команда или член команды перегружены работой по сравнению с другими командами или членами команды?

• Сколько времени было потрачено на разных этапах жизненного цикла проекта? В частности, сколько времени ушло на планирование и какова была разбивка команды на этом этапе?

• Как часто возникают недоразумения между командами или участниками проекта? Были ли эти недоразумения специфичными для определенной группы или для метода общения?

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

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


«Возврат долгов» сообществу

Большая часть преимуществ, связанных с devops-движением, обеспечивается его сообществом. Это сообщество представляет собой группу практиков, которые собираются вместе, чтобы поговорить о работе и способах ее выполнения. В наши дни отсутствует завеса секретности, скрывающая технологии и методики, имевшая место в предыдущие десятилетия. Фактически некоторые из самых известных компаний, работающие в этом пространстве, в течение многих лет говорят не только о своих успехах, но и о неудачах.

Компания Etsy, известная своим техническим блогом Code и многочисленными инструментами, основанными на программах с открытым кодом, в том числе StatsD, называет эту идею «щедростью духа». Эта «щедрость» подразумевает написание постов в публичном блоге, выступления на отраслевых конференциях либо участие в создании программ с открытым кодом. Также сотрудникам предлагается принять участие хотя бы в одном мероприятии в течение года. Это позволяет убедиться в том, что эти люди продолжают приносить прибыль и «возвращать долги» сообществу. Любая организация, которая получает и использует полезные сведения, полученные на основе выступлений на конференциях, постов блогов, собраний или проектов с открытым кодом, должна приложить усилия для «возврата долгов» в натуральной форме.

Участники сообщества не прочь поделиться своей работой и идеями в свободной и открытой форме, что приводит к укреплению сообщества и повышает его ценность. Люди делятся идеями с помощью таких средств общения, как Twitter, LinkedIn, а также выступают на разных встречах и конференциях. Это позволяет сформировать отношения и связи, которые были бы невозможны в иных случаях. Откройте для себя новые решения и познакомьтесь с новыми идеями. Не тратьте зря время на решение проблем, которые уже были решены до вас (во многом благодаря использованию программ с открытым исходным кодом). Это позволит вам более эффективно использовать коллективное время и усилия.

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


Близость между командами разработчиков и эксплуатации в компании Sparkle Corp

«Мне нравится, что существует возможность сократить время разработки с помощью примеров использования, например функции обзора. Это позволяет улучшить впечатление конечного пользователя от нашего сервиса. На основе анализа нашего текущего графика я пришел к выводам о том, что мы можем потратить немного времени на оценку и разработку прототипа, если это целесообразно», – сказал Хедвиг после завершения демонстрации.

«Я обладаю минимальным опытом работы с MongoDB. Мне нужно согласовать все это с остальной частью команды, выяснить, каким опытом они обладают и насколько сложно будет принять новый проект, – предупредил Джордж. – Как инженер эксплуатации из Sparkle Corp, обладающий небольшим опытом работы, я не хочу поручать сомнительную работу эксплуатационной команде».

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


Выводы

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

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

Глава 10. Заблуждения и устранение проблем

 
убрать рекламу







27 onclick=setCookie('596892','1167797427'); return false;>Сделать закладку на этом месте книги

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


Заблуждения

Люди часто имеют разные представления об обязанностях и вкладах разных команд, созданных внутри организации, а также о степени влияния близости и общего доступа к информации в devops-среде.


Разработчики более ценны, чем специалисты по эксплуатации

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

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

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

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


Утечка информации за пределы организации ослабляет конкурентные преимущества

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

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

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


Поиск и устранение проблем

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


Один или несколько сотрудников нарушают групповой рабочий поток

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

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

В эффективных организациях признается ценность командной работы и сотрудничества. Первый шаг на пути к устранению проблем заключается в подтверждении намерений о борьбе с подобным деструктивным поведением путем информирования о его последствиях. Убедитесь в том, что в организации налажено распространение информации и созданы условия для безопасного сообщения сведений о нарушениях. Исключите условия, способствующие формированию страха перед возможным возмездием. Разработайте нормы, определяющие допустимые и недопустимые типы поведения, а также способы управления этими видами поведения. Используйте материалы сайта Geek Feminism (https://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations ) в качестве руководства при выработке таких норм.

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

Если предпринятые меры не помогают в устранении проблемы, переведите сотрудника в другую команду, изыщите возможности по отказу от командной работы либо разрешите сотруднику уволиться. Далеко не всегда увольнение сотрудника – это плохо. Гораздо хуже постоянно предоставлять поблажки людям, не способным и не желающим работать с другими людьми. Это создаст негативный прецедент, который позволит другим членам команды судить о допустимости негативного поведения.


Одна команда блокирует работу других команд

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

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

Даже при наличии общения могут иметь место недоразумения. Обе вовлеченные в общение команды должны удостовериться в том, что достигнут максимально возможный уровень понимания предстоящих действий, известны сроки сдачи работы и требования. Также следует понимать, почему нужна эта работа, и знать о выдвигаемых приоритетах. Чем раньше будут устранены возникшие недоразумения, тем реже будут возникать блокировки и задержки в работе.

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

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

Непосредственная связь может иметь большое значение при устранении многих причин возникновения блокировок, но важно вступать в разговоры при наличии правильного отношения. Если у вас, например, возникает чувство, что кто-то осознанно работает против вас, нетрудно предположить, что эти люди руководствуются злым умыслом или же просто некомпетентны. Произносимые вами слова и выполняемы вами действия будут продиктованы этими предположениями. С другой стороны, если люди чувствуют себя как на допросе либо ощущают, что их работа не ценится, они могут начать огрызаться. В результате могут формироваться циклы дисфункционального или пассивно-агрессивного поведения. Чтобы достичь взаимопонимания, обе стороны должны придерживаться следующего правила: все они работают в одной и той же компании, имеют одни и те же цели. Также стороны должны попытаться откровенно и непосредственно поговорить, чтобы повторно оценить ситуацию и общие ожидания.


Некоторые команды чувствуют себя недооцененными

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

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

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

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

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

Мы выступаем против отношения к разработчикам как к «рок-звездам». Еще хуже, когда столь восторженное отношение к разработчикам сочетается с игнорированием других команд и организаций. Это способствует росту недовольства и не настраивает на сотрудничество.


Люди не склонны доверять друг другу

Поощрять, развивать и поддерживать доверие очень сложно, особенно в среде, в которой его не было изначально. Доверие со стороны коллег, менеджеров или начальства должно быть заработано. Не стоит требовать доверия, чтобы потом злоупотреблять им. Если в вашей среде отсутствует доверие, это, скорее всего, связано с культурными проблемами, которые должны быть устранены.

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

Открытое общение на всех уровнях организации является критически важным для формирования доверия. Если менеджеры и руководители действуют втайне, находясь за закрытыми дверьми в прямом и переносном смысле этого слова, бесполезно требовать от остальных сотрудников открытости и честности. Недостаточно просто провозгласить политику открытых дверей, поскольку большинство людей воспримут это как пустую декларацию. Многие люди не способны задавать неудобные вопросы в общении «один на один» или просто не хотят привлекать к себе внимание. Даже в самых лучших организациях существуют запретные темы для разговоров, например о компенсациях. Соответствующие вопросы обычно не задаются напрямую исходя из множества причин как личного, так и культурного характера. Чтобы поддерживать прозрачность и формировать доверие в направлении сверху вниз, рекомендуется проводить регулярные встречи, на которых сотрудники могут задавать вопросы, просматривать их и голосовать на них. Ответы на большинство вопросов общего характера дают сотрудники службы персонала, менеджеры и руководители подразделений.

Если вы планируете подобные встречи, обязательно реализуйте эти планы. В современном мире, в котором отдельные люди и компании постоянно стремятся что-то «впарить», потребители выработали здравый смысл. Этот смысл позволяет им почувствовать ложь независимо от того, является она явной или же погребена под тоннами корпоративного красноречия. Большинство людей в подобной ситуации скорее предпочтут ответ «мы не можем (или не будем) давать ответ» какому-нибудь невнятному.

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

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


Люди сосредоточены только на технических аспектах работы, а не на общении

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

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

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

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

Динамика команды также влияет на командную мораль, которая, в свою очередь, воздействует на производительность (как уже рассматривалось в этой части и в части II). Таким образом, проблема заключается не в том, чтобы завести друзей, а в том, чтобы расширить наши представления о работе. Работа – это нечто большее, чем просиживание за рабочим столом, заваленным бумагами, или написание кода. Это формирование отношений, которые позволят эффективно осуществлять совместную деятельность в организации.


Создается впечатление, что разные команды никогда не смогут работать вместе

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

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

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


Межличностные конфликты прошлого приводят к конфликтам между командами

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

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

Если конфликт между командами разгорается без видимых причин, часто может помочь перераспределение людей между командами или проектами. Вполне возможно, что сформировались устойчивые группы по интересам, которые являются благодатной почвой для жалоб и противопоставления «мы – они». В этом случае ротация сотрудников поможет разбить эти группы. У людей также вырабатываются определенные привычки при взаимодействии с другими людьми. И слова «команда разработчиков» или «эксплуатационная команда» могут вызвать негативную реакцию на рефлекторном уровне. Чтобы устранить застарелые привычки, понадобится перестроить или даже переименовать команды.

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


Команда X является бункером для ее участников

Подобно группам по интересам, которые упоминались ранее, в команде формируются группы людей, которые изолируют себя от остальных членов команды, всего отдела и даже от организации. Большинство сотрудников принимают изменения, происходящие в рамках devops-трансформации, – реорганизацию команд, появление новых инструментов или пересмотр рабочих процессов. Но в то же время остаются небольшие группки людей, которые до последнего сопротивляются всяким изменениям.

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

Даже с появлением таких движений, как devops, приводящих к повышению значимости таких ролей, как эксплуатация, все равно остаются виды деятельности, которым присущи недостаточная оценка и уважение либо отсутствуют гарантии сохранения рабочих мест. Как и раньше, встречаются люди, которым не нравится работа. К этим людям обычно относятся хуже, чем к коллегам, и на них постоянно «сыплются все шишки». Именно здесь проявляется расхождение между теорией и практикой devops. Конечно, бункеры могут строиться из-за страхов, связанных с ожиданием появления проблем, имевших место в прошлом. Эти страхи связаны с негативным опытом и никак не связаны с действительностью, это просто «фантомные боли».

В процессе устранения вышеописанных проблем сначала нужно выяснить потребности этих сотрудников. Для ответа на этот вопрос используется иерархия потребностей Маслоу. Когда идет речь о базовых потребностях, предусмотрите справедливую компенсацию. Чтобы чувствовать себя в безопасности, сотрудники должны быть уверены в сохранности рабочих мест. Выполняемая ими работа должна достойно оцениваться организацией. Также организация должна заблаговременно ставить их в известность в случае предстоящих событий, которые так или иначе затронут этих сотрудников, например в случае грядущего ухода в отпуск за свой счет. Люди должны чувствовать себя комфортно на рабочем месте, надлежащим образом оцениваться менеджерами и коллегами. Поэтому внимательно отслеживайте ситуации, когда кто-то не получает должного уважения или находится в изоляции. Если сотрудники гордятся собой и выполняемой ими работой, значит, они реализовали себя и имеют высокую самооценку. Конечно, если в организации какие-то должности считаются непрестижными, самооценка сотрудников может упасть.

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


Людям свойственно возлагать на devops ответственность за допущенные ошибки

Серьезные изменения всегда сопровождаются тр


убрать рекламу







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

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

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

Предоставьте сотрудникам организации возможность дать обратную связь. Пусть делятся своими мыслями о ходе процесса изменений, о том, как эти изменения отражаются на них. Уделяйте внимание негативным отзывам и авторам таких отзывов. Если предлагаемые изменения не устраивают множество людей, возможно, следует докопаться до причин такого недовольства и внести необходимые коррективы. Но если несколько недовольных сотрудников поднимают шумиху, не позвольте им «пустить под откос» изменения, которые приносят благо большинству сотрудников. Далеко не каждый сотрудник подходит организации, а если он противится любым изменениям, в том числе и внедрению devops, лучше с ним расстаться.

Часть IV. Инструменты

 Сделать закладку на этом месте книги

Глава 11. Обзор экосистемы инструментов

 Сделать закладку на этом месте книги

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

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


Разработка программного обеспечения

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


Локальная среда разработки

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

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

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

Идентифицируйте общую область для документирования локальной среды разработки. Документы могут храниться в хранилище системы контроля версий, во внутреннем хранилище wiki или даже в Google Docs. Со временем и при наличии практики степень владения инструментами будет возрастать. Поэтому исчерпывающая документация, в которой описаны все нюансы работы с инструментами, попросту не нужна. Достаточно иметь руководство, содержащее начальные сведения по работе с инструментами.


Контроль версий

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

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

Выбирайте систему контроля версий, которая поощряла бы желаемый для вас тип сотрудничества. В следующем списке приведены предпосылки для развития сотрудничества:

• открытие и доступ к клонированию хранилищ;

• содействие развитию хранилищ;

• управление вкладами в собственные хранилища;

• определение процессов для содействия;

• обмен правами для фиксации изменений.

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

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

В следующем списке приводится дополнительная терминология, относящаяся к контролю версий.

Фиксация 

Фиксация – это последовательность действий по включению изменений, внесенных в файлы под управлением контроля версий.

Конфликты 

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

Запрос на включение кода 

Запрос на включение кода (pull request) – это механизм, который посылает разработчику сигнал о том, что его вклад готов к просмотру и слиянию с основной ветвью.

Избирательный подход 

Избирательный подход – это применение определенных подтверждений из одной отрасли в другой отрасли. Этот подход полезен при необходимости выбора определенных изменений запроса на включение кода.


Управление артефактами

Артефакт – это результат выполнения какого-либо шага в процессе разработки программного обеспечения. Артефакты хранятся в хранилище. Можно выбрать как простое, так и более сложное полнофункциональное хранилище. В последнем случае нужно оценить стоимость поддержки дополнительных услуг и проблем с обеспечением безопасности.

Хранилище артефактов должно быть:

• защищенным;

• доверенным;

• стабильным;

• доступным;

• версионированным.

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

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

На ранних стадиях эволюции организация может не соответствовать определенным требованиям безопасности. Но по мере роста и появления линий продуктов ситуация может измениться. Благодаря наличию выделенного локального хранилища артефактов обеспечивается более плавный переход на пути к достижению соответствия вышеупомянутым требованиям.

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

РАННИЕ ПОЛИТИКИ

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

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

В следующем списке приведена дополнительная терминология, относящаяся к управлению артефактами.

Управление зависимостями 

Зависимости определяются характером и степенью взаимозависимости одного программного проекта от другого. Для выявления подобных зависимостей используются разные механизмы. На уровне артефактов для программного обеспечения может оказаться полезным сохранение зависимых артефактов.

Закрепление 

Закрепление – это метод блокировки явной версии артефакта для окружающей среды. При управлении зависимостями может оказаться полезным определение явной версии зависимого артефакта программы, работающей с вашим проектом.

Продвижение 

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


Автоматизация

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


Установка сервера

Под установкой сервера понимается автоматизация конфигурирования и настройки отдельных серверов. Производители оборудования, такие как HP и Dell, предоставляют инструмент, который можно использовать при работе с оборудованием этих брендов.

Некоторые дистрибутивы Linux также поддерживают инструменты, предназначенные для соответствующей операционной системы. Например, для установки сервера в среде Red Hat Enterprise Linux или CentOS могут использоваться Cobbler и Kickstart. Персонал из эксплуатационного отдела может создавать файлы Kickstart, которые определяют разбиение жесткого диска, конфигурирование сети, устанавливаемые пакеты ПО и т. п.

УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ОБОРУДОВАНИЯ

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


Автоматизация инфраструктуры

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

При описании управления инфраструктурой используется следующая дополнительная терминология.

Конфигурационный сдвиг 

Этот термин описывает феномен, заключающийся в постепенном отклонении конфигурации серверов от начальной.

Среднее время работы между сбоями (mean time between failures; MTBF )

Среднее время работы между сбоями.

Среднее время восстановления (mean time to repair; MTTR) 

Период времени, необходимый для восстановления работоспособности системы.

Доступность 

Широко используемая единица измерения, показывающая, как часто система или услуга оказывается доступной по сравнению с общим временем ее потенциальной полезности. Доступность = MTBF / (MTBF + MTTR).

Управление мощностями 

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

Сервер-«снежинка [42]» 

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

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

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

Автоматизация инфраструктуры по минимуму должна обеспечивать следующее.

Управление конфигурационным сдвигом 

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

Исключение серверов-«снежинок» 

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

Версионированные артефакты инфраструктурного кода 

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

Минимизация сложности 

Решения автоматизации инфраструктуры позволяют отдельным сотрудникам (независимо от выполняемой ими роли) управлять гетерогенной средой с минимальными затратами. Необходимое условие – указание версий конфигурации для типа или версии платформы.

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

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

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

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

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

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


Система выделения ресурсов

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

Система выделения ресурсов (system provisioning) расширяет автоматизацию инфраструктуры, позволяя компаниям определять собственную инфраструктуру. При этом используются не отдельные узлы, а кластеры зависимых систем. Это позволяет сотрудникам задавать отдельную группу серверов, которая будет предоставляться один раз, а затем использовать эту спецификацию автоматически произвольное количество раз.


Автоматизация тестирования и сборки исполняемых файлов

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

Современные инструментальные средства автоматизации обычно специфицируют порядок сборки исполняемых файлов (необходимые шаги и порядок их выполнения). Также определяются требуемые зависимости (другое программное обеспечение, используемое для успешного создания исполняемых файлов). Некоторые инструменты лучше всего подходят для проектов, относящихся к конкретным языкам программирования, таких как Apache Maven и Ant. В то же время эти инструменты могут применяться совместно с другими языками программирования, которые чаще всего используются в проектах Java. Другие же инструменты, такие как Hudson или Jenkins, могут использоваться для большего диапазона проектов.

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

Автоматизация по требованию 

Этот инструмент обычно применяется на усмотрение пользователя и зачастую запускается в командной строке. Например, разработчик может запустить сценарий Make вручную, в среде локальной разработки. Это позволит убедиться в возможности создания исполняемого файла прежде, чем придется проверять его с помощью системы контроля версий.

Запланированная автоматизация 

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

Условная автоматизация 

Этот инструмент запускается в случае какого-либо события, например когда сервер непрерывной интеграции создает новую сборку при каждом подтверждении изменения кода.


ТЕСТЫ, МОНИТОРЫ И ДИАГНОСТИКА по Ивонн Лам

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

Во время выступления на конференции Sysadvent 2014 (https://sysadvent.blogspot.com/2014/12/day-5-how-to-talk-about-monitors-tests.html ) Ивонн Лам определила ряд вопросов, на которые должна ответить команда, чтобы сформировать общий контекст на основе тестов, мониторов и диагностики.

• Где будут выполняться тесты?

• Когда будут выполняться тесты?

• Как часто они будут проводиться

• Кто будет использовать результат?

• Какие действия будут выполняться с результатом?

Затем Лам перечислила ряд дефиниций, которые могут применяться для выяснения различий между системами. Тесты, выполняемые по отношению к непроизводственным системам, предназначены для определения степени готовности системы или программного обеспечения. Как правило, тесты выполняются в том случае, когда что-либо изменяется. Мониторы выполняются в соответствии с графиком в системах подготовки к производству и в производственных системах. Обычно монитор запускается часто или вызывается на выполнение по событию. Диагностика выполняется в производственных системах по требованию и в связи с событием.

Все три вышеперечисленных инструмента используются для наиболее эффективного отслеживания поведения разных систем. Эти инструменты также позволяют уточнить области ответственности разных групп или отдельных сотрудников. Благодаря подобному уточнению облегчается поддержка общего понимания и ответственности.


В следующем списке перечислена дополнительная терминология, имеющая отношение к тестированию.

Дымовое тестирование 

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

Регрессионное тестирование 

Это тестирование позволяет проверить, не вызвали ли изменения в программном обеспечении новые ошибки или сбои.

Тестирование удобства использования 

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

A/B-тестирование 

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

Сине-зеленое развертывание 

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

«Канареечный» процесс 

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


убрать рекламу







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


Мониторинг

Мониторинг – это большая тема, которую можно разбить на подтемы, – чаще всего происходящие события и аналитика. При выполнении мониторинга применяются методы сбора информации, такие как метрики и логи. Процесс мониторинга включает сбор основных показателей системного уровня. Собираются сведения о времени работы или простоя сервера, объеме используемой памяти, использовании времени центрального процессора и величине свободного места на дисках. Также осуществляется мониторинг приложений на более высоком уровне, который варьируется от количества пользовательских запросов, обрабатываемых сервером, числа элементов в очереди системы массового обслуживания, времени загрузки веб-страницы до накопления в базе данных наиболее длительных запросов. Когда-то мониторинг являлся зоной ответственности системных и сетевых администраторов. По мере роста сложности программного обеспечения и все более тесного сотрудничества между командами люди начинают понимать, что благодаря мониторингу можно своевременно выявлять состояние программного продукта.

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


Метрики

Метрики – это совокупность количественных и качественных результатов измерений. Обычно они сравниваются с неким эталоном или установленным стандартом. Цель подобного сравнения заключается в выполнении аналитических исследований или в пополнении архивов. Зачастую метрики накапливаются в функциональных организациях, что может повлиять на выбор корректного направления разработки продуктов.

Метрики являются ключевыми компонентами мониторинга. Могут собираться и накапливаться данные, относящиеся ко всем компонентам наиболее сложных интернет-приложений. Разные команды могут располагать различными метриками, которые они могут отслеживать и использовать в работе. Часто используемые инструменты StatsD и Graphite обеспечивают отслеживание, хранение и просмотр метрик.

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


Системы логирования

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

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


Оповещения

Мониторинг и оповещения важны не только с точки зрения обеспечения производительности программного обеспечения, но и с точки зрения профилактики. В частности, вы сможете своевременно узнать о потенциальных проблемах, пока они не превратились в реальные проблемы для ваших заказчиков. Например, после запуска в октябре 2013 года сайта US HealthCare.gov  отсутствовали средства мониторинга и оповещения, которые позволяли бы определить работоспособность сайта.

Микки Дикерсон, который выполняет функции администратора United States Digital Service, выступал с докладами на многих отраслевых конференциях. Он утверждал, что мониторинг сайтов, выполняемый его командой в течение первых месяцев автоматизации, сводился к просмотру новостных источников, таких как отчеты CNN. Использование открытых источников информации чревато появлением проблем, которых в какой-то степени поможет избежать лишь хорошо продуманная стратегия оповещений.

При рассмотрении системы оповещений нужно учитывать несколько факторов.

Влияние 

Далеко не все системы оказывают одинаковое влияние на другие системы или людей. Те из них, которые получили широкое распространение и воздействуют на многие системы или большие группы пользователей, оказывают намного большее влияние, чем те, которые воздействуют на небольшую группу других систем или людей. Некоторые инциденты вообще не задевают интересы клиентов либо воздействуют на системы, которые обладают достаточным запасом прочности. Чтобы избежать усталости, вызванной навязчивыми оповещениями, применяйте их только в случае наиболее значительных инцидентов. Подробнее эта тема будет рассмотрена далее.

Срочность 

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

Заинтересованная сторона 

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

Ресурсы 

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

Стоимость 

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

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


События

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

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

Многие системы оповещения и мониторинга используют встроенные методы автоматического реагирования на события. Например, система мониторинга Nagios включает «обработчики событий», которые могут быть сконфигурированы с учетом различных условий оповещений. Эти обработчики могут выполнять различные действия – от автоматического перезапуска службы до создания распоряжения технику на замену отказавшего жесткого диска. Автоматизированные обработчики событий могут существенно сократить объем работы эксплуатационного отдела (и объем сверхурочной работы), хотя использование таких обработчиков связано с определенными рисками. Важно убедиться в том, что условия сбоев четко определены, а принципы работы обработчика событий понимаются настолько хорошо, что могут быть автоматизированы. Также нужны определенные гарантии в том, что автоматизация в большей степени решает проблемы, чем создает.

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

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

Проектирование оповещений, или методы создания оповещений, которые передают информацию людям в наиболее понятной форме, является непростой проблемой. В компании Etsy был создан инструмент OpsWeekly (https://github.com/etsy/opsweekly ), предназначенный для создания подобных оповещений и выполнения категоризации оповещений по типу и компоненту. Благодаря отслеживанию трендов оповещений и анализу данных оповещений можно резко улучшить эффективность оповещений и сделать счастливыми людей, призванных отвечать на них.

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

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


Эволюция экосистемы инструментов

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

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

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

По мере адаптирования системы разработки приложений к критериям повышения эффективности продолжает развиваться экосистема инструментов. Если вы начнете перечислять вручную 12 факторов[43], участвующих в разработке приложения, это будет то же самое, что и ручная настройка конфигурации серверов. Если будут стандартизованы и автоматизированы рабочие требования, сотрудники получат свободу выбора языка и рабочего шаблона.

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


Выводы

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

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

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

Глава 12. Инструменты: акселераторы культуры

 Сделать закладку на этом месте книги

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

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

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


Значение инструментов для людей

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

Инструменты не создаются сами по себе, как самоцель, они нужны для облегчения выполняемой работы. Это обстоятельство важно учитывать при выборе инструментов. Благодаря правильно подобранным инструментам обеспечивается возможность более тесного сотрудничества. В результате становится возможным переход от написания и поддержки программ одним человеком к созданию программ несколькими людьми и даже командами. А написанные ранее программы могут восприниматься и поддерживаться разными командами даже несколько лет спустя.


Определение инструментов

Зачастую при обсуждении инструментов в центре внимания оказывается программное обеспечение. Обговариваются используемые языки программирования, интегрированные среды разработки, текстовые редакторы, оболочки, решения по управлению конфигурированием или программы чата. Но инструменты – это нечто большее, чем программное обеспечение. По сути, это все, что помогает нам достичь цели, но само не потребляется в процессе достижения цели. В следующем перечне приводятся примеры инструментов.

• Подъемная тележка сервера позволяет снизить травматизм и ускорить работы по техобслуживанию в центрах обработки данных.

• Меньший по размерам и более легкий ноутбук облегчает вашу жизнь во время поездок на конференции и посещения центра обработки данных.

• Выбор аппаратного RAID-решения обойдется вам дороже (по сравнению с программным RAID-решением), но зато даст такие преимущества, как возможность аварийного электропитания от батарей и более легкое техобслуживание.

НАИЛУЧШИЙ ИНСТРУМЕНТ

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

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


Выбор нужных инструментов для решения реальных проблем

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

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

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

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

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


Область охвата проектов с открытым кодом

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

Должны ли компании отказаться от использования инструментов с открытым исходным кодом из-за боязни утратить конкурентное преимущество? Скорее нет, чем да. Возможно, ваша компания зарабатывает деньги на продаже инструментов, которые являются составной частью бизнес-модели. Но в этом случае можно продавать программное обеспечение либо, как делают многие современные компании, зарабатывать деньги на поддержке или обслуживании этого программного обеспечения.

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

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

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

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

В силу ряда причин компании не желают быть привязанными к одному конкретному поставщику. К тому же следует принимать во внимание негатив, вызванный синдромом неприятия чужой разработки  (Not Invented Here). Например, если в вашей компании отсутствует команда экспертов в области компьютерной безопасности, создаваемое вами криптографическое программное обеспечение будет содержать ошибки, а следовательно, уязвимости в системе безопасности. Если компания не специализируется в области сетевого ПО, вряд ли для нее целесообразно разрабатывать собственный DNS-сервер. Вряд ли специалисты из этой компании смогут создать что-то лучшее, чем сервер BIND. К тому же разработчикам не стоит тратить время на разработку, поддержку и устранение проблем незнакомого программного обеспечения.

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

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


Стандартизация инструментов

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

Инструменты могут использоваться для:

• улучшения общения;

• установки границ;

• устранения недопонимания в рамках devops-пакта.

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


Последовательные процессы анализа инструментов

Благодаря стандартизации инструментов «прокладываются мостики» между старыми и новыми технологиями по мере изменения компании. Благодаря использованию последовательных процессов оценки, выбора и отказа от инструментов организации будут:

• выбирать инструменты, соответствующие потребностям большинства людей;

• обеспечивать наличие необходимых средств, как прежних, так и новых;

• гарантировать подготовку сотрудников, необходимую для эффективного использования нового оборудования или программ.

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

Благодаря использованию последовательных


убрать рекламу







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


Исключения из стандартизации

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

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

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


Бесполезность инструментов

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

Выражение «инструменты ничего не значат» имеет два значения:

• использование инструментов не является достаточным основанием для существования devops-культуры;

• инструменты не способны исправить дефектные культуры, скорее они выявляют и усугубляют условия среды.

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


Причины неудач – в процессе, а не в инструментах

Компания потерпит неудачу, если не сможет понять, каким образом реализовать и использовать управление конфигурацией вместо красивых и уникальных серверов-«снежинок». Неспособность к своевременному реагированию на проблемы среды приводит к возникновению простоев, а следовательно, к потере прибыли. И независимо от инструментов, выбранных для управления конфигурацией, – Puppet, Chef, Ansible, Salt, CFEngine или же какого-либо другого инструмента, – при использовании должной методики вы просто обречены на успех.

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


Применение закона Конвея для выбора инструмента

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

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


Влияние инструментов на культуру

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


Инструменты, влияющие на процесс общения

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

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

Зачастую важнее не то, какой инструмент выбирается, а то, как он используется. Например, рассмотрим систему отслеживания ошибок. Если команды примут решение о том, что инструменты не имеют значения, и выберут систему отслеживания ошибок, дополняющую используемый этими командами рабочий стиль, велика вероятность, что применяемые в этих командах разные средства и практики существенно затруднят эффективную совместную работу.

Члены команд, использующих разные инструменты, будут иметь несколько учетных записей, подлежащих управлению, либо будут недостаточно информированы о работе других команд.

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

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

Как упоминалось в части II, существует много факторов, которые следует учитывать при общении. Эти факторы препятствуют выбору единого инструмента общения, отвечающего всем потребностям здоровой организации. Также вполне вероятно, что потребности в общении будут изменяться по мере роста компании. Например, в небольшом стартапе имеет смысл организация общения с помощью чата, когда участие в беседе может принимать каждый сотрудник. По мере роста организации более рациональным может стать общение с помощью электронной почты или командной вики-страницы.

ОЦЕНКА СТЕПЕНИ УЧАСТИЯ СОТРУДНИКОВ В ПРИНЯТИИ ВАЖНЫХ РЕШЕНИЙ

По мере роста компании критически важно понимать и оценивать степень участия отдельных сотрудников.

Процесс поиска корректных инструментов, используемых в нужное время, является итеративным. Учет мнения всех сотрудников в процессе принятия важных решений способствует формированию здоровых организаций. Не следует полагать, что молчание означает согласие большинства. Как показали результаты исследований деятельности смарт-команд, более эффективными и продуктивными являются те команды, в которых каждый обладает правом голоса[44].

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

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


ХОЛЛИ КЭЙ, «BEING A DEAF DEVELOPER» (КАКОВО БЫТЬ ГЛУХИМ ПРОГРАММИСТОМ)[45]

Я страдаю глухотой с детства. Моя глухота не абсолютна, скорее она находится в диапазоне от умеренной до тяжелой. Я не слышу звуки, находящиеся в высокочастотной части спектра, к которой относится большинство человеческих голосов. Для понимания человеческий речи я использую чтение по губам и полагаюсь на закономерности произношения гласных букв. Но мне сложно распознавать следующие структурные компоненты речи:

• согласные, особенно шипящие и глухие (все согласные, произносимые с высокой частотой, а также глухие и шипящие согласные, при произнесении которые не используются голосовые связки);

• начало (и конец) предложений.

У многих сложился стереотипный образ программиста как нелюдимого типа, сторонящегося сотрудников компании. На самом деле этот образ далек от реальности. Программисты, объединенные в группу, довольно сильно социализированы. Мы ведем блоги, выступаем на конференциях, пишем учебники, исполняем роль наставников. Подобная атмосфера присутствует вот уже несколько десятков лет в Bell Labs, Массачусетском технологическом университете и во многих других научно-исследовательских организациях. Я обожаю социальный мир кода, мне нравится возможность окружить себя компетентными энтузиастами, которые способствуют моему собственному росту. Единственное, что мне не нравится, – парное программирование.

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

Но если вы не слишком хорошо слышите, вы не оцените преимущества парного программирования. Например, для меня парное программирование более чем бесполезно. Мне приходится одновременно думать о коде, смотреть на находящийся передо мной экран и читать по губам. При этом я пытаюсь разобрать произносимые с высоким темпом слова и технический жаргон. В лучшем случае я понимаю не более 30 % сказанного, поэтому ощущаю себя глубоко несчастной. В конце концов мне надоедает наблюдать за моим недовольным партнером, и я передаю ему бразды правления. Ему приходится смотреть на экран, искать способы программирования и пытаться наладить беседу со мной. В итоге вся работа ложится на его плечи, что приводит к нивелированию самой идеи парного программирования.

Конечно, было бы здорово поработать в паре с Роуэн Мэннинг (Rowan Manning) над проектом Pa11y. В рамках этого проекта разрабатывается автоматизированный инструмент тестирования доступности, предназначенный для компании Nature. Благодаря использованию инструмента Screenhero для создания удаленных парных сеансов мы могли бы одновременно смотреть на экран и общаться в текстовом режиме. При этом отсутствует риск утери информации и каких-либо конфузов. Это первый удачный, как по мне, пример парного сеанса. Довольно трудно описать словами преимущества, обеспечиваемые этим сеансом. Давайте оценим масштабы потери информации, имеющие место в процессе беседы со слабослышащим человеком. Предположим, что во всех книгах, доступных в вашем городе, около 60 % слов закрашены маркером. Затем представьте себе, что вы отправились в соседний город, в котором книги не подвергаются подобной цензуре. Естественно, что вам очень понравится возможность свободного чтения книг без необходимости угадывать смысл. Теперь вы понимаете, насколько комфортно будет чувствовать себя слабослышащий человек в случае правильной организации парного сеанса.


Инструменты, влияющие на расширенный набор поведений

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

Учитывая вышесказанное, отметим, что аргументы в пользу выбора инструмента, полностью удовлетворяющего всем требованиям, лишены смысла. Поэтому в этой главе вы не найдете утверждений типа «Этот X  является единственным подходящим инструментом Y  для devops», поскольку это утверждение в корне неправильное. Это все равно что объявить редактор ed [46] истинным победителем в войне редакторов. В связи с тем, что достижение универсального консенсуса по поводу «лучшего» инструмента невозможно, выбор лучшего решения определяется спецификой решаемых проблем.


Выбор инструментов

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

• развитие продукта;

• состояние здоровья сообщества;

• настройка по месту установки.

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

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

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


Развитие продукта

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

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

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

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


Состояние здоровья сообщества

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

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

• частота ответов на запросы на включение;

• среднее время устранения проблем;

• частота выпуска новых версий;

• создание контента (посты в блогах, статьи и новости);

• частота общения в форумах.

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

• Существуют ли кодексы поведения для проектов и событий, связанных с сообществом?

• Какова направленность дискуссий, связанных с проблемами и запросами на включение кода?

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

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


Настройка по месту установки

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

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

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


Пример: сравнение систем контроля версий

Системы контроля версий со временем записывают изменения в набор файлов. В 2000 году компания CollabNet основала проект Subversion, используемый в качестве системы контроля версий и ревизий программного обеспечения с открытым исходным кодом. Эта система была совместима с системой CVS (Concurrent Versions System, система одновременных версий). В феврале 2004 года появилась подверсия 1.0 (Subversion 1.0), или svn. Использование и свойства svn диктовались технологиями и привычками пользователей. Ядром архитектуры svn явилась концепция централизованного хранилища. Благодаря этому хранилищу пользователи могли контролировать, кто был допущен или не допущен к выполнению изменений.

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


Пример: автоматизация ручной инфраструктуры

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

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

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

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

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

И наконец, при выборе инструментов нужно сбалансировать связанность и гибкость. Если же применяется много способов коммуникации, людям придется выполнять множество действий для поиска нужной информации. Эта информация может находиться в сообщении электронной почты, документе Google Doc или на wiki-странице. Также придется искать наиболее эффективный способ передачи информации людям – с помощью мгновенного сообщения, текстового сообщения или получения доступа к рабочему столу пользователя. С другой стороны, при недостатке способов коммуникации также возникнут проблемы. Все мы слышали истории о компаниях, которые по каждому поводу проводят собрания, когда можно проще и быстрее решить возникающие проблемы с помощью электронной почты.

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


Аудит экосистемы инструментов

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

Критически важным для эффективного использования инструмента является согла