Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf

222
Часть IV. Инструменты
Автоматизация инфраструктуры приводит к появлению повторяющихся, последо- вательных, документированных, проверяемых и упругих процессов. В результате освобождается время, повышается эффективность персонала, обеспечивается большая степень гибкости и облегчается управление рисками. Благодаря автома- тизации инфраструктуры также повышается степень уверенности в идентичности установки и развертывания компьютеров, уменьшаются затраты времени на устра- нение проблем, вызванных системными различиями.
Существует контраст между автоматизацией инфраструктуры и ручным кон- фигурированием каждой группы серверов. Люди, выполняющие повторяю- щиеся задачи, могут допускать ошибки. В результате изменений в процессе конфигурирования, невозможности конфигурирования устаревших систем и пропущенного шага из контрольного списка системы могут быть сконфигу- рированы некорректно.
Не стремитесь создавать дополнительные процессы и контрольные списки.
Лучше выделите больше времени на преобразование контрольных списков, созданных вручную, в сценарии, исполняемые компьютером. Компьютеры выполняют повторяющиеся задачи намного лучше людей.
Одно из многих ощутимых преимуществ, связанных с использованием инфраструк- туры в качестве кода, заключается в том, что это один из первых инструментов, который могут исследовать компании в процессе выполнения культурной трансфор- мации. Инструменты могут быть понятны только в контексте использования кон- кретной среды. На эффективность применяемого инструмента влияют специфиче- ская культура и верования, вызванные этой окружающей средой. Выбор наилучшей автоматизации инфраструктуры зависит от ваших индивидуальных потребностей.
Система выделения ресурсов
Ранее многим компаниям приходилось планировать, покупать и предоставлять оборудование, установленное в центрах обработки данных. Теперь же они имеют возможность инвестировать средства в облачную инфраструктуру. При исполь- зовании вычислений по требованию компании могут приобретать нужные им услуги, а также выполнять необходимое масштабирование вверх или вниз. Эта инфраструктура может быть закуплена и подготовлена намного быстрее, чем физическое оборудование, к тому же является более выгодной для организаций в экономическом плане.
Система выделения ресурсов (system provisioning) расширяет автоматизацию инфраструктуры, позволяя компаниям определять собственную инфраструктуру.
При этом используются не отдельные узлы, а кластеры зависимых систем. Это позволяет сотрудникам задавать отдельную группу серверов, которая будет пре- доставляться один раз, а затем использовать эту спецификацию автоматически произвольное количество раз.

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

224
Часть IV. Инструменты
ТЕСТЫ, МОНИТОРЫ И ДИАГНОСТИКА ПО ИВОНН ЛАМ
Зачастую термины тесты, мониторы и диагностика не разграничиваются, что приводит к лишним разговором внутри команды и между командами. Чтобы работать вместе, команды должны выработать общий словарь, предназначенный для кодирования информации. При этом стимулируется обмен знаниями без ограничений для каждого отдельного члена команды. Также не требуется, чтобы каждый член команды был посвящен во все детали.
Во время выступления на конференции Sysadvent 2014 (http://sysadvent.blogspot.
com/2014/12/day-5-how-to-talk-about-monitors-tests.html) Ивонн Лам определи- ла ряд вопросов, на которые должна ответить команда, чтобы сформировать общий контекст на основе тестов, мониторов и диагностики.
• Где будут выполняться тесты?
• Когда будут выполняться тесты?
• Как часто они будут проводиться
• Кто будет использовать результат?
• Какие действия будут выполняться с результатом?
Затем Лам перечислила ряд дефиниций, которые могут применяться для выяс- нения различий между системами. Тесты, выполняемые по отношению к непро- изводственным системам, предназначены для определения степени готовности системы или программного обеспечения. Как правило, тесты выполняются в том случае, когда что-либо изменяется. Мониторы выполняются в соответст- вии с графиком в системах подготовки к производству и в производственных системах. Обычно монитор запускается часто или вызывается на выполнение по событию. Диагностика выполняется в производственных системах по требо- ванию и в связи с событием.
Все три вышеперечисленных инструмента используются для наиболее эф- фективного отслеживания поведения разных систем. Эти инструменты также позволяют уточнить области ответственности разных групп или отдельных сотрудников. Благодаря подобному уточнению облегчается поддержка общего понимания и ответственности.
В следующем списке перечислена дополнительная терминология, имеющая отно- шение к тестированию.
Дымовое тестирование
Это название позаимствовано из простейшей методики проверки оборудо- вания. Суть этой методики заключалась в подаче электропитания на устрой- ство с дальнейшим наблюдением за этим устройством. Если появлялся дым, сопровождаемый запахом гари, это свидетельствовало о наличии серьезных проблем. В производстве программного обеспечения дымовой тест — это очень простой и быстрый тест, позволяющий выяснить, работает ли про- грамма вообще и дает ли она ожидаемые результаты.

