Описанное выше поведение может объясняться разными причинами, и наиболее распространенная среди них – конкуренция. Многие компании просто не хотят признавать решения, разработанные конкурентами, не говоря уже об использовании этих решений. Свою роль играет страх перед неизвестным программным обеспечением, созданным незнакомыми разработчиками. Многие просто не доверяют коду, написанному другими разработчиками, полагая, что они могли бы написать лучший код. Некоторым людям просто нравится программировать либо разбираться в новых языках программирования.
Свою роль могут играть и вполне обоснованные опасения по поводу использования решений от сторонних поставщиков. Если какой-либо компонент встраивается в существующий программный проект, придется обновить либо изменить лицензию проекта, чтобы она соответствовала лицензии нового внешнего компонента. Также существует вероятность лишиться поддержки производителя внешнего программного компонента. Соответственно, вы лишитесь возможности получать новые версии программы и рано или поздно будете вынуждены перейти на другую программу.
В силу ряда причин компании не желают быть привязанными к одному конкретному поставщику. К тому же следует принимать во внимание негатив, вызванный синдромом неприятия чужой разработки (Not Invented Here). Например, если в вашей компании отсутствует команда экспертов в области компьютерной безопасности, создаваемое вами криптографическое программное обеспечение будет содержать ошибки, а следовательно, уязвимости в системе безопасности. Если компания не специализируется в области сетевого ПО, вряд ли для нее целесообразно разрабатывать собственный DNS-сервер. Вряд ли специалисты из этой компании смогут создать что-то лучшее, чем сервер BIND. К тому же разработчикам не стоит тратить время на разработку, поддержку и устранение проблем незнакомого программного обеспечения.
Применение инструментов может способствовать усилению поведения, оказывающего влияние на культуру. Поэтому при исследовании связи между набором поведений и культур крайне важно исследовать влияние выбора инструментов. Использование программ с открытым кодом может не только открыть путь к решениям, которые являются новыми с точки зрения доступных инструментов и технологий, но и окажет заметное влияние на культуру сотрудничества, общего доступа и открытости.
Благодаря огромному количеству проектов с открытым кодом и соответствующих сообществ разработчики могут получить бесценный опыт и освоить множество паттернов разработки, подходящих для текущей среды.
Стандартизация инструментовЭффективная работа невозможна без выработки взаимного понимания и ведения переговоров, позволяющих смягчить возможное недопонимание, которое возникает в случае, если команды пытаются одновременно достичь нескольких целей.
Инструменты могут использоваться для:
• улучшения общения;
• установки границ;
• устранения недопонимания в рамках devops-пакта.
Организации нуждаются в стандартизации инструментов, чтобы достичь баланса между проблемами и затратами на поддержку инструментов, выполняющих одни и те же функции. Благодаря стандартизации достигается гибкость на уровне команд. Благодаря возможности выбора собственных инструментов расширяются возможности отдельных сотрудников по внедрению гибкого и ответственного подхода к работе.
Последовательные процессы анализа инструментовБлагодаря стандартизации инструментов «прокладываются мостики» между старыми и новыми технологиями по мере изменения компании. Благодаря использованию последовательных процессов оценки, выбора и отказа от инструментов организации будут:
• выбирать инструменты, соответствующие потребностям большинства людей;
• обеспечивать наличие необходимых средств, как прежних, так и новых;
• гарантировать подготовку сотрудников, необходимую для эффективного использования нового оборудования или программ.
Если же последовательные процессы, необходимые для построения «мостов» между старыми и новыми технологиями, отсутствуют, сотрудники будут противиться внедрению новых инструментов и технологий. Подобные процессы минимизируют риск, связанный как с отсутствием удовлетворения прежних и новых потребностей, так и с наличием людей, противящихся изменениям в рабочей среде.
Благодаря использованию последовательных процессов вы сможете избежать разного рода логистических кошмаров, которые могут стать суровой реальностью в случае отсутствия соответствующих процессов или стандартизации. Например, если в каждой команде используется собственная система отслеживания ошибок, уменьшается степень прозрачности на уровне всей организации, повышается вероятность дублирования усилий и увеличивается количество времени, которое придется тратить на ориентирование и взаимодействие между разными системами.
Исключения из стандартизацииКак и любому другому процессу, стандартизации присущи свои исключения. Если команда нуждается в некоторой изоляции или ей присущи определенные уникальные требования, вряд ли стоит заставлять эту команду использовать стандартные инструменты.
В качестве одного из примеров можно рассмотреть совместимость со стандартом безопасности PCI, которая требует очень четкого разделения обязанностей. Команда, ответственная за работу с PCI, работает на отдельных компьютерах и в отдельной сети, изолированной от корпоративной сети. В этом случае сегрегированная среда позволяет использовать разные инструменты, не оказывая отрицательного влияния на организацию в целом. В каждом конкретном случае решения должны приниматься с учетом индивидуальных особенностей.
Несмотря на наличие общих черт, каждая команда и организация обладает уникальными потребностями и опытом. В практиках, относящихся к этой главе, будут рассмотрены подходы двух команд к выбору и внедрению инструментов. Несмотря на наличие общих принципов и подходов, подход к выбору каждого инструмента индивидуален и основан на текущей среде.
Бесполезность инструментовСуществуют различные мнения по поводу ценности и полезности инструментов. Точка зрения «инструменты ничего не значат» появилась в ответ на попытки некоторых поставщиков навесить ярлык «devops» буквально на все продукты независимо от того, соответствует это действительности или нет.
Выражение «инструменты ничего не значат» имеет два значения:
• использование инструментов не является достаточным основанием для существования devops-культуры;
• инструменты не способны исправить дефектные культуры, скорее они выявляют и усугубляют условия среды.
В конечном счете любое «devops-решение», которое включает только инструменты, игнорируя при этом то, кто, как и почему использует эти инструменты в организации, не позволяет получить представление о самом движении devops и о критериях успешного внедрения devops. Не пытайтесь решать межличностные и культурные проблемы исключительно с помощью инструментов и технологий.
Причины неудач – в процессе, а не в инструментах
Компания потерпит неудачу, если не сможет понять, каким образом реализовать и использовать управление конфигурацией вместо красивых и уникальных серверов-«снежинок». Неспособность к своевременному реагированию на проблемы среды приводит к возникновению простоев, а следовательно, к потере прибыли. И независимо от инструментов, выбранных для управления конфигурацией, – Puppet, Chef, Ansible, Salt, CFEngine или же какого-либо другого инструмента, – при использовании должной методики вы просто обречены на успех.
Важны не различия между инструментами, а функциональные свойства, которые помогают решить конкретные проблемы организации. И что немаловажно, успешное решение этих проблем зависит от культуры, сформированной в организации.
Применение закона Конвея для выбора инструмента
В соответствии с этим законом, названным в честь ученого и программиста Мелвина Конвея, разрабатываемое программное обеспечение обычно отражает структуру и организацию команд-разработчиков. Поэтому для обеспечения совместной работы двух компонентов программного обеспечения, каждый из которых спроектирован и внедрен отдельной командой, необходимо взаимодействие между этими командами.
Если же команды не могут адекватно общаться между собой, например, в силу нахождения в чрезмерно изолированной среде, создаваемые ими продукты не будут корректно взаимодействовать между собой. В результате команды выбирают и используют инструменты
