Привіт, Хабре! Представляю вашій увазі переклад статті автора Steve Mezak.
Залежно від вашої точки зору, DevOps відзначатиме свою дев'яту чи десяту річницю цього року. У 2016 у звіті компанії RightScales про стан хмар зазначалося, що 70 відсотків малого та середнього бізнесу використовують методи DevOps. Кожен складник цієї оцінки індикатор з того часу збільшився. Поки DevOps готується розміняти друге десятиліття свого існування, було б чудово прогулятися закутками минулого і повернутися до витоків DevOps — і навіть до походження самої цієї назви.
До 2007: Ідеальний ланцюг подій
До 2007 року серія обставин нарешті дала народження тому, що сьогодні відомо як DevOps.
ощадливе виробництво вже зарекомендувало себе як найкращу практику. Також відоме як виробнича система Toyota, ощадливе виробництво прагне оптимізації процесів у виробничому цеху. (До речі, керівництво Toyota спочатку надихалося оригінальними методами складальної лінії, представленої Ford Motor Company). постійне вдосконалення - Це мантра для ощадливого виробництва. На практиці постійно оцінюються такі шляхи:
- Підтримка рівня запасів сировини та готових виробів на мінімумі. Ощадливе виробництво означає мінімальну кількість запасів сировини для виробництва товарів та мінімальну кількість уже готових виробів, що очікують розподілу на замовлення або відвантаження.
- Мінімізація черги замовлень. Ідеально, якщо отримані замовлення одразу переходять у стан завершених. Ключовою метрикою ощадливого виробництва завжди буде час від надходження замовлення до постачання.
- Максимізація ефективності виробничого процесу. Реорганізація процесів та покращена автоматизація об'єднуються з метою настільки швидкого виробництва товарів, наскільки це можливо. Кожна ділянка виробництва по всьому шляху (різання, зварювання, складання, тестування тощо) оцінюється щодо неефективності.
У світі IT традиційні методи каскадної моделі розробки програмного забезпечення вже поступилися дорогою швидким ітеративним методам, таким як Перевірений. Швидкість була бойовим кличем, навіть якщо якість іноді погіршувалась у гонитві за швидкою розробкою та розгортанням. Приблизно так само хмарні обчислення, зокрема Інфраструктура як послуга (IaaS) та Platform-as-a-Service (PaaS) зарекомендували себе як зрілі рішення у процесах та інфраструктурі IT.
Нарешті, нещодавно почали з'являтися набори інструментів Безперервна інтеграція (CІ). Уявлення про інструменти 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