Глава 11. Обзор экосистемы инструментов
225
Регрессионное тестирование
Это тестирование позволяет проверить, не вызвали ли изменения в про- граммном обеспечении новые ошибки или сбои.
Тестирование удобства использования
В результате выполнения этой разновидности тестирования осуществляется проверка программного продукта на пользователях, позволяющая оценить способность этого продукта к выполнению требуемых функций.
A/B-тестирование
Под этим названием скрывается экспериментальный подход, заключаю- щийся в выполнении сравнения двух разных версий веб-страницы или приложения, чтобы определить, какая из этих версий лучше работает.
Сине-зеленое развертывание
Процесс выпуска версий программных продуктов, предусматривающий поддержку двух идентичных производственных сред. Одна среда рассма- тривается как «живая» и предназначена для обслуживания всего трафика.
Заключительная стадия тестирования нового продукта осуществляется во второй среде. Сразу же после прохождения тестов выполняется пере- направление трафика во вторую среду. Благодаря подобной организации производственной среды уменьшается степень риска при разработке. Если при создании нового выпуска возникли проблемы, можно тут же выполнить откат к предыдущей производственной среде.
«Канареечный» процесс
В прошлом шахтеры использовали канареек для раннего обнаружения ядовитых газов. Как только у канареек начинали появляться симптомы от- равления, это означало, что концентрация ядовитых газов в воздухе шахты достигла опасного предела. В условиях разработки программного обеспе- чения «канареечный» процесс заключается в выполнении нового кода на небольшом поднаборе производственных систем. Это позволяет сравнить производительность нового и старого кода.
Мониторинг
Мониторинг — это большая тема, которую можно разбить на подтемы, — чаще всего происходящие события и аналитика. При выполнении мониторинга применяют- ся методы сбора информации, такие как метрики и логи. Процесс мониторинга включает сбор основных показателей системного уровня. Собираются сведения о времени работы или простоя сервера, объеме используемой памяти, использо- вании времени центрального процессора и величине свободного места на дисках.
Также осуществляется мониторинг приложений на более высоком уровне, который

