Страница 6 из 13
Процесс развертывания кода настолько хорошо оптимизирован, что на его выполнение тратится около 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 пользователи получили доступ к простому веб-интерфейсу, доступному каждому
Очевидно, что наделение персонала полномочиями по созданию инструментов, упрощающих развертывание, значительно упрощает всю дальнейшую работу. Процесс развертывания стал «прозрачным» и значительно упростился. Тесты прошли путь от хаотичных и требующих много времени инструментов до средств, помогающих выявлять ошибки. Благодаря появлению журналов, графиков и предупреждений даже неквалифицированные пользователи получили возможность видеть результаты выполненных изменений.
Ключевой вывод, который можно сделать на основании историй со всеми перечисленными инструментами, заключается не столько в специфике этих инструментов, сколько в том, чтобы кто-то понял, что эти инструменты должны быть созданы и что на это потребуются время и ресурсы.
Чтобы создать необходимые инструменты и сформировать культуру их применения, общего доступа и сотрудничества, требуется вовлеченность со стороны менеджмента, свобода экспериментов, работа с кодом, невидимым для заказчиков, и доверие между разными группами разработчиков.
Благодаря этим факторам компания Etsy превратилась в так называемого единорога devops (хотя они предпочитают называть себя «лошадью в блестках»). И эта компания старается поддерживать соответствующую культуру на всех внутренних уровнях. Пример с этой компанией олицетворяет наше определение эффективных devops-практик, реализованных в организации. В результате применения этих практик вносятся изменения в культуру, которые влияют на то, как отдельные сотрудники думают о работе. Также оцениваются разные роли, присущие сотрудникам, ускоряется рост ценности бизнеса и измеряется эффект, вызванный изменениями. Именно devops-практики помогли Etsy перейти из состояния фрустрации и изоляции в состояние успешного производства, построенного на основе сотрудничества, и воспитать разработчиков инструментов. Примеры использования подобных руководящих принципов мы уже видели в историях успеха компаний, работающих в этой отрасли. Подобные истории могут использоваться в качестве руководства к действию компаниями, которые хотят реализовать у себя подобные трансформации.
Все мы думаем на языке наших собственных мыслей. А делимся концепциями.
Эта книга включает тематические исследования и истории, рассказанные группами и отдельными людьми. Если же обратиться к существующим книгам, посвященным devops, то вы обнаружите, что в них описываются инструменты и абстрактные культурные практики, а историям из реальной жизни уделяется не столь много внимания. Одно дело говорить о том, как что-то должно работать, в теории, и совсем другое – реализовать это на практике. Мы хотим поделиться с вами историями применения теоретических знаний на практике, рассказать о том, что было сделано, а что не сделано, поделиться идеями, лежащими в основе принятия решений. Это позволит вам получить максимум информации, применяемой в процессе внедрения практик devops.
Моя история, связанная с devops, началась во времена зарождения движения devops. Я совершила резкий поворот в своей карьере в сторону эксплуатации сразу же после формализации идеи devops и проведения первых конференций devopsdays. Я выступала в роли эксплуатационной группы, состоящей из единственной женщины, которая работала в маленьком стартапе, развернутом в пространстве электронной коммерции. И я для себя открыла, что мне нравится эксплуатационная работа. И даже несмотря на то что я на протяжении столь длительного времени работала в одиночестве, идеи devops не лишены для меня смысла. Эти идеи основаны на здравом рассуждении, поскольку обеспечивают более эффективную работу с другими частями организации, не относящимися к вашей группе. В те времена я была рядовым системным администратором, проводившим свои дни в дебрях центра обработки данных. Я была единственным сотрудником по вызову и была столь занята борьбой с унаследованными «пожарами», что практически не представляла, чем занимаются разработчики (либо кто-либо другой, если это имеет значение). Поэтому идеи разделения обязанностей и информации, а также разрушения барьеров между командами действительно имеют для меня значение.