Философия DevOps. Искусство управления IT Дэвис Дженнифер

Глава 12. Инструменты: акселераторы культуры

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

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

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

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

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

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

• Подъемная тележка сервера позволяет снизить травматизм и ускорить работы по техобслуживанию в центрах обработки данных.

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

• Выбор аппаратного RAID-решения обойдется вам дороже (по сравнению с программным RAID-решением), но зато даст такие преимущества, как возможность аварийного электропитания от батарей и более легкое техобслуживание.

НАИЛУЧШИЙ ИНСТРУМЕНТ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОЦЕНКА СТЕПЕНИ УЧАСТИЯ СОТРУДНИКОВ В ПРИНЯТИИ ВАЖНЫХ РЕШЕНИЙ

По мере роста компании критически важно понимать и оценивать степень участия отдельных сотрудников.

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

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

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

ХОЛЛИ КЭЙ, «BEING A DEAF DEVELOPER» (КАКОВО БЫТЬ ГЛУХИМ ПРОГРАММИСТОМ)[45]

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

• согласные, особенно шипящие и глухие (все согласные, произносимые с высокой частотой, а также глухие и шипящие согласные, при произнесении которые не используются голосовые связки);

• начало (и конец) предложений.

У многих сложился стереотипный образ программиста как нелюдимого типа, сторонящегося сотрудников компании. На самом деле этот образ далек от реальности. Программисты, объединенные в группу, довольно сильно социализированы. Мы ведем блоги, выступаем на конференциях, пишем учебники, исполняем роль наставников. Подобная атмосфера присутствует вот уже несколько десятков лет в Bell Labs, Массачусетском технологическом университете и во многих других научно-исследовательских организациях. Я обожаю социальный мир кода, мне нравится возможность окружить себя компетентными энтузиастами, которые способствуют моему собственному росту. Единственное, что мне не нравится, – парное программирование.

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

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

Конечно, было бы здорово поработать в паре с Роуэн Мэннинг (Rowan Manning) над проектом Pa11y. В рамках этого проекта разрабатывается автоматизированный инструмент тестирования доступности, предназначенный для компании Nature. Благодаря использованию инструмента Screenhero для создания удаленных парных сеансов мы могли бы одновременно смотреть на экран и общаться в текстовом режиме. При этом отсутствует риск утери информации и каких-либо конфузов. Это первый удачный, как по мне, пример парного сеанса. Довольно трудно описать словами преимущества, обеспечиваемые этим сеансом. Давайте оценим масштабы потери информации, имеющие место в процессе беседы со слабослышащим человеком. Предположим, что во всех книгах, доступных в вашем городе, около 60 % слов закрашены маркером. Затем представьте себе, что вы отправились в соседний город, в котором книги не подвергаются подобной цензуре. Естественно, что вам очень понравится возможность свободного чтения книг без необходимости угадывать смысл. Теперь вы понимаете, насколько комфортно будет чувствовать себя слабослышащий человек в случае правильной организации парного сеанса.

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

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

Учитывая вышесказанное, отметим, что аргументы в пользу выбора инструмента, полностью удовлетворяющего всем требованиям, лишены смысла. Поэтому в этой главе вы не найдете утверждений типа «Этот X является единственным подходящим инструментом Y для devops», поскольку это утверждение в корне неправильное. Это все равно что объявить редактор ed[46] истинным победителем в войне редакторов. В связи с тем, что достижение универсального консенсуса по поводу «лучшего» инструмента невозможно, выбор лучшего решения определяется спецификой решаемых проблем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Что восхищает/расстраивает вас?

• Что способствует пополнению/истощению вашей энергии и мотивации?

• Как вы оцениваете выполняемую работу?

• Какова степень вашего влияния?

• Что мы должны прекратить делать?

• Что мы должны начать делать?

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

Улучшения: планирование и оценка изменений

Внедрение изменений требует времени. Независимо от того, идет речь о программах или о людях, для сложных проблем не существует быстрых универсальных решений. Согласно принципу целей «SMART»[47], цели должны быть конкретными, измеримыми, достижимыми и ограниченными временными рамками. Изменение SMART критически важно как для организации в целом, так и для поддержания культуры на рабочем месте.

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

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

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

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

Первая практика, рассматриваемая в этой главе, – платформа потокового видео DramaFever. На этой платформе реализован документальный сайт SundanceNow Doc Club и сайт ужасов Shudder. Компания DramaFever была основана в 2009 году, а уже к середине 2015 года она насчитывала около 120 сотрудников. Платформы DramaFever поддерживают международный контент из 15 стран, насчитывающий около 15 000 эпизодов, который предлагается 70 провайдерами контента. Аудитория контента насчитывает 20 миллионов зрителей[48]. Чтобы погрузиться в атмосферу оценки и применения инструментов (и технологий), мы поговорили с Тимом Гроссом и Бриджит Кромхаут. На момент интервью они работали инженерами по эксплуатации в DramaFever.

