Философия DevOps — страница 53 из 95

неприятия чужой разработки (Not Invented Here). Например, если в вашей компании отсутствует команда экспертов в области компьютерной безопасности, создаваемое вами криптографическое программное обеспечение будет содержать ошибки, а следовательно, уязвимости в системе безопасности. Если компания не специализируется в области сетевого ПО, вряд ли для нее целесообразно разрабатывать собственный DNS-сервер. Вряд ли специалисты из этой компании смогут создать что-то лучшее, чем сервер BIND. К тому же разработчикам не стоит тратить время на разработку, поддержку и устранение проблем незнакомого программного обеспечения.

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

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

Стандартизация инструментов

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

Инструменты могут использоваться для:

• улучшения общения;

• установки границ;

• устранения недопонимания в рамках devops-пакта.

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

Последовательные процессы анализа инструментов

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

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

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

• гарантировать подготовку сотрудников, необходимую для эффективного использования нового оборудования или программ.

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

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

Исключения из стандартизации

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

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

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

Бесполезность инструментов

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

Выражение «инструменты ничего не значат» имеет два значения:

• использование инструментов не является достаточным основанием для существования devops-культуры;

• инструменты не способны исправить дефектные культуры, скорее они выявляют и усугубляют условия среды.

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


Причины неудач – в процессе, а не в инструментах

Компания потерпит неудачу, если не сможет понять, каким образом реализовать и использовать управление конфигурацией вместо красивых и уникальных серверов-«снежинок». Неспособность к своевременному реагированию на проблемы среды приводит к возникновению простоев, а следовательно, к потере прибыли. И независимо от инструментов, выбранных для управления конфигурацией, – Puppet, Chef, Ansible, Salt, CFEngine или же какого-либо другого инструмента, – при использовании должной методики вы просто обречены на успех.

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


Применение закона Конвея для выбора инструмента

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

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

Влияние инструментов на культуру

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


Инструменты, влияющие на процесс общения

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

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

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

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

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

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