Глава 11. Обзор экосистемы инструментов

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

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

Разработка программного обеспечения

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

Локальная среда разработки

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

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

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

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

Контроль версий

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

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

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

• открытие и доступ к клонированию хранилищ;

• содействие развитию хранилищ;

• управление вкладами в собственные хранилища;

• определение процессов для содействия;

• обмен правами для фиксации изменений.

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

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

В следующем списке приводится дополнительная терминология, относящаяся к контролю версий.

Фиксация

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

Конфликты

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

Запрос на включение кода

Запрос на включение кода (pull request) – это механизм, который посылает разработчику сигнал о том, что его вклад готов к просмотру и слиянию с основной ветвью.

Избирательный подход

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

Управление артефактами

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

Хранилище артефактов должно быть:

• защищенным;

• доверенным;

• стабильным;

• доступным;

• версионированным.

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

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

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

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

РАННИЕ ПОЛИТИКИ

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

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

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

Управление зависимостями

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

Закрепление

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

Продвижение

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

Автоматизация

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

Установка сервера

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

Некоторые дистрибутивы Linux также поддерживают инструменты, предназначенные для соответствующей операционной системы. Например, для установки сервера в среде Red Hat Enterprise Linux или CentOS могут использоваться Cobbler и Kickstart. Персонал из эксплуатационного отдела может создавать файлы Kickstart, которые определяют разбиение жесткого диска, конфигурирование сети, устанавливаемые пакеты ПО и т. п.

УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ОБОРУДОВАНИЯ

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

Автоматизация инфраструктуры

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

При описании управления инфраструктурой используется следующая дополнительная терминология.

Конфигурационный сдвиг

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

Среднее время работы между сбоями (mean time between failures; MTBF)

Среднее время работы между сбоями.

Среднее время восстановления (mean time to repair; MTTR)

Период времени, необходимый для восстановления работоспособности системы.

Доступность

Широко используемая единица измерения, показывающая, как часто система или услуга оказывается доступной по сравнению с общим временем ее потенциальной полезности. Доступность = MTBF / (MTBF + MTTR).

Управление мощностями

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

Сервер-«снежинка»

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

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

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

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

Управление конфигурационным сдвигом

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

Исключение серверов-«снежинок»

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

Версионированные артефакты инфраструктурного кода

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

Минимизация сложности

Решения автоматизации инфраструктуры позволяют отдельным сотрудникам (независимо от выполняемой ими роли) управлять гетерогенной средой с минимальными затратами. Необходимое условие – указание версий конфигурации для типа или версии платформы.

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

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

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

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

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

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

Система выделения ресурсов

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

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

Автоматизация тестирования и сборки исполняемых файлов

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

Современные инструментальные средства автоматизации обычно специфицируют порядок сборки исполняемых файлов (необходимые шаги и порядок их выполнения). Также определяются требуемые зависимости (другое программное обеспечение, используемое для успешного создания исполняемых файлов). Некоторые инструменты лучше всего подходят для проектов, относящихся к конкретным языкам программирования, таких как Apache Maven и Ant. В то же время эти инструменты могут применяться совместно с другими языками программирования, которые чаще всего используются в проектах Java. Другие же инструменты, такие как Hudson или Jenkins, могут использоваться для большего диапазона проектов.

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

Автоматизация по требованию

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

Запланированная автоматизация

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

Условная автоматизация

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

ТЕСТЫ, МОНИТОРЫ И ДИАГНОСТИКА по Ивонн Лам

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

Во время выступления на конференции Sysadvent 2014 (http://sysadvent.blogspot.com/2014/12/day-5-how-to-talk-about-monitors-tests.html) Ивонн Лам определила ряд вопросов, на которые должна ответить команда, чтобы сформировать общий контекст на основе тестов, мониторов и диагностики.

• Где будут выполняться тесты?

• Когда будут выполняться тесты?

• Как часто они будут проводиться

• Кто будет использовать результат?

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

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

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

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

Дымовое тестирование

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

Регрессионное тестирование

Это тестирование позволяет проверить, не вызвали ли изменения в программном обеспечении новые ошибки или сбои.

Тестирование удобства использования

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

A/B-тестирование

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

Сине-зеленое развертывание

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

«Канареечный» процесс

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

Мониторинг

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

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

Метрики

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

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

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

Системы логирования

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

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

Оповещения

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

Микки Дикерсон, который выполняет функции администратора United States Digital Service, выступал с докладами на многих отраслевых конференциях. Он утверждал, что мониторинг сайтов, выполняемый его командой в течение первых месяцев автоматизации, сводился к просмотру новостных источников, таких как отчеты CNN. Использование открытых источников информации чревато появлением проблем, которых в какой-то степени поможет избежать лишь хорошо продуманная стратегия оповещений.

При рассмотрении системы оповещений нужно учитывать несколько факторов.

Влияние

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

Срочность

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

Заинтересованная сторона

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

Ресурсы

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

Стоимость

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

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

События

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

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

Многие системы оповещения и мониторинга используют встроенные методы автоматического реагирования на события. Например, система мониторинга Nagios включает «обработчики событий», которые могут быть сконфигурированы с учетом различных условий оповещений. Эти обработчики могут выполнять различные действия – от автоматического перезапуска службы до создания распоряжения технику на замену отказавшего жесткого диска. Автоматизированные обработчики событий могут существенно сократить объем работы эксплуатационного отдела (и объем сверхурочной работы), хотя использование таких обработчиков связано с определенными рисками. Важно убедиться в том, что условия сбоев четко определены, а принципы работы обработчика событий понимаются настолько хорошо, что могут быть автоматизированы. Также нужны определенные гарантии в том, что автоматизация в большей степени решает проблемы, чем создает.

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

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

Проектирование оповещений, или методы создания оповещений, которые передают информацию людям в наиболее понятной форме, является непростой проблемой. В компании Etsy был создан инструмент OpsWeekly (https://github.com/etsy/opsweekly), предназначенный для создания подобных оповещений и выполнения категоризации оповещений по типу и компоненту. Благодаря отслеживанию трендов оповещений и анализу данных оповещений можно резко улучшить эффективность оповещений и сделать счастливыми людей, призванных отвечать на них.

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

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

Эволюция экосистемы инструментов

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

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

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

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

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

Выводы

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

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

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

 

Глава 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» (КАКОВО БЫТЬ ГЛУХИМ ПРОГРАММИСТОМ)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Практики

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

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

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

Знакомство с DramaFever

Тим Гросс начинал свою карьеру в области архитектуры, позднее занялся разработкой программных инструментов и ИТ-проектами. Затем Тим стал первым «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. В этом случае мы будем регулярно масштабировать узлы в течение рабочего дня. Это позволит обоснованно прогнозировать возникающие требования и в случае необходимости выполнять масштабирование при небольших затратах.

К тому же затраты на поддержание платформы AWS намного меньше, чем затраты на поддержку CDN (большие затраты связаны с большим объемом видеоданных, передаваемых каждый месяц) и зарплаты инженеров. Небольшая оптимизация расходов в случае перехода к другому провайдеру нивелируется резким ростом трудозатрат со стороны инженерного персонала.

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

• Какие средства абсолютно необходимы, а какие – желательны?

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

• Каким образом затраты на внедрение необходимых вам средств соотносятся с затратами на внедрение доступных средств?

Непрерывное влияние новых технологий

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

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

• Как правило, Django применялось для выполнения медленного неатомического развертывания со сложными сбоями. Приложение Django являлось одним из важнейших приложений пути запроса, которое имело серьезные требования к доступности и времени ожидания. Из-за использования клона git замедлялось развертывание, к тому же в процессе развертывания периодически случались сбои.

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

• Раздельное тестирование качества и процессов развертывания производства без каких-либо возможностей аудита.

• Различные среды разработки и непрерывной интеграции.

Гросс также описал дополнительные цели, которые преследовала его команда:

• переход от монолитного приложения к меньшим по размерам микросервисам;

• изоляция разных версий приложения на одном хосте в средах разработки и контроля качества.

Как говорит Гросс:

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

Большой риск заключался в том, что в те времена Docker был весьма сырым проектом (в октябре 2013 года, версия 0.6). К тому же мы не развертывали в производственной среде проекты, не подготовленные к использованию в производстве. Мы знали, что в случае возникновения каких-либо проблем можем всегда вернуться к более зрелой базовой LXC-системе. Эту ситуацию мы изложили руководству команды разработчиков, чтобы получить «добро» на продолжение работы.

После выполнения испытаний в среде разработки/контроля качества мы развернули Docker для производства основного приложения Django. Только после завершения тестирования мы можем перейти к контейнеризации остальных приложений.

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

В среде CI часто возникали проблемы, связанные с дисками. Зачастую причина появления этих проблем заключалась в повышенной вибрации. Для устранения этой проблемы был заменен драйвер хранилища Docker (эта задача довольно сложная). Также возникали проблемы, связанные с масштабированием реестра Docker. Чтобы устранить технологические проблемы, связанные с реестром, выполнялось развертывание локального реестра хоста, при поддержке AWS S3 (вместо использования центрального сервера).

Третья проблемная область появилась после развертывания Docker в локальной среде разработки. По этому поводу Гросс сказал:

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

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

• Каковы известные риски новой технологии?

• С какими неизвестными моментами вы можете столкнуться?

• Какие проблемы невозможно решить в рамках существующей технологии?

Расширенное внедрение практик формирования близости

Безупречный постмортем (https://codeascraft.com/2012/05/22/blameless-postmortems/) с целью формирования культуры непрерывного улучшения.

– @0x74696d at @dramafever

Мне очень приятно, когда @0x74696d ссылается на @codeascraft в дискуссии, посвященной трактовке сбоев со стороны @dramafever. Спасибо за помощь в обучении, Etsy!

– Bridget Kromhout (@bridgetkromhout)

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

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

В DramaFever поощряется прозрачность. Как говорит Кромхаут, «прямо сейчас разработчики получают полный доступ к сервисам AWS в среде разработки. Мы также активизировали IAM-доступ в режиме чтения». Благодаря подобной прозрачности сотрудники могут учиться и наблюдать непосредственно из среды разработки, которая реплицирует производство и ответы на вопросы об использовании производства в реальном мире по мере их возникновения.

Поскольку DramaFever эксклюзивно использует технологию AWS, не требуется центр обработки данных. Также отсутствуют требования к сотрудникам по поводу явного присутствия в специфической среде. Команда DramaFever, насчитывающая примерно 120 человек, в основном находится в Филадельфии и в Нью-Йорке, а некоторые сотрудники трудятся в других местах. В процессе описания среды Кромхаут сказала следующее: «Наши сотрудники находятся поблизости, в Мэриленде, или очень далеко, в Сеуле, и все они должны без помех выполнять одну и ту же работу».

Чтобы еще больше облегчить работу удаленных сотрудников, в конференц-залах DramaFever установлены компактные компьютеры Chromebox. На основе такого компьютера реализуется бизнес-система организации видеоконференций. Используется операционная система Chrome OS, камера с высоким разрешением, внешние микрофоны и колонки. По умолчанию совещания проводятся в режиме виртуального присутствия, реализованного с помощью Google Hangouts, благодаря чему не требуется физическое присутствие в офисе.

Обратите внимание на то, каким образом инструменты и методы работы взаимодействуют между собой внутри вашей организации и команд.

• Каковы ценности, исповедуемые в вашей команде или организации?

• Помогают ли инструменты реализовать эти ценности на практике или только мешают этому процессу?

• Насколько прозрачно взаимодействуют между собой ценности и процессы?

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

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

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

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

Согласно объяснению, приведенному Кромхаут,

при выборе между своим собственным сервисом и SaaS [49] оцениваются соответствующие расходы и преимущества, включая затраты, связанные с выполнением дополнительных работ (как затраты времени персонала, так и финансовые).

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

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

Как отмечает Кромхаут:

Создание рабочей инфраструктуры, определенной кодом, очень важно, поскольку мы стремимся все заменять в оперативном режиме, не отключая сайт на проведение профилактических работ. Рассматриваемый код может обрабатываться с помощью файла JSON, определяющего конфигурацию сервисов AWS, или «поваренных книг» Chef, или же с помощью Python (посредством Boto и Fabric). Мы отправляем запросы на включение подобного кода, который будет просмотрен и протестирован нашими коллегами перед выполнением слияния и развертывания. Критерий успеха в данном случае – создание рабочего кода. Это позволило нам отказаться от GitHub и наладить рабочий поток в стиле Канбан.

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

• Кто несет ответственность за принятие решений по выбору инструмента?

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

• Что является главным при выборе инструмента с точки зрения разработчика и заказчика?

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

Знакомство с Etsy

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

Явная и неявная культура

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

• Мы представляем думающий, прозрачный и гуманный бизнес.

• Мы планируем и строим исходя из долгосрочной перспективы.

• Мы ценим профессионализм во всем, что мы делаем.

• Мы считаем, что все нужно делать с улыбкой.

• Мы никогда не отрываемся от реальности.

Эти ценности вдохновляют и объединяют сотрудников согласно данным отчета Etsy Progress Report за 2013 год. Хотя в Etsy отсутствует devops-команда, devops-менеджер и devops-инженеры, явно и четко объявленные ценности отражены в ключевых практиках и руководствах по наблюдению за поведением и созданию вклада в devops-сообщество. Заранее обдуманные практики Etsy включают проявление сострадания, экспериментирование, повторное выполнение действий и поощрение обучающих организаций.

Культура сострадания

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

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

ВАЖНОСТЬ БЛАГОДАРНОСТИ

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

Согласно данным исследований, благодарность обеспечивает ряд преимуществ, в том числе:

Улучшение состояния здоровья

Усиление иммунной системы и снижение кровяного давления.

Повышение устойчивости

Больший уровень сопротивляемости по отношению к невзгодам.

Повышенный уровень положительных эмоций

Более высокие уровни счастья, радости и довольства.

Уменьшение уровня негативных эмоций

Уменьшение остроты ощущения одиночества и изоляции.

Усиление стремления к сотрудничеству и взаимодействию

Более высокие уровни щедрости и сострадания.

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

• Какое поведение вы собираетесь поощрять среди сотрудников?

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

• Как могут использоваться инструменты для поощрения определенного поведения или ценности?

Публичное общение поощряется не только в инженерных отделах, но и во всей компании. Как можно чаще отправляйте членам команды поощрительные сообщения по электронной почте и мгновенные сообщения. Поощряйте членов команд за устранение ошибок, добавление новых функций, вклад в хранилище программ с открытым кодом, оказание помощи другим сотрудникам и даже за обновление документации. Как говорит Джон Коуи, Staff Operations Engineer:

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

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

Культура безупречности

Как уже упоминалось в главе 4, безупречная среда формируется там, где сотрудники делятся между собой историями и несут ответственность за повышение степени безопасности. Джон Оллспоу, занимающий пост технического директора Etsy, в мае 2012 года написал статью Blameless PostMortems and a Just Culture» (https://codeascraft.com/2012/05/22/blameless-postmortems/). В этой статье описывается трансформация обработки неточностей и ошибок с применением безупречного подхода.

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

В постмортеме, созданном с помощью применяемого в Etsy инструмента Morgue (https://github.com/etsy/morgue), отдельным сотрудникам предлагается дать подробный отчет, включающий следующие пункты:

• график действий и событий;

• наблюдаемые эффекты;

• ожидания;

• допущения;

• результаты и решения.

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

Дружелюбие по отношению к удаленным пользователям

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

Чтобы внедрить подобный вид культуры, используются несколько инструментов, в том числе IRC (обмен мгновенными сообщениями или организация чата), электронная почта (обмен более длинными текстовыми сообщениями) и Vidyo (организация видеоконференций и сотрудничества). В Etsy практикуется идея общения в «удаленной по умолчанию» форме, когда даже те люди, которые работают в локальном офисе, будут использовать инструменты, предназначенные для удаленного общения.

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

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

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

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

• Насколько гибкими являются ваши инструменты? В какой степени они могут быть настроены?

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

Роль инструментов в укреплении практик

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

При осуществлении поддержки удаленных сотрудников недоступны сеансы специального кодирования и неформальные беседы с глазу на глаз. В этом случае большая часть общения осуществляется в письменном формате. Люди обмениваются сообщениями электронной почты в случае принятия решений, внесения изменений, появления простоев, возникновения проблем либо при необходимости поделиться какими-либо инициативами. Чтобы уменьшить количество сообщений электронной почты, используются фильтры. Всю переписку целесообразно хранить в архиве с возможностью поиска. Ретранслируемый интернет-чат (Internet Relay Chat; IRC) критически важен для формирования культуры, дружественной к удаленным пользователям, которая взлелеяна в Etsy. Чат-боты обновляют каналы с помощью информации о развертываниях, предупреждениях и изменениях конфигурации. Чат-боты также поддерживают системное взаимодействие, например, для обмена тихими предостережениями Nagios, относящимися к предстоящему плановому техническому обслуживанию либо к обзору кода. Чат-боты могут применяться для продвижения культуры благодарности путем обмена «плюсиками» и одобрениями.

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

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

Документация воспринимается в качестве способа выполнения каких-либо операций в Etsy. Как правило, wiki-страницы, созданные с помощью программы Atlassian Confluence, являются точными и актуальными. Настоятельно рекомендуется обновлять страницы с документацией (особенно с информацией о текущих задачах). В то время как некоторые компании ленятся создавать документацию, мотивируя свое поведение фактом ее быстрого устаревания, компания Etsy является сторонником принципа «обновление wiki-страниц – лучшее вложение трудозатрат».

Покупка или самостоятельная разработка

Компания Etsy уклоняется от практики использования новейших технологий только на основании того, что они являются новыми и интересными. Большинство инструментов, применяемых в компании, хорошо известны и имеют большой стаж использования. Дополнительная информация, обосновывающая эту философию, приводится в посте блога бывшего инженера компании Etsy Дэна Маккинли Choose Boring Technology («Выбор скучной технологии»). Эта статья доступна на сайте http://mcfunley.com/choose-boring-technology. Идея, заложенная в основу этой статьи, заключается в том, что сосредоточение на реализации новых и непроверенных технологий крадет время и энергию, которые могут потребоваться на инновации продукта, что является конечной целью компании.

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

Общий подход к выбору инструментов предусматривает получение ответов на следующие вопросы.

• Можем ли мы сделать это с помощью инструмента, который мы знаем и которым владеем? Существуют ли веские причины отказаться от такого решения?

• Существует ли инструмент, который отвечает нашим потребностям?

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

• Имеются ли возможность, время и желание создать инструмент самостоятельно?

• Нужно ли решать возникшую проблему и достаточно ли только внутренних возможностей?

Компания Etsy вносит вклад в разработку множества инструментов, в том числе Nagios, Chef, Elasticsearch и Kibana. Если же инструменты перестают давать нужную отдачу, они подлежат замене. В Etsy контролируется сетевое оборудование и отслеживается поведение новых устройств. Одно время в Etsy использовался Cacti (www.cacti.net), но из-за сложности и необходимости ручной настройки этого инструмента был разработан и выпущен FITB (https://github.com/lozzd/FITB).

Пограничный протокол шлюза (Border Gateway Protocol; BGP) выполняет мониторинг, отслеживание сайта и синтетическое тестирование. Именно в этих областях Etsy выбирала внешние услуги или программы, исходя из природы проблемного пространства. Рассматривая BGP-мониторинг в качестве примера, можно сказать, что этот пример имел смысл только для Etsy, поскольку BGP-мониторинг включает мониторинг всех внешних потоков трафика. Эти потоки анализируются, чтобы понять их влияние и устранить проблемы, возникающие при маршрутизации в сетях. Лучше использовать время сетевых инженеров, чем воссоздавать сложную услугу мониторинга, которая применяется в других местах. В этом случае понятно, что лучше использовать существующий инструмент.

Рассмотрение автоматизации

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

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

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

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

• Каковы ваши самые большие «болевые точки»?

• Что можно, а что нельзя автоматизировать?

• Должны ли полностью автоматизироваться некоторые аспекты рабочего процесса?

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

Оценка успеха

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

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

Поскольку не существовало четких критериев выбора нужных инструментов, приходилось экспериментировать. При этом ставилась цель понять, что происходит с сайтом, приложениями и компонентами блокировки. Были выбраны Nagios, Cacti и Ganglia, поскольку руководители были знакомы с этими платформами. К тому же была достаточно высока результирующая скорость внедрения и низкие накладные расходы (эти платформы распространяются на бесплатной основе).

Со временем, благодаря частой итерации и эволюции, все подразделения Etsy были охвачены практикой «измерять все, что только можно». Помимо опережающего планирования объектов измерения любой пользователь мог легко получить нужные ему сведения в виде графика. Был разработан и выпущен StatsD, сетевой демон, выполняющийся на платформе Node.js. Этот демон может прослушивать статистику, отсылаемую через порты UDP и TCP, и агрегировать полученные данные с помощью подключаемых серверных служб, таких как Graphite. Поскольку каждые 10 секунд данные сбрасываются, обеспечивается создание коллекции данных практически в режиме реального времени.

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

• Если у вас возникают вопросы, задайте их кому-либо.

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

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

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

• Каким образом ваши инструменты дифференцируются между мониторингом и обработкой оповещений?

• Каким образом ваши инструменты и процессы удовлетворяют потребности в мониторинге разных команд?

• Насколько гибки и настраиваемы решения мониторинга и обработки оповещений?

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

Проблемы, связанные с мотивацией и процессом принятия решений

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

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

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

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

Использование инструментов в Sparkle Corp

«Я действительно считаю, что наши демо-дни являются довольно интересными и познавательными, – заявил Джордж. – Я заметил, что вы используете виртуальную машину на ноутбуке и управляете ею отдельно от кода. Пытались ли вы использовать инструмент Test Kitchen для создания проекта по управлению виртуальной машиной? Эксплуатационная команда использует этот инструмент при тестировании новых реализаций сервисов. Таким образом мы можем воссоздать то, что делает каждый сотрудник или команда».

«Нет, я раньше никогда не слышала о Test Kitchen. Я хотела бы познакомиться с этим инструментом поближе, особенно в свете того, что он позволит облегчить создание пользовательской виртуальной системы», – сказала Элис.

«Фактически мы начинаем с ChefDK. Этот набор для разработки кода от Chef. Он уже установлен на всех ноутбуках, находящихся у сотрудников компании, – заметил Джордж. – Похоже, что мы должны координировать свои действия с ИТ-командой и обязаны позаботиться об обновлении документации, посвященной описанию локальной среды разработки для компании. Эти обязанности прописаны в моем новом контракте инженера по эксплуатации. И я не понимал, почему другие команды не выполняли эти действия».

Джордж проиллюстрировал простоту настройки быстрой «поваренной книги» Chef. При этом использовался заранее созданный шаблон Test Kitchen, включающий зеркальное отображение настроек, сделанных Элис, Джорди и Джози при установке MongoDB.

«Теперь я могу передать это обратно, в нашу централизованную среду Git, а любой из вас может получить проект и работать с ним дальше», – сказал Джордж.

Элис протестировала сказанное путем клонирования проекта и использования команд kitchen, как это делал Джордж. После того как образ ОС был синхронизирован, она быстро сформировала тестовую среду на своем ноутбуке.

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

«А как насчет того, чтобы разделиться на две команды и в паре подключиться к нашему кластеру Jenkins? Это позволит нам протестировать процесс вытягивания программного проекта на каждую платформу с одновременным выполнением оценки», – сказал Джордж.

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

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

Выводы

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

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

• безупречная среда;

• экспериментирование и итерация;

• последовательное улучшение;

• обучающие организации.

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

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

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

Знайте, что оценка вашего прогресса критически важна для достижения успеха. Если вы находитесь в состоянии нулевого мониторинга, учтите, что это единственная область, которой стоит уделить время. Чтобы воспользоваться дополнительными преимуществами мониторинга, прочитайте книгу Джейсона Диксона (Jason Dixon) Monitoring with Graphite (O’Reilly). Эта книга, а также другие источники информации приведены в главе 20.

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

 

Глава 13. Инструменты: заблуждения и устранение неполадок

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

Заблуждения, связанные с инструментами

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

Мы используем технологию X, тогда как другие используют технологию Y; мы должны любой ценой перейти к использованию технологии Y

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

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

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

Наличие конкретного инструмента или технологии не означает, что вы не можете развернуть успешную инициативу devops. Использование каналов IRC вместо Slack или Hipchat, запуск и выполнение серверов на физическом сервере вместо «облака» либо использование монолита PHP вместо микросервисов Go не исключает использования идей devops. Суть движения devops заключается в культуре производства и в организации совместной работы, а не в применении самых современных инструментов. Качество общения не зависит от того, какую программу чата вы используете, – современную или двадцатилетней давности.

Использование технологии X эквивалентно внедрению devops

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

Например, автоматизация инфраструктуры позволяет сотрудникам вносить изменения более непосредственным и надежным способом, уменьшая риск и «трения», связанные с изменениями.

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

Простое добавление в среду Chef, Docker, Slack или любого другого инструмента, часто упоминаемого в связи с devops, вовсе не означает, что вы «сделали devops». На самом деле набор инструментов – это лишь одно из условий организации совместной работы. Не наличие или отсутствие инструмента приводит к формированию или разрушению инициативы devops. Инструменты могут лишь помогать или мешать формированию культуры, основанной на devops.

Мы должны убедиться в том, что не выбрали некорректный инструмент

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

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

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

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

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

Можно купить devops «в упаковке» или devops в качестве услуги

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

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

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

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

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

Поиск и устранение проблем, связанных с инструментами

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

Мы пытаемся найти лучшие практики для технологии X

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

• Идентифицируйте состояние проблемы в настоящее время.

• Определите нужные вещи и полезные штучки.

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

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

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

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

Мы не можем заставить людей согласиться на использование конкретного инструмента

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

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

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

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

Мы решили принять технологию X (или отказаться от нее), но люди не хотят ее использовать (или отказаться от нее)

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

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

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

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