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

Слишком часто мы обнаруживаем, как наши приложения работают в среде, приближенной к производственной, только во время развертывания — когда уже слишком поздно, чтобы устранять проблемы без негативного влияния на клиентов. Наглядный пример широкого спектра проблем, вызванных рассогласованием приложений и сред, — программа Enterprise Data Warehouse. Ее созданием в крупной австралийской телекоммуникационной компании в 2009 г. руководила Эм Кэмпбел-Претти. Она стала генеральным менеджером и бизнес-спонсором этой программы, стоившей 200 миллионов долларов, и одновременно получила ответственность за все стратегические цели, связанные с этой платформой.

В презентации на конференции DevOps Enterprise Summit в 2014 г. Кэмпбел-Претти пояснила, что «в то время параллельно шли десять потоков работы, все с помощью водопадного метода, и все десять потоков значительно отставали от графика. Только один из потоков успешно дошел до стадии приемочных испытаний, проводимых пользователями (User Acceptance Testing, UAT), в запланированный срок, и еще шесть месяцев потребовались для завершения этих испытаний, которые показали, что результирующая производительность оказалась намного ниже ожидаемой. Эта недостаточная производительность явилась основным катализатором преобразования отдела по технологии Agile».

Однако после использования Agile в течение почти года разработчики добились только небольших улучшений, по-прежнему не получая необходимых результатов в бизнесе. Кэмпбел-Претти провела ретроспективный обзор программы и задала команде вопрос: «Если учесть весь опыт, накопленный нами за время последнего релиза, то какие вещи мы могли бы сделать, чтобы удвоить нашу продуктивность?»

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

Новая команда интеграции и сборки стала ответственной за «создание качества внутри процессов вместо проверки качества после создания продукта». Первоначально она была в составе команды администраторов баз данных (DBA), и специалисты получили задачу по автоматизации процесса создания среды. Команда быстро сделала удивительное открытие: только 50 % исходного кода в средах разработки и тестирования соответствовало производственной среде.

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

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

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

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

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

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

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

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

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

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

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

• копирование виртуализированной среды (например, образа VMware, запуск сценария Vagrant, загрузка файла Amazon Machine Image в EC2);

• создание процесса автоматизированного формирования среды, который начинает работу с нуля (например, PXE — установка из базовых образов);

• с помощью инструментов управления конфигурациями «инфраструктура как код» (например, Puppet, Chef, Ansible, Salt, CFEngine и так далее);

• с помощью автоматизированных инструментов конфигурации операционной системы (например, Solaris Jumpstart, Red Hat Kickstart, Debian preseed);

• сборка среды из набора виртуальных образов или контейнеров (например, Vagrant, Docker);

• сборка новой среды в общедоступной среде облачных вычислений (например, Amazon Web Services, Google App Engine, Microsoft Azure), частном облаке или в других PaaS (таких, как OpenStack или Cloud Foundry и так далее).

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

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

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

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

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

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

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

• весь код приложения и все зависимости (например, библиотеки, статическое содержимое и так далее);

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

• все инструменты для создания среды и артефактов, описанных на предыдущем шаге (например, образы VMware или AMI, рецепты Puppet или Chef и так далее);

• все файлы, использующиеся для создания контейнеров (например, определения или композиционные файлы состава Docker или Rocket);

• все вспомогательные автоматические тесты и все сценарии тестирования вручную;

• все сценарии, обеспечивающие упаковку кода, развертывание, миграцию баз данных и предоставление рабочей среды;

• все артефакты проекта (например, документации с описанием требований к продукту, процедуры развертывания, примечания к релизу и так далее);

• все файлы конфигурации облаков (например, шаблоны формирования AWS Cloud, файлы Microsoft Azure Stack DSC, OpenStack HEAT);

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

Можно иметь несколько репозиториев для различных типов объектов, в которых они маркированы и помечены наравне с исходным кодом. Например, мы можем хранить большие образы виртуальных машин и ISO-файлы, собранные двоичные файлы и тому подобное в репозиториях артефактов (таких, как Nexus, Artifactory и так далее). Или можем положить их в хранилища blob (например, блоки Amazon S3) или положить образы Docker в хранилища Docker и так далее.

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

Согласно докладу 2014 State of DevOps Report компании Puppet Labs использование отделом эксплуатации системы контроля версий — наилучший показатель для предсказывания производительности как IT-подразделений, так и всей организации в целом. По сути, этот показатель даже лучше, чем использование системы контроля версий разработчиками.

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

Но почему использование системы контроля версий для сред разработки позволяет точнее предсказать производительность IT-подразделений и организации в целом, чем использование этой системы непосредственно для контроля кода?

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

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

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

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

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

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

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

Последняя модель — так называемая постоянная инфраструктура: в ней внести изменения в производственную среду вручную невозможно, единственный способ — внести изменения в систему контроля версий и создать код и среду «с нуля». При таком подходе вариабельность никак не сможет «вползти» в производственную среду.

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

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

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

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

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

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

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

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

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

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

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

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

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