226
Часть IV. Инструменты варьируется от количества пользовательских запросов, обрабатываемых сервером, числа элементов в очереди системы массового обслуживания, времени загрузки веб-страницы до накопления в базе данных наиболее длительных запросов. Когда-то мониторинг являлся зоной ответственности системных и сетевых администраторов.
По мере роста сложности программного обеспечения и все более тесного сотруд- ничества между командами люди начинают понимать, что благодаря мониторингу можно своевременно выявлять состояние программного продукта.
В общем случае мониторинг — это процесс отслеживания текущего состояния си- стем и окружающей среды. Обычно цель этой проверки заключается в выяснении соответствия некоторым заранее определенным условиям, которые описывают же- лаемое состояние. Зачастую мониторинг, оповещение и тестирование неразрывно связаны между собой. Это может привести к путанице относительно того, что мы собираемся построить или достичь. Как упоминалось ранее, мониторинг обычно выполняется в соответствии с заранее разработанным графиком, а тесты выпол- няются в ответ на изменения. Оповещения — это автоматизированные сообщения, которые уведомляют человека о результатах выполнения теста или события.
Метрики
Метрики — это совокупность количественных и качественных результатов измере- ний. Обычно они сравниваются с неким эталоном или установленным стандартом.
Цель подобного сравнения заключается в выполнении аналитических исследо- ваний или в пополнении архивов. Зачастую метрики накапливаются в функцио- нальных организациях, что может повлиять на выбор корректного направления разработки продуктов.
Метрики являются ключевыми компонентами мониторинга. Могут собираться и накапливаться данные, относящиеся ко всем компонентам наиболее сложных интернет-приложений. Разные команды могут располагать различными метрика- ми, которые они могут отслеживать и использовать в работе. Часто используемые инструменты StatsD и Graphite обеспечивают отслеживание, хранение и просмотр метрик.
Существует управляемая сообществом инициатива по определению набора системных и прикладных метрик. Эти метрики группируются по протоколам, службам и приложениям в хранилище каталога метрик GitHub, поддержива- емом Джейсоном Диксоном, организатором конференций по мониторингу
Monitorama. По сути, это хранилище хороших практик, призванных служить в качестве справочного пособия для людей, желающих создавать или расши- рять свои собственные хранилища метрик.
Системы логирования
Суть процесса логирования заключается в генерировании, фильтрации, записи и анализе событий, происходящих в системе, как из-за самой операционной сис- темы, так и вследствие появления программных сообщений. При отслеживании

Глава 11. Обзор экосистемы инструментов
227
источника проблем, связанных с программным обеспечением, в первую очередь просматриваются логи для выявления соответствующих сообщений об ошибках.
Логи могут быть просто кладезем полезной информации. И поскольку стоимость хранения информации постоянно снижается, можно легко и просто сохранить любой лог для использования в дальнейшем. Логи могут порождаться разрабаты- ваемыми приложениями, инструментами от независимых поставщиков либо даже самой операционной системой. И поскольку не существует единого программного стандарта систем логирования, категоризация и классификация событий, заноси- мых в лог, может вызывать затруднения.
Всего лишь одна-единственная система может генерировать сотни или даже тыся- чи строк логов в день. В современных средах, когда десятки приложений выполня- ются на сотнях или даже тысячах серверов, объем данных логов переходит всякие границы. Поиск нужных сведений в таком огромном массиве данных может быть весьма затруднительным. Поэтому много сил и средств было потрачено на разра- ботку приложений, предназначенных для работы с хранилищами и поиска нужных сведений в логах. Сложности, связанные с решениями по логированию, выходят за рамки этой главы, но все же не следует их недооценивать.
Оповещения
Мониторинг и оповещения важны не только с точки зрения обеспечения произ- водительности программного обеспечения, но и с точки зрения профилактики.
В частности, вы сможете своевременно узнать о потенциальных проблемах, пока они не превратились в реальные проблемы для ваших заказчиков. Например, по- сле запуска в октябре 2013 года сайта US HealthCare.gov отсутствовали средства мониторинга и оповещения, которые позволяли бы определить работоспособность сайта.
Микки Дикерсон, который выполняет функции администратора United States
Digital Service, выступал с докладами на многих отраслевых конференциях. Он утверждал, что мониторинг сайтов, выполняемый его командой в течение первых месяцев автоматизации, сводился к просмотру новостных источников, таких как отчеты CNN. Использование открытых источников информации чревато появ- лением проблем, которых в какой-то степени поможет избежать лишь хорошо продуманная стратегия оповещений.
При рассмотрении системы оповещений нужно учитывать несколько факторов.
Влияние
Далеко не все системы оказывают одинаковое влияние на другие системы или людей. Те из них, которые получили широкое распространение и воз- действуют на многие системы или большие группы пользователей, оказыва- ют намного большее влияние, чем те, которые воздействуют на небольшую группу других систем или людей. Некоторые инциденты вообще не задева- ют интересы клиентов либо воздействуют на системы, которые обладают