В интернете есть уже тысячи споров о том, чем является DevOps. Мы решили подойти иначе: не навязывать вам точку зрения «понимайте это слово так-то», а оглянуться в прошлое и проследить историю его возникновения. Что привело к появлению DevOps? Какие люди первыми стали употреблять это слово и что они под ним подразумевали? Что изменилось за это время, а что осталось неизменным? И что там дальше?

А разобравшись со всем этим, в итоге можно обнаружить, что теперь и на вопрос «что такое DevOps» отвечаешь себе более четко.

Предыстория: как не утонуть в водопаде? 

До разговора непосредственно о DevOps вспомним, что ему предшествовало.

Как известно, главная идея DevOps в эффективном сотрудничестве разработки («Dev») и эксплуатации («Ops»). Конечно, эффективное сотрудничество разных специалистов — это всегда хорошо, но почему именно в этом случае ему уделяют столько внимания? Потому что здесь оно помогает бизнесу добиваться многих важных для него целей: быстрее выводить решения на рынок, оперативнее восстанавливаться при сбоях и так далее. 

А эти цели люди преследовали задолго до того, как слова «development» и «operations» сошлись вместе. Обратимся к истории. 

Можно сказать, что разработчики в современном понимании (они сидели за терминалом и писали код) появились после 1957 года, когда изобрели первый высокоуровневый язык программирования FORTRAN. До этого как таковых менеджерских подходов к разработке не было — написание программ для тех самых компьютеров размером с дом было штучным продуктом. Но затем все стало меняться.

К концу 1970-х и 1980-х разработчики могли уже регулярно сидеть за рабочими станциями, писать код, компилировать его и тестировать на одном компьютере. Развертывание состояло из компиляции и копирования на десятки дискет. Компании начали открывать вакансии программистов для написания «исходного кода» — термина, который только недавно вошел в лексикон. Начал расти рынок коммерческого ПО и массовой разработки.

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

В 1970 году мир узнал о водопадной (или каскадной) модели разработки. Она была предложена американцем Уинстоном Ройсом — директором центра Lockheed Software Technology. Описанный подход напоминал конвейерное производство — вся работа распределялась по стадиям (анализ, проектирование, написание кода, тестирование, релиз), к следующей стадии можно было переходить только после завершения предыдущей. Никакие поздние изменения не допускались. 

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

Как писал Роберт Мартин в Clean Agile: Back to Basics («Чистый Agile», Питер, 2020): «Крупная работа не выполняется большими командами. На самом деле крупная работа выполняется большим количеством маленьких команд, которые в свою очередь выполняют много небольших задач. В 1950-х и 60-х годах программисты понимали это на уровне инстинкта. Но в 1970-е годы про это просто-напросто забыли».

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

А к середине 90-x сообщество через боль и слезы наконец осознало, что принципы разработки необходимо перезагрузить.  

В 2001 году в городке Сноуберд был составлен Agile Manifesto. Про сам манифест вы наверняка слышали, но обращали ли вы внимание на то, насколько тезисы «12 принципов Agile-разработки» близки DevOps? «Deliver frequently», «continuous delivery» — кажется, если заменить заголовок на «12 принципов хорошего DevOps» и запостить на Хабр, многие не заметят никакого подвоха.

Позже авторы манифеста развивали его идеи. В числе авторов Agile Manifesto, помимо того же Роберта Мартина и других известных людей вроде Мартина Фаулера, был Алистер Кокберн — и в 2004-м он описал методологию разработки ПО Crystal Clear. А дальше идеи подхватывали и развивали уже другие люди: например, в 2006-м системный администратор Марсель Вегерманн написал эссе на немецком языке, посвященное использованию принципов разработки ПО Crystal Clear, Scrum и Agile в области системного администрирования. Можете посмотреть его короткое выступление 2008-го по мотивам этой работы на Chaos Communication Congress. 

Обращение Марселя не стало особо популярным, но оно показывает существование спроса на «Agile в эксплуатации»: не только в разработке хотели всё улучшить. В том же 2008-м системный администратор и Agile-практик Патрик Дебуа выступил на Agile Conference в Торонто с докладом «Agile infrastructure and operations», и сыграл куда большую роль. Но об этом чуть позже.

Дорога в облака

А что, кроме Agile, способствовало появлению DevOps? Изменение IT-ландшафта: появление новых технологий и реакция индустрии на них.

Например, в 90-е стали бурно развиваться интернет и облачные технологии. Это меняло многое — стал необходим новый способ разработки и доставки. В 1995 году появилась также СУБД MySQL, помогавшая создавать динамические веб-сайты и приложения.

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

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

Со всем этим «быстрая доставка софта» превратилась в насущную потребность. Теперь бизнес требовал, чтобы софт создавался быстро, но при этом качественно и с минимальными издержками.

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

Дебуа и другие

Одним из таких людей и был Патрик Дебуа. Он помогал министерству Бельгии с миграцией дата-центров и работал в связке с несколькими Agile-командами. Дебуа должен был координировать действия между командами разработки приложений и эксплуатационными командами (сервер, сеть баз данных). 

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

На конференции Agile 2008 в Торонто он выступил с докладом «Agile Operations and Infrastructure: How Infra-gile are You?», где рассказал о своем опыте изменения эксплуатационной работы. Он говорил о применении принципов Agile в инфраструктуре, а не при написании кода. Но в Agile-сообществе доклад широкого отклика не получил.

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

А дальнейшему развитию движение обязано курьезному случаю. Программист Эндрю Клэй Шафер, интересовавшийся проблемами в IT, предложил на той же конференции провести встречу-дискуссию по гибкой инфраструктуре (Agile Infrastructure). Однако тема настолько не привлекла внимание зрителей, что он даже сам не пошел на свое мероприятие, посчитав его никому не нужным. А вот Патрик Дебуа пришел. И для него эта «фан-встреча, куда никто не пришел» наоборот стала сигналом, что раз кто-то ее придумал, значит, кому-то все-таки это нужно! Он связался с Эндрю и продолжил обсуждение гибких методологий в инфраструктуре с ним напрямую. 

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

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

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

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

Также они предлагали следующее:

• Автоматизированную инфраструктуру -> согласованные платформы для разработки и продакшена (инфраструктура как код, управление ролями и конфигурациями).

• Общий контроль версий как для разработки, так и для эксплуатации.

• Настройку одноэтапной системы сборки.

• Развертывание за один шаг.

• Журнал развертывания (Кто? Когда? Что?).

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

Нельзя сказать, что этот доклад немедленно перевернул индустрию: слова про «10 деплоев в день» для многих звучали либо враньем, либо безумием, либо пустым бахвальством крупной компании («ну они там могут себе позволить такое, а нам-то с этого что»). 

Но доклад вдохновил конкретного человека — Патрика Дебуа. Ему не нравилось, что тогда были конференции о разработке и конференции об инфраструктуре, но не было мероприятия, где две аудитории пересекались бы и общались. И совместный доклад Оллспоу и Хэммонда убеждает его, что такое мероприятие необходимо. Дебуа решает создать конференцию одновременно и для «dev», и для «ops».

Он называет её DevOpsDays («потому что Agile System Administration было слишком длинно») и впервые проводит в 2009-м в Бельгии. После завершения конференции ее участники продолжили обсуждать поднятые темы в Твиттере, где название мероприятия сократилось до хэштега #DevOps. А в итоге слово, стихийно возникшее как хэштег, прижилось настолько, что сегодня гугл находит его на миллионах страниц. Так что этим названием мы обязаны Патрику, хотя сам он совершенно не ожидал такого эффекта.

В 2010-м конференция DevOpsDays впервые прошла в США, и там это тоже дало плодотворную почву для дискуссий. Дэймон Эдвардс и Джон Уиллис тогда придумали аббревиатуру CAMS (Culture, Automation, Measurement, Sharing) — культура, автоматизация, измерение и совместное использование. Джез Хэмбл позже добавил L (Lean) — бережливый. Так были обозначены ключевые принципы DevOps и появился фреймворк для оценки готовности к переходу в DevOps.

Кстати, Джон Уиллис стал одним из ключевых людей для всего явления (например, как соавтор книги «Руководство DevOps»), много выступал в связи с ним, и одно из таких выступлений было на нашей конференции DevOops:

Служить и доставлять

Бывший технический директор компании Tripwire Джин Ким в работе The Three Ways: The Principles Underpinning DevOps (иллюстрации ниже взяты из оригинальной статьи) пишет про так называемые «Три пути» (или три принципа), которые позволяют добиться устранения отсутствующих связей между Dev и Ops.

Позже Ким стал соавтором бизнес-романов The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win («Проект “Феникс”», Эксмо, 2015) и The Unicorn Project (IT Revolution Press, 2019), герои которых идут именно по этим трем путям. Первая книга стала основополагающей для погружения и понимания процесса внедрения DevOps в компании.

В итоге «три пути» в DevOps-контексте возникают регулярно: например, на нашей конференции DevOops 2020 Виталий Дмитриев из «Липтсофт» тоже попытался вернуться к основам и рассказал о своем опыте применения «Трех путей».

Итак, что же это за три пути?

Первый путь: системное мышление

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

Второй путь: усиление обратной связи

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

Третий путь: культура экспериментов и обучения

Третий путь — создаем культуру, способствующую двум вещам: постоянному экспериментированию и извлечению уроков из неудач. Люди должны понимать, что повторение и практика являются предпосылками к мастерству.

Герои книги «Проект “Феникс”» вот так справляются с этой задачей:

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

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

Так что, дело в культуре? 

По данным Gartner, к 2023 году 90% инициатив DevOps не оправдают ожиданий. Почему? Из-за неверного понимания сути концепции и неправильного подхода к внедрению. Раджеш Сетху, директор DevOps в Replicon сказал в 2018 году: «Основная причина того, что DevOps внедряется сложнее, чем другие методологии, заключается в том, что он объединяет культурные изменения с эксплуатацией и разработкой. Изменение бизнес-культуры — особенно в крупных компаниях с устоявшимися процессами — совсем не то, что можно мгновенно преобразовать на уровне людей, процессов и информации».

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

К 2015 году идеи DevOps становятся популярней — они сулят успех в поставке ПО, но из-за отсутствия четкого зафиксированного определения разные компании начинают эти идеи понимать по-своему.

Это DevOps?

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

Руководство DevOps

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

Инструменты

Твиттер-аккаунт «DevOps Борат» сообщает нам, что просто совершить ошибку — это в природе людей, а вот для автоматического распространения ошибки на все сервера без #devops не обойдешься.

Несмотря на шуточный посыл, здесь кроется стереотипное восприятие практик DevOps как набора инструментов. Часто, когда люди говорят, что используют DevOps, то подразумевают под этим, что используют Puppet для управления конфигурацией серверов, Ansible — для развертывания версий приложений, Cloudify — для оркестровки и так далее. 

Но еще сам Патрик Дебуа в 2012 году говорил, что DevOps — это человеческая проблема. И согласно такому взгляду, важно не то, какой инструмент для чего используется. DevOps — это не инструмент, а ситуация, когда: 

• Разработка и эксплуатация работают в тесном сотрудничестве.

• Всем понятна работа друг друга: разработчики знают систему, для которой пишут код (и приспосабливаются к ней), а администраторы знают код, который развертывают (и понимают, как это влияет на систему).

• Всё разрабатывается в короткие итерации и может быстро развертываться (как инфраструктура, так и приложения), чтобы можно было сразу устранять ошибки.

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

В 2012 году, когда DevOps был уже достаточно популярен, один из основоположников фреймворка CAMS Джон Уиллис опубликовал мрачный твит с хештегом #devopsdead, где заявил, что убирает букву C (culture) из аббревиатуры CAMS. В ответ Патрик Дебуа посоветовал ему не отчаиваться.

Культура — это все-таки самая сложная часть DevOps.

Команды DevOps

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

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

DevOps и Agile

А еще важно помнить, что DevOps != Agile, однако без Agile практически невозможно извлечь максимальную выгоду из создания кросс-функциональных команд. Для достижения целей DevOps требуются гибкие методологии.  

Например, об этом неоднократно говорил Михаэль Хюттерманн — Java-чемпион, инженер по доставке и эксперт по Agile и DevOps. В своей книге DevOps for Developers он пишет, что Agile обязательно должен внедряться в отдел эксплуатации и это позволит устранить конфликт между Dev и Ops.

DevOps-инженеры

Логично предположить, что если DevOps — это культура и процесс, а не инженерная специальность, то и DevOps-инженеров быть не должно, об этом мы уже писали. Сторонники такой позиции говорят, что это словосочетание появилось от желания менеджеров и HR-ов упростить себе жизнь: если появилась какая-то потребность (в данном случае в DevOps), то можно просто ввести роль, которая эту потребность закроет! 

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

Вне зависимости от того, считаете ли вы это словосочетание осмысленным, бессмысленно спорить с тем, что люди его активно используют:

Тогда вопрос в другом: что люди им обозначают в реальности? Похоже, что совершенно разные вещи в зависимости от ситуации. А если помониторить вакансии «DevOps-инженера», то список требований может оказаться колоссальным. Практически всё и сразу — и разработчик, и сисадмин, и специалист по безопасности!

А вот как в 2021 году говорит о своей роли один российский DevOps-инженер:

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

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

Само по себе — это неплохо, но чтобы не расстраивать Дэймона Эдвардса и Джона Уиллиса, еще раз отметим, что по их мнению DevOps — это не что-то конкретное, выраженное в инструментах или конкретных ролях, а культура.

DevOps сейчас

Итак, что же такое DevOps в 2021 году? Инструменты, люди, процессы? Умение писать на Bash скрипты для кофемашины?

Как  и многие фреймворки гибких методологий, DevOps не имеет четкого определения, и каждая компания будет объяснять его по-своему. Но его главная идея DevOps — это культура сотрудничества, и эта идея оставалась неизменной всегда. Об этом говорили Патрик Дебуа и Эндрю Клэй Шафер, Пол Хэммонд и Джон Оллспоу, а теперь об этом говорят люди вроде Баруха Садогурского.

А что тогда изменилось за 12 лет существования понятия? Во-первых, практики DevOps постепенно меняли общий подход к поставке ПО. Из новомодного слова все превращалось в общепринятую норму. Как в свое время Agile стал стандартом в разработке, так и DevOps становится стандартом в поставке.

А во-вторых, как и Agile в свое время, идея получает дальнейшее развитие. Например, в 2020 году Патрик Дебуа выступал на нашей конференции DevOops c докладом DevSecOps: More of the same — back to the roots, и в частности рассказывал про то, как важно вернуться к основам и посмотреть, что стоит за модным словом «Devops».  А сейчас, уже практически из зрелой методологии вырастает новая —  DevSecOps. Ее жизнеспособность покажет время и практика, а пока еще раз напомним, что самое важное в DevOps — это люди и культура.

А напоследок зададим такой вопрос: если с понятием «DevOps» всё так неоднозначно, то какой тогда должна быть DevOps-конференция? Как сделать, чтобы она не превратилась в набор технических фактов про Kubernetes и Terraform  (мало связанный с исходным значением слова), но в то же время не превратилась в пустословие «наша культура культурнее вашей культуры», где можно сколько угодно лить воду?

Мы не первый год проводим DevOops и считаем так: на девопс-конференции нужен баланс между этими составляющими. Поэтому программа у нас делится на разные логические блоки: есть про процессы и культуру, есть про SRE (вот тут всякие кубернетесы-терраформы), есть про Cloud Native. 

Если вы согласны с таким подходом, то вам наверняка будет интересно на следующем DevOops, который пройдет 8–11 ноября. А если захотелось повозражать, дополнить, поделиться своим взглядом — добро пожаловать в комментарии.