Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf

36
Часть I. Основы devops рекомендации, помогающие идентифицировать изменения, заслуживающие прос- мотра кода, а также определить, кто именно должен заниматься этой работой.
Поскольку в то время Кэтрин только что приняли на работу в 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.

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

38
Часть I. Основы devops
Рис. 1.1. До появления среды Deployinator процесс развертывания был сложным и полным ошибок
Рис. 1.2. После появления среды Deployinator пользователи получили доступ к простому веб-интерфейсу, доступному каждому
Очевидно, что наделение персонала полномочиями по созданию инструментов, упрощающих развертывание, значительно упрощает всю дальнейшую работу.
Процесс развертывания стал «прозрачным» и значительно упростился. Тесты прошли путь от хаотичных и требующих много времени инструментов до средств, помогающих выявлять ошибки. Благодаря появлению журналов, графиков и пре- дупреждений даже неквалифицированные пользователи получили возможность видеть результаты выполненных изменений.

Глава 1. Первое знакомство
39
Ключевой вывод, который можно сделать на основании историй со всеми перечис- ленными инструментами, заключается не столько в специфике этих инструментов, сколько в том, чтобы кто-то понял, что эти инструменты должны быть созданы и что на это потребуются время и ресурсы.
Чтобы создать необходимые инструменты и сформировать культуру их приме- нения, общего доступа и сотрудничества, требуется вовлеченность со стороны менеджмента, свобода экспериментов, работа с кодом, невидимым для заказ- чиков, и доверие между разными группами разработчиков.
Благодаря этим факторам компания Etsy превратилась в так называемого едино- рога devops (хотя они предпочитают называть себя «лошадью в блестках»). И эта компания старается поддерживать соответствующую культуру на всех внутренних уровнях. Пример с этой компанией олицетворяет наше определение эффективных devops-практик, реализованных в организации. В результате применения этих прак тик вносятся изменения в культуру, которые влияют на то, как отдельные со- трудники думают о работе. Также оцениваются разные роли, присущие сотрудни- кам, ускоряется рост ценности бизнеса и измеряется эффект, вызванный измене- ниями. Именно devops-практики помогли Etsy перейти из состояния фрустрации и изоляции в состояние успешного производства, построенного на основе сотруд- ничества, и воспитать разработчиков инструментов. Примеры использования подобных руководящих принципов мы уже видели в историях успеха компаний, работающих в этой отрасли. Подобные истории могут использоваться в качестве руководства к действию компаниями, которые хотят реализовать у себя подобные трансформации.
Истории пути к успеху
Все мы думаем на языке наших собственных мыслей. А делимся концеп- циями.
— Стивен Тулмин. Человеческое понимание
Эта книга включает тематические исследования и истории, рассказанные груп- пами и отдельными людьми. Если же обратиться к существующим книгам, по- священным devops, то вы обнаружите, что в них описываются инструменты и аб- страктные культурные практики, а историям из реальной жизни уделяется не столь много внимания. Одно дело говорить о том, как что-то должно работать, в теории, и совсем другое — реализовать это на практике. Мы хотим поделиться с вами историями применения теоретических знаний на практике, рассказать о том, что было сделано, а что не сделано, поделиться идеями, лежащими в основе принятия решений. Это позволит вам получить максимум информации, применя- емой в процессе внедрения практик devops.

40
Часть I. Основы devops
История Кэтрин
Моя история, связанная с devops, началась во времена зарождения движения devops. Я совершила резкий поворот в своей карьере в сторону эксплуатации сразу же после формализации идеи devops и проведения первых конферен- ций devopsdays. Я выступала в роли эксплуатационной группы, состоящей из единственной женщины, которая работала в маленьком стартапе, развернутом в пространстве электронной коммерции. И я для себя открыла, что мне нравит- ся эксплуатационная работа. И даже несмотря на то что я на протяжении столь длительного времени работала в одиночестве, идеи devops не лишены для меня смысла. Эти идеи основаны на здравом рассуждении, поскольку обеспечивают более эффективную работу с другими частями организации, не относящимися к вашей группе. В те времена я была рядовым системным администратором, проводившим свои дни в дебрях центра обработки данных. Я была единствен- ным сотрудником по вызову и была столь занята борьбой с унаследованными
«пожарами», что практически не представляла, чем занимаются разработчики
(либо кто-либо другой, если это имеет значение). Поэтому идеи разделения обязанностей и информации, а также разрушения барьеров между командами действительно имеют для меня значение.
Некоторые организации более восприимчивы к изменениям и новым идеям, чем другие. Но помимо того, что мой стартап совершенно не подвергался изме- нениям, руководство не желало прислушиваться к высказываниям юного сис- темного администратора. Чтобы не прислушиваться к моим идеям, мне просто говорили следующее: «Ты не настоящий системный администратор». И у них даже не было денег, чтобы купить мне пару книг. Мне пришлось самой купить книги Тома Лимончелли Practice of System and Network Administration и Time
Management for System Administrators. Я уже молчу о том, что мне не светило по- пасть на конференции LISA, Velocity и на devopsdays (Нью-Йорк) в ближайшие несколько лет.
К счастью, я начала искать devops-сообщества в Интернете и оказалась в состо- янии общаться и учиться у людей, которые разделяли мою увлеченность вопро- сами эксплуатации. Благодаря совместной учебе и работе я просто воспряла духом. Джеймс Тернбулл, который в настоящее время является техническим директором компании Kickstarter, в то время работал в компании Puppet. Он нашел меня в Твиттере, завязал со мной разговор и отправил мне копию своей великолепной книги Pro Puppet. Это случилось в тот момент, когда я сражалась с 200 унаследованными серверами от компании Snowflake, не располагая даже простейшим bash-сценарием для управления этими серверами. Благодаря этой книге я познакомилась с растущим и процветающим сообществом людей, ко- торые подарили мне надежду на то, что в один прекрасный день я смогу стать членом этого сообщества.
Как отмечает в своей истории Дженнифер, трудно добиться изменений, если вы уже «выгорели». Если уже прошел год в бесплодных попытках изменить

Глава 1. Первое знакомство
41
и улучшить родную компанию, но меня никто не слушает в силу отсутствия опыта, хотя он растет каждый день. И я сделала выбор и пошла дальше. Я продолжала учиться и совершенствовать свои навыки, но все еще не чувствовала себя полно- стью сроднившейся с рабочим местом. Мне все казалось, что я сражаюсь со своими коллегами и организациями, вместо того чтобы работать с ними.
В январе 2013 года я попала на свою первую конференцию devopsdays (Нью-
Йорк). Я впитывала как губка все разговоры и пыталась слушать как можно больше, даже если понимала, что вряд ли смогу что-либо добавить к сказанному.
Я жила под воздействием хэштега
#VelocityConf в Твиттере. В октябре того же года у меня было короткое выступление на второй конференции devopsdays (Нью-
Йорк), на которой я встретилась с Майком Римбетси, одним из организаторов конференции. Он пригласил меня работать в Etsy, но я подумала, что он шутит, поскольку не считала себя профессионалом в этой области. Я следовала кодексу
Code as Craft и придерживалась практики эксплуатационной группы Etsy в Интер- нете с тех пор, как открыла для себя devops-сообщества, но я не считала себя столь профессиональной, чтобы присоединиться к ним.
Когда я поняла, что ошибалась, меня просто переполнило счастье. Моя карьера в области эксплуатации началась как путешествие через несколько разных орга- низационных структур и способов разработки, эксплуатации, а иногда даже через группы «devops», с которыми я работала. Располагая опытом работы с такими компаниями, как стартап, состоящий из 25 человек, и огромная корпорация, суще- ствующая десятки лет на рынке, с сотней тысяч сотрудников, я видела множество в разной степени эффективных способов разработки и поставки программных продуктов и систем.
Имея опыт работы специалиста по вызову, доступного 24 часа в сутки и 7 дней в неделю большую часть года, и будучи знакомой с иными сценариями работы, далекими от идеального, я хочу поделиться с читателями книги приемами и ме- тодами, которые успешно применяются мной и членами моих групп. С помощью этих методик удалось снизить количество сотрудников, считающих себя «слабым звеном» в своей организации. В большой степени мотивация к написанию этой книги представляла собой возможность поделиться историями с читателями, историями, которые имели ко мне отношение или были рассказаны другими людьми. Это дает возможность делиться знаниями с другими пользователями, учиться и расти как сообщество. Именно devops-сообщество помогло мне занять мое нынешнее место, и эта книга представляет собой лишь один из способов воз- врата долга с моей стороны.
История Дженнифер
В 2007 году я связалась с руководством Yahoo по поводу позиции, которая отно- силась «немного к разработке» и «немного к эксплуатации». Речь шла о вакан- сии старшего сервисного инженера, ответственного за создание и обслуживание