Глава 1. Первое знакомство

По сути devops – это способ мышления и работы. Это своего рода каркас, служащий для того, чтобы делиться историями и развивать эмпатию. Благодаря devops отдельные люди и группы могут эффективно и непрерывно развивать свои навыки. Это часть культурной «ткани», которая формирует способы выполнения работы, а также создает мотивацию для этой работы. Многие представляют devops как некий набор специфических инструментов, таких как Chef или Docker, но на самом деле devops не ограничивается ими. Инструменты превращаются в «devops» благодаря способу их применения, а не в силу характеристик самих инструментов.

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

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

Культура развертывания ПО

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

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

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

Путем запуска набора локальных модулей и функциональных тестов инженеры 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 пользователи получили доступ к простому веб-интерфейсу, доступному каждому

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

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

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

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

Истории пути к успеху

Все мы думаем на языке наших собственных мыслей. А делимся концепциями.

– Стивен Тулмин. Человеческое понимание

Эта книга включает тематические исследования и истории, рассказанные группами и отдельными людьми. Если же обратиться к существующим книгам, посвященным devops, то вы обнаружите, что в них описываются инструменты и абстрактные культурные практики, а историям из реальной жизни уделяется не столь много внимания. Одно дело говорить о том, как что-то должно работать, в теории, и совсем другое – реализовать это на практике. Мы хотим поделиться с вами историями применения теоретических знаний на практике, рассказать о том, что было сделано, а что не сделано, поделиться идеями, лежащими в основе принятия решений. Это позволит вам получить максимум информации, применяемой в процессе внедрения практик 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-сценарием для управления этими серверами. Благодаря этой книге я познакомилась с растущим и процветающим сообществом людей, которые подарили мне надежду на то, что в один прекрасный день я смогу стать членом этого сообщества.

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

В январе 2013 года я попала на свою первую конференцию devopsdays (Нью-Йорк). Я впитывала как губка все разговоры и пыталась слушать как можно больше, даже если понимала, что вряд ли смогу что-либо добавить к сказанному. Я жила под воздействием хэштега #VelocityConf в Твиттере. В октябре того же года у меня было короткое выступление на второй конференции devopsdays (Нью-Йорк), на которой я встретилась с Майком Римбетси, одним из организаторов конференции. Он пригласил меня работать в Etsy, но я подумала, что он шутит, поскольку не считала себя профессионалом в этой области. Я следовала кодексу Code as Craft и придерживалась практики эксплуатационной группы Etsy в Интернете с тех пор, как открыла для себя devops-сообщества, но я не считала себя столь профессиональной, чтобы присоединиться к ним.

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

Имея опыт работы специалиста по вызову, доступного 24 часа в сутки и 7 дней в неделю большую часть года, и будучи знакомой с иными сценариями работы, далекими от идеального, я хочу поделиться с читателями книги приемами и методами, которые успешно применяются мной и членами моих групп. С помощью этих методик удалось снизить количество сотрудников, считающих себя «слабым звеном» в своей организации. В большой степени мотивация к написанию этой книги представляла собой возможность поделиться историями с читателями, историями, которые имели ко мне отношение или были рассказаны другими людьми. Это дает возможность делиться знаниями с другими пользователями, учиться и расти как сообщество. Именно devops-сообщество помогло мне занять мое нынешнее место, и эта книга представляет собой лишь один из способов возврата долга с моей стороны.

История Дженнифер

В 2007 году я связалась с руководством Yahoo по поводу позиции, которая относилась «немного к разработке» и «немного к эксплуатации». Речь шла о вакансии старшего сервисного инженера, ответственного за создание и обслуживание мультиарендованного, размещенного на хосте, распределенного и географически реплицированного хранилища данных типа «ключ/значение» под названием Sherpa.

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

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

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

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

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

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

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

Сбои – это ужасно, но они чему-то учат.

– Боб Саттон, инструктор из Stanford Management

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

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

Я была готова к внедрению devops. Для меня ценность devops заключалась не в мантре «разрабатываем X и поддерживаем Y, либо разработка и поддержка», а в том, чтобы делиться историями, решать проблемы, возникающие в производстве, на основе принципов сотрудничества и укреплять ряды сообщества. Открытая среда для совместной работы превратилась в новую систему поддержки, которая укрепила основы устойчивых рабочих практик и способствовала развитию взаимоотношений между людьми.

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

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

Истории, иллюстрирующие devops-практики

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

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

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

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

 

Глава 2. Определение devops

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

Рецепт формирования культуры

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

Уравнение devops

Существует опасность, что движение, которое расценивает себя как новое, будет пытаться охватывать все, что не является старым.

– Ли Рой Бич и др., Naturalistic Decision Making and Related Research Lines

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

Хотя термин devops образован на основе слов «development» (разработка) и «operations» (эксплуатация), принципы devops могут и должны применяться на всех стадиях рабочего процесса, реализуемого в организации. Устойчивый и успешный бизнес представляет собой нечто большее, чем совокупность, состоящую из команд разработчиков и эксплуатации. Если же вы будете ограничиваться исключительно этими командами, вы окажете бизнесу, налаженному в вашей организации, «медвежью услугу».

Использование «devops» в качестве народной модели

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

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

Прежний и новый взгляд

