Глава 3. История devops
55
USENIX. Это был один из первых и быстро развивающихся способов коммуника- ции и обмена знаниями между организациями, имеющими компьютеры.
Хотя этот инструмент способствовал обмену знаниями между университетами и кор- порациями, в те времена многие детали, связанные с деятельностью компаний, были засекречены. Было не принято обсуждать проблемы за стенами офиса компании, поскольку подобная информация рассматривалась как конкурентное преимущество.
На основе подобных сведений конкуренты могли делать выводы о неэффективности компании. Это привело к появлению барьеров на пути к сотрудничеству и к ограни- чению эффективности доступных коммуникационных каналов. Подобная культурная изоляция приводила к появлению сложностей на пути к росту компаний.
Появление все более сложных систем, в свою очередь, привело к неизбежности специализации навыков и к распределению ролей. Подобные роли включали сис- темных администраторов, специализирующихся в области управления системами и минимизирующих затраты на поддержку систем, а также инженеров-програм- мистов, которые специализировались на создании новых продуктов и возможно- стей для удовлетворения вновь возникающих потребностей. Также завершилась изоляция других, более специализированных групп, таких как сетевой операцион- ный центр, отдел обеспечения качества, отдел безопасности, отдел поддержки баз данных и хранилищ данных.
Подобная ситуация привела к формированию институционной Вавилонской башни, население которой в силу разных причин говорило на разных языках.
К еще большему разделению привели специфические проблемы, касающиеся оборудования и программного обеспечения. Теперь уже разработчикам не прихо- дится отслеживать «синие экраны смерти», сопровождающие «падение» системы, или подвергаться гневу неудовлетворенных пользователей. Крен в сторону язы- ков высокого уровня, наметившийся в программировании, означал, что процесс разработки ПО стал более абстрактным, все сильнее отдаляясь от оборудования и системных инженеров прошлого.
В своем стремлении выполнять упреждающие действия и предотвращать сбои в об- служивании системные администраторы начали документировать наборы действий, необходимых для ручного выполнения рутинных операций. Системные админист- раторы позаимствовали идею «анализа первопричин» из методики всеобщего управ- ления качеством. Частично это способствовало привлечению дополнительного внимания и усилий, что позволило минимизировать риск неудачи. Недостаточная степень прозрачности и плохо реализованное управление изменениями ведут к ро- сту энтропии, с которой все чаще и чаще приходится иметь дело инженерам.
Истоки глобального сообщества
В то время как взаимосвязанные сети позволили программистам и ИТ-практикам обмениваться идеями в Интернете, обычные люди также стали искать способы об- мена идеями. Начали появляться новые и все более популярные пользовательские
56
Часть I. Основы devops группы, предназначенные для обсуждения разных вопросов практиками и поль- зователями различных технологий. В те времена одной из самых больших поль- зовательских групп была DECUS (Digital Equipment Computer Users’ Society,
Сообщество пользователей цифрового компьютерного оборудования), основанная в 1961 году. В основной состав этой группы входили программисты, создающие или поддерживающие код для компьютеров DEC.
Американское отделение DECUS проводило различные технические конференции и организовывало локальные пользовательские группы в США, тогда как отделе- ния, действующие в других странах, проводили соответствующие мероприятия у себя. Результаты этих конференций и событий начали публиковаться в форме сборников трудов DECUS. Эти сборники были доступны для членов сообщества в качестве средства обмена информацией. Они стимулировали рост общего объема знаний сообщества и усиливали степень сплоченности членов этого сообщества.
КОММЕРЧЕСКИЕ СЕКРЕТЫ И КОНФИДЕНЦИАЛЬНАЯ ИНФОРМАЦИЯ
Информация, которая неизвестна широкой публике, является засекречен- ной. Это делается для обеспечения экономических или бизнес-преимуществ.
Подобные закрытые сведения расцениваются как коммерческий секрет. Ин- формация, которая является собственностью компании, либо информация, на использование которой компания имеет эксклюзивные права, считается кон- фиденциальной. Примеры конфиденциальной информации компании – про- граммное обеспечение, процессы, методы, структура зарплаты, организаци- онная структура и списки заказчиков. Например, исходный код собственного программного обеспечения обычно недоступен для конечных пользователей.
Все коммерческие секреты являются конфиденциальными, но далеко не вся конфиденциальная информация является секретной.
В дополнение к изменениям в культуре, в промышленности на засекречен- ность информации оказывают влияние коммерциализация и затраты на при- обретение знаний и технологий.
Аналогичное сообщество, объединившее в своих рядах системных администрато- ров, было создано в USENIX. Это сообщество представляло собой группу пользо- вателей со специальными интересами и получило название System Administrators
Group (группа системных администраторов). Позднее эта группа называлась
SAGE, сейчас же она известна как группа пользователей со специальными ин- тересами LISA (Large Installation System Administration, Администрирование установки больших систем). Эта группа проводит ежегодные конференции под на- званием «Large Installation System Administration»
1
. Кроме того, встречи NSFNET
«Regional-Tech» эволюционировали в группу North American Network Operators’
1
Согласно анонсу от USENIX, группа LISA будет расформирована в конце 2016 года. Более подробные сведения по этой теме можно найти на сайте https://www.usenix.org/blog/refocusing-
lisa-community.
Глава 3. История devops
57
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-х годов отдельным программистам и коллективам приходилось рабо- тать быстрее и проявлять большую гибкость, чтобы быть конкурентоспособными.
Это было время тоски и разочарования для программистов и системных админи- страторов. Некоторые из системных администраторов являлись представителями
58
Часть I. Основы devops традиционной культуры, суть которой заключалась в ключевых фразах «нет» и «очень важно для сохранения стабильности». В 1992 году Симон Траваглия начал публиковать в Usenet серию статей под общим названием «Чертов ублюдок оператор». Эти статьи были посвящены мошеннику сисадмину, который вымещал свое разочарование и гнев на пользователях. И нашлись сисадмины, недовольные своей работой, которые начали подражать герою этих публикаций, часто в ущерб другим пользователям.
В процессе разработки программного обеспечения господствовали две точки зрения, выраженные следующими фразами: «критически важно выполнить эти изменения» и «я не хочу знать, как это делать, поскольку у меня ничего не полу- чается». В некоторых средах разработки это побуждало разработчиков рисковать стабильностью системы в процессе поиска незадокументированных способов об- хода установившихся процессов для достижения собственных целей. Это, в свою очередь, вело к дополнительным массовым чисткам и к росту убежденности в том, что изменения являются крайне рискованным делом. Те же единицы, которые пытались внести изменения в общие процессы, часто «застревали в трясине» авторитетных мнений экспертов в предметной области и блокировались на этапе технической поддержки.
Развитие методологий разработки
программного обеспечения
В 2001 году в сообществе активных и деятельных приверженцев экстремального программирования и в других подобных сообществах было разослано приглаше- ние принять участие в дискуссии, посвященной разработке программного обеспе- чения. Экстремальное программирование — это одна из форм гибкой разработки программ, которая более чутко реагировала на изменяющиеся требования, чем предыдущие методологии разработки программного обеспечения, такие как ко- роткие циклы выпуска, интенсивное тестирование и парное программирование.
В ответ на это предложение 17 инженеров-программистов собрались в Сноуберде
(штат Юта). Они обсудили свои общие ценности, позволяющие включить адап- тивность и реагирование на изменения в процесс разработки программного обес- печения с явным выделением человеческого фактора. Эти ценности были изложе- ны в манифесте гибкого программирования, который положил начало движению сторонников гибкого программирования.
В 2004 году программист Алистер Кокберн, являющийся одним из соавторов манифеста гибкого программирования (Agile Manifesto), описал методологию разработки ПО Crystal Clear
1
. Эта методология основана на десятилетнем опыте
1
Alistair Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered
Methodology for Small Teams (Boston: Addison Wesley, 2004).
Глава 3. История devops
59
изучения успешных команд и предназначена для небольших групп разработчиков.
Алистер описал три основных метода, используемых в 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). Эти сервисы представляли собой первую попытку реализации виртуальных компьютерных экземпляров