Непрерывная доставка – возможность работать быстрее

Более 10 лет назад мы начали проект, целью которого было понять, насколько быстро наши команды реализуют идеи в виде качественных промышленных систем. В его рамках мы измеряли, как быстро мы работаем над созданием ПО, чтобы повысить скорость исполнения. Оказалось, что с момента сдачи кода до его вывода в рабочую среду требовалось в среднем 16 дней. Сотрудники Amazon начинали с идеи, для реализации которой требовалось примерно полтора дня. На формирование сборки и развертывание кода уходило меньше часа. Оставшееся время, почти 14 дней, тратилось на то, что сотрудники ждали, пока можно будет начать работу над сборкой, развертыванием и тестированием. По результатам проекта мы сформулировали рекомендацию автоматизировать процессы, следующие за сдачей кода, чтобы ускорить исполнение. Нужно было устранить задержки, сохранив или даже повысив качество.

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

У Amazon уже были средства разработки, которые повышали скорость работы программистов. Мы создали собственную централизованную главную систему управления сборками, Brazil, которая исполняет на сервере серию команд с целью создания артефакта, который может быть развернут. На тот момент Brazil не учитывала изменений в исходном коде. Сотруднику нужно было инициировать сборку. У нас также была собственная система развертывания, Apollo, куда нужно было загрузить сборку артефакта для того, чтобы инициировать развертывание. Интерес к непрерывной доставке, существовавший в отрасли, привел к созданию нашей собственной системы Pipelines, которая автоматизировала процесс доставки ПО между Brazil и Apollo.

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

Гигиена развертывания: самая базовая форма тестирования при развертывании позволяет убедиться, что вновь развернутый артефакт запускается и реагирует на запросы. Операции, следующие за развертыванием, включают в себя оперативные проверки, которые гарантируют, что развернутый артефакт запустился и обслуживает трафик. Например, в файле AWS Codedeploy AppSpec мы используем процедуры жизненного цикла для выполнения простых скриптов для запуска, остановки и проверки развертывания. Мы также проверяем, достаточны ли ресурсы для обслуживания клиентского трафика. Чтобы гарантировать, что у нас всегда есть ресурсы обслуживать клиентов, мы разработали такие принципы, как принцип минимального количества рабочих узлов в CodeDeploy. И, наконец, если средство развертывания может найти ошибку, оно должно уметь осуществлять откат изменений, чтобы время, в течение которого клиенты будут замечать ошибку, было бы минимальным.

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

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

В Amazon мы также используем методику, называемую «опытно-промышленным тестированием». Опытно-промышленная среда – последнее место, в которой производится тестирование до развертывания изменений в промышленной среде. Тест в опытно-промышленной среде использует конфигурацию промышленной системы, поэтому она действует в точности как таковая. У этого подхода есть два преимущества. Во-первых, тестирование в опытно-промышленной среде позволяет убедиться, что сервис может правильно подключаться ко всем рабочим ресурсам, включая места хранения рабочих данных. Во-вторых, она позволяет убедиться, что система правильно взаимодействует в API-интерфейсами действующих сервисов, от которых она зависит. Опытно-промышленные среды используются только ответственной за сервис командой, поэтому клиентский трафик на них никогда не направляется. Выполнение опытно-промышленного тестирования повышает уверенность в том, что этот же код и конфигурация будут нормально функционировать в рабочей среде.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вернемся в сегодняшний день. Сегодня команды программистов Amazon стремятся добиться полной автоматизации при написании нового кода. Для нас автоматизация – единственный способ дальнейшего роста бизнеса.