Если в компании складывается практика взаимных обвинений и преследований за совершенные ошибки, формируется атмосфера страха. В результате между сотрудниками компании появятся «стены», препятствующие общению. А теперь представьте себе идеальную среду, в которой все проблемы решаются сообща и расцениваются в качестве возможности для обучения как отдельных людей, так и организации в целом. Профессор Сидни Деккер в своей книге Field Guide to Understanding Human Error характеризует эти ситуации как «прежний взгляд» и «новый взгляд» на человеческие ошибки.

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

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

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

Если вы поделитесь опытом применения devops, то это:

• приведет к увеличению степени прозрачности и доверия в группе;

• поможет вашим коллегам понять, как избежать ошибок, чреватых серьезными потерями;

• предоставит больше времени на решение новых задач, благодаря чему появятся дополнительные инновации.

Как только истории об опыте применения devops станут всеобщим достоянием, они окажут влияние на отрасль в целом. В результате появятся новые возможности и знания, а также станет возможным обмен знаниями.

Devops-пакт

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

Пример пакта

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

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

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

При восхождении используется набор словесных ключей, позволяющих проверить готовность к процессу восхождения. Сначала восходитель спрашивает у напарника: «На страховке?» Напарник отвечает: «На страховке». Затем восходитель говорит: «Подъем!», сигнализируя о готовности к началу восхождения. И наконец, напарник подтверждает осведомленность о готовности восходителя, произнося слово «подъем».

Для обеспечения работоспособности этого пакта применяются следующие принципы:

• общие четко сформулированные цели;

• непрерывное общение;

• динамическая настройка и коррекция понимания.

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

Пример devops-пакта

Представьте себе, что два сотрудника компании Sparkle Corp работают в разных командах. Сотрудник по имени Дженераль является старшим разработчиком, обладает множеством рабочих навыков и работает в компании Sparkle Corp уже два года. Джордж работает в отделе техподдержки, обладает некоторыми рабочими навыками и является новичком в компании Sparkle Corp.

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

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

Как Дженераль, так и Джорджу присуще понимание общих целей:

• внедрение нового инструмента, увеличивающего ценность для заказчиков компании Sparkle Corp;

• поддержка безопасности и доверия при осуществлении взаимного обмена информацией.

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

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

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

 

Глава 3. История devops

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

Разработчик в качестве оператора

Изначально разработчик программ являлся оператором. На исходе Второй мировой войны правительство США обратилось к ведущим математикам с призывом создать «компьютеры». Эти устройства должны были применяться для расчета баллистических таблиц, используемых при стрельбе. На этот призыв откликнулись женщины-математики, и среди них была Джин Бартик. Она пренебрегла возражениями своего преподавателя колледжа, который считал, что решение повторяющихся задач не столь важно, как продолжить семейную традицию и получить классическое образование.

Иногда полезно выслушать совет и сделать по-своему. Джин Бартик оказалась на нужном месте в нужное время и стала одним из первых программистов компьютера ENIAC.

Используя анализ аппаратных и логических схем, Бартик и пять ее коллег-программистов смогли научиться программировать на компьютере ENIAC, и это при полном отсутствии сопровождающей документации. Программирование на этом компьютере, работающем на 18 тысячах радиолампах, осуществлялось путем вращения дисков и изменения кабельных подключений с помощью 40 управляющих панелей.

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

Появление программной инженерии

В 1961 году президент США Джон Кеннеди провозгласил амбициозную лунную программу. В рамках этой программы в течение ближайших десяти лет должен был состояться полет человека на Луну с последующим благополучным возвращением на Землю. Учитывая сжатые сроки и отсутствие специалистов, которые могли бы создать необходимое программное обеспечение, NASA объявило о наборе профессиональных программистов. Проект NASA по разработке ПО возглавила математик из Массачусетского технологического института Маргарет Гамильтон.

Как вспоминает Гамильтон:

Процесс генерирования новых идей превратился в настоящее приключение. Везде царили самоотверженный труд и ответственность. Атмосфера взаимного уважения способствовала комфортной работе. Поскольку процесс разработки ПО носит мистический характер, являясь чем-то вроде «черного ящика», топ-менеджмент предоставил нам полную свободу и оказал абсолютное доверие. Мы должны были найти эффективный способ создания программ, и мы сделали это. Оглядываясь назад, я хочу сказать, что мы были счастливейшими людьми в мире. У нас не было другого выбора, кроме как стать первыми в мире, и не было времени на то, чтобы пребывать в состоянии «чайников» [4] .

Поскольку Гамильтон была известна стремлением к созданию сложного программного обеспечения, ей приписывают создание термина программная инженерия. Она также разработала приоритетные дисплеи, программное обеспечение, предупреждающее астронавтов о наличии информации, которая требует реагирования в режиме реального времени. Маргарет разработала набор правил по сбору требований, один из пунктов которого заключался в обеспечении качества как одного из методов программного инжиниринга. Список методов программной инженерии включал следующие позиции:

• отладка всех отдельных компонентов;

• тестирование отдельных компонентов до этапа сборки;

• интеграционное тестирование.

В 1969 году во время осуществления миссии «Аполлон-11» произошел сбой бортового компьютера из-за большого объема выполняемых вычислений. Команда разработчиков предусмотрела возможность вмешательства астронавтов в процесс управления модулем в обход бортового компьютера. Это позволило Нейлу Армстронгу в критической ситуации взять управление лунным модулем на себя.

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

ПРОБЛЕМЫ, СВЯЗАННЫЕ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ

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