Вторая практика посвящена Etsy (см. главу 2). Эта глобальная торговая площадка предназначена для продажи винтажных и хендмейд-товаров. Она была основана в 2005 году Робом Калином, Джаредом Тарбеллом, Крисом Магуайром и Хаимом Шоппиком. Во втором квартале 2015 года в компании Etsy работали примерно 785 сотрудников. Помимо соавтора книги Кэтрин Дэниелс, которая поделилась своим опытом работы с Etsy, мы поговорили с инженером по работе с персоналом из компании Etsy Джоном Коуи. Благодаря этой беседе мы получили представление о том, каким образом в Etsy оценивают и используют инструменты и технологии.

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

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

В команде отсутствовало преднамеренное или формальное распределение обязанностей и ролей, был лишь постепенный процесс, который привел к созданию эксплуатационной команды. Хотя соответствующая должность в компании называлась «devops-инженер», на самом деле все ограничивается выполнением работ по эксплуатации. Выполняемые обязанности описываются следующей фразой: «управление и автоматизация всех аспектов […] инфраструктуры, включая развертывание сайтов, CDN и управление облачными услугами». К числу специфических обязанностей относятся поддержка высокодоступных AWS-систем и online-дежурства. В данном случае какой-либо специфический devops-проект отсутствовал.

Описание должностных обязанностей devops-инженера в компании DramaFever включает следующую фразу.

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

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

В июле 2014-го в состав devops-команды в DramaFever вошла Бриджит Кромхаут. При описании стека технологий DramaFever Кромхаут отметила, что весь он включен в состав веб-сервисов Amazon (Amazon Web Services; AWS) наравне с веб-приложением Django/Python и постоянно растущим числом микросервисов на Go. Основная сеть доставки контента Akamai (content delivery network; CDN) обеспечивает доставку необходимого контента и быстрое кэширование.

Код пути запроса – это код приложения, который объявляет путь для запроса конечного пользователя в базе кода, а также для всех связанных сервисов, для которых имеют место критические требования к доступности и времени ожидания (помимо требований со стороны других приложений). Этот путь запроса использует неизменную инфраструктуру, которая создается с помощью Chef и Packer. Сам код приложения выполняется в контейнерах Docker начиная с конца 2013 года.

По словам Кромхаут:

Наш код приложения существует в виде экземпляров без состояния, которые автоматически масштабируются в 10–20 раз (в виде нескольких экземпляров) в течение одной недели. Наши слои хранения данных находятся в Elasticache (Memcached, Redis), RDS (MySQL), DynamoDB и Redshift. Мы передаем логи в ELK и записываем их в Graphite с помощью CollectD и StatsD.

Сервисы, которые не указаны в пути запроса, включают асинхронные рабочие задания Celery, задания cron, агрегацию регистрации и серверы метрик, такие как Graphite или Logstash, либо внутренние приложения, такие как приложение отслеживания качества. Кромхаут продолжает:

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

Влияние существующей технологии

Благодаря доступности сервисов AWS (с 2006 года) произошла трансформация индустрии. Современные компании больше не нуждаются в привлечении менеджеров, владеющих навыками управления центрами обработки данных. Ранее приходилось брать на работу сотрудников, владеющих навыками управления средствами общего пользования. Изначально платформа DramaFever поддерживала веб-сервисы AWS. В настоящее время она продолжает использовать эти веб-сервисы для поддержки вычислительных ресурсов. Гросс заявил следующее:

Мы использовали Google App Engine (GAE) для создания и поддержки некоторых одноразовых проектов. По мере роста интенсивности использования GAE возникла необходимость перехода к среде AWS, в которой доступен более высокий уровень контроля.

В качестве примера подобного перехода можно привести наш микросервис обработки изображений, который называется ImageBoss. Этот сервис позволяет по запросу изменять размеры изображений, обрезать их. В результате вашим художникам не придется создавать слишком много вариантов каждого графического объекта. Первоначально этот микросервис был развернут на платформе GAE. При этом одновременно на каждом узле для Go было доступно лишь одно ядро. В результате были очень высоки эксплуатационные расходы. После перемещения этого сервиса на платформу AWS была получена оптимально настроенная среда приложения.

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

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

Страницы: «« « 4567891011 » »»