Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 417
Скачиваний: 25
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
ГЛАВА 11
Обзор экосистемы инструментов
Прежде чем приступать к обсуждению способов применения инструментов для улучшения и поддержания разных аспектов культуры, рассмотрим дополнитель- ные определения и термины. Эти дополнения расширяют терминологию, введен- ную в главе 4, для описания формирования дополнительного контента и дости- жения взаимопонимания между командами. И даже после этих дополнений мы получим далеко не исчерпывающий перечень технологий и терминов.
Люди могут использовать разные народные модели, приводящие к формирова- нию различного понимания одних и тех же терминов и концепций. Если же эти термины и концепции трактуются с точки зрения здравого смысла, это будет спо- собствовать более детальному обсуждению и лучшему пониманию сотрудниками организации.
Разработка программного обеспечения
Инструменты разработки программ призваны помочь в процессе программирова- ния, документирования, тестирования, а также исправления ошибок в приложе- ниях и службах. Благодаря тому, что эти инструменты не ограничены определен- ными ролями, они будут полезными для всех, кто имеет отношение к разработке и поддержке программ.
Локальная среда разработки
Наличие последовательной локальной среды разработки критически важно для быстрого привлечения сотрудников к процессу разработки программ. Сказанное вовсе не означает, что нужно «запереть» сотрудников в узкие рамки стандартного редактора, лишив их каких-либо дополнительных возможностей по настройке.
Скорее это означает, что в распоряжении пользователей появятся инструменты, которые позволят им эффективно выполнять работу.
Глава 11. Обзор экосистемы инструментов
215
Минимальные требования к локальной среде разработки могут существенно от- личаться в зависимости от индивидуальных предпочтений. Если нужно просто расширить сотрудничество, достаточно установить несколько дополнительных мониторов. Если же предполагается проводить длительные сеансы просмотра в комфортных условиях, придется установить мониторы высокого разрешения, клавиатуры, мыши и другие устройства ввода информации. Процесс классифи- кации текущего стандарта локальной среды разработки включает идентифи- кацию согласованной структуры, используемой как внутри команды, так и на межкомандном уровне. Благодаря такой классификации облегчается и ускоря- ется привлечение новых сотрудников к выполнению важных заданий в вашей организации.
Важно придерживаться баланса между стандартной организацией труда и ин- дивидуально настроенными рабочими компьютерами и привычками сотрудни- ков. Чрезмерная индивидуализация рабочих мест ведет к изоляции знаний либо к дополнительным расходам времени и сил на индивидуальную настройку спе- циализированных сред. Но в последние годы сотрудники начали больше ценить индивидуальный подход к работе. И если руководство не будет разрешать сотруд- никам выполнять индивидуальные настройки рабочего места, это приведет к утере конкурентного преимущества, связанного с наймом и удержанием сотрудников.
Идентифицируйте общую область для документирования локальной сре- ды разработки. Документы могут храниться в хранилище системы контроля версий, во внутреннем хранилище wiki или даже в Google Docs. Со временем и при наличии практики степень владения инструментами будет возрастать.
Поэтому исчерпывающая документация, в которой описаны все нюансы ра- боты с инструментами, попросту не нужна. Достаточно иметь руководство, содержащее начальные сведения по работе с инструментами.
Контроль версий
Чтобы расширить кооперацию и сотрудничество внутри команд и между коман- дами, нужно располагать возможностями по фиксации изменений, сравнению, слиянию и восстановлению прошлых версий объектов, находящихся в хранилище.
В результате сводится к минимуму риск отката к предыдущим версиям программ в производственной среде.
Буквально в каждой организации нужно реализовывать, использовать, изучать и адаптировать контроль версий. Благодаря этому средству команды могут раз- решать конфликты, возникающие в случаях, когда несколько людей одновремен- но работают над одним и тем же файлом или проектом. Также обеспечивается безопасный способ выполнения и отката изменений. Использование контроля версий на ранних стадиях жизненного цикла команды или продукта способствует выработке хороших привычек.
216
Часть IV. Инструменты
Выбирайте систему контроля версий, которая поощряла бы желаемый для вас тип сотрудничества. В следующем списке приведены предпосылки для развития сотрудничества:
открытие и доступ к клонированию хранилищ;
содействие развитию хранилищ;
управление вкладами в собственные хранилища;
определение процессов для содействия;
обмен правами для фиксации изменений.
Некоторые инструменты плохо подходят для совместной работы, но поскольку со временем к ним привыкают, начинают мириться с имеющимися недостатками.
В подобных случаях оцените последствия отказа от использования более под- ходящих инструментов. Например, то, как это повлияет на найм персонала или слияние различных областей. При внедрении адекватного процесса коллективная работа может выполняться даже при наличии неподходящих инструментов, хотя и со сложностями.
Используя такой показатель, как количество строк кода, невозможно точ- но оценить стоимость труда программиста. Некоторые разработчики могут превратить сотни строк непонятного кода в десятки простых для понима- ния абстракций, которые могут восприниматься прочими членами команды.
Другие разработчики сосредоточиваются на поиске ошибок, скрытых в коде.
Поэтому используйте сведения о количестве строк созданного кода в качестве справочной информации, позволяющей стимулировать нужное вам поведе- ние. Например, если у вас отсутствуют навыки качественного анализа кода, не думайте, что больше всегда означает лучше.
В следующем списке приводится дополнительная терминология, относящаяся к контролю версий.
Фиксация
Фиксация — это последовательность действий по включению изменений, внесенных в файлы под управлением контроля версий.
Конфликты
Конфликт имеет место в том случае, когда внесены два очень похожих изменения и система контроля версий не может определить, какое из этих изменений является корректным. В большинстве случаев система контроля версий обеспечивает способ просмотра и выбора желательных изменений для разрешения конфликтов.
Глава 11. Обзор экосистемы инструментов
217
Запрос на включение кода
Запрос на включение кода (pull request) — это механизм, который посыла- ет разработчику сигнал о том, что его вклад готов к просмотру и слиянию с основной ветвью.
Избирательный подход
Избирательный подход — это применение определенных подтверждений из одной отрасли в другой отрасли. Этот подход полезен при необходимости выбора определенных изменений запроса на включение кода.
Управление артефактами
Артефакт — это результат выполнения какого-либо шага в процессе разработки программного обеспечения. Артефакты хранятся в хранилище. Можно выбрать как простое, так и более сложное полнофункциональное хранилище. В последнем случае нужно оценить стоимость поддержки дополнительных услуг и проблем с обеспечением безопасности.
Хранилище артефактов должно быть:
защищенным;
доверенным;
стабильным;
доступным;
версионированным.
При наличии хранилища артефактов появляется возможность статической трак- товки зависимостей. Вы можете хранить версионированную общую библиотеку в качестве артефакта отдельно от системы контроля версий программного обеспе- чения. Это позволит всем командам использовать одну и ту же общую библиотеку.
Вам придется создавать двоичный файл всего лишь один раз (даже если вы можете построить его повторно). В результате один и тот же двоичный файл используется на протяжении циклов испытаний и продвижений между сборками, что сущест- венно упрощает работу.
В хранилище можно хранить артефакты в соответствии со способом их использо- вания. В некоторых системах можно одновременно хранить лишь единственную версию пакета. Это может привести к появлению проблем при описании истории пакетов. Чтобы не допустить появления подобных проблем, нужно увеличить фактор дублирования хранилища пакетов. Это позволит поддерживать отдельное хранилище пакетов для каждой среды в рабочем потоке.
На ранних стадиях эволюции организация может не соответствовать определен- ным требованиям безопасности. Но по мере роста и появления линий продуктов
218
Часть IV. Инструменты ситуация может измениться. Благодаря наличию выделенного локального храни- лища артефактов обеспечивается более плавный переход на пути к достижению соответствия вышеупомянутым требованиям.
В идеале ваша локальная среда разработки должна иметь тот же доступ к внутрен- нему хранилищу артефактов, что и другие механизмы построения и развертыва- ния, действующие в вашей среде. Поскольку одни и те же пакеты и зависимости используются в производственной среде и в локальной среде разработки, миними- зируется вероятность появления синдрома «это работает на моем ноутбуке». Если же доступ ограничен или заблокирован, могут появиться новые способы выпол- нения тех или иных действий, которые обходят безопасность и другие политики.
РАННИЕ ПОЛИТИКИ
Раннее развертывание процессов управления содействует развитию сотруд- ничества в контексте среды и ограничений. Например, определите, кто и какие артефакты может выдвигать. Также установите, каким образом проверяются, лицензируются и обеспечиваются артефакты. Все это позволит избежать появ- ления проблем, вызванных использованием устаревших артефактов.
Если в вашей среде отсутствует доступ к Интернету, вам придется сформиро- вать свою собственную вселенную. Эта вселенная включает общие хранилища программ, серверы специфичных языковых пакетов, управление зависимостями и другие компоненты. Также должно воспроизводиться множество доступных об- щих служб. Создание подобной вселенной обеспечивает ряд преимуществ, в том числе защиту организации от незадокументированных разрушающих изменений свыше и от внешних сбоев, вызывающих внутренние проблемы. Если же при фор- мировании зависимостей полагаться на Интернет, в конечном счете кто-то будет определять доступность и совместимость ваших сборок. Подобных ситуаций ста- раются не допускать многие организации.
В следующем списке приведена дополнительная терминология, относящаяся к управлению артефактами.
Управление зависимостями
Зависимости определяются характером и степенью взаимозависимости одного программного проекта от другого. Для выявления подобных за- висимостей используются разные механизмы. На уровне артефактов для программного обеспечения может оказаться полезным сохранение зави- симых артефактов.
Закрепление
Закрепление — это метод блокировки явной версии артефакта для окружа- ющей среды. При управлении зависимостями может оказаться полезным определение явной версии зависимого артефакта программы, работающей с вашим проектом.
Глава 11. Обзор экосистемы инструментов
219
Продвижение
Продвижение — это метод выбора конкретной версии программного обеспе- чения для перемещения в сторону доставки, как правило, ключ к успешному прохождению тестов.
Автоматизация
Благодаря использованию средств автоматизации уменьшаются затраты рабочей силы, энергии и материалов, используемых в целях обеспечения качества, точно- сти и корректности результатов.
Установка сервера
Под установкой сервера понимается автоматизация конфигурирования и настрой- ки отдельных серверов. Производители оборудования, такие как HP и Dell, предо- ставляют инструмент, который можно использовать при работе с оборудованием этих брендов.
Некоторые дистрибутивы Linux также поддерживают инструменты, предназна- ченные для соответствующей операционной системы. Например, для установ- ки сервера в среде Red Hat Enterprise Linux или CentOS могут использоваться
Cobbler и Kickstart. Персонал из эксплуатационного отдела может создавать фай- лы Kickstart, которые определяют разбиение жесткого диска, конфигурирование сети, устанавливаемые пакеты ПО и т. п.
УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ОБОРУДОВНИЯ
Каждая компания в той или иной форме должна иметь дело с управлением оборудованием или жизненным циклом. Благодаря появлению облачных и ин- фраструктурных либо платформенных служб эта задача немного упрощается.
Жизненный цикл оборудования начинается с планирования и приобретения
(либо аренды), продолжается установкой, обслуживанием и ремонтом, а за- вершается продажей, возвратом или утилизацией.
Автоматизация инфраструктуры
По существу, автоматизация инфраструктуры — это перевод элементов инфра- структуры на язык кода. Этот код подобен остальному программному обеспече- нию, дополнительно появляется возможность по восстановлению бизнеса с помо- щью резервных копий данных, хранилища кода и компьютерных ресурсов.
При описании управления инфраструктурой используется следующая дополни- тельная терминология.
220
Часть IV. Инструменты
Конфигурационный сдвиг
Этот термин описывает феномен, заключающийся в постепенном отклоне- нии конфигурации серверов от начальной.
Среднее время работы между сбоями (mean time between failures; MTBF)
Среднее время работы между сбоями.
Среднее время восстановления (mean time to repair; MTTR)
Период времени, необходимый для восстановления работоспособности системы.
Доступность
Широко используемая единица измерения, показывающая, как часто сис- тема или услуга оказывается доступной по сравнению с общим временем ее потенциальной полезности. Доступность = MTBF / (MTBF + MTTR).
Управление мощностями
Процесс, используемый для обеспечения соответствия между потенциалом инфраструктуры (а также другими ресурсами) и текущими, а также буду- щими потребностями бизнеса эффективным образом.
Сервер-«снежинка
1
»
Текущая желаемая конфигурация этого сервера достигается в результате выполнения множества ручных изменений. В процессе выполнения измене- ний часто используются инструменты командной строки, файлы конфигу- рации, примененные вручную заплаты и даже конфигурации и инсталляции графического интерфейса пользователя.
Автоматизация инфраструктуры зачастую трактуется как управление конфи- гурацией специалистом из отдела техобслуживания. И это действительно так, поскольку многие аспекты управления конфигурацией могут быть автоматизи- рованы. В частности, это касается идентификации программных пакетов, уста- новленных на сервере, определения версий этих пакетов, которые должны быть использованы, проверки наличия или отсутствия различных системных файлов, определения служб, которые должны выполняться.
«Трактовка кода инфраструктуры как всего остального программного обеспе- чения» означает, что код был разработан с помощью обычной локальной среды разработки и версионирован с применением системы контроля версий. Также использовалось версионирование в виде артефактов в хранилище артефактов, тестирование и верификация перед вводом в эксплуатацию.
1
Сервер-«снежинка» всегда настроен и используется вручную, а называется он так потому, что уникален, как снежинка. — Примеч. пер.
Глава 11. Обзор экосистемы инструментов
221
Автоматизация инфраструктуры по минимуму должна обеспечивать следующее.
Управление конфигурационным сдвигом
Конфигурационный сдвиг может возникать из-за изменений, внесенных вручную, обновления программного обеспечения, ошибок или законов энтропии. В этом случае нужен способ, позволяющий избежать подобных негативных проявлений. Зачастую выделяется отдельный узел, для которо- го выполняется регулярная проверка фактической конфигурации, которая сравнивается с реальной конфигурацией. В случае обнаружения каких-либо несоответствий выполняется самокорректировка.
Исключение серверов-«снежинок»
При автоматизации инфраструктуры можно обойтись без создания серве- ров-«снежинок». Для этого требуется четкое и детерминированное опреде- ление изменений. Чтобы исключить серверы-«снежинки», можно включить управление для одной части системы до тех пор, пока тот же «рецепт» управ- ления конфигурацией не будет применен для воссоздания сервера «с нуля» с применением желаемой конфигурации.
Версионированные артефакты инфраструктурного кода
Хорошее решение автоматизации инфраструктуры предусматривает ис- пользование контроля версий и хранилища артефактов. В результате код, который определяет конфигурацию сервера, может версионироваться со всеми преимуществами, предоставляемыми версионированием. Например, обеспечивается возможность простого отката изменений обратно, к хорошо известной версии, либо использование перехватчиков, которые выполняют тестирование кода, задающего инфраструктуру, после выполнения транзак- ций. Также все члены команды могут в комфортных условиях вносить свой вклад в улучшение кода инфраструктуры.
Минимизация сложности
Решения автоматизации инфраструктуры позволяют отдельным сотрудни- кам (независимо от выполняемой ими роли) управлять гетерогенной средой с минимальными затратами. Необходимое условие — указание версий кон- фигурации для типа или версии платформы.
Даже в стартапе с минимальным количеством систем не следует накапливать технические «долги». Благодаря инвестициям в сотрудников, которые понима- ют разницу между сценариями оболочки и автоматизацией инфраструктуры сервера-«снежинки», вы получите быструю отдачу.
Если доступные средства автоматизации инфраструктуры не удовлетворяют ваши текущие потребности, эффективнее расширить набор функциональных свойств либо повысить степень надежности существующего программного обеспечения.
Обзор экосистемы инструментов
Прежде чем приступать к обсуждению способов применения инструментов для улучшения и поддержания разных аспектов культуры, рассмотрим дополнитель- ные определения и термины. Эти дополнения расширяют терминологию, введен- ную в главе 4, для описания формирования дополнительного контента и дости- жения взаимопонимания между командами. И даже после этих дополнений мы получим далеко не исчерпывающий перечень технологий и терминов.
Люди могут использовать разные народные модели, приводящие к формирова- нию различного понимания одних и тех же терминов и концепций. Если же эти термины и концепции трактуются с точки зрения здравого смысла, это будет спо- собствовать более детальному обсуждению и лучшему пониманию сотрудниками организации.
Разработка программного обеспечения
Инструменты разработки программ призваны помочь в процессе программирова- ния, документирования, тестирования, а также исправления ошибок в приложе- ниях и службах. Благодаря тому, что эти инструменты не ограничены определен- ными ролями, они будут полезными для всех, кто имеет отношение к разработке и поддержке программ.
Локальная среда разработки
Наличие последовательной локальной среды разработки критически важно для быстрого привлечения сотрудников к процессу разработки программ. Сказанное вовсе не означает, что нужно «запереть» сотрудников в узкие рамки стандартного редактора, лишив их каких-либо дополнительных возможностей по настройке.
Скорее это означает, что в распоряжении пользователей появятся инструменты, которые позволят им эффективно выполнять работу.
Глава 11. Обзор экосистемы инструментов
215
Минимальные требования к локальной среде разработки могут существенно от- личаться в зависимости от индивидуальных предпочтений. Если нужно просто расширить сотрудничество, достаточно установить несколько дополнительных мониторов. Если же предполагается проводить длительные сеансы просмотра в комфортных условиях, придется установить мониторы высокого разрешения, клавиатуры, мыши и другие устройства ввода информации. Процесс классифи- кации текущего стандарта локальной среды разработки включает идентифи- кацию согласованной структуры, используемой как внутри команды, так и на межкомандном уровне. Благодаря такой классификации облегчается и ускоря- ется привлечение новых сотрудников к выполнению важных заданий в вашей организации.
Важно придерживаться баланса между стандартной организацией труда и ин- дивидуально настроенными рабочими компьютерами и привычками сотрудни- ков. Чрезмерная индивидуализация рабочих мест ведет к изоляции знаний либо к дополнительным расходам времени и сил на индивидуальную настройку спе- циализированных сред. Но в последние годы сотрудники начали больше ценить индивидуальный подход к работе. И если руководство не будет разрешать сотруд- никам выполнять индивидуальные настройки рабочего места, это приведет к утере конкурентного преимущества, связанного с наймом и удержанием сотрудников.
Идентифицируйте общую область для документирования локальной сре- ды разработки. Документы могут храниться в хранилище системы контроля версий, во внутреннем хранилище wiki или даже в Google Docs. Со временем и при наличии практики степень владения инструментами будет возрастать.
Поэтому исчерпывающая документация, в которой описаны все нюансы ра- боты с инструментами, попросту не нужна. Достаточно иметь руководство, содержащее начальные сведения по работе с инструментами.
Контроль версий
Чтобы расширить кооперацию и сотрудничество внутри команд и между коман- дами, нужно располагать возможностями по фиксации изменений, сравнению, слиянию и восстановлению прошлых версий объектов, находящихся в хранилище.
В результате сводится к минимуму риск отката к предыдущим версиям программ в производственной среде.
Буквально в каждой организации нужно реализовывать, использовать, изучать и адаптировать контроль версий. Благодаря этому средству команды могут раз- решать конфликты, возникающие в случаях, когда несколько людей одновремен- но работают над одним и тем же файлом или проектом. Также обеспечивается безопасный способ выполнения и отката изменений. Использование контроля версий на ранних стадиях жизненного цикла команды или продукта способствует выработке хороших привычек.
216
Часть IV. Инструменты
Выбирайте систему контроля версий, которая поощряла бы желаемый для вас тип сотрудничества. В следующем списке приведены предпосылки для развития сотрудничества:
открытие и доступ к клонированию хранилищ;
содействие развитию хранилищ;
управление вкладами в собственные хранилища;
определение процессов для содействия;
обмен правами для фиксации изменений.
Некоторые инструменты плохо подходят для совместной работы, но поскольку со временем к ним привыкают, начинают мириться с имеющимися недостатками.
В подобных случаях оцените последствия отказа от использования более под- ходящих инструментов. Например, то, как это повлияет на найм персонала или слияние различных областей. При внедрении адекватного процесса коллективная работа может выполняться даже при наличии неподходящих инструментов, хотя и со сложностями.
Используя такой показатель, как количество строк кода, невозможно точ- но оценить стоимость труда программиста. Некоторые разработчики могут превратить сотни строк непонятного кода в десятки простых для понима- ния абстракций, которые могут восприниматься прочими членами команды.
Другие разработчики сосредоточиваются на поиске ошибок, скрытых в коде.
Поэтому используйте сведения о количестве строк созданного кода в качестве справочной информации, позволяющей стимулировать нужное вам поведе- ние. Например, если у вас отсутствуют навыки качественного анализа кода, не думайте, что больше всегда означает лучше.
В следующем списке приводится дополнительная терминология, относящаяся к контролю версий.
Фиксация
Фиксация — это последовательность действий по включению изменений, внесенных в файлы под управлением контроля версий.
Конфликты
Конфликт имеет место в том случае, когда внесены два очень похожих изменения и система контроля версий не может определить, какое из этих изменений является корректным. В большинстве случаев система контроля версий обеспечивает способ просмотра и выбора желательных изменений для разрешения конфликтов.
Глава 11. Обзор экосистемы инструментов
217
Запрос на включение кода
Запрос на включение кода (pull request) — это механизм, который посыла- ет разработчику сигнал о том, что его вклад готов к просмотру и слиянию с основной ветвью.
Избирательный подход
Избирательный подход — это применение определенных подтверждений из одной отрасли в другой отрасли. Этот подход полезен при необходимости выбора определенных изменений запроса на включение кода.
Управление артефактами
Артефакт — это результат выполнения какого-либо шага в процессе разработки программного обеспечения. Артефакты хранятся в хранилище. Можно выбрать как простое, так и более сложное полнофункциональное хранилище. В последнем случае нужно оценить стоимость поддержки дополнительных услуг и проблем с обеспечением безопасности.
Хранилище артефактов должно быть:
защищенным;
доверенным;
стабильным;
доступным;
версионированным.
При наличии хранилища артефактов появляется возможность статической трак- товки зависимостей. Вы можете хранить версионированную общую библиотеку в качестве артефакта отдельно от системы контроля версий программного обеспе- чения. Это позволит всем командам использовать одну и ту же общую библиотеку.
Вам придется создавать двоичный файл всего лишь один раз (даже если вы можете построить его повторно). В результате один и тот же двоичный файл используется на протяжении циклов испытаний и продвижений между сборками, что сущест- венно упрощает работу.
В хранилище можно хранить артефакты в соответствии со способом их использо- вания. В некоторых системах можно одновременно хранить лишь единственную версию пакета. Это может привести к появлению проблем при описании истории пакетов. Чтобы не допустить появления подобных проблем, нужно увеличить фактор дублирования хранилища пакетов. Это позволит поддерживать отдельное хранилище пакетов для каждой среды в рабочем потоке.
На ранних стадиях эволюции организация может не соответствовать определен- ным требованиям безопасности. Но по мере роста и появления линий продуктов
218
Часть IV. Инструменты ситуация может измениться. Благодаря наличию выделенного локального храни- лища артефактов обеспечивается более плавный переход на пути к достижению соответствия вышеупомянутым требованиям.
В идеале ваша локальная среда разработки должна иметь тот же доступ к внутрен- нему хранилищу артефактов, что и другие механизмы построения и развертыва- ния, действующие в вашей среде. Поскольку одни и те же пакеты и зависимости используются в производственной среде и в локальной среде разработки, миними- зируется вероятность появления синдрома «это работает на моем ноутбуке». Если же доступ ограничен или заблокирован, могут появиться новые способы выпол- нения тех или иных действий, которые обходят безопасность и другие политики.
РАННИЕ ПОЛИТИКИ
Раннее развертывание процессов управления содействует развитию сотруд- ничества в контексте среды и ограничений. Например, определите, кто и какие артефакты может выдвигать. Также установите, каким образом проверяются, лицензируются и обеспечиваются артефакты. Все это позволит избежать появ- ления проблем, вызванных использованием устаревших артефактов.
Если в вашей среде отсутствует доступ к Интернету, вам придется сформиро- вать свою собственную вселенную. Эта вселенная включает общие хранилища программ, серверы специфичных языковых пакетов, управление зависимостями и другие компоненты. Также должно воспроизводиться множество доступных об- щих служб. Создание подобной вселенной обеспечивает ряд преимуществ, в том числе защиту организации от незадокументированных разрушающих изменений свыше и от внешних сбоев, вызывающих внутренние проблемы. Если же при фор- мировании зависимостей полагаться на Интернет, в конечном счете кто-то будет определять доступность и совместимость ваших сборок. Подобных ситуаций ста- раются не допускать многие организации.
В следующем списке приведена дополнительная терминология, относящаяся к управлению артефактами.
Управление зависимостями
Зависимости определяются характером и степенью взаимозависимости одного программного проекта от другого. Для выявления подобных за- висимостей используются разные механизмы. На уровне артефактов для программного обеспечения может оказаться полезным сохранение зави- симых артефактов.
Закрепление
Закрепление — это метод блокировки явной версии артефакта для окружа- ющей среды. При управлении зависимостями может оказаться полезным определение явной версии зависимого артефакта программы, работающей с вашим проектом.
Глава 11. Обзор экосистемы инструментов
219
Продвижение
Продвижение — это метод выбора конкретной версии программного обеспе- чения для перемещения в сторону доставки, как правило, ключ к успешному прохождению тестов.
Автоматизация
Благодаря использованию средств автоматизации уменьшаются затраты рабочей силы, энергии и материалов, используемых в целях обеспечения качества, точно- сти и корректности результатов.
Установка сервера
Под установкой сервера понимается автоматизация конфигурирования и настрой- ки отдельных серверов. Производители оборудования, такие как HP и Dell, предо- ставляют инструмент, который можно использовать при работе с оборудованием этих брендов.
Некоторые дистрибутивы Linux также поддерживают инструменты, предназна- ченные для соответствующей операционной системы. Например, для установ- ки сервера в среде Red Hat Enterprise Linux или CentOS могут использоваться
Cobbler и Kickstart. Персонал из эксплуатационного отдела может создавать фай- лы Kickstart, которые определяют разбиение жесткого диска, конфигурирование сети, устанавливаемые пакеты ПО и т. п.
УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ОБОРУДОВНИЯ
Каждая компания в той или иной форме должна иметь дело с управлением оборудованием или жизненным циклом. Благодаря появлению облачных и ин- фраструктурных либо платформенных служб эта задача немного упрощается.
Жизненный цикл оборудования начинается с планирования и приобретения
(либо аренды), продолжается установкой, обслуживанием и ремонтом, а за- вершается продажей, возвратом или утилизацией.
Автоматизация инфраструктуры
По существу, автоматизация инфраструктуры — это перевод элементов инфра- структуры на язык кода. Этот код подобен остальному программному обеспече- нию, дополнительно появляется возможность по восстановлению бизнеса с помо- щью резервных копий данных, хранилища кода и компьютерных ресурсов.
При описании управления инфраструктурой используется следующая дополни- тельная терминология.
220
Часть IV. Инструменты
Конфигурационный сдвиг
Этот термин описывает феномен, заключающийся в постепенном отклоне- нии конфигурации серверов от начальной.
Среднее время работы между сбоями (mean time between failures; MTBF)
Среднее время работы между сбоями.
Среднее время восстановления (mean time to repair; MTTR)
Период времени, необходимый для восстановления работоспособности системы.
Доступность
Широко используемая единица измерения, показывающая, как часто сис- тема или услуга оказывается доступной по сравнению с общим временем ее потенциальной полезности. Доступность = MTBF / (MTBF + MTTR).
Управление мощностями
Процесс, используемый для обеспечения соответствия между потенциалом инфраструктуры (а также другими ресурсами) и текущими, а также буду- щими потребностями бизнеса эффективным образом.
Сервер-«снежинка
1
»
Текущая желаемая конфигурация этого сервера достигается в результате выполнения множества ручных изменений. В процессе выполнения измене- ний часто используются инструменты командной строки, файлы конфигу- рации, примененные вручную заплаты и даже конфигурации и инсталляции графического интерфейса пользователя.
Автоматизация инфраструктуры зачастую трактуется как управление конфи- гурацией специалистом из отдела техобслуживания. И это действительно так, поскольку многие аспекты управления конфигурацией могут быть автоматизи- рованы. В частности, это касается идентификации программных пакетов, уста- новленных на сервере, определения версий этих пакетов, которые должны быть использованы, проверки наличия или отсутствия различных системных файлов, определения служб, которые должны выполняться.
«Трактовка кода инфраструктуры как всего остального программного обеспе- чения» означает, что код был разработан с помощью обычной локальной среды разработки и версионирован с применением системы контроля версий. Также использовалось версионирование в виде артефактов в хранилище артефактов, тестирование и верификация перед вводом в эксплуатацию.
1
Сервер-«снежинка» всегда настроен и используется вручную, а называется он так потому, что уникален, как снежинка. — Примеч. пер.
Глава 11. Обзор экосистемы инструментов
221
Автоматизация инфраструктуры по минимуму должна обеспечивать следующее.
Управление конфигурационным сдвигом
Конфигурационный сдвиг может возникать из-за изменений, внесенных вручную, обновления программного обеспечения, ошибок или законов энтропии. В этом случае нужен способ, позволяющий избежать подобных негативных проявлений. Зачастую выделяется отдельный узел, для которо- го выполняется регулярная проверка фактической конфигурации, которая сравнивается с реальной конфигурацией. В случае обнаружения каких-либо несоответствий выполняется самокорректировка.
Исключение серверов-«снежинок»
При автоматизации инфраструктуры можно обойтись без создания серве- ров-«снежинок». Для этого требуется четкое и детерминированное опреде- ление изменений. Чтобы исключить серверы-«снежинки», можно включить управление для одной части системы до тех пор, пока тот же «рецепт» управ- ления конфигурацией не будет применен для воссоздания сервера «с нуля» с применением желаемой конфигурации.
Версионированные артефакты инфраструктурного кода
Хорошее решение автоматизации инфраструктуры предусматривает ис- пользование контроля версий и хранилища артефактов. В результате код, который определяет конфигурацию сервера, может версионироваться со всеми преимуществами, предоставляемыми версионированием. Например, обеспечивается возможность простого отката изменений обратно, к хорошо известной версии, либо использование перехватчиков, которые выполняют тестирование кода, задающего инфраструктуру, после выполнения транзак- ций. Также все члены команды могут в комфортных условиях вносить свой вклад в улучшение кода инфраструктуры.
Минимизация сложности
Решения автоматизации инфраструктуры позволяют отдельным сотрудни- кам (независимо от выполняемой ими роли) управлять гетерогенной средой с минимальными затратами. Необходимое условие — указание версий кон- фигурации для типа или версии платформы.
Даже в стартапе с минимальным количеством систем не следует накапливать технические «долги». Благодаря инвестициям в сотрудников, которые понима- ют разницу между сценариями оболочки и автоматизацией инфраструктуры сервера-«снежинки», вы получите быструю отдачу.
Если доступные средства автоматизации инфраструктуры не удовлетворяют ваши текущие потребности, эффективнее расширить набор функциональных свойств либо повысить степень надежности существующего программного обеспечения.