В 1967 году Научный комитет НАТО, в состав которого входили ученые из разных стран и отраслей промышленности, организовал проведение дискуссий, посвященных состоянию программной инженерии. Осенью 1967 года была сформирована исследовательская группа по компьютерным наукам. Цель этой группы заключалась в привлечении внимания к проблемам, связанным с программным обеспечением. Были приглашены 50 экспертов в разных областях, которые в составе трех рабочих групп сосредоточили внимание на разработке, производстве и поддержке программного обеспечения. При этом предпринимались попытки определить, описать и приступить к решению проблем в области программной инженерии.

В 1968 году на конференции НАТО, посвященной программной инженерии, были сформулированы ключевые проблемы программной инженерии, перечисленные в следующем перечне:

• определение и оценка степени успеха;

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

• разработка систем в соответствии с графиком и спецификацией;

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

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

Появление закрытого программного обеспечения и стандартизация

До 1964 года существовала практика создания компьютеров, которые были весьма специфичными и соответствовали требованиям конкретного заказчика. Оборудование и программное обеспечение были не стандартизованы и не взаимозаменяемы. В 1964 году компания IBM анонсировала семейство компьютеров System/360. Компьютеры, входящие в это семейство, имели разные размеры и предназначались для использования в коммерческих и научных целях.

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

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

Сетевая эра

В 1979 году появилась всемирная система групп новостей Usenet, которую создали студенты из Университета Дьюка Том Трескотт и Джим Эллис. Изначально Usenet представляла собой простой сценарий оболочки, который автоматически вызывал разные компьютеры, искал изменения в файлах, находящихся на этих компьютерах, а потом копировал изменения с одного компьютера на другой с помощью набора программ UUCP. Этот набор обеспечивал передачу файлов и выполнение команд на удаленных компьютерах. Эллис выступил с докладом Invitation to a General Access UNIX Network в группе пользователей Unix, известной как USENIX. Это был один из первых и быстро развивающихся способов коммуникации и обмена знаниями между организациями, имеющими компьютеры.

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

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

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

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

Истоки глобального сообщества

В то время как взаимосвязанные сети позволили программистам и ИТ-практикам обмениваться идеями в Интернете, обычные люди также стали искать способы обмена идеями. Начали появляться новые и все более популярные пользовательские группы, предназначенные для обсуждения разных вопросов практиками и пользователями различных технологий. В те времена одной из самых больших пользовательских групп была DECUS (Digital Equipment Computer Users’ Society, Сообщество пользователей цифрового компьютерного оборудования), основанная в 1961 году. В основной состав этой группы входили программисты, создающие или поддерживающие код для компьютеров DEC.

Американское отделение DECUS проводило различные технические конференции и организовывало локальные пользовательские группы в США, тогда как отделения, действующие в других странах, проводили соответствующие мероприятия у себя. Результаты этих конференций и событий начали публиковаться в форме сборников трудов DECUS. Эти сборники были доступны для членов сообщества в качестве средства обмена информацией. Они стимулировали рост общего объема знаний сообщества и усиливали степень сплоченности членов этого сообщества.

КОММЕРЧЕСКИЕ СЕКРЕТЫ И КОНФИДЕНЦИАЛЬНАЯ ИНФОРМАЦИЯ

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

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

Аналогичное сообщество, объединившее в своих рядах системных администраторов, было создано в USENIX. Это сообщество представляло собой группу пользователей со специальными интересами и получило название System Administrators Group (группа системных администраторов). Позднее эта группа называлась SAGE, сейчас же она известна как группа пользователей со специальными интересами LISA (Large Installation System Administration, Администрирование установки больших систем). Эта группа проводит ежегодные конференции под названием «Large Installation System Administration». Кроме того, встречи NSFNET «Regional-Tech» эволюционировали в группу North American Network Operators’ Group (NANOG). Это сообщество специально предназначено для организации сотрудничества между сетевыми администраторами, стремящимися внести свой вклад в улучшение Интернета.

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

Эра приложений и Интернета

