Паходжанне DevOps: што крыецца ў назове?

Прывітанне, Хабр! Уяўляю вашай увазе пераклад артыкула "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). Пастаяннае ўдасканаленне - Гэта мантра для беражлівага вытворчасці. На практыцы ўвесь час ацэньваюцца наступныя шляхі:

  1. Падтрымка ўзроўню запасаў сыравіны і гатовых вырабаў на мінімуме. Ашчадная вытворчасць азначае мінімальную колькасць запасаў сыравіны для вытворчасці тавараў і мінімальную колькасць ужо гатовых вырабаў, якія чакаюць размеркавання па заказах або адгрузкі.
  2. Мінімізацыя чаргі заказаў. Ідэальна, калі атрыманыя замовы адразу пераходзяць у стан завершаных. Ключавой метрыкай беражлівай вытворчасці заўсёды будзе час ад паступлення замовы да пастаўкі.
  3. Максімізацыя эфектыўнасці вытворчага працэсу. Рэарганізацыя працэсаў і палепшаная аўтаматызацыя аб'ядноўваюцца з мэтай настолькі хуткай вытворчасці тавараў, наколькі гэта магчыма. Кожны ўчастак вытворчасці на ўсім шляху (рэзка, зварка, зборка, тэсціраванне і г.д.) ацэньваецца на прадмет неэфектыўнасці.

У свеце IT традыцыйныя метады каскаднай мадэлі распрацоўкі праграмнага забеспячэння ўжо саступілі дарогу хуткім ітэратыўным метадам, такім як Спрытны. Хуткасць была баявым клічам, нават калі якасць часам пагаршалася ў пагоні за хуткай распрацоўкай і разгортваннем. Прыкладна гэтак жа хмарныя вылічэнні, у прыватнасці Інфраструктура як паслуга (IaaS) і Платформа-як-Сэрвіс (PaaS) зарэкамендавалі сябе як сталыя рашэнні ў працэсах і інфраструктуры IT.

Нарэшце, нядаўна пачалі з'яўляцца наборы прылад для Бесперапынная інтэграцыя (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

Дадаць каментар