Onko DevOpsista puhuttaessa vaikea ymmärtää pääasiaa? Olemme koonneet sinulle eläviä analogioita, silmiinpistäviä muotoiluja ja asiantuntijoiden neuvoja, jotka auttavat myös ei-asiantuntijoita pääsemään asiaan. Lopuksi bonus on Red Hat -työntekijöiden omat DevOps.
Termi DevOps sai alkunsa 10 vuotta sitten, ja se on muuttunut Twitter-hashtagista IT-maailman voimakkaaksi kulttuuriliikkeeksi, todelliseksi filosofiaksi, joka kannustaa kehittäjiä saamaan asiat valmiiksi nopeammin, kokeilemaan ja iteroimaan eteenpäin. DevOpsista on tullut erottamattomasti sidoksissa digitaalisen muuntamisen käsite. Mutta kuten IT-terminologian kanssa usein tapahtuu, DevOps on viimeisen kymmenen vuoden aikana hankkinut monia määritelmiä, tulkintoja ja väärinkäsityksiä itsestään.
Siksi voit usein kuulla kysymyksiä DevOpsista, kuten onko se sama kuin ketterä? Vai onko tämä jokin erityinen menetelmä? Vai onko se vain yksi synonyymi sanalle "yhteistyö"?
DevOps sisältää monia erilaisia konsepteja (jatkuva toimitus, jatkuva integrointi, automaatio jne.), joten tärkeiden asioiden selvittäminen voi olla haastavaa, varsinkin jos olet intohimoinen aiheeseen. Tämä taito on kuitenkin erittäin hyödyllinen, olitpa sitten yrittämässä välittää ideoitasi esimiehille tai yksinkertaisesti kertoa jollekin perheellesi tai ystävillesi työstäsi. Laitetaan siksi syrjään DevOpsin terminologiset vivahteet toistaiseksi ja keskitytään kokonaisuuteen.
Mikä on DevOps: 6 määritelmää ja analogiaa
Pyysimme asiantuntijoita selittämään DevOpsin olemuksen mahdollisimman yksinkertaisesti ja lyhyesti, jotta sen arvo tulee selväksi lukijoille, joilla on minkä tahansa tason tekninen tietämys. Näiden keskustelujen tulosten perusteella olemme valinneet silmiinpistävimmät analogiat ja silmiinpistävät muotoilut, jotka auttavat sinua rakentamaan tarinaasi DevOpsista.
1. DevOps on kulttuuriliike
"DevOps on kulttuuriliike, jossa molemmat osapuolet (ohjelmistokehittäjät ja IT-järjestelmien toiminnan asiantuntijat) tunnustavat, että ohjelmistot eivät tuota todellista hyötyä ennen kuin joku alkaa käyttää niitä: asiakkaat, asiakkaat, työntekijät, ei pointti", sanoo vanhempi tutkija Eveline Oehrlich. analyytikko DevOps Institutessa. "Siksi molemmat osapuolet varmistavat yhdessä nopean ja laadukkaan ohjelmistotoimituksen."
2. DevOpsissa on kyse kehittäjien voimaannuttamisesta.
"DevOps antaa kehittäjille mahdollisuuden omistaa sovelluksia, käyttää niitä ja hallita toimitusta alusta loppuun."
"Yleensä DevOpsista puhutaan tapana nopeuttaa sovellusten toimitusta tuotantoon rakentamalla ja ottamalla käyttöön automatisoituja prosesseja", sanoo Jai Schniepp, vakuutusyhtiö Liberty Mutualin DevOps-alustojen johtaja. "Mutta minulle se on paljon perustavanlaatuisempi asia." DevOps antaa kehittäjille mahdollisuuden omistaa sovelluksia tai tiettyjä ohjelmistoja, käyttää niitä ja hallita niiden toimitusta alusta loppuun. DevOps poistaa vastuusekaannusta ja opastaa kaikkia automatisoidun, kehittäjävetoisen infrastruktuurin luomisessa mukana olevia."
3. DevOps on yhteistyötä sovellusten luomisessa ja toimittamisessa.
"Yksinkertaisesti sanottuna DevOps on lähestymistapa ohjelmistotuotantoon ja -toimitukseen, jossa kaikki työskentelevät yhdessä", sanoo Gur Staf, BMC:n digitaalisen liiketoiminnan automaation johtaja ja johtaja.
4. DevOps on putki
"Kuljetinkokoonpano on mahdollista vain, jos kaikki osat sopivat yhteen."
"Vertaisin DevOpsia auton kokoonpanolinjaan", jatkaa Gur Staff. – Ideana on suunnitella ja valmistaa kaikki osat etukäteen niin, että ne voidaan sitten koota ilman yksittäistä säätöä. Kuljettimen kokoaminen on mahdollista vain, jos kaikki osat sopivat yhteen. Niiden, jotka suunnittelevat ja rakentavat moottorin, on harkittava, kuinka se kiinnitetään runkoon tai runkoon. Jarrut valmistavien täytyy ajatella pyöriä ja niin edelleen. Saman pitäisi olla ohjelmiston kanssa.
Liiketoimintalogiikkaa tai käyttöliittymää luovan kehittäjän on pohdittava asiakastietoja tallentavaa tietokantaa, tietoturvatoimenpiteitä käyttäjätietojen suojaamiseksi ja kuinka tämä kaikki toimii, kun palvelu alkaa palvella suurta, ehkä jopa miljoonan dollarin käyttäjäyleisöä. ."
”Ihmisten saaminen tekemään yhteistyötä ja pohtimaan muiden tekemiä työn osia sen sijaan, että keskittyisivät vain omiin tehtäviinsä, on suurin este, joka on voitettava. Jos pystyt tähän, sinulla on erinomaiset mahdollisuudet digitaaliseen transformaatioon”, Gur Staff lisää.
5. DevOps on oikea yhdistelmä ihmisiä, prosesseja ja automaatiota
Jayne Groll, DevOps Instituten toiminnanjohtaja, tarjosi loistavan analogian selittääkseen DevOpsin. Hänen sanoin: "DevOps on kuin resepti, jossa on kolme pääaineluokkaa: ihmiset, prosessi ja automaatio. Suurin osa näistä ainesosista voidaan ottaa muilta alueilta ja lähteistä: Lean, Agile, SRE, CI/CD, ITIL, johtajuus, kulttuuri, työkalut. DevOpsin, kuten minkä tahansa hyvän reseptin, salaisuus on, kuinka saada oikeat suhteet ja sekoitus näitä ainesosia sovellusten luomisen ja julkaisemisen nopeuttamiseksi ja tehostamiseksi.
6. DevOps on silloin, kun ohjelmoijat työskentelevät kuin Formula 1 -tiimi
"Kilpailua ei suunnitella alusta maaliin, vaan päinvastoin maalista lähtöön."
"Kun puhun siitä, mitä odottaa DevOps-aloitteelta, ajattelen esimerkkinä NASCAR- tai Formula 1 -kilpajoukkuetta", sanoo Chris Short, Red Hatin pilvialustan markkinoinnin johtaja ja DevOps'ish-uutiskirjeen julkaisija. – Tällaisen joukkueen johtajalla on yksi tavoite: ottaa kilpailun lopussa korkein mahdollinen paikka ottaen huomioon joukkueen käytettävissä olevat resurssit ja sitä kohtaavat haasteet. Tässä tapauksessa kilpailua ei suunnitella alusta loppuun, vaan päinvastoin maalista lähtöön. Ensin asetetaan kunnianhimoinen tavoite ja sitten määritellään keinot sen saavuttamiseksi. Sitten ne jaetaan osatehtäviin ja delegoidaan tiimin jäsenille."
"Tiimi viettää koko viikon ennen kilpailua varikkopysähdyksen parantamiseen. Hän harjoittelee voimaharjoittelua ja kardioa pysyäkseen kunnossa uuvuttavan kilpailupäivän ajan. Harjoittelee yhdessä ratkaisemaan kilpailun aikana mahdollisesti ilmeneviä ongelmia. Samoin kehitystiimin tulisi kouluttaa taitoa julkaista uusia versioita usein. Jos sinulla on tällaiset taidot ja hyvin toimiva turvajärjestelmä, myös uusien versioiden lanseeraus tuotantoon tapahtuu useammin. Tässä maailmankuvassa lisääntynyt nopeus tarkoittaa parempaa turvallisuutta, Short sanoo.
"Kyse ei ole 'oikean asian' tekemisestä", Short lisää, "kyseessä on eliminoida mahdollisimman monta sellaista asiaa, jotka estävät halutun lopputuloksen. Tee yhteistyötä ja mukauta reaaliajassa saamasi palautteen perusteella. Varaudu poikkeamiin ja pyri parantamaan laatua minimoidaksesi niiden vaikutuksen edistymiseen kohti tavoitettasi. Tämä odottaa meitä DevOps-maailmassa."
Kuinka skaalata DevOps: 10 vinkkiä asiantuntijoilta
DevOps ja mass DevOps ovat vain täysin eri asioita. Kerromme sinulle, kuinka voit voittaa esteet matkalla ensimmäisestä toiseen.
Monille organisaatioille matka DevOpsiin alkaa helposti ja miellyttävästi. Syntyy pieniä intohimoisia tiimejä, vanhoja prosesseja korvataan uusilla, eivätkä ensimmäiset onnistumiset odota kauaa.
Valitettavasti tämä on vain vääriä välähdyksiä, edistyksen illuusiota, sanoo Ben Grinnell, North Highlandin konsulttiyrityksen toimitusjohtaja ja digitaalijohtaja. Varhaiset voitot ovat varmasti rohkaisevia, mutta ne eivät auta saavuttamaan perimmäistä tavoitetta eli DevOpsin laajaa käyttöönottoa koko organisaatiossa.
On helppo nähdä, että tuloksena on kulttuuri jako "meiden" ja "heiden" välillä.
"Usein organisaatiot käynnistävät nämä uraauurtavat projektit ajattelemalla, että ne tasoittavat tietä valtavirran DevOpsille, ottamatta huomioon, pystyvätkö muut tai haluavatko seurata tätä polkua", Ben Grinnell selittää. – Ryhmät tällaisten projektien toteuttamiseen rekrytoidaan yleensä itsevarmista "varangilaisista", jotka ovat jo tehneet vastaavaa muualla, mutta ovat uusia organisaatiollesi. Samalla heitä rohkaistaan rikkomaan ja tuhoamaan kaikkia muita sitovia sääntöjä. On helppo nähdä, että tuloksena on "meiden" ja "heiden" kulttuuri, joka estää tiedon ja taitojen siirtoa.
"Ja tämä kulttuurinen ongelma on vain yksi syistä, miksi DevOpsia on vaikea skaalata. DevOps-tiimit kohtaavat kasvavia teknisiä haasteita, jotka ovat tyypillisiä nopeasti kasvaville IT-alan yrityksille”, sanoi Steve Newman, Scalyrin perustaja ja puheenjohtaja.
”Palvelut muuttuvat nykymaailmassa heti, kun tarvetta ilmenee. On hienoa ottaa jatkuvasti käyttöön uusia ominaisuuksia, mutta tämän prosessin koordinointi ja syntyvien ongelmien poistaminen on todellinen päänsärky, lisää Steve Newman. – Hyvin nopeasti kasvavissa organisaatioissa monitoimitiimien insinöörit kamppailevat säilyttääkseen näkyvyyden muutokseen ja sen aiheuttamiin peräkkäisiin vaikutuksiin riippuvuustasolla. Lisäksi insinöörit eivät ole tyytyväisiä, kun heiltä riistetään tämä mahdollisuus, ja sen seurauksena heidän on vaikeampi ymmärtää esiin tulevien ongelmien ydintä.”
Kuinka voittaa nämä yllä kuvatut haasteet ja siirtyä DevOpsin massakäyttöön suuressa organisaatiossa? Asiantuntijat vaativat kärsivällisyyttä, vaikka perimmäisenä tavoitteenasi olisikin nopeuttaa ohjelmistokehityssykliäsi ja liiketoimintaprosessejasi.
1. Muista, että kulttuurin muutos vie aikaa.
Jayne Groll, toiminnanjohtaja, DevOps Institute: ”Mielestäni DevOps-laajentumisen tulisi olla yhtä inkrementaalista ja iteratiivista kuin ketterä kehitys (ja yhtä lailla kulttuuria koskettava). Agile ja DevOps painottavat pieniä tiimejä. Mutta kun näiden tiimien lukumäärä ja integraatio kasvavat, päädymme siihen, että yhä useammat ihmiset omaksuvat uusia työskentelytapoja, ja seurauksena on valtava kulttuurinen muutos.
2. Käytä tarpeeksi aikaa suunnitteluun ja alustan valintaan
Eran Kinsbruner, Perfecton johtava tekninen evankelista: "Jotta skaalaus toimisi, DevOps-tiimien on ensin opittava yhdistämään perinteiset prosessit, työkalut ja taidot ja sitten hitaasti vaalimaan ja vakauttamaan jokaista DevOps-vaihetta. Kaikki alkaa käyttäjätarinoiden ja arvovirtojen huolellisesta suunnittelusta, jota seuraa ohjelmistojen kirjoittaminen ja versionhallinta käyttämällä runkopohjaista kehitystä tai muita koodin haaroittamiseen ja yhdistämiseen parhaiten soveltuvia lähestymistapoja.
”Sitten tulee integraatio- ja testausvaihe, jossa skaalautuva alusta automaatioon tarvitaan jo valmiiksi. Tässä DevOps-tiimien on tärkeää valita oikea alusta, joka sopii heidän taitotasoonsa ja projektin lopputavoitteisiin.
Seuraava vaihe on käyttöönotto tuotantoon, ja tämä pitäisi olla täysin automatisoitua orkestrointityökalujen ja säiliöiden avulla. On tärkeää, että DevOpsin kaikissa vaiheissa (tuotantosimulaattori, laadunvarmistusympäristö ja varsinainen tuotantoympäristö) on virtualisoituja ympäristöjä, ja testaamiseen käytetään aina vain uusinta dataa asiaankuuluvien johtopäätösten saamiseksi. Analyysin on oltava älykäs ja kyettävä käsittelemään suurdataa nopealla ja toimivalla palautteella."
3. Ota syyllisyys pois vastuusta.
Gordon Haff, RedHat-evankelista: ”Kokeilua mahdollistavan ja kannustavan järjestelmän ja ilmapiirin luominen mahdollistaa niin sanotut onnistuneet epäonnistumiset ketterissä ohjelmistokehityksessä. Tämä ei tarkoita, etteikö kukaan muu olisi vastuussa epäonnistumisista. Itse asiassa vastuullisen tunnistaminen on entistä helpompaa, koska "vastuullisuus" ei enää tarkoita "onnettomuuden aiheuttamista". Eli vastuullisuuden olemus muuttuu laadullisesti. Neljästä tekijästä tulee kriittistä: häiriön laajuus, lähestymistavat, tuotantoprosessit ja kannustimet. (Voit lukea lisää näistä tekijöistä Gordon Huffin artikkelista "DevOps-oppitunnit: terveellisten kokeiden 4 aspektia.")
4. Tyhjennä polku eteenpäin
Ben Grinnell, toimitusjohtaja ja digitaalijohtaja konsulttiyrityksestä North Highland: ”Mittakaavan saavuttamiseksi suosittelen ”polunraivaus”-ohjelman käynnistämistä yhdessä pioneeriprojektien kanssa. Tämän ohjelman tavoitteena on siivota DevOps-pioneerien jälkeensä jättämät roskat, kuten vanhentuneet säännöt ja muut vastaavat, jotta tie eteenpäin pysyy vapaana."
"Anna ihmisille organisaatiotukea ja vauhtia viestinnällä, joka menee paljon edelläkävijäryhmän ulkopuolelle juhlimalla laajasti uusien työtapojen menestystä. Valmentaa ihmisiä, jotka ovat mukana seuraavassa DevOps-projektien aallossa ja ovat hermostuneita DevOpsin käyttämisestä ensimmäistä kertaa. Ja muista, että nämä ihmiset ovat hyvin erilaisia kuin pioneerit.”
5. Demokratisoi työkalut
Steve Newman, Scalyrin perustaja ja puheenjohtaja: ”Työkaluja ei pidä piilottaa ihmisiltä, ja niiden tulee olla suhteellisen helppo oppia kaikille, jotka haluavat käyttää aikaa. Jos kyky tehdä kyselyjä lokeista on rajoitettu kolmeen henkilöön, jotka on "sertifioitu" käyttämään työkalua, sinulla on aina enintään kolme henkilöä käytettävissäsi käsittelemään ongelmaa, vaikka sinulla olisi erittäin suuri tietokoneympäristö. Toisin sanoen tässä on pullonkaula, joka voi johtaa vakaviin (liiketoiminnallisiin) seurauksiin."
6. Luo ihanteelliset olosuhteet ryhmätyölle
Tom Clark, ITV:n yhteisen alustan johtaja: "Voit tehdä mitä tahansa, mutta ei kaikkea kerralla. Aseta siis suuret tavoitteet, aloita pienistä ja siirry eteenpäin nopeissa iteraatioissa. Ajan myötä kehität mainetta asioiden hoitajana, joten muutkin haluavat käyttää menetelmiäsi. Älä myöskään ole huolissasi erittäin tehokkaan joukkueen rakentamisesta. Sen sijaan tarjoa ihmisille ihanteelliset työolosuhteet ja tehokkuus seuraa sitä."
7. Älä unohda Conwayn lakia ja Kanban-levyjä
Logan Daigle, CollabNetVersionOnen ohjelmistotoimituksesta ja DevOps-strategiasta vastaava johtaja: ”On tärkeää ymmärtää Conwayn lain seuraukset. Löysällä parafraasillani tämä laki sanoo, että luomamme tuotteet ja siihen käyttämämme prosessit, mukaan lukien DevOps, osoittautuvat rakenteellisiksi samalla tavalla kuin organisaatiomme.
”Jos organisaatiossa on paljon siiloita ja ohjaus vaihtaa omistajaa monta kertaa ohjelmistojen suunnittelun, rakentamisen ja julkaisun aikana, skaalausvaikutus on nolla tai lyhytikäinen. Jos organisaatio rakentaa monialaisia tiimejä tuotteiden ympärille, jotka rahoitetaan markkinalähtöisesti, onnistumisen mahdollisuudet kasvavat dramaattisesti.
"Toinen tärkeä skaalauksen näkökohta on näyttää kaikki keskeneräiset työt (WIP, workinprogress) Kanban-levyillä. Kun organisaatiolla on paikka, jossa ihmiset näkevät nämä asiat, se rohkaisee suuresti yhteistyöhön, millä on positiivinen vaikutus skaalautumiseen.
8. Etsi vanhoja arpia
Manuel Pais, DevOps-konsultti ja Team Topologiesin toinen kirjoittaja: "DevOps-käytäntöjen vieminen itse Dev ja Ops -ominaisuuden ulkopuolelle ja niiden soveltaminen muihin toimintoihin on tuskin optimaalinen lähestymistapa. Tällä on varmasti vaikutusta (esimerkiksi manuaalisen ohjauksen automatisoimalla), mutta paljon enemmän voidaan saavuttaa, jos aloitamme toimitus- ja palauteprosessien ymmärtämisestä.
"Jos organisaation IT-järjestelmässä on vanhoja arpia - menettelyjä ja johtamismekanismeja, jotka on otettu käyttöön aikaisempien tapausten seurauksena, mutta jotka ovat menettäneet merkityksensä (tuotteissa, teknologioissa tai prosesseissa tapahtuneiden muutosten vuoksi) - niin ne on ehdottomasti poistettava. tai tasoittaa tehottomia tai tarpeettomia prosesseja automatisoinnin sijaan."
9. Älä lisää DevOps-vaihtoehtoja
Anthony Edwards, Eggplantin toimintajohtaja: "DevOps on hyvin epämääräinen termi, joten jokainen joukkue saa oman versionsa DevOpsista. Ja ei ole mitään pahempaa, kun organisaatiolla on yhtäkkiä 20 erilaista DevOps-laitetta, jotka eivät tule hyvin toimeen keskenään. Jokaisella kolmesta kehitystiimistä ei voi olla omaa erityistä rajapintaa kehityksen ja tuotehallinnan välillä. Tuotteilla ei myöskään pitäisi olla omia ainutlaatuisia odotuksia palautteen käsittelyyn siirrettäessä tuotantosimulaattoriin. Muuten et koskaan voi skaalata DevOpsia."
10. Saarnaa DevOpsin liikearvoa
Steve Newman, Scalyrin perustaja ja puheenjohtaja: "Työskentele DevOpsin arvon tunnistamiseksi. Opi ja puhu vapaasti tekemäsi eduista. DevOps säästää uskomatonta aikaa ja rahaa (ajattele vain: vähemmän seisokkeja, lyhyempi keskimääräinen palautumisaika), ja DevOps-tiimien on väsymättä korostettava (ja saarnattava) näiden aloitteiden merkitystä liiketoiminnan menestykselle. Näin voit laajentaa kannattajapiiriä ja lisätä DevOpsin vaikutusvaltaa organisaatiossa.”
BONUS
Päälle Omat DevOpsimme saapuvat syyskuun 13. päivänä - kyllä, Red Hatilla ohjelmistovalmistajana on omat DevOps-tiimit ja -käytännöt.
Insinöörimme Mark Birger, joka kehittää sisäisiä automaatiopalveluita muille ryhmille koko organisaatiossa, kertoo oman tarinansa selkeällä venäjällä - kuinka Red Hat DevOps -tiimi siirsi sovelluksia Ansiblen hallinnoimista Hat Virtualization -virtuaaliympäristöistä täysimittaiseen konttimuotoon osoitteessa OpenShift-alustalla.
Mutta se ei ole kaikki:
Kun organisaatiot ovat siirtäneet työmäärät säilöihin, perinteiset sovellusten valvontamenetelmät eivät välttämättä toimi. Toisessa puheessa selitämme motivaatiomme kirjaustavan muuttamiseen ja näytämme jatkoa tielle, joka johti meidät nykyaikaisiin kirjaus- ja seurantamenetelmiin.
Lähde: will.com