Один из первых примеров успешной кооперации в рамках одной организации – суперпопулярный HTTP-сервер Apache (https://httpd.apache.org/ABOUT_APACHE.html), появившийся в 1995 году. Этот сервер был основан на бесплатном http-сервере NCSA HTTPd и разработан студентом Иллинойского университета (Урбана-Шампейн) Робертом Маккулом. Благодаря использованию модульного программного обеспечения Apache любой пользователь может быстро развертывать веб-сервер, выполнив лишь минимальную конфигурацию. Это ознаменовало начало эпохи использования решений с открытым программным кодом. Программы с открытым исходным кодом предоставляют пользователям лицензии на чтение, изменение и распространение исходного кода. Эти программы начинают конкурировать с собственными программными решениями, имеющими закрытый программный код.

Учитывая доступность различных дистрибутивов операционной системы Linux и рост популярности языков написания сценариев, таких как PHP и Perl, возрастающая популярность программ с исходным открытым кодом привела к распространению стека LAMP (Linux, Apache, MySQL и PHP) в качестве средства создания веб-приложений. Система управления реляционными базами данных MySQL, появившаяся в 1995 году, наравне с инструментами написания серверных сценариев PHP позволила разработчикам создавать динамические веб-сайты и приложения. Эти сайты и приложения быстро обновлялись и динамически генерировали контент. Учитывая ту простоту, с которой могли создаваться новые веб-приложения, в конце 1990-х годов отдельным программистам и коллективам приходилось работать быстрее и проявлять большую гибкость, чтобы быть конкурентоспособными.

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

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

Развитие методологий разработки программного обеспечения

В 2001 году в сообществе активных и деятельных приверженцев экстремального программирования и в других подобных сообществах было разослано приглашение принять участие в дискуссии, посвященной разработке программного обеспечения. Экстремальное программирование – это одна из форм гибкой разработки программ, которая более чутко реагировала на изменяющиеся требования, чем предыдущие методологии разработки программного обеспечения, такие как короткие циклы выпуска, интенсивное тестирование и парное программирование. В ответ на это предложение 17 инженеров-программистов собрались в Сноуберде (штат Юта). Они обсудили свои общие ценности, позволяющие включить адаптивность и реагирование на изменения в процесс разработки программного обеспечения с явным выделением человеческого фактора. Эти ценности были изложены в манифесте гибкого программирования, который положил начало движению сторонников гибкого программирования.

В 2004 году программист Алистер Кокберн, являющийся одним из соавторов манифеста гибкого программирования (Agile Manifesto), описал методологию разработки ПО Crystal Clear. Эта методология основана на десятилетнем опыте изучения успешных команд и предназначена для небольших групп разработчиков. Алистер описал три основных метода, используемых в Crystal Clear:

• Быстрая доставка полезного кода, переход от больших и редких развертываний кода к меньшим и более частым развертываниям.

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

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

Эта методология развивалась несколько лет, приобретая все большее влияние. В этот период времени системный администратор Марсель Вегерманн написал эссе, посвященное использованию принципов разработки программного обеспечения Crystal Clear, Scrum и Agile в области системного администрирования. В дополнение к блиц-докладу по теме, в котором были предложены такие идеи, как контроль версий для каталога /etc операционной системы Linux, парное администрирование системы и операционные ретроспективы, в 2008 году Марсель также создал список рассылки Agile System Administration.

Приложения с открытым исходным кодом и собственные услуги

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

В 2006 году компания электронной коммерции Amazon.com, Inc., которая ранее была известна своим сайтом по продаже книг и других товаров, предназначенных для широкого круга потребителей, запустила два сервиса: Amazon Elastic Compute Cloud (EC2) и Amazon Simple Storage Service (S3). Эти сервисы представляли собой первую попытку реализации виртуальных компьютерных экземпляров и виртуального хранилища с помощью собственной службы. В результате пользователи получили доступ к вычислительным ресурсам без предварительных инвестиций в оборудование. Также можно было запрашивать дополнительные ресурсы по мере необходимости. Как и в случае появления компьютеров из семейства System/360, этот сервис был быстро принят пользователями, став стандартом «де факто» благодаря простоте использования, невысоким начальным затратам и гибкости.

По мере роста и развития веб-технологий появлялись новые способы коммуникации и сотрудничества в Интернете. В 2006 году появился онлайновый сетевой сервис Твиттер. Изначально этот сервис применялся пользователями, которые хотели делиться информацией, представленной в сокращенном формате. Эта информация использовалась в качестве средства привлечения внимания как простыми пользователями, так и знаменитостями. Но в 2007-м популярность Твиттера буквально взлетела до небес благодаря конференции South by Southwest Interactive (SXSW). Эта конференция транслировалась в режиме реального времени с помощью твитов на экранах, установленных в холлах.

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

Гибкая инфраструктура

На конференции Agile 2008, проходящей в Торонто, системный администратор и ИТ-консультант Патрик Дебуа в своем докладе «Agile Operations and Infrastructure: How Infra-gile are You?» рассказывал о включении методологии Scrum в эксплуатационную работу. Патрик работал с командами по разработке и эксплуатации над проектом по тестированию передачи информации в центр обработки данных. И он предпочитал один день работать в команде разработчиков, а на следующий день – в эксплуатационной команде. Если же переключаться между выполнением двух задач в течение одного дня, теряется примерно 20 % от обычной производительности.

На этой же конференции бывший программист Эндрю Клэй Шафер, который начал проявлять большой интерес к связанным с ИТ проблемам, предложил провести сеанс гибкой инфраструктуры (Agile Infrastructure). Эндрю почему-то считал, что предложенная им тема никого не заинтересует, поэтому пропустил собственноручно объявленный сеанс. Когда Патрик увидел это, он понял, что кроме него есть другие люди, интересующиеся гибким системным администрированием. После этого Патрик связался с Эндрю и предложил ему подробнее обсудить данную концепцию.

Отдельные компании начали не только добиваться больших успехов во внедрении процессов, позволивших им идти в ногу с постоянно ускоряющимися изменениями Интернета, но и делиться своим опытом в сообществах. Эти сообщества формировались вокруг таких популярных конференций, как O’Reilly Velocity Conference (http://conferences.oreilly.com/velocity).

Одной из таких компаний является Flickr, популярное интернет-сообщество фотографов. После приобретения компанией Yahoo в 2005 году Flickr потребовалось переместить все сервисы и данные из Канады в США. Джон Оллспоу, энтузиаст в области эксплуатации веб-приложений с многолетним опытом работы по техобслуживанию систем, присоединился к компании Flickr в качестве ведущего инженера по эксплуатации. Его цель заключалась в оказании помощи при масштабировании нового проекта по миграции данных. В 2007 году к группе разработчиков Flickr присоединился Пол Хэммонд. В 2008 году Пол стал техническим директором Flickr, возглавив отдел разработки ПО вместе с Оллспоу.

На конференции Velocity Santa Clara 2009 Хэммонд и Оллспоу совместно представили доклад «10+ Deploys per Day: Dev and Ops Cooperation at Flickr». В этом докладе они описали революционные изменения, которые позволят команде быстро продвигаться вперед. Они не предлагали ломать барьеры между сотрудниками либо формировать большое профессиональное и культурное движение. Они просто делились своим опытом совместной работы в Flickr, который серьезно отличался от опыта предыдущей работы Оллспоу в компании Friendster, где брали верх эмоции и моральное давление, а сотрудничество между членами команды практически отсутствовало.

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

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

Конференции devopsdays

Не ограничивайтесь простым «нет», относитесь уважительно к проблемам других людей… #velocityconf #devops #workingtogether

– Эндрю Клэй Шафер (@littleidea)

Этот твит, созданный 23 июня 2009 года Эндрю Клэй Шафером, побудил Патрика Дебуа пожаловаться в Твиттере на то, что он не сможет посетить лично ежегодную конференцию Velocity. Прис Нэсрат, который в то время выполнял обязанности ведущего системного интегратора в Guardian, отправил ответное сообщение в Твиттере. В этом сообщении он спросил о том, почему бы не организовать собственную конференцию Velocity в Бельгии. Вдохновленный этими словами Патрик поступил практически в полном соответствии с данным советом. Он организовал локальную конференцию, на которой разработчики, системные администраторы, системные программисты и другие специалисты, работающие в этой области, могли обмениваться информацией. В октябре этого же года в Генте прошла первая конференция devopsdays. Двумя неделями позже Дебуа писал следующее:

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

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

Текущее состояние devops

За шесть лет, прошедших с момента проведения первых devopsdays в Бельгии (под руководством Патрика Дебуа), движения devops ушло далеко вперед. В отчете «2015 State of Devops Report» (https://puppet.com/resources/white-paper/2015-state-devops-report), опубликованном компанией Puppet, отмечается, что компании, использующие devops, имеют лучшие показатели, чем компании, которые не применяют devops. На убедительном языке цифр продемонстрированы факты, о которых многие люди догадывались на интуитивном уровне. Отдельные сотрудники и команды, которые эффективно сотрудничают друг с другом, работают лучше, чем группа сотрудников, находящихся в одной комнате и не умеющих работать вместе. Высокоэффективные devops-организации чаще развертывают код, реже допускают ошибки, быстрее восстанавливаются после сбоев, а сотрудники этих организаций – более счастливые люди.

Количество конференций devopsdays выросло с одной в 2009 году до двадцати двух в 2015 году (во всем мире). Каждый год знаменуется новыми событиями devopsdays, проходящими в разных городах и странах. Эти конференции не связаны с такими центрами развития технологий, как Силиконовая долина или Нью-Йорк. Существуют десятки локальных групп, объединяющих в своих рядах тысячи членов, которые буквально разбросаны по всему земному шару, не говоря уже о множестве бесед на эту тему, происходящих ежедневно в Твиттере.

Выводы

Размышляя о нашей истории, мы видим склонность к концентрации на результатах, а не на людях и процессах. Многие вещи были позаимствованы из презентации Джона Оллспоу и Пола Хэммонда «10+ Deploys a Day», в которой подчеркивается, что важно развертывать более 10 программ в день. Ну а подзаголовок «Dev & Ops Cooperation at Flickr» многие просто не замечали.

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

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

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

 

Глава 4. Основные термины и концепции

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

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

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

Методологии, применяемые при разработке программного обеспечения

Процесс разбиения деятельности по разработке ПО на отдельные фазы называется методологией разработки программного обеспечения.

Обычно выделяются следующие фазы:

• спецификация конечных результатов работы или артефактов;

• разработка и верификация кода в соответствии со спецификацией;

• развертывание кода в финальной потребительской или производственной среде.

Рассмотрение абсолютно всех методологий, применяемых при разработке программного обеспечения, выходит за рамки этой главы, поэтому коснемся лишь тех из них, которые в какой-то степени связаны с devops.

Каскад

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

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

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

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

Рис. 4.1. Каскадная модель

Гибкая методология разработки ПО

Эпитет «гибкий» (agile) относится к целой группе методологий, применяемых при разработке программного обеспечения. Эти методологии являются более «легкими» и гибкими по сравнению с более ранними методиками (например, с каскадной моделью). В 2001 году был опубликован Agile-манифест (см. главу 2), в котором были изложены основные принципы гибкого программирования.

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

• отдельных людей и взаимодействий выше ценности процессов и инструментов;

• рабочей документации выше ценности исчерпывающей документации;

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

• реагирования на изменение ситуации выше ценности точного следования плану.

Как видите, компоненты, находящиеся в левой части списка, оцениваются выше компонентов, расположенных в правой части списка.

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

ЯВЛЯЕТСЯ ЛИ DEVOPS ПРОСТО ОЧЕРЕДНОЙ ГИБКОЙ МЕТОДОЛОГИЕЙ?

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

Scrum

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

Одна из ключевых особенностей методологии Scrum – проведение ежедневных Scrum-встреч либо ежедневных собраний, на которых члены команды как можно быстрее дают ответы на следующие три вопроса:

• Что из того, что я сделал, помогло команде достичь целей спринта?

• Что я планирую сделать сегодня, чтобы помочь команде достичь этих целей?

• Что делать в том случае, когда какое-либо препятствие мешает мне или команде достичь целей?

На ежедневных встречах, проходящих по утрам, scrum-мастер помогает сотрудникам с повесткой дня, а также способствует устранению проблем. Роль scrum-мастера включает такие обязанности, как оказание помощи команде в самоорганизации, координирование усилий, прилагаемых в процессе работы, устранение препятствий в работе. В результате команда будет продолжать добиваться успеха, а также привлекать владельцев проекта и заинтересованные стороны. В результате вырабатывается общее понимание того, что означает «сделано», и критериев оценки прогресса. Принципы Scrum часто неформально применяются во многих современных методологиях разработки программного обеспечения.

Методологии эксплуатации

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

ITIL

Методология ITIL, ранее известная как Information Technology Infrastructure Library (Библиотека инфраструктуры информационных технологий), представляет собой набор методов, предназначенных для управления ИТ-услугами. Эта методология изложена в пяти книгах. В этих книгах описываются способы осуществления процессов, процедур и задач, а также составления контрольных списков, необходимых при эксплуатации. Эта методология позволяет установить соответствие разработанных программ сформулированным критериям, а также оценить прогресс на пути к достижению целей. Методология ITIL сформировалась на основе практических методик, применявшихся в 1980-х годах во многих ИТ-организациях.

Британское центральное компьютерное и телекоммуникационное агентство разработало набор рекомендаций по стандартизации этих практических методик. Первая публикация методологии ITIL имела место в 1989 году, а последняя – в 2011 году. За это время она эволюционировала с пяти основных разделов до многотомного собрания и теперь включает описание стратегии техобслуживания, проектирования услуг, перехода к услугам, выполнения услуг и непрерывного улучшения услуг.

ИТ-аналитик и консультант Стивен Манн отмечает, что наряду со многими преимуществами, которые дает ITIL-стандартизация и наличие более 1,5 млн ITIL-сертифицированных специалистов во всем мире, существуют и проблемы. Одна из основных проблем – недостаточное внимание к отдельным практическим областям. Согласно утверждению Манна, методология ITIL чаще является реактивной, а не проактивной, поэтому организациям, использующим ITIL, рекомендуется уделить больше внимания проактивному планированию и заказчикам.

COBIT

Методология COBIT (Control Objectives for Information and Related Technology; Задачи управления для информационных и смежных технологий) представляет собой каркас ISACA, предназначенный для управления информацией и технологиями. Эта методология была впервые обнародована в 1996 году. Основной принцип COBIT заключается в согласовании бизнес-целей с ИТ-целями.

Методология COBIT основана на следующих пяти принципах:

• удовлетворение нужд заинтересованных сторон;

• полный охват предприятия;

• применение простого интегрированного каркаса;

• обеспечение целостного подхода;

• отделение управления от менеджмента.

Системные методологии

Некоторые методики сосредоточиваются на системах в целом, а не на более конкретных областях, таких как разработка программного обеспечения либо техобслуживание компьютеров. Навыки системного мышления критически важны для тех, кто работает со сложными системами, такими как многие современные программы. Читателям, желающим получить представление о системном мышлении в целом, рекомендуется обратиться к книгам Thinking in Systems (Donella Meadows) и How Complex Systems Fail (Dr. Richard Cook).

Бережливость

По итогам пятилетнего изучения тенденций в развитии автомобильной промышленности и производственной системы «Тойоты» (TPS) Джеймс П. Вомак, Дэниел Т. Джонс и Дэниел Рус ввели термин «бережливое производство». Вомак и Джонс выработали следующие пять принципов бережливого мышления:

• ценность;

• процесс создания ценности;

• поток;

• вытягивание;

• совершенствование.

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

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

В бережливых методологиях разработки ПО и оказания ИТ-услуг появляются следующие отходы:

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

• задержки при общении;

• замедленный отклик приложения;

• бюрократические процессы.

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

• частично выполненная работа;

• дополнительные возможности;

• переучивание;

• ненужные передачи обслуживания;

• переключение между задачами;

• задержки;

• дефекты.

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

Концепции разработки, релиза и развертывания ПО

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

Контроль версий

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

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

Разработка через тестирование

При выполнении разработки через тестирование (Test Driven Development; TDD) разработчик начинает с написания проверяемого функционал-теста, применяемого для проверки функциональности нового кода. После этого создается сам код, затем начинается тестирование этого кода. Благодаря тестированию гарантируется безупречная работа новых функций, а также становится более очевидным назначение кода.

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

Развертывание приложений

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

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

Непрерывная интеграция

Непрерывная интеграция (Continuous Integration; CI) – это процесс интегрирования нового кода, написанного разработчиками, в основной код или ветку «мастер», осуществляемый в течение рабочего дня. Этот подход отличается от методики, в соответствии с которой разработчики работают с независимыми ветками неделями или месяцами, выполняя слияние кода в основную ветку только после полного завершения работы над проектом. Длительные периоды времени между слияниями приводят к тому, что в код вносится очень много изменений, что повышает вероятность появления ошибок. При работе с большими пакетами изменений гораздо труднее изолировать и идентифицировать фрагмент кода, который вызвал сбой. Если же используются небольшие наборы изменений, для которых часто выполняется слияние, поиск ошибок значительно упрощается. Постарайтесь избежать проблем, связанных с интеграцией, которые неизбежно появятся при слиянии больших наборов изменений.

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

Непрерывная доставка

Методология непрерывной доставки (Continuous Delivery; CD) представляет собой набор общих принципов по разработке программного обеспечения, которые позволяют часто создавать новые релизы программного обеспечения с привлечением автоматизированного тестирования и непрерывной интеграции. Эта методология тесно связана с непрерывной интеграцией и часто воспринимается как расширение непрерывной интеграции. Это позволяет убедиться в том, что новые изменения могут быть интегрированы без обращения к автоматическим тестам. В случае непрерывной доставки обеспечивается развертывание изменений.

Непрерывное развертывание

Непрерывное развертывание (Continuous deployment; CD) – это процесс развертывания изменений при разработке путем создания тестов и проверок, позволяющих свести риск ошибок к минимуму. В то время как непрерывная доставка позволяет гарантировать развертывание новых изменений, непрерывное развертывание означает, что выполняется развертывание изменений в производственном цикле.

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

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

С тех пор как методологии непрерывной доставки и непрерывного развертывания завоевали популярность в среде разработчиков, многократно обсуждались различия между ними. Джез Хамбл, автор концепции непрерывной доставки, определил эту методологию как общий набор принципов, который может применяться к произвольному проекту разработки ПО, включая Интернет вещей (IoT, internet of things) и внедренное программное обеспечение, в то время как непрерывное развертывание относится к веб-приложениям. Чтобы получить больше сведений о различиях между этими двумя концепциями, обратитесь к дополнительным ресурсам.

Минимально жизнеспособный продукт

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

Минимально жизнеспособный продукт (Minimum Viable Product; MVP) – это прототип готового продукта, который можно проверить на соответствие требованиям с приложением минимальных усилий. Создание минимально жизнеспособного продукта целесообразно в тех случаях, когда высока вероятность внесения серьезных изменений в готовый продукт. При этом вы сэкономите значительный объем времени и усилий. В минимально жизнеспособном продукте отключены некоторые второстепенные функции или расширенные настройки, которые не нужны для оценки базовых концепций, либо делается упор на функциях, а не на дизайне или производительности. Подобно методологиям бережливой разработки и непрерывной доставки, минимально жизнеспособный продукт позволяет быстрее осуществлять рабочие итерации и улучшать продукт, уменьшая затраты и количество отходов.

Концепции, относящиеся к инфраструктуре

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

Управление конфигурацией

В 1950-х годах Министерство обороны США в качестве технической дисциплины менеджмента разработало методологию управления конфигурацией (Configuration Management; CM). Позднее эта методология была принята во многих других областях. Управление конфигурацией – это процесс установления и поддержки согласованности между функциональными и физическими атрибутами, а также управление производительностью на протяжении всего жизненного цикла. Эта методология включает политики, процессы, документацию и инструменты, требуемые для реализации согласованной производительности, функциональности и атрибутов.

Различные организации и органы по стандартизации, такие как ITIL, IEEE (Institute of Electrical and Electronics Engineers, Институт инженеров по электротехнике и электронике), ISO (International Organization for Standardization, Международная организация по стандартизации) и SEI (Software Engineering Institute, Институт программной инженерии) предложили стандарт управления конфигурированием, который используется в индустрии разработки программного обеспечения. Как и в случае с другими народными моделями, появление подобного стандарта привело к некоторой путанице с применяемыми ранее определениями.

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

Облачные вычисления

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

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

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

Автоматизация инфраструктуры

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

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

Управление артефактами

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

В общем случае хранилище артефактов может выступать в качестве:

• центрального пункта управления бинарными файлами и зависимостями;

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

• интегрированного хранилища, предназначенного для продвижения разработанного в организации программного обеспечения.

Контейнеры

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

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

Культурные концепции

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

Ретроспектива

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

Что произошло?

Каковы были цели проекта и что мы получили после его завершения.

Что было сделано хорошо?

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

Что пошло не так?

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

Постмортем

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

Что случилось?

Хронология инцидента от начала до конца, часто вместе с журналами общения или системных ошибок.

Опрос

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

Что нужно исправить?

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

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

Безупречность

Концепция безупречности является противоположной культуре, основанной на обвинениях. Несмотря на то что эта концепция обсуждалась уже несколько лет, в основном Сидни Деккером и его сторонниками, настоящую известность она получила после появления поста Джона Оллспоу, посвященного постмортемам, не содержащим упреков (https://codeascraft.com/2012/05/22/blameless-postmortems/). Суть этого поста заключается в том, что ретроспектива инцидента будет более эффективной в случае акцента на обучении, а не на наказании.

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

Организационное обучение

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

– Karen E. Watkins and Victoria J. Marsick, Partners for Learning

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

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

Выводы

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

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

 

Глава 5. Заблуждения и антишаблоны, относящиеся к devops

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

Общие заблуждения, связанные с devops

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

Devops – это лишь разработчики и системные администраторы

Несмотря на то что название «devops» произошло от слов development (разработка) и operations (эксплуатация), оно скорее является напоминанием об источниках происхождения движения devops, чем строгим определением. И хотя на конференциях devopsdays звучит слоган «Конференция, которая объединяет разработку и эксплуатацию», на самом деле концепции и идеи devops охватывают все роли в организации. Не существует единого исчерпывающего списка, регламентирующего, как и какие люди и команды должны быть вовлечены в движение devops. Также отсутствует единый универсальный подход к внедрению devops.

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

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

Devops – это команда

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

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

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

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

Devops как профессия

Толкование профессии «devops-инженер» является неоднозначным. Некоторые из толкований приведены в следующем списке:

• системный администратор, который знает, как писать программный код;

• разработчик ПО, владеющий навыками системного администрирования;

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

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

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

Несмотря на все, что сказано выше, должность «devops-инженер» действительно существует. В соответствии с данными, опубликованными в отчете 2015 DevOps Salary Report от Puppet (https://puppet.com/resources/white-paper/2015-devops-salary-report), у инженеров, в названии должности которых присутствует слово «devops», зарплата выше, чем у обычных системных администраторов. Конечно, эти оценки весьма приблизительны, поскольку в разных организациях devops-инженеры исполняют самые разные роли. Скажите на милость, кто бы отказался от звания devops-инженера за прибавку в 10 тыс. долларов к зарплате?

В отчете 2015 DevOps Salary Report отмечается, что «большинство devops-инженеров работают более 50 часов в неделю, системные инженеры работают от 41 до 50 часов в неделю, а системные администраторы работают менее 40 часов в неделю». Как видите, никто даром деньги не платит. Если вы получаете высокую зарплату, будьте готовы пожертвовать своим личным временем и здоровьем.

Методология devops связана только с веб-стартапами

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

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

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

Devops нужно сертифицировать

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

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

Благодаря devops можно сократить персонал

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

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

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

Не существует единственно верного пути внедрения devops

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

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

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

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

Для внедрения devops нужно X недель/месяцев

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

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

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

Методология devops – это лишь инструменты

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

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

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

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

Методология devops эквивалентна автоматизации

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

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

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

Рис. 5.1. Карикатура на потраченное и сэкономленное время согласно представлению карикатуриста из XKCD (https://xkcd.com/ 1205); изначально была опубликована со следующим текстом: «Не забывайте о том, что на поиск диаграммы, которая позволит узнать, сколько вы сэкономите, тратится время. Также вы тратите время на чтение напоминания о потраченном времени. И тратите время на выяснение разных фактов. Помните о том, что вы тратите секунды вашей жизни на выполнение разных действий, и делаете это сейчас»

РАННИЕ ПРИМЕРЫ АВТОМАТИЗАЦИИ В АВИАЦИИ

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

В июле 2013 года рейс 214 компании Asiana Airlines врезался в дамбу в международном аэропорту Сан-Франциско. В результате этого авиационного происшествия получили смертельные травмы 3 человека. В ходе расследования этого инцидента, проводимого Национальным советом по безопасности на транспорте (National Transportation Safety Board, NTSB), был выявлен ряд причин, способствующих катастрофе. Среди этих причин – недостаточный контроль скорости воздушного судна из-за чрезмерной зависимости от автоматизированных систем, показания которых не всегда корректно интерпретировались пилотами.

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

Джеймс Рисон, Managing the Risks of Organizational Accidents

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

Методология devops вышла из моды

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

Одно из основных различий между devops и такими методологиями, как ITIL и гибкая разработка (Agile), заключается в том, что последние имеют строгие определения, им присущ постепенно добавляемый контент. С другой стороны, devops – это движение, основанное на историях и идеях, которыми делятся отдельные люди, команды и организации. Это движение выливается в повторяющиеся беседы, эволюцию процессов и идей, которые приводят к росту и изменениям организаций.

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

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

Движение devops объединило эти идеи и смогло достичь значимого успеха (http://bit.ly/2015-state-of-devops). Обобщение и использование эффективных методик devops приведет к росту и эволюции инструментов, технологий и процессов в вашей организации.

Антишаблоны devops

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

Культура, основанная на обвинениях

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

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

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

Барьеры

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

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

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

Анализ первопричин

Анализ первопричин (Root Cause Analysis; RCA) – это метод идентификации причин возникших событий либо опасных ситуаций и выработки комплекса мер, направленных на предотвращение рецидивов. Это повторяющийся процесс, который продолжается до тех пор, пока не будут идентифицированы все организационные факторы либо пока не будут исчерпаны все данные. Организационный фактор – это фактор, который осуществляет контроль над системой на любом этапе жизненного цикла: проектирование, разработка, тестирование, техническое обслуживание, эксплуатация и списание.

Один из методов идентификации первопричин известен под названием «5 почему». При использовании этого способа вопросы «почему» задаются до тех пор, пока не будут идентифицированы основные причины. При этом требуется, чтобы лица, отвечающие на вопрос «почему», располагали объемом информации, достаточным для ответа на вопрос должным образом. Второй, более систематический подход заключается в создании диаграммы Ишикавы. Разработанная в 1968 году Каору Ишикавой, эта причинно-следственная диаграмма помогает командам визуализировать и группировать первопричины в основные категории, чтобы идентифицировать причины изменчивости, выявлять взаимосвязи между источниками и обеспечивать понимание процесса.

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

Человеческие ошибки

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

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

Выводы

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

 

Глава 6. Четыре столпа devops

По мнению Патрика Дебуа, devops является чисто человеческой проблемой (http://bit.ly/debois-devops-culture). Это означает, что в каждой организации формируется собственная devops-культура, которая является уникальной для людей, принимающих в ней участие. Хотя и не существует универсального «единственно верного» способа внедрения devops во всех организациях, мы идентифицировали четыре общих компонента, с которыми придется иметь дело команде или организации, выделяющей время и ресурсы на внедрение devops.

Внедрение эффективных devops-методик зиждется на следующих четырех столпах:

• сотрудничество;

• близость;

• инструменты;

• масштабирование.

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

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

Сотрудничество

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

Близость

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

Инструменты

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

Масштабирование

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

Выводы

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