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