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

Глава 12. Инструменты: акселераторы культуры
245
Вряд ли может считаться здоровым общество, в котором допускаются личные оскорбления, сексистские, гомофобные или трансфобные высказывания. Это относится ко всем сообществам, а не только к проектам с открытым исходным кодом. Люди, использующие различные инструменты в своей повседневной работе, будут взаимодействовать с другими пользователями этих инструментов.
Это взаимодействие реализуется в форме локальных встреч либо глобальных конференций, на которых рассматриваются инструменты и порядок их приме- нения.
Как рассматривалось ранее в главе, одно из преимуществ программного обес- печения с открытым исходным кодом заключается в том, что вам не придется изобретать велосипед, устраняя ранее решенные проблемы. Благодаря увели- чению вклада в решение с открытым исходным кодом со стороны сообщества повышается эффективность его внедрения.
Настройка по месту установки
Инструменты, которые легко настраиваются и имеют большую поддержку со сто- роны сообщества, позволяют создавать надежное решение, которое хорошо под- ходит как для технологических, так и для гуманистических аспектов среды. Это особенно важно для тех организаций, в которых с определенным инструментом ра- ботает большое количество людей. Инструмент с таким масштабом использования будет иметь возможность расти вместе с вашей организацией, а также облегчать выполнение инженерных работ.
Как правило, инструменты с открытым исходным кодом являются самыми настра- иваемыми. Это связано с тем, что в вашем распоряжении имеется программный код, который гораздо проще просмотреть и изменить в случае необходимости.
В результате облегчается выполнение таких действий, как исправление ошибок.
Вместо того чтобы подавать заявку в службу поддержки и ожидать ее решения, можно самостоятельно идентифицировать ошибку и даже отправить запрос на включение кода. Даже при использовании инструментов с закрытым исходным кодом обращайте внимание на наличие таких средств, как API, которые могут при- меняться для разработки дополнительных инструментов, используемых наравне с существующими инструментами.
Если вы в состоянии настроить инструмент, устранить свои собственные ошибки и даже добавить новые средства и расширения, значит, со временем вы в совер- шенстве овладеете этим инструментом. Если вы располагаете средством, которое является нишевым или малозначительным, но чрезвычайно полезно для одной из ваших команд, проще внедрить его самостоятельно, чем ждать соответствующей милости от разработчика. Вполне возможно, что в результате подобного творчест- ва появится действительно полезный инструмент.

246
Часть IV. Инструменты
Пример: сравнение систем контроля версий
Системы контроля версий со временем записывают изменения в набор файлов.
В 2000 году компания CollabNet основала проект Subversion, используемый в ка- честве системы контроля версий и ревизий программного обеспечения с откры- тым исходным кодом. Эта система была совместима с системой CVS (Concurrent
Versions System, система одновременных версий). В феврале 2004 года появилась подверсия 1.0 (Subversion 1.0), или svn. Использование и свойства svn диктова- лись технологиями и привычками пользователей. Ядром архитектуры svn явилась концепция централизованного хранилища. Благодаря этому хранилищу пользо- ватели могли контролировать, кто был допущен или не допущен к выполнению изменений.
Годом позже, в 2005 году, появилась система Git. Это также система контроля версий программного обеспечения с открытым исходным кодом. В этой системе делался упор на децентрализованной системе контроля версий, быстродействии целостности данных и поддержке распределенных нелинейных рабочих процес- сов. В результате каждый разработчик получал полный локальный контроль.
В то время как можно было адаптировать централизованный рабочий поток и установить «центральное» хранилище, могли применяться и гибкие процес- сы. В результате появилась возможность выбора используемой технологии.
Несмотря на то что в этом случае увеличивается время «разгона», улучшенные функциональные средства позволяют ускорить выполнение организационных изменений.
Пример: автоматизация ручной инфраструктуры
Большинство используемых решений автоматизации инфраструктуры аналогич- ны с точки зрения функциональных свойств, даже если отличаются в реализации.
Каждый из инструментов может привести как к поощрению, так и к подавлению разных аспектов сотрудничества.
Во многих организациях конфигурирование системы выполняется в ручном ре- жиме. Процесс конфигурирования и обновления документируется с помощью контроль ных списков. Пропущенный шаг может привести систему в неопределен- ное состояние, для выхода из которого потребуются значительные усилия.
Когда Адам Джейкоб разрабатывал программу Chef, он пытался создать решение, которое могло бы использоваться в разных организациях. Программа Chef была разработана таким образом, чтобы поддерживать абстракции, используемые при конфигурировании и менеджменте. При этом был создан язык, который давал программистам возможность с помощью кода определять инфраструктуру и по- литику.
Создать язык, который позволял бы детально учитывать интересы разработчиков, системных администраторов, инженеров по обеспечению качества и безопасности,

Глава 12. Инструменты: акселераторы культуры
247
довольно сложно. С помощью Chef, а не путем повторного использования тер- минологии, которая расставляет приоритеты для разных ролей, Джейкоб создал новую терминологию, включающую ресурсы и рецепты.
Весьма важно учитывать инструменты общения, подобные инструментам, рас- смотренным в примере про двух скалолазов (см. главу 2). Эти инструменты могут как оказаться полезными, поддержав созданный нами пакт, так и оказать медвежью услугу, сбив нас с правильного пути. Конечно же, все зависит от спосо- ба использования каждого инструмента. Если, например, пытаться использовать среду общения с низкой степенью безотлагательности, например электронную почту, в ситуациях, когда требуются немедленные ответы, это приведет к воз- никновению проблем. Также проблемы появятся, если вы попытаетесь описать что-либо словами в ситуации, когда иллюстрации быстрее и эффективнее пере- дадут суть дела.
И наконец, при выборе инструментов нужно сбалансировать связанность и гиб- кость. Если же применяется много способов коммуникации, людям придется вы- полнять множество действий для поиска нужной информации. Эта информация может находиться в сообщении электронной почты, документе Google Doc или на wiki-странице. Также придется искать наиболее эффективный способ передачи информации людям — с помощью мгновенного сообщения, текстового сообщения или получения доступа к рабочему столу пользователя. С другой стороны, при недостатке способов коммуникации также возникнут проблемы. Все мы слыша- ли истории о компаниях, которые по каждому поводу проводят собрания, когда можно проще и быстрее решить возникающие проблемы с помощью электронной почты.
Наш пакт, основанный на всеобщем понимании, будет полезным только в том случае, когда есть традиции или обычаи, на которые можно опираться при выборе наиболее эффективного средства. Но при этом необходимо наличие гибкости, позволяющей выбрать инструмент, который был бы подходящим для выполнения определенной работы.

248
Часть IV. Инструменты
Критически важным для эффективного использования инструмента является согласование процессов и желаний отдельных пользователей. Чрезмерный ак- цент на процессах приводит к высокой цене для отдельных пользователей. Это связано с тем, что им приходится поддерживать сложный контекст, связанный с этими процессами. Подобная деятельность может отвлекать от работы над проектом. Если же процессам уделяется слишком мало внимания, это приводит к отстраненности команды от применяемых инструментов и методов. То же са- мое касается отдельных сотрудников. При этом потребуется время на коррекцию понимания, слияние работы или проверку наличия дублирующих видов работ.
Выполнение подобных базовых операций является ключевым для всех аспектов идентификации и выбора инструментов. Особенно важны они при масштабиро- вании организаций.
Как правило, цель использования инструментов заключается в оказании помощи при создании среды, в которой люди могут концентрироваться на решении реаль- ных проблем. Создание среды подобного рода гарантирует предоставление воз- можностей по управлению успешной командой, а также требует приложения по- стоянных усилий. Аудит подобного рода не относится в категории задач, которые можно выполнить один раз, а потом забыть о них. Чтобы создавать и поддерживать эффективную среду, рядовые сотрудники и менеджеры должны использовать проактивный подход.
Устранение инструментов
Следует выполнять регулярные обзоры текущих процессов и инструментов, которые позволят убедиться в эффективности их использования. Благодаря от- слеживанию технических долгов и долгов, связанных с автоматизацией, можно идентифицировать процессы и инструменты, которые необходимо устранить.
В результате предотвращаются ситуации, когда использование инструмента уве- личивает объем работ. Также облегчается идентификация и устранение инстру- ментов, выполняющих одни и те же функции. Это позволяет снизить затраты и ликвидировать беспорядок.
Эти обзоры также должны включать выполнение регулярных проверок сотруд- ников, в ходе которых исследуются базовые истории, которые воздействуют на сотрудников и выполняемую ими работу. Задайте следующие вопросы.

Что восхищает/расстраивает вас?

Что способствует пополнению/истощению вашей энергии и мотивации?

Как вы оцениваете выполняемую работу?

Какова степень вашего влияния?

Глава 12. Инструменты: акселераторы культуры
249

Что мы должны прекратить делать?

Что мы должны начать делать?
Задавайте эти вопросы только тем людям, которые регулярно используют инстру- менты для выполнения текущей работы. Решения, принятые в пользу выбора или устранения инструментов, должны основываться на мнении пользователей этих инструментов. Эти решения не должны спускаться сверху людьми, которые не имеют практического опыта работы с этими инструментами.
Улучшения: планирование и оценка изменений
Внедрение изменений требует времени. Независимо от того, идет речь о програм- мах или о людях, для сложных проблем не существует быстрых универсальных решений. Согласно принципу целей «SMART»
1
, цели должны быть конкретными, измеримыми, достижимыми и ограниченными временными рамками. Изменение
SMART критически важно как для организации в целом, так и для поддержания культуры на рабочем месте.
Идентифицируйте конкретную проблему, которую вы решаете в данный момент.
Прежде чем приступать к выполнению изменений, оглянитесь вокруг и проверьте, что должно быть сделано. Установите, кто заинтересован в проекте, у кого есть время, и оцените общую стоимость проекта. Отобразите различные параметры и идентифицируйте возможные проекты. Расставьте приоритеты для проектов и убедитесь в том, что вы работаете над устранением актуальных проблем.
Разбейте конкретный проект на меньшие фрагменты, которые могут выполнять- ся и отслеживаться по отдельности. Эти фрагменты обычно проще планировать, а следовательно, легче обсуждать. Соответственно проще убедиться в том, что они являются достижимыми, реалистичными и направлены на решение нужных задач.
Чтобы выполнять планирование этих проектов на высоком уровне, нужно иденти- фицировать людей, заинтересованных в устранении проблем. Каковы их потребно- сти и мотивация? Как часто они собираются использовать это решение? Опишите решение в терминах конечной цели. Пообщайтесь с заинтересованными лицами и получите одобрение начальства. Все это требует затрат времени и усилий.
После идентификации проблемы и лиц, заинтересованных в ее устранении, можно приступать к подбору необходимых инструментов. Прежде чем выбрать опреде- ленное решение, рассмотрите сильные и слабые стороны различных предлагаемых решений. Также привлекайте к этому процессу заинтересованных лиц, которые помогут вам оценить потенциальные решения. Порой вы будете приходить к выво- дам об отсутствии подходящего решения. В этом случае вам придется изобретать
1
G. T. Doran, «There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives» (Management
Review, 1981).