ГЛАВА 12Инструменты: акселераторы культурыИнструменты служат акселераторами, увеличивающими скорость изменений те- кущей культуры организации. Если же мы не осознаем наше текущее положение либо направление движения, ускорение может привести к неожиданным послед- ствиям с потенциально негативным воздействием.Мир стремительно изменяется, поэтому для достижения успеха нужно оператив- но реагировать на вызовы. Требуется время, чтобы осознать наше текущее поло- жение, наши отношения с другими командами, организациями, конкурентами и миром в целом. И помочь нам в этом может «стоп-кадр», который выявляет, над чем мы должны работать, что нужно отложить, а что исключить из нашей среды.В этой главе мы выйдем за рамки нашего исследования текущей экосистемы инструментов и рассмотрим примеры из реальной жизни, иллюстрирующие взаимное влияние и воздействие друг на друга инструментов и культуры. Эти ис- следования представлены не в виде конкретных инструкций, а скорее в качестве иллюстрации различных способов, с помощью которых организации оценивают, выбирают и используют инструменты в своих средах. Расценивайте результаты этих исследований как рекомендации по выбору инструментов, а не как требова- ния по использованию одного-единственного инструмента в качестве универсаль- ного средства удовлетворения всех потребностей devops.
Значение инструментов для людейИспользование инструментов для повышения эффективности работы имеет длинную историю. Например, переход от пишущих машинок на текстовые про- цессоры позволил снизить стоимость исправления ошибок. Переход от перфо- карт и языков ассемблера к языкам более высокого уровня привел к улучшению понимания кода.
Глава 12. Инструменты: акселераторы культуры
233
Инструменты не создаются сами по себе, как самоцель, они нужны для облег- чения выполняемой работы. Это обстоятельство важно учитывать при выборе инструментов. Благодаря правильно подобранным инструментам обеспечивается возможность более тесного сотрудничества. В результате становится возможным переход от написания и поддержки программ одним человеком к созданию про- грамм несколькими людьми и даже командами. А написанные ранее программы могут восприниматься и поддерживаться разными командами даже несколько лет спустя.
Определение инструментов
Зачастую при обсуждении инструментов в центре внимания оказывается про- граммное обеспечение. Обговариваются используемые языки программирования, интегрированные среды разработки, текстовые редакторы, оболочки, решения по управлению конфигурированием или программы чата. Но инструменты — это нечто большее, чем программное обеспечение. По сути, это все, что помогает нам достичь цели, но само не потребляется в процессе достижения цели. В следующем перечне приводятся примеры инструментов.
Подъемная тележка сервера позволяет снизить травматизм и ускорить работы по техобслуживанию в центрах обработки данных.
Меньший по размерам и более легкий ноутбук облегчает вашу жизнь во время поездок на конференции и посещения центра обработки данных.
Выбор аппаратного RAID-решения обойдется вам дороже (по сравнению с программным RAID-решением), но зато даст такие преимущества, как возможность аварийного электропитания от батарей и более легкое техоб- служивание.
НАИЛУЧШИЙ ИНСТРУМЕНТ
Не существует двух одинаковых инструментов. Всем им присущи разная цен- ность и накладные расходы. Если бы это было не так, нам бы не пришлось писать эту главу. Вы бы просто могли выбрать инструмент в соответствии с предъявляемыми ему требованиями. Даже среди инструментов, которые совершенно справедливо рассматриваются в качестве ключевых, например инструменты по управлению конфигурацией или инструменты контроля ис- ходного кода, одни лучше подходят для конкретной среды, а другие хуже.
Применяемый набор инструментов может изменяться в зависимости от ваше- го опыта, знаний и процессов. Это означает, что команды могут использовать один и тот же инструмент, но получать при этом совершенно разные резуль- таты. Инструменты должны соответствовать контексту окружающей среды. Не существует самого лучшего в мире инструмента вне контекста, а сам контекст постоянно изменяется.
234
Часть IV. Инструменты
Выбор нужных инструментов для решения
реальных проблем
Если инструмент должен широко адаптироваться и применяться для реализа- ции успешных изменений, он должен быть приспособлен для решения реальных проблем. Поскольку в процесс принятия решений, относящихся к данному ин- струменту, вовлечены люди, нужно уметь обнаруживать, понимать и решать их разочарования и проблемы.
Понимание реальных базовых проблем, которые могут быть решены с помощью инструментов, позволит нам в целом выбрать правильные решения, а также пол- ностью осознать сложности, возникающие в работе. Благодаря такому пониманию мы можем минимизировать эти сложности и любой связанный с ними риск, что, в свою очередь, поможет сократить накладные расходы и сосредоточиться на нуж- ных областях.
В некоторых организациях сотрудники, использующие инструменты, не допу- скаются к процессу выполнения закупок. Это приводит к тому, что проблемы, имеющие отношению к процессу или культуре, выглядят подобно инструмен- тальным или техническим проблемам.
Развитие нового продукта или организации либо поддержка существующих продуктов и организаций приводят к появлению различных проблем. В любом случае решения не должны приниматься исключительно одним человеком на основе чисто субъективных ощущений. Зачастую инструмент выбирается только потому, что кто-то хочет попробовать поработать с ним. Вряд ли это желание является достаточным основанием для выбора инструмента.
В то время как инструменты могут представлять интерес сами по себе, а удачно внедренная автоматизация позволит освободить время и энергию сотрудни- ков для работы над решением более сложных проблем, при выборе инстру- ментов нужны более серьезные обоснования, чем интересность или новизна.
Область охвата проектов с открытым кодом
Сообщества пользователей проектов с открытым исходным кодом обеспечивают возможность попрактиковаться в сотрудничестве с другими людьми. Благодаря таким сообществам сотрудники начинают ценить вклад со стороны других людей, а также учатся создавать вклад, который был бы полезен для иных пользователей.
Например, проще выполнить несколько небольших дискретных подтверждений, связанных с одним планируемым изменением, чем управлять и принимать одно большое подтверждение, которое затрагивает много различных фрагментов кода.
Должны ли компании отказаться от использования инструментов с открытым исходным кодом из-за боязни утратить конкурентное преимущество? Скорее нет, чем да. Возможно, ваша компания зарабатывает деньги на продаже инструментов,
Глава 12. Инструменты: акселераторы культуры
235
которые являются составной частью бизнес-модели. Но в этом случае можно продавать программное обеспечение либо, как делают многие современные ком- пании, зарабатывать деньги на поддержке или обслуживании этого программного обеспечения.
Содействие проектам с открытым исходным кодом — это отличный способ де- монстрации намерений компании. Благодаря проектам с открытым исходным кодом, поддерживаемым в компании, команды могут вносить взаимный вклад в их разработку и поддержку. При этом им не придется «изобретать колесо», а также убеждать отдельных сотрудников и менеджеров в преимуществах сотрудничества в разработке проектов с открытым исходным кодом. Содействие продвижению проектов с открытым исходным кодом и использование подобных проектов часто осуществляется одновременно. Команды, участвующие в сообществе разработ- чиков программ с открытым исходным кодом, скорее всего, будут искать готовые проекты, а не создавать их заново.
Многие компании обращают внимание на хорошо известных игроков в пространст- ве devops, таких как Netflix и Etsy, и на их вклад в пространство программ с откры- тым кодом. В результате они начинают создавать свои собственные инструменты, поскольку не хотят «поступать как все». Несмотря на все преимущества программ с открытым исходным кодом, не стоит слишком увлекаться ими. Соблюдайте разум- ный баланс между использованием программ с открытым исходным кодом от неза- висимых поставщиков и инструментов, разработанных внутри организации.
Описанное выше поведение может объясняться разными причинами, и наиболее распространенная среди них — конкуренция. Многие компании просто не хотят признавать решения, разработанные конкурентами, не говоря уже об использо- вании этих решений. Свою роль играет страх перед неизвестным программным обеспечением, созданным незнакомыми разработчиками. Многие просто не до- веряют коду, написанному другими разработчиками, полагая, что они могли бы написать лучший код. Некоторым людям просто нравится программировать либо разбираться в новых языках программирования.
Свою роль могут играть и вполне обоснованные опасения по поводу использо- вания решений от сторонних поставщиков. Если какой-либо компонент встраи- вается в существующий программный проект, придется обновить либо изменить лицензию проекта, чтобы она соответствовала лицензии нового внешнего ком- понента. Также существует вероятность лишиться поддержки производителя внешнего программного компонента. Соответственно, вы лишитесь возможности получать новые версии программы и рано или поздно будете вынуждены перейти на другую программу.
В силу ряда причин компании не желают быть привязанными к одному конкрет- ному поставщику. К тому же следует принимать во внимание негатив, вызванный синдромом неприятия чужой разработки (Not Invented Here). Например, если в вашей компании отсутствует команда экспертов в области компьютерной безо- пасности, создаваемое вами криптографическое программное обеспечение будет
236
Часть IV. Инструменты содержать ошибки, а следовательно, уязвимости в системе безопасности. Если компания не специализируется в области сетевого ПО, вряд ли для нее целесо- образно разрабатывать собственный DNS-сервер. Вряд ли специалисты из этой компании смогут создать что-то лучшее, чем сервер BIND. К тому же разработ- чикам не стоит тратить время на разработку, поддержку и устранение проблем незнакомого программного обеспечения.
Применение инструментов может способствовать усилению поведения, ока- зывающего влияние на культуру. Поэтому при исследовании связи между набором поведений и культур крайне важно исследовать влияние выбора инструментов. Использование программ с открытым кодом может не только открыть путь к решениям, которые являются новыми с точки зрения доступных инструментов и технологий, но и окажет заметное влияние на культуру сотруд- ничества, общего доступа и открытости.
Благодаря огромному количеству проектов с открытым кодом и соответствующих сообществ разработчики могут получить бесценный опыт и освоить множество паттернов разработки, подходящих для текущей среды.
Стандартизация инструментов
Эффективная работа невозможна без выработки взаимного понимания и ведения переговоров, позволяющих смягчить возможное недопонимание, которое возни- кает в случае, если команды пытаются одновременно достичь нескольких целей.
Инструменты могут использоваться для:
улучшения общения;
установки границ;
устранения недопонимания в рамках devops-пакта.
Организации нуждаются в стандартизации инструментов, чтобы достичь балан- са между проблемами и затратами на поддержку инструментов, выполняющих одни и те же функции. Благодаря стандартизации достигается гибкость на уровне команд. Благодаря возможности выбора собственных инструментов расширяют- ся возможности отдельных сотрудников по внедрению гибкого и ответственного подхода к работе.
Последовательные процессы
анализа инструментов
Благодаря стандартизации инструментов «прокладываются мостики» меж- ду старыми и новыми технологиями по мере изменения компании. Благодаря
Глава 12. Инструменты: акселераторы культуры
237
использованию последовательных процессов оценки, выбора и отказа от инстру- ментов организации будут:
выбирать инструменты, соответствующие потребностям большинства людей;
обеспечивать наличие необходимых средств, как прежних, так и новых;
гарантировать подготовку сотрудников, необходимую для эффективного использования нового оборудования или программ.
Если же последовательные процессы, необходимые для построения «мостов» между старыми и новыми технологиями, отсутствуют, сотрудники будут про- тивиться внедрению новых инструментов и технологий. Подобные процессы минимизируют риск, связанный как с отсутствием удовлетворения прежних и новых потребностей, так и с наличием людей, противящихся изменениям в ра- бочей среде.
Благодаря использованию последовательных процессов вы сможете избежать разного рода логистических кошмаров, которые могут стать суровой реально- стью в случае отсутствия соответствующих процессов или стандартизации.
Например, если в каждой команде используется собственная система отслежи- вания ошибок, уменьшается степень прозрачности на уровне всей организации, повышается вероятность дублирования усилий и увеличивается количество времени, которое придется тратить на ориентирование и взаимодействие между разными системами.
Исключения из стандартизации
Как и любому другому процессу, стандартизации присущи свои исключения. Если команда нуждается в некоторой изоляции или ей присущи определенные уникаль- ные требования, вряд ли стоит заставлять эту команду использовать стандартные инструменты.
В качестве одного из примеров можно рассмотреть совместимость со стандар- том безопасности PCI, которая требует очень четкого разделения обязанностей.
Команда, ответственная за работу с PCI, работает на отдельных компьютерах и в отдельной сети, изолированной от корпоративной сети. В этом случае сегреги- рованная среда позволяет использовать разные инструменты, не оказывая отрица- тельного влияния на организацию в целом. В каждом конкретном случае решения должны приниматься с учетом индивидуальных особенностей.
Несмотря на наличие общих черт, каждая команда и организация обладает уни- кальными потребностями и опытом. В практиках, относящихся к этой главе, будут рассмотрены подходы двух команд к выбору и внедрению инструментов.
Несмотря на наличие общих принципов и подходов, подход к выбору каждого инструмента индивидуален и основан на текущей среде.
238
Часть IV. Инструменты
Бесполезность инструментов
Существуют различные мнения по поводу ценности и полезности инструментов.
Точка зрения «инструменты ничего не значат» появилась в ответ на попытки не- которых поставщиков навесить ярлык «devops» буквально на все продукты неза- висимо от того, соответствует это действительности или нет.
Выражение «инструменты ничего не значат» имеет два значения:
использование инструментов не является достаточным основанием для существования devops-культуры;
инструменты не способны исправить дефектные культуры, скорее они вы- являют и усугубляют условия среды.
В конечном счете любое «devops-решение», которое включает только инстру- менты, игнорируя при этом то, кто, как и почему использует эти инструменты в организации, не позволяет получить представление о самом движении devops и о критериях успешного внедрения devops. Не пытайтесь решать межличностные и культурные проблемы исключительно с помощью инструментов и технологий.
Причины неудач — в процессе, а не в инструментах
Компания потерпит неудачу, если не сможет понять, каким образом реализовать и использовать управление конфигурацией вместо красивых и уникальных сер- веров-«снежинок». Неспособность к своевременному реагированию на проблемы среды приводит к возникновению простоев, а следовательно, к потере прибыли.
И независимо от инструментов, выбранных для управления конфигурацией, —
Puppet, Chef, Ansible, Salt, CFEngine или же какого-либо другого инструмента, — при использовании должной методики вы просто обречены на успех.
Важны не различия между инструментами, а функциональные свойства, кото- рые помогают решить конкретные проблемы организации. И что немаловаж- но, успешное решение этих проблем зависит от культуры, сформированной в организации.
Применение закона Конвея для выбора инструмента
В соответствии с этим законом, названным в честь ученого и программиста Мел- вина Конвея, разрабатываемое программное обеспечение обычно отражает струк- туру и организацию команд-разработчиков. Поэтому для обеспечения совместной работы двух компонентов программного обеспечения, каждый из которых спроек- тирован и внедрен отдельной командой, необходимо взаимодействие между этими командами.