Кэтрин Дэниелс - Философия DevOps. Искусство управления IT Страница 5

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

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

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

После прохождения внутренних и пробных тестов разработчик присоединяется к очереди магазинного типа Etsy, чтобы выполнить развертывание изменений в производственной среде. Если несколько разработчиков готовы развернуть изменения одновременно, для координирования развертывания изменений в системе управления очередью используется Internet Relay Chat (IRC) и IRC-бот. Как только подходит очередь Кэтрин, она подтверждает изменения в мастер-ветви репозитория, в которой она работает. Для развертывания изменений на сервере QA в Etsy используется среда Deployinator. Благодаря применению этой среды выполняется автоматическое создание QA-сервера и выполняется полный набор тестов CI.

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

Процесс развертывания кода настолько хорошо оптимизирован, что на его выполнение тратится около 10 минут в среднем (от начала до завершения), и инженерный персонал Etsy проделывает эту операцию до 60 раз в день. Благодаря наличию документации и наставничеству опытных сотрудников, объясняющих подробности процесса, начинающий инженер запускает код в производство за один день. Даже сотрудники, не относящиеся к инженерному персоналу, поощряются к участию в процессе в рамках программы First Push Program. Под руководством инженеров они развертывают небольшие изменения, такие как публикация фотографий на странице персонала веб-сайта. Помимо использования для регулярного развертывания ПО, процессы тестирования и Deployinator могут применяться для развертывания чего угодно – от инструментов, применяемых разработчиками для построения виртуальных машин, до панелей Kibana, применяемых для поиска журналов, от проверок программы мониторинга Nagios до самого процесса Deployinator.

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

Группы, сформированные в инженерной организации, были разрознены. Многие разработчики имели склонность «перебрасывать» код через «метафорические стены» эксплуатационной группе, которая несла исключительную ответственность за мониторинг и поддержку этого кода. В результате появлялась склонность к слишком частому изменению кода. Разработчики создавали код, вызывали на выполнение вручную написанные сценарии, чтобы создать новую SVN-ветвь. При этом развертывание выполнялось с помощью средства svn merge. Этот довольно сложный в применении инструмент применялся для слияния всех изменений, выполненных разработчиками, в одной ветви развертывания. Затем разработчики сообщали об используемой ветви инженеру из службы эксплуатации, наделенному полномочиями по выполнению развертывания ПО. Как видите, процесс развертывания был весьма кропотливым и занимал много часов (рис. 1.1). По причине сложности этот процесс выполнялся раз в две-три недели.

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

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

Рис. 1.1. До появления среды Deployinator процесс развертывания был сложным и полным ошибок

Рис. 1.2. После появления среды Deployinator пользователи получили доступ к простому веб-интерфейсу, доступному каждому

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

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