Хей Хабр! Представям на вашето внимание превода на статията „Произходът на DevOps: Какво има в името?“ от Стив Мезак.

В зависимост от вашата гледна точка, DevOps ще отпразнува деветата или десетата си годишнина тази година. През 2016 г. докладът на RightScales за състоянието на облака отбелязва, че 70 процента от малките и средни предприятия възприемат практиките на DevOps. Всеки показател, който съставлява този резултат, се е увеличил оттогава. Тъй като DevOps се подготвя да навлезе във второто си десетилетие, би било чудесно да се разходим в миналото и да се върнем към произхода на DevOps – и дори към произхода на самото име.

Преди 2007: Перфектна верига от събития

Преди 2007 г. поредица от обстоятелства в крайна сметка родиха това, което днес е известно като DevOps.

Постно вече се е доказала като най-добра практика. Също известен като Производствена система на Toyota, Lean Manufacturing се стреми да оптимизира процесите на производствения етаж. (Между другото, ръководството на Toyota първоначално беше вдъхновено от оригиналните методи на поточна линия, въведени от Ford Motor Company). Непрекъснато усъвършенстване е мантрата за щадящо производство. На практика непрекъснато се оценяват следните пътища:

1. Поддържане на запасите от суровини и готови продукти до минимум. Опростеното производство означава минимален запас от суровини за производство на стоки и минимално количество готови продукти, които чакат да бъдат поръчани или изпратени.
2. Минимизиране на опашката за поръчки. В идеалния случай получените поръчки незабавно преминават към завършено състояние. Ключовият показател за икономично производство винаги ще бъде времето от получаването на поръчката до доставката.
3. Максимизиране на ефективността на производствения процес. Реинженерингът на процесите и подобрената автоматизация се комбинират, за да произвеждат стоки възможно най-бързо. Всяка област на производство по целия път (рязане, заваряване, сглобяване, тестване и т.н.) се оценява за неефективност.

В света на ИТ традиционните методи на водопадния модел на разработка на софтуер вече са отстъпили място на бързи итеративни методи като напр. Пъргав. Скоростта беше обединяващият вик, дори ако качеството понякога страдаше в стремежа към бързо развитие и внедряване. По почти същия начин, по-специално облачните изчисления Инфраструктура като услуга (IaaS) и Платформа като-услуга (PaaS) са се доказали като зрели решения в ИТ процесите и инфраструктурата.

И накрая, наскоро започнаха да се появяват набори от инструменти за Непрекъснато интегриране (CI). Идеята за CI инструменти е родена и представена от Gradi Booch през 1991 г. в неговия метод Booch.

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

Белгийският консултант, ръководител на проекти и практики Agile Патрик Дебоа прие назначение от белгийско правителствено министерство да помогне с миграцията на центрове за данни. По-специално, той участва в сертифицирането и тестването на готовността. Отговорностите му изискваха да координира и изгражда взаимоотношения между екипите за разработка на софтуер и екипите за сървъри, бази данни и мрежови операции. Неговото разочарование от липсата на сплотеност и стените, разделящи методите на разработка и работа, го оставиха горчив. Желанието на Дебоа да се подобри скоро го накара да действа.
На конференцията Agile през 2008 г. в Торонто Андрю Шефър предложи модериране на специално организирана неформална среща за обсъждане на темата "Гъвкава инфраструктура„И само един човек дойде да обсъди темата: Патрик Дебоа. Тяхната дискусия и обмен на идеи допринесоха за концепцията за администриране на гъвкави системи. Същата година Дебоа и Шефър създадоха умерено успешната група за гъвкави системни администратори в Google.

2009: Случаят на сътрудничество между Dev и Ops

На конференцията O'Reilly Velocity двама служители на Flickr, старши вицепрезидент по технически операции Джон Олспау и технически директор Пол Хамънд, изнесоха известната вече презентация „10 внедрявания на ден: Сътрудничество на Dev и Ops във Flickr“.

Презентацията беше драма, като Allspaw и Hammond възпроизведоха сложните взаимодействия между представители на разработката и операциите по време на процеса на внедряване на софтуера, допълнени с сочене с пръсти и взаимни обвинения по линия на „Това не е моят код, това са всичките ви компютри!“ Тяхното представяне потвърди, че единственият разумен вариант е дейностите по разработване и внедряване на софтуер да бъдат безпроблемни, прозрачни и напълно интегрирани. С течение на времето тази презентация стана легендарна и сега исторически се разглежда като важен крайъгълен камък, когато ИТ индустрията започна да призовава за методологията, известна днес като DevOps.

2010: DevOps в Съединените американски щати

С нарастващ брой последователи, конференцията DevOpsDays се проведе за първи път в Съединените щати в Маунтин Вю, Калифорния, веднага след годишната конференция Velocity. Бързо напред до 2018 г. и има повече от 30 планирани конференции DevOpsDays, включително десетки в Съединените щати.

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

За много от нас друг забележителен момент в историята на DevOps беше публикуването на книгата „Проектът Феникс“ от Джийн Ким, Кевин Бер и Джордж Сафорд. Този роман разказва историята на ИТ мениджър, който се озовава в отчаяна ситуация: той има задачата да спаси критичен проект за електронна търговия, който се е объркал. Мистериозният наставник на мениджъра - член на борда на директорите, който е запален по методите на щадящо производство - предлага нови начини на главния герой да мисли за ИТ и разработка на приложения, предвиждайки концепцията на DevOps. Между другото, „Проектът Phoenix“ ни вдъхнови да напишем книгата „Изнесете или иначе...“ за подобна бизнес история, в която вицепрезидент на софтуера използва DevOps по време на разработването на нов основен изнесен продукт.

DevOps за бъдещето

Струва си да се опише DevOps като пътуване или може би като стремеж, а не като крайна дестинация. DevOps, подобно на щадящото производство, се стреми към непрекъснато подобрение, повишена производителност и ефективност и дори непрекъснато внедряване. Автоматизираните инструменти за поддръжка на DevOps продължават да се развиват.

Много беше постигнато от създаването на DevOps през последното десетилетие и очакваме да видим още повече през 2018 г. и след това.

Източник: www.habr.com