DevOpsi päritolu: mis on selle nime all?

Tere Habr! Esitan teie tähelepanu artikli tõlkele "DevOpsi päritolu: mis on nimes?" autor Steve Mezak.

Olenevalt teie vaatenurgast tähistab DevOps sel aastal oma üheksandat või kümnendat aastapäeva. 2016. aastal märgiti RightScalesi pilveseisundi aruandes, et 70 protsenti väikestest ja keskmise suurusega ettevõtetest kasutavad DevOpsi tavasid. Iga näitaja, mis selle skoori moodustab, on sellest ajast alates tõusnud. Kui DevOps valmistub oma teisele kümnendile astuma, oleks suurepärane jalutada minevikku ja naasta DevOpsi päritolu ja isegi nime enda päritolu juurde.

Enne 2007. aastat: täiuslik sündmusteahel

Enne 2007. aastat põhjustas rida asjaolusid lõpuks selle, mida tänapäeval tuntakse DevOpsi nime all.

Lahja on end juba tõestanud parima tavana. Tuntud ka kui Toyota tootmissüsteem, Lean Manufacturing püüab optimeerida protsesse tootmispõrandal. (Muide, Toyota juhtkond oli algselt inspireeritud Ford Motor Company poolt kasutusele võetud algsetest konveierimeetoditest). Pidev täiustamine on säästliku tootmise mantra. Praktikas hinnatakse pidevalt järgmisi teid:

  1. Tooraine ja valmistoodete varude taseme hoidmine miinimumini. Lean tootmine tähendab minimaalset toorainevaru kaupade tootmiseks ja minimaalset kogust valmistooteid, mis ootavad tellimist või saatmist.
  2. Tellimuste järjekorra minimeerimine. Ideaalis liiguvad saadud tellimused kohe valmis olekusse. Säästva tootmise võtmenäidik on alati aeg tellimuse kättesaamisest tarnimiseni.
  3. Tootmisprotsessi efektiivsuse maksimeerimine. Protsesside ümberprojekteerimine ja täiustatud automatiseerimine ühendatakse, et toota kaupu võimalikult kiiresti. Ebaefektiivsust hinnatakse igas tootmispiirkonnas kogu raja ulatuses (lõikamine, keevitamine, kokkupanek, katsetamine jne).

IT-maailmas on tarkvaraarenduse kosemudeli traditsioonilised meetodid juba andnud teed kiiretele iteratiivsetele meetoditele nagu näiteks Väle. Kiirus oli rallikarje, isegi kui kvaliteet kiire arengu ja kasutuselevõtu tagaajamisel mõnikord kannatas. Umbes samamoodi, eriti pilvandmetöötlus Infrastruktuur teenusena (IaaS) ja Platform-as-a-Service (PaaS) on end tõestanud IT protsesside ja infrastruktuuri küpsete lahendustena.

Lõpuks on hiljuti hakanud ilmuma tööriistakomplektid Pidev integreerimine (CI). CI tööriistade idee sündis ja esitas Gradi Booch 1991. aastal oma Boochi meetodis.

2007-2008: pettunud belglane

Belgia konsultant, Agile'i projekti- ja praktikajuht Patrick Debois nõustus Belgia valitsuse ministeeriumiga andmekeskuste migreerimisel abistama. Eelkõige tegeles ta sertifitseerimise ja valmisoleku testimisega. Tema kohustuste tõttu pidi ta koordineerima ja looma suhteid tarkvaraarendusmeeskondade ning serveri-, andmebaasi- ja võrguoperatsioonide meeskondade vahel. Tema pettumus sidususe puudumise ning arendus- ja tegutsemismeetodeid eraldavate seinte pärast jättis ta kibedaks. Desboisi soov end parandada viis ta peagi tegudeni.
2008. aasta Agile'i konverentsil Torontos tegi Andrew Schaefer ettepaneku korraldada teema arutamiseks spetsiaalselt korraldatud mitteametlik kohtumine.Agiilne infrastruktuur"Ja seda teemat arutlema tuli ainult üks inimene: Patrick DeBois. Nende arutelu ja ideede vahetamine viisid edasi Agile'i süsteemide administreerimise kontseptsiooni. Samal aastal lõid DeBois ja Schaefer Google'is mõõdukalt eduka Agile Systems Administrator'i rühma.

2009: Devi ja Opsi koostöö juhtum

O'Reilly Velocity konverentsil pidasid nüüd kuulsa ettekande kaks Flickri töötajat, tehniliste operatsioonide vanemasepresident John Allspaw ja tehnoloogiadirektor Paul Hammond. "10 kasutuselevõttu päevas: arendajate ja operatsioonide koostöö Flickris".

Esitlus oli draama, Allspaw ja Hammond taasesitasid tarkvara juurutamise käigus arenduse ja operatsioonide esindajate vahelist keerulist suhtlust koos näpuga näitamise ja etteheitetega, nagu "See pole minu kood, see on kõik teie arvutid!" Nende ettekanne kinnitas, et ainus mõistlik variant on, et tarkvara arendus- ja juurutustegevused oleksid sujuvad, läbipaistvad ja täielikult integreeritud. Aja jooksul muutus see esitlus legendaarseks ja seda peetakse ajalooliselt oluliseks verstapostiks, kui IT-tööstus hakkas nõudma metoodikat, mida tänapäeval tuntakse kui DevOps.

2010: DevOps Ameerika Ühendriikides

Kasvava kuulajaskonnaga toimus DevOpsDaysi konverents esimest korda Ameerika Ühendriikides Californias Mountain View's kohe pärast iga-aastast Velocity konverentsi. Edaspidi 2018. aastasse ja kavas on üle 30 DevOpsDaysi konverentsi, sealhulgas kümneid Ameerika Ühendriikides.

2013: projekt "Phoenix"

Paljude meist oli DevOpsi ajaloo teine ​​tähelepanuväärne hetk Gene Kimi, Kevin Behri ja George Saffordi raamatu “The Phoenix Project” avaldamine. See romaan räägib loo IT-juhist, kes satub meeleheitlikku olukorda: tema ülesandeks on päästa kriitiline e-kaubanduse projekt, mis on valesti läinud. Juhataja salapärane mentor – juhatuse liige, kes on kirglik lean tootmismeetodite vastu – soovitab peategelasele uusi viise IT ja rakenduste arendamise üle mõelda, nähes ette DevOpsi kontseptsiooni. Muide, "Phoenixi projekt" inspireeris meid kirjutama raamatut "Outsource or else..." sarnasest äriloost, kus tarkvara VP kasutab DevOpsi uue suurema allhanketoote väljatöötamisel.

DevOps tuleviku jaoks

DevOpsi tasub kirjeldada kui reisi või võib-olla püüdlust, mitte kui lõppsihtkohta. DevOps, nagu ka säästlik tootmine, püüdleb pideva täiustamise, tootlikkuse ja tõhususe suurendamise ning isegi pideva kasutuselevõtu poole. DevOpsi toetavad automatiseeritud tööriistad arenevad jätkuvalt.

Alates DevOpsi loomisest on viimasel kümnendil palju saavutatud ning loodame, et 2018. aastal ja pärast seda näeme veelgi rohkem.

Allikas: www.habr.com

Lisa kommentaar