Глава 3. История devops. Чтобы лучше понять причины, которые привели к зарождению и развитию движения devops, нужно рассмотреть историю разработки ПО, а также повторяющиеся паттерны и идеи, применяемые в этой области. Вооруженные этими знаниями, мы можем представить, где находимся в данный момент. Мы осознаем, каким образом с помощью эффективных devops-способов можно разорвать порочный круг расширения специализации, приводящий к созданию изолированных сред и девальвации конкретных ролей. Разработчик в качестве оператора. Изначально разработчик программ являлся оператором. На исходе Второй мировой войны правительство США обратилось к ведущим математикам с призывом создать «компьютеры». Эти устройства должны были применяться для расчета баллистических таблиц, используемых при стрельбе. На этот призыв откликнулись женщины-математики, и среди них была Джин Бартик. Она пренебрегла возражениями своего преподавателя колледжа, который считал, что решение повторяющихся задач не столь важно, как продолжить семейную традицию и получить классическое образование. Иногда полезно выслушать совет и сделать по-своему. Джин Бартик оказалась на нужном месте в нужное время и стала одним из первых программистов компьютера ENIAC. Используя анализ аппаратных и логических схем, Бартик и пять ее коллег-программистов смогли научиться программировать на компьютере ENIAC, и это при полном отсутствии сопровождающей документации. Программирование на этом компьютере, работающем на 18 тысячах радиолампах, осуществлялось путем вращения дисков и изменения кабельных подключений с помощью 40 управляющих панелей. В те времена для обеспечения работы компьютеров вместо программирования использовалась аппаратная инженерия. В случае возникновения проблем инженеры заявляли о том, что причина появления проблем заключается не в машине, а в операторе. Программисты несли на себе бремя ответственности за управление и эксплуатацию компьютеров. Им приходилось заменять предохранители и кабели, а также устранять синтаксические ошибки в программах. Появление программной инженерии. В 1961 году президент США Джон Кеннеди провозгласил амбициозную лунную программу. В рамках этой программы в течение ближайших десяти лет должен был состояться полет человека на Луну с последующим благополучным возвращением на Землю. Учитывая сжатые сроки и отсутствие специалистов, которые могли бы создать необходимое программное обеспечение, NASA объявило о наборе профессиональных программистов. Проект NASA по разработке ПО возглавила математик из Массачусетского технологического института Маргарет Гамильтон[3]. Как вспоминает Гамильтон: Процесс генерирования новых идей превратился в настоящее приключение. Везде царили самоотверженный труд и ответственность. Атмосфера взаимного уважения способствовала комфортной работе. Поскольку процесс разработки ПО носит мистический характер, являясь чем-то вроде «черного ящика», топ-менеджмент предоставил нам полную свободу и оказал абсолютное доверие. Мы должны были найти эффективный способ создания программ, и мы сделали это. Оглядываясь назад, я хочу сказать, что мы были счастливейшими людьми в мире. У нас не было другого выбора, кроме как стать первыми в мире, и не было времени на то, чтобы пребывать в состоянии «чайников»[4]. Поскольку Гамильтон была известна стремлением к созданию сложного программного обеспечения, ей приписывают создание термина программная инженерия. Она также разработала приоритетные дисплеи, программное обеспечение, предупреждающее астронавтов о наличии информации, которая требует реагирования в режиме реального времени. Маргарет разработала набор правил по сбору требований, один из пунктов которого заключался в обеспечении качества как одного из методов программного инжиниринга. Список методов программной инженерии включал следующие позиции: • отладка всех отдельных компонентов; • тестирование отдельных компонентов до этапа сборки; • интеграционное тестирование. В 1969 году во время осуществления миссии «Аполлон-11» произошел сбой бортового компьютера из-за большого объема выполняемых вычислений. Команда разработчиков предусмотрела возможность вмешательства астронавтов в процесс управления модулем в обход бортового компьютера. Это позволило Нейлу Армстронгу в критической ситуации взять управление лунным модулем на себя. Благодаря свободе и доверию, предоставленным менеджерами группе инженеров-разработчиков ПО, а также взаимному уважению, царившему в группе разработчиков, стало возможным создание программного обеспечения, способствующего достижению величайших технологических успехов, таких как высадка Нейла Армстронга на Луну. Если бы в среде разработки ПО отсутствовало взаимное доверие, вряд ли была бы реализована критически важная функция ручного управления лунным модулем. Если бы не эта функция, вряд ли лунная эпопея завершилась бы благополучно. ПРОБЛЕМЫ, СВЯЗАННЫЕ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ. В 60-е годы ХХ века космические полеты были не единственной областью, в которой применялось программное обеспечение. По мере того как оборудование стало более доступным, начало вызывать тревогу постоянно усложняющееся программное обеспечение. Эта сложность не соответствовала стандартам, принятым в других инженерных дисциплинах. Быстрый рост сложности систем и возрастающая зависимость от них начали беспокоить пользователей. В 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[5] в группе пользователей 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»[6]. Кроме того, встречи 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[7]. Эта методология основана на десятилетнем опыте изучения успешных команд и предназначена для небольших групп разработчиков. Алистер описал три основных метода, используемых в 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 % от обычной производительности[8]. На этой же конференции бывший программист Эндрю Клэй Шафер, который начал проявлять большой интерес к связанным с ИТ проблемам, предложил провести сеанс гибкой инфраструктуры (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 изменился способ производства. Произошло переключение внимания на людей и процессы, начали поощряться сотрудничество и кооперация, исчезла конкуренция среди специалистов.