Глава 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). Управление мощностями. Процесс, используемый для обеспечения соответствия между потенциалом инфраструктуры (а также другими ресурсами) и текущими, а также будущими потребностями бизнеса эффективным образом. Сервер-«снежинка[42]» Текущая желаемая конфигурация этого сервера достигается в результате выполнения множества ручных изменений. В процессе выполнения изменений часто используются инструменты командной строки, файлы конфигурации, примененные вручную заплаты и даже конфигурации и инсталляции графического интерфейса пользователя. Автоматизация инфраструктуры зачастую трактуется как управление конфигурацией специалистом из отдела техобслуживания. И это действительно так, поскольку многие аспекты управления конфигурацией могут быть автоматизированы. В частности, это касается идентификации программных пакетов, установленных на сервере, определения версий этих пакетов, которые должны быть использованы, проверки наличия или отсутствия различных системных файлов, определения служб, которые должны выполняться. «Трактовка кода инфраструктуры как всего остального программного обеспечения» означает, что код был разработан с помощью обычной локальной среды разработки и версионирован с применением системы контроля версий. Также использовалось версионирование в виде артефактов в хранилище артефактов, тестирование и верификация перед вводом в эксплуатацию. Автоматизация инфраструктуры по минимуму должна обеспечивать следующее. Управление конфигурационным сдвигом. Конфигурационный сдвиг может возникать из-за изменений, внесенных вручную, обновления программного обеспечения, ошибок или законов энтропии. В этом случае нужен способ, позволяющий избежать подобных негативных проявлений. Зачастую выделяется отдельный узел, для которого выполняется регулярная проверка фактической конфигурации, которая сравнивается с реальной конфигурацией. В случае обнаружения каких-либо несоответствий выполняется самокорректировка. Исключение серверов-«снежинок». При автоматизации инфраструктуры можно обойтись без создания серверов-«снежинок». Для этого требуется четкое и детерминированное определение изменений. Чтобы исключить серверы-«снежинки», можно включить управление для одной части системы до тех пор, пока тот же «рецепт» управления конфигурацией не будет применен для воссоздания сервера «с нуля» с применением желаемой конфигурации. Версионированные артефакты инфраструктурного кода. Хорошее решение автоматизации инфраструктуры предусматривает использование контроля версий и хранилища артефактов. В результате код, который определяет конфигурацию сервера, может версионироваться со всеми преимуществами, предоставляемыми версионированием. Например, обеспечивается возможность простого отката изменений обратно, к хорошо известной версии, либо использование перехватчиков, которые выполняют тестирование кода, задающего инфраструктуру, после выполнения транзакций. Также все члены команды могут в комфортных условиях вносить свой вклад в улучшение кода инфраструктуры. Минимизация сложности. Решения автоматизации инфраструктуры позволяют отдельным сотрудникам (независимо от выполняемой ими роли) управлять гетерогенной средой с минимальными затратами. Необходимое условие – указание версий конфигурации для типа или версии платформы. Даже в стартапе с минимальным количеством систем не следует накапливать технические «долги». Благодаря инвестициям в сотрудников, которые понимают разницу между сценариями оболочки и автоматизацией инфраструктуры сервера-«снежинки», вы получите быструю отдачу. Если доступные средства автоматизации инфраструктуры не удовлетворяют ваши текущие потребности, эффективнее расширить набор функциональных свойств либо повысить степень надежности существующего программного обеспечения. Автоматизация инфраструктуры приводит к появлению повторяющихся, последовательных, документированных, проверяемых и упругих процессов. В результате освобождается время, повышается эффективность персонала, обеспечивается большая степень гибкости и облегчается управление рисками. Благодаря автоматизации инфраструктуры также повышается степень уверенности в идентичности установки и развертывания компьютеров, уменьшаются затраты времени на устранение проблем, вызванных системными различиями. Существует контраст между автоматизацией инфраструктуры и ручным конфигурированием каждой группы серверов. Люди, выполняющие повторяющиеся задачи, могут допускать ошибки. В результате изменений в процессе конфигурирования, невозможности конфигурирования устаревших систем и пропущенного шага из контрольного списка системы могут быть сконфигурированы некорректно. Не стремитесь создавать дополнительные процессы и контрольные списки. Лучше выделите больше времени на преобразование контрольных списков, созданных вручную, в сценарии, исполняемые компьютером. Компьютеры выполняют повторяющиеся задачи намного лучше людей. Одно из многих ощутимых преимуществ, связанных с использованием инфраструктуры в качестве кода, заключается в том, что это один из первых инструментов, который могут исследовать компании в процессе выполнения культурной трансформации. Инструменты могут быть понятны только в контексте использования конкретной среды. На эффективность применяемого инструмента влияют специфическая культура и верования, вызванные этой окружающей средой. Выбор наилучшей автоматизации инфраструктуры зависит от ваших индивидуальных потребностей. Система выделения ресурсов. Ранее многим компаниям приходилось планировать, покупать и предоставлять оборудование, установленное в центрах обработки данных. Теперь же они имеют возможность инвестировать средства в облачную инфраструктуру. При использовании вычислений по требованию компании могут приобретать нужные им услуги, а также выполнять необходимое масштабирование вверх или вниз. Эта инфраструктура может быть закуплена и подготовлена намного быстрее, чем физическое оборудование, к тому же является более выгодной для организаций в экономическом плане. Система выделения ресурсов (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 факторов[43], участвующих в разработке приложения, это будет то же самое, что и ручная настройка конфигурации серверов. Если будут стандартизованы и автоматизированы рабочие требования, сотрудники получат свободу выбора языка и рабочего шаблона. Описанные выше тенденции позволяют концентрироваться на инструментах, которые подчеркивают превосходство «мы» над «я», формировать взаимопонимание между командами и поощрять затраты времени на получение ценных результатов. Выводы. В этой главе был выполнен обзор текущей экосистемы инструментов. В то время как эти инструменты являются важной частью devops-среды, важно подчеркнуть, что они усиливают межличностные и культурные аспекты этой среды, но никогда не смогут заменить их. Порядок использования инструментов, а также простота их использования влияют на принятие и распространение специфических аспектов культуры. Когда мы говорим о devops-инструментах, мы подразумеваем как сами инструменты, так и порядок их использования, а не только основные характеристики этих инструментов. Культура devops является одной из разновидностей сотрудничества между командами, организациями и отраслями. В процессе разработки решений важно представлять степень их влияния на команды и организации, а не только на отдельных сотрудников. Иногда это означает коррекцию ожиданий в сторону блага для организации, работу в целях поиска решений, пригодных для всех, кто не является «рок-звездами» организации, кто имеет решающий голос и может оказать положительное влияние на организацию в целом. Инструменты devops подчеркивают преимущество «мы» над «я», позволяя группам и организациям формировать взаимопонимание, необходимое для выполнения работы. Выбор инструментов, по сути, является выбором общего языка. Приносит этот язык пользу организации в целом или подгруппам, входящим в состав определенных команд? Порой из-за отсутствия хорошо сбалансированного инструмента выбор должен быть сделан в пользу команды, имеющей большую когнитивную ценность. Будьте осведомлены о ценности и чуткости к воздействиям со стороны вовлеченных команд.