Книга: Философия DevOps. Искусство управления IT

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

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

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

Под установкой сервера понимается автоматизация конфигурирования и настройки отдельных серверов. Производители оборудования, такие как 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-тестирование

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

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

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

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

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

Оглавление книги