Привет, Хабр! Представляю вашему вниманию перевод статьи «The Origins of DevOps: What’s in a Name?» автора Steve Mezak.

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

До 2007: Идеальная цепь событий

До 2007 года серия обстоятельств в конце концов дала рождение тому, что сегодня известно как DevOps.

Бережливое производство уже зарекомендовало себя как лучшую практику. Также известное как производственная система Toyota, бережливое производство стремится к оптимизации процессов в производственном цеху. (Кстати, руководство Toyota изначально вдохновлялось оригинальными методами сборочной линии, представленной Ford Motor Company). Постоянное совершенствование — это мантра для бережливого производства. На практике постоянно оцениваются следующие пути:

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

В мире IT традиционные методы каскадной модели разработки программного обеспечения уже уступили дорогу быстрым итеративным методам, таким как Agile. Скорость была боевым кличем, даже если качество иногда ухудшалось в погоне за быстрой разработкой и развёртыванием. Примерно так же облачные вычисления, в частности Infrastructure-as-a-Service (IaaS) и Platform-as-a-Service (PaaS) зарекомендовали себя как зрелые решения в процессах и инфраструктуре IT.

Наконец, недавно начали появляться наборы инструментов для Continuous Integration (CI). Представление об инструментах CI было рождено и представлено Гради Бучем ещё в 1991 году в его Методе Буча.

2007-2008: Разочарованный бельгиец

Бельгийский консультант, менеджер проектов и практик Agile Патрик Дебуа принял назначение от министерства правительства Бельгии, чтобы помочь с миграцией центров обработки данных. В частности, он занимался сертификацией и проверкой готовности. Обязанности требовали от него согласовывать действия и выстраивать взаимоотношения между группами разработки программного обеспечения и группами по эксплуатации серверов, баз данных и сетей. Его разочарование по поводу отсутствия сплочённости и стен, разделяющих методы разработки и эксплуатации, заронили в него досаду. Стремление к лучшему скоро привело Дебуа к действию.
В 2008 году на конференции по Agile в Торонто Эндрю Шефер предложил модерировать специально устроенную неформальную встречу для обсуждения темы "Agile-инфраструктура". И только один человек пришёл обсудить тему: Патрик Дебуа. Их дискуссия и обмен идеями продвинули концепцию системного администрирования по Agile. В этом же году Дебуа и Шефер создали умеренно успешную группу Agile Systems Administrator в Google.

2009: Дело о сотрудничестве Dev и Ops

На конференции O’Reilly Velocity два сотрудника Flickr, старший вице-президент по техническим операциям Джон Оллспоу и технический директор Пол Хэммонд, представили ныне знаменитую презентацию «10 развёртываний в день: сотрудничество Dev и Ops во Flickr».

Презентация была в стиле драмы, Оллспоу и Хэммонд разыгрывали сложное взаимодействие между представителями Development и Operations в процессе развёртывания программного обеспечения вместе с поиском виноватых и взаимными обвинениями в духе «Это не мой код, это всё твои компьютеры!» Их презентация подтвердила, что единственный разумный выход состоит в том, чтобы деятельность по разработке и развёртыванию программного обеспечения была плавной, прозрачной и полностью интегрированной. Со временем эта презентация стала легендарной, и теперь исторически рассматривается как основополагающая веха, когда в индустрии IT возник запрос на методологию, известную сегодня как DevOps.

2010: DevOps в Соединённых Штатах Америки

С ростом числа сторонников, конференция DevOpsDays впервые была проведена в Соединённых Штатах Америки в Маунтин-Вью (Калифорния) сразу же после ежегодной конференции Velocity. Перенесёмся в 2018 год: запланировано более 30 конференций DevOpsDays, включая десятки в Соединённых Штатах.

2013: Проект «Феникс»

Для многих из нас ещё одним примечательным моментом в истории DevOps стало издание книги «Проект „Феникс“» авторства Джина Кима, Кевина Бера и Джорджа Саффорда. В этом романе рассказывается история IT-менеджера, попавшего в безвыходную ситуацию: ему поручили спасти критически важный проект по развитию электронной коммерции, который пошёл не так. Таинственный наставник менеджера — член совета директоров, увлечённый методами бережливого производства — подсказывает главному герою новые способы осмысления IT и разработки приложений, предвосхищая концепцию DevOps. Кстати, «Проект „Феникс“» вдохновил нас написать книгу «Переходи на аутсорсинг, иначе…» о похожей истории из бизнеса, когда вице-президент по программному обеспечению использует DevOps в ходе разработки нового крупного продукта на аутсорсинге.

DevOps для будущего

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

Многое было достигнуто с момента создания DevOps в последнее десятилетие, и мы ожидаем увидеть ещё больше в 2018 году и в будущем.

Источник: habr.com