Hei Habr! Esitän huomionne artikkelin käännöksen Kirjailija: Steve Mezak
Näkökulmastasi riippuen DevOps viettää tänä vuonna yhdeksättä tai kymmentä vuotta. Vuonna 2016 RightScalesin State of the Cloud -raportti totesi, että 70 prosenttia pk-yrityksistä ottaa käyttöön DevOps-käytäntöjä. Jokainen indikaattori, joka muodostaa tämän pistemäärän, on kasvanut sen jälkeen. Kun DevOps valmistautuu siirtymään toiselle vuosikymmenelle, olisi hienoa kävellä menneisyyteen ja palata DevOpsin alkuperään – ja jopa itse nimen alkuperään.
Ennen vuotta 2007: Täydellinen tapahtumaketju
Ennen vuotta 2007 sarja olosuhteita lopulta synnytti sen, mikä tunnetaan nykyään nimellä DevOps.
Nojata on jo osoittanut olevansa paras käytäntö. Tunnetaan myös Toyotan tuotantojärjestelmä, Lean Manufacturing pyrkii optimoimaan tuotantolattian prosesseja. (Muuten, Toyotan johto sai alun perin inspiraationsa Ford Motor Companyn esittelemistä alkuperäisistä kokoonpanolinjamenetelmistä). Jatkuva parantaminen on kevyen tuotannon mantra. Käytännössä seuraavia polkuja arvioidaan jatkuvasti:
- Raaka-aineiden ja valmiiden tuotteiden varastotasojen pitäminen minimissä. Lean valmistus tarkoittaa vähimmäismäärää raaka-aineiden varastoa tavaroiden valmistukseen ja vähimmäismäärää valmiita tuotteita, jotka odottavat tilausta tai lähetystä.
- Tilausjonon minimoiminen. Ihannetapauksessa vastaanotetut tilaukset siirtyvät välittömästi valmiiksi. Kevyen valmistuksen keskeinen mittari on aina tilauksen vastaanottamisesta toimitukseen kuluva aika.
- Tuotantoprosessin tehokkuuden maksimointi. Prosessien uudelleensuunnittelu ja parannettu automaatio yhdistyvät tuottamaan tavaroita mahdollisimman nopeasti. Jokainen tuotantoalue koko polun varrella (leikkaus, hitsaus, kokoonpano, testaus jne.) arvioidaan tehottomuuden varalta.
IT-maailmassa ohjelmistokehityksen vesiputousmallin perinteiset menetelmät ovat jo väistyneet nopeille iteratiivisille menetelmille, kuten esim. Ketterä. Nopeus oli rallihuuto, vaikka laatu joskus kärsi nopean kehityksen ja käyttöönoton tavoittelussa. Samalla tavalla, erityisesti pilvipalvelu Infrastruktuuri palveluna (IaaS) ja Platform-as-a-Service (PaaS) ovat osoittautuneet kypsiksi ratkaisuiksi IT-prosesseissa ja -infrastruktuurissa.
Lopuksi työkalupakkeja on viime aikoina alkanut ilmestyä Jatkuva integraatio (CI). Gradi Booch syntyi ja esitteli idean CI-työkaluista vuonna 1991 Booch-menetelmässä.
2007-2008: Pettynyt belgialainen
Belgialainen konsultti, ketterä projekti- ja käytäntöpäällikkö Patrick Debois on hyväksynyt Belgian hallituksen ministeriön nimityksen auttamaan datakeskusten siirtymisessä. Hän osallistui erityisesti sertifiointiin ja valmiustestaukseen. Hänen vastuunsa vaati häntä koordinoimaan ja rakentamaan suhteita ohjelmistokehitystiimien ja palvelin-, tietokanta- ja verkkotoimintoryhmien välillä. Hänen turhautumisensa yhteenkuuluvuuden puutteeseen ja kehitys- ja toimintatapoja erottaviin seiniin sai hänet katkeraksi. Desbois'n halu kehittyä sai hänet pian toimiin.
Vuonna 2008 Torontossa pidetyssä ketterässä konferenssissa Andrew Schaefer ehdotti erityisesti järjestetyn epävirallisen kokouksen johtamista aiheesta keskustelemaan.Ketterä infrastruktuuri"Ja vain yksi henkilö tuli keskustelemaan aiheesta: Patrick DeBois. Heidän keskustelunsa ja ajatustenvaihtonsa kehittivät ketterän järjestelmän hallinnan käsitettä. Samana vuonna DeBois ja Schaefer loivat kohtalaisen menestyneen Agile Systems Administrator -ryhmän Googlelle.
2009: Devin ja Opsin yhteistyön tapaus
O'Reilly Velocity -konferenssissa kaksi Flickr-työntekijää, teknisten toimintojen johtaja John Allspaw ja teknologiajohtaja Paul Hammond pitivät nyt kuuluisan esityksen. "10 käyttöönottoa päivässä: kehittäjien ja operaatioiden yhteistyö Flickrissä".
Esitys oli dramaattinen, ja Allspaw ja Hammond esittelivät uudelleen kehitys- ja operatiivisten edustajien välisen monimutkaisen vuorovaikutuksen ohjelmiston käyttöönottoprosessin aikana sekä sormella osoittamista ja syytöksiä "Se ei ole minun koodini, vaan kaikki sinun tietokoneesi!" Heidän esityksensä vahvisti, että ainoa järkevä vaihtoehto on, että ohjelmistokehitys- ja käyttöönottotoiminnot ovat saumattomia, läpinäkyviä ja täysin integroituja. Ajan myötä tästä esityksestä tuli legendaarinen, ja sitä pidetään nyt historiallisena virstanpylväänä, kun IT-ala alkoi vaatia menetelmää, joka tunnetaan nykyään nimellä DevOps.
2010: DevOps Yhdysvalloissa
DevOpsDays-konferenssi järjestettiin ensimmäistä kertaa Yhdysvalloissa Mountain View'ssa, Kaliforniassa, heti vuosittaisen Velocity-konferenssin jälkeen. Nopeasti eteenpäin vuoteen 2018, ja DevOpsDays-konferenssia on suunnitteilla yli 30, mukaan lukien kymmeniä Yhdysvalloissa.
2013: Projekti "Phoenix"
Monille meistä toinen huomionarvoinen hetki DevOpsin historiassa oli Gene Kimin, Kevin Behrin ja George Saffordin kirjan "The Phoenix Project" julkaiseminen. Tämä romaani kertoo IT-päälliköstä, joka joutuu epätoivoiseen tilanteeseen: hänen tehtäväkseen on pelastaa kriittinen verkkokauppaprojekti, joka on mennyt pieleen. Johtajan salaperäinen mentori – lean valmistusmenetelmistä intohimoinen hallituksen jäsen – ehdottaa päähenkilölle uusia tapoja ajatella IT- ja sovelluskehitystä ennakoiden DevOps-konseptia. Muuten, "The Phoenix Project" inspiroi meitä kirjoittamaan kirjan "Outsource or else..." samanlaisesta bisnestarinasta, jossa ohjelmistojohtaja käyttää DevOpsia uuden suuren ulkoistetun tuotteen kehittämisessä.
DevOps tulevaisuutta varten
DevOpsia kannattaa kuvata matkana tai ehkä pyrkimyksenä, ei lopullisena määränpäänä. DevOps, kuten kevyt valmistus, pyrkii jatkuvaan parantamiseen, tuottavuuden ja tehokkuuden lisäämiseen ja jopa jatkuvaan käyttöönottoon. DevOpsia tukevien automaattisten työkalujen kehitys jatkuu.
Paljon on saavutettu DevOpsin perustamisen jälkeen viimeisen vuosikymmenen aikana, ja odotamme näkevämme vielä enemmän vuonna 2018 ja sen jälkeen.
Lähde: will.com