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

Выбор инструментов

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

• развитие продукта;

• состояние здоровья сообщества;

• настройка по месту установки.

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

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

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

Развитие продукта

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

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

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

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

Состояние здоровья сообщества

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

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

• частота ответов на запросы на включение;

• среднее время устранения проблем;

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

• создание контента (посты в блогах, статьи и новости);

• частота общения в форумах.

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

• Существуют ли кодексы поведения для проектов и событий, связанных с сообществом?

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

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

Настройка по месту установки

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

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

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

Оглавление книги