Vaikka DevOps-metodologia on ollut kanssamme jo jonkin aikaa, se on silti kiivaan keskustelun keskipiste. Yritykset haluavat sitä, mutta eivät ole varmoja siitä, miten lähestyä sitä.
DevOps on kaikkialla . Ja vaikka se on mielenkiintoinen trendi, se tulisi sovittaa tuotteisiin, ei päinvastoin.
Mutta jotkut ihmiset eivät näe sitä niin. Minulta kysytään usein esimerkiksi: 'Luuletko, että meidän pitäisi alkaa käyttää Dockeria, tai hypätä suoraan Kubernetesiin?' Tällaiset kysymykset ovat merkityksettömiä edes tietämättä, mistä tuotteessa on kyse.
Kaikki nämä hienot ehdot - pilvi, Kuvernöörit , säilöt, kokoonpanon hallinta, Infrastructure-as-Code - lupaavat jonkin verran parannusta. Mutta heidän on DevOps aivan kuten teleskoopit ovat tähtitieteessä. Ne voivat olla hyödyllisiä, mutta ne eivät ole välttämättömiä.
Ytimessä DevOps pyrkii poistamaan kuilun asiakkaan tilaaman ja kehitystiimin toimittaman välillä. Painotetaan lyhyitä julkaisusyklejä, iteratiivista lähestymistapaa suunnitteluun ja toistuvien vaiheiden automatisointia. Mikä on mielestäsi tärkeintä saada ne todellisuuteen?
Jos sanoit 'hyvä viestintä', olet oikeassa. Työkalut ovat kaikki kunnossa. Mutta ne ovat vain niihin sijoittamansa rahan arvoisia, kun ne parantavat viestintää.
Yksi viestinnän osa on tietää, mitä tarvitaan työn tekemiseen. Ja työ ei tarkoita, että 'koodi on sitoutunut arkistoon'. Ajattele sitä pikemminkin 'asiakas näki tuotannon muutoksen ja hyväksyi sen'.
Heti kun tämä ensimmäinen vaihe on määritetty ja kaikki tietävät, mitä pitää tapahtua, on paras aika kirjoittaa se muistiin. Missä? No, olen valtava kannattaja ylläpitämään README.md Jokainen tiimissä oleva henkilö voi aina kurkistaa sen sisälle ja tietää projektin tilan, ja se on luonnollinen tapa projektin uusille tulijoille.
Automaatio, seuraava vaihe README: n kirjoittamisen jälkeen, on valinnainen. Se on kuitenkin luonnollinen kasvu prosessin dokumentoinnissa. Ja kyllä, automaatio on se, mikä tulee usein mieleen, kun ajatellaan DevOpsia.
Odota hetki ... automaatio on valinnaista DevOpsissa? Eikö DevOps ole sen henkilön osasto, joka suorittaa käyttöönottoja?
Mitä ihmiset yleensä ymmärtävät 'DevOps-insinööri'-termillä, on joko ohjelmistojen luotettavuusinsinööri, alustainsinööri tai toimintojen automaatioinsinööri. Nämä ovat kaikki kelvollisia rooleja, jotka mahdollistavat DevOpsin harjoittamisen, mutta yhteisnimen 'DevOps-insinööri' käyttö voi olla hieman epäselvää.
Joten katsotaanpa lähemmin DevOpsia itseään.
Ensin haluan näyttää, mikä DevOps ei ole:
Tämän tietäessä tiedät nyt, että et voi yksinkertaisesti 'palkata DevOps-insinööriä' tai 'luoda DevOps-tiimiä' yrityksessä varmistaaksesi, että olet tulevaisuuden varma. DevOps muistuttaa ketterää kehitystä. Voisitko palkata ketterän kehittäjän? sellaisenaan ? Luultavasti ei. Joko kehität tuotetta ketterällä tavalla tai et.
Kuinka sitten DevOpsia voidaan kuvata? Se on metodologia. Tai ehkä a kulttuuri . Ehkä jopa henki. Tuotteen tekeminen DevOps-periaatteiden mukaisesti tarkoittaa, että kaikilla - olkoon kehittäjä, operatiivisinsinööri tai tuotepäällikkö - on yhteinen visio ylläpitämällä sitä viestinnän kautta. Pienemmässä määrin se tarkoittaa myös sitä, että kaikki käyttävät samoja työkaluja. Näiden työkalujen ei ole tarkoitus auttaa yksittäisiä ihmisryhmiä. Niiden on tarkoitus työntää tuotetta eteenpäin.
Tämän käsitteen noudattaminen edellyttää vakavaa ajattelutavan muutosta, mikä on suurin este. Miksi niin? Se johtuu siitä, että ihmisten on poistuttava mukavuusalueestaan ja aloitettava yhteistyö ihmisten kanssa, joilla on erilainen osaaminen. Kehittäjien on yhtäkkiä opittava pilven toiminta ja aloitettava oman koodinsa käyttöönotto. Toiminnot, joiden ihmisten on hylättävä manuaaliset asetukset ja aloitettava koodaus. Kaikkien on opittava uusia käsitteitä. Kaikilla on uudet vastuut .
Tämä ei ole helppoa, mutta hyvällä viestinnällä ja yhteisellä tavoitteella se on melko saavutettavissa. Tähän tiedonantoon kuuluu kulttuurin luominen, kevyiden prosessien asettaminen ja asianmukaisen dokumentoinnin ylläpito.
Luultavasti et koskaan ajatellut sitä sillä tavalla. Mutta suurin osa DevOpsiin yleisesti liittyvistä työkaluista on dokumentointityökalut :
Dockerfile s siinä asiakirjassa, kuinka tietyt mikropalvelut rakennetaan ja määritetäänKaikki nämä hienot käsitteet tekevät periaatteessa yhden asian: ne auttavat tiimin jäseniä kommunikoimaan paremmin dokumentoimalla prosessit. Nämä prosessit voidaan sitten ajaa manuaalisesti tai automatisoida. Tärkeää on, että jokainen projektin sidosryhmä pystyy seuraamaan niitä.
Prosessien dokumentoinnilla koodina on yksi suuri etu tavallisiin käyttöohjeisiin verrattuna. Koodi voidaan tarkistaa ja käyttäytyy ennakoivasti. Kun otetaan huomioon sama tulo, se tuottaa saman tuotoksen.
Kirjallisilla ohjeilla sinulla on niin monta tulkintaa kuin lukijoita. Jos kirjoitat epäselviä tai epämääräisiä asiakirjoja, niiden lukija täyttää aukot. Asia on, että sinulla ei ole hallintaa aukkoihin.
Se on paljon yksinkertaisempi koodilla. Ilman konkreettisia vaiheita ohjelma lakkaa toimimasta. Nämä konkreettiset vaiheet ovat yksi keskeinen osa DevOps-viestintää.
Kirjassa Phoenix-projekti olemme todistamassa äskettäin ylennetyn johtajan ongelmia, jonka tehtävänä on toteuttaa iso projekti. Koska kukaan ei tiedä mitä tapahtuu, kaikki taistelevat tulipaloja ilman suurta edistystä. Kirjan alaotsikossa mainitaan, että se on tarina DevOpsista. Olen samaa mieltä.
Mutta mielenkiintoista on, että koko kirjan ajan ei esitetä yhtä uutta työkalua. Voitko saavuttaa DevOps-tilan parantamalla pelkästään viestintää? Kirjan päähenkilöt tekivät sen, joten on toivoa myös sinulle!
Vaikka päähenkilöiden lähestymistapaa voidaankin pitää vanhana kouluna (todellisten paperikorttien käyttäminen oikean virheenseurantajärjestelmän sijasta), asiat alkavat muuttua parempaan suuntaan vasta, kun kaikki osapuolet alkavat puhua keskenään.
Saatat ajatella, että kehityksen ja toimintojen välistä yhteistyötä voidaan parantaa vain luomalla parempia rajapintoja niiden välille, kuten palvelutasosopimukset tai tapauskohtaiset lokit. Mutta päinvastoin. Rikkomalla rajapinnat ja tuomalla empatiaa ja yhteistä syytä sinulla on joukkue, joka pyrkii kohti yhteistä päämäärää.
Ihannetapauksessa jokaisella tuotteella tulisi olla vain yksi tiimi: tuotetiimi.
Olin kerran kehitystiimissä, jossa yhteinen tavoite muiden joukkueiden kanssa puuttui. Kehitystiimi halusi työntää mahdollisimman monta muutosta. Validointiryhmän tehtävänä oli estää vikojen syntyminen. Heillä oli erilaisia johtajia ja heitä arvioitiin erikseen.
Lopputulos? Kehitys ja validointi pelasivat ping-pongia vikaraporteilla. Kun vahvistus löysi testin, joka ei läpäissyt, kehitystoiminta oli kiinnostuneempi löytämään puutteita itse testikoodista kuin yrittämään tehdä omasta koodistaan virheettömiä.
Vapautussykli kasvoi tietysti, koska raporttien, vastaraporttien ja niin edelleen täyttämiseen vaadittiin valtavia yleiskustannuksia. Mitä useimmat näyttivät jättävän tunnustamatta, oli se, että tuotteen suhteen molemmilla joukkueilla tulisi olla yhteinen tavoite ja työskennellä yhdessä sen saavuttamiseksi. Mutta asianmukaisen yhteistyön ja siilomentaalisuuden puute teki siitä erittäin vaikeata huomata.
Lean tuotannon ajattelutapa, joka innoitti Ketterän ohjelmistokehityksen manifestin ( joka puolestaan esitteli meidät DevOps: iin ) oli jätteiden torjunta. Jätteellä tarkoitamme kaikkea, mikä ei ole suoraan merkityksellistä asiakkaan tilaamien tuotteiden kanssa. Keskeneräiset keskeneräiset työt ovat tuhlausta. Jokainen vaihe prosessista, joka ei johda selvästi päästöihin, on tuhlausta.
Mutta jätteet voidaan nähdä vain korkealta. Jotkin menettelyt saattavat tuntua välttämättömiltä yhden ryhmän sisällä. Tuotteen näkökulmasta ne voivat kuitenkin olla hyödyttömiä.
Jotta voit selvittää, mitkä ponnistelut ovat hukkaan, sinun on yhdistettävä voimasi ja otettava huomioon toimitetun tuotteen elinkaari. Sinun on myös ajateltava asiakkaan näkökulmasta. Onko tämä ominaisuus jotain, mitä asiakas halusi? Jos ei, voit myös ohittaa sen tällä hetkellä. Ovatko prosessisi yksinkertaisia ja kevyitä? Katso syvällisemmin etenkin niitä, jotka ylittävät joukkueen rajat.
Haluatko varmistaa, että tuotteen kehitys on mahdollisimman tehokasta? Kutsu ulkopuolinen katsomaan miten työskentelet. Henkilö, joka ei ole osa tiimiäsi, voi esittää oivaltavia kysymyksiä ja löytää uusia parannettavia alueita.
CALMS on erittäin tarkka kuvaus siitä, miten DevOpsia tulisi käyttää:
Huomaa, että se on muodostettu voileivän tavoin. Kolme keskiarvoa ovat teknisempiä, kun taas ulkoiset arvot liittyvät pehmeisiin taitoihin. Mutta kaiken kulttuurin perusta on viestintä: Vaihdamme arvojamme ja vakaumuksiamme muiden tiimin jäsenten kanssa, kunnes pääsemme yksimielisyyteen siitä, miten asioiden tulisi toimia.
Sama koskee jakamista. Ruoan, kuten ruoan, jakaminen ei vaadi viestintää. Itse ele voidaan kuitenkin nähdä myös viestintänä. 'Välitän sinusta, joten jaan kanssasi.' Emme halua rajoittaa vain sanallista viestintää.
Ideoiden ja työkalujen jakaminen vaatii kuitenkin viestintää. Kuinka meidän pitäisi jakaa ne? Minne me laitamme ne? Ovatko ne hyödyllisiä jokaiselle tiimin jäsenelle vai vain pienemmälle ryhmälle?
Jos keskityt vain teknisempiin näkökohtiin - Automaatio, Lean ja Mittaus -, DevOps-kohta puuttuu. Mikä on niin hyvää, kun käytössä on automaattinen käyttöönotto-komentosarja, jota kukaan ei koskaan käytä kirjoittajan vieressä? Jos käsikirjoitus säästää häntä jonkin aikaa, se voi olla perusteltua. Mutta kuvittele, kuinka paljon aikaa voitaisiin säästää, jos kaikki jakavat tämän käsikirjoituksen. Tämä kertoo jotain jätteiden torjunnasta!
Jos keskityt vain teknisempiin näkökohtiin - Automaatio, Lean ja Mittaus -, DevOps-kohta puuttuu. TweetJotkut sanovat, että DevOps tuo toiminnan lähemmäksi kehitystä. Tämä on totta, mutta se ei ole koko totuus. Kun se tehdään oikein, DevOps tuo jokaisen yksikön lähemmäksi. Sen avulla yritykset ja asiakkaat voivat nähdä, mitä kehitys tekee, lähes reaaliajassa.
Tämä lyhyempi palautesilmukka hyödyttää kaikkia sidosryhmiä. Teos on yleensä näkyvämpi, ja myös kehittäjät näkevät helposti, kuinka asiakkaat käyttävät tuottamaansa koodia. Perinteisellä käyttöönotolla voit odottaa useita kuukausia, ennen kuin joku huomaa virheitä tai vaatimuksia. Jatkuvan käyttöönoton avulla jokainen voi reagoida kaikkiin ongelmiin niiden syntyessä. Kehittäjät, toiminnot, liiketoiminta ja asiakkaat voivat istua yhdessä huoneessa ja muokata toimivaa sovellusta nykyisten tarpeiden mukaan.
Tietenkin tarvitaan kaikki työkalut sen mahdollistamiseksi.
Mutta mikään työkalu ei voi korvata hyvää viestintää ja empatiaa yrityksen sisällä. Havaitsin kerran tuotteen, jossa rakennusprosessi oli yhden ryhmän omistama, kun taas toimitetun koodin omisti toinen.
Koontijärjestelmän ongelmat olivat yleisiä. Kehittäjät eivät olleet varmoja sen käytöstä. Se perustui vakiotyökaluihin, mutta ne räätälöitiin niin, että kaikki verkossa olevat asiakirjat osoittautuivat hyödyttömiksi.
Kaikki halusivat parantaa tilannetta, mutta joukkueiden välillä ei ollut ymmärrystä. Tämä tarkoitti sitä, että molemmat osapuolet esittivät uusia työkaluja neuvottelematta toisen osapuolen kanssa. Tämä vain kasvatti kuilua sen sijaan, että sulkisi sen.
Jos haluat aloittaa DevOps-muunnoksen organisaatiossasi, aloita parantamalla viestintätapaa. Älä vain oleta ratkaisua: Aivoriihi avoimella mielellä ensimmäinen . Sitten saatat huomata, että esimerkiksi työkalutuki ei riitä tarpeisiisi. Silloin voit harkita nykyisten työkalujen muokkaamista tai uusien käyttöönottoa - muuten olet todennäköisesti lisäämässä alkuperäistä ongelmaa.
Johdannossa mainitsin kysymyksen, jonka asiakkaat usein kysyvät minulta: 'Pitäisikö minun mennä Dockerin kanssa vai pitäisikö minun hypätä suoraan Kubernetesiin?' Kun olet lukenut tämän artikkelin, voit nähdä, että tällaiseen kysymykseen vastataan parhaiten, kun olet suorittanut jonkin valmistelutyön - DevOps-ajattelutavan avulla.
Jos tiedät, että tuotetiimisi ymmärtää DevOpsin edut itselleen ja asiakkaalle, tiimi ja asiakas voivat aloittaa asettamalla odotuksensa. Sitten insinöörit voivat selvittää kehitys- ja käyttöönottomallin. Lopuksi voit määrittää tarvittavat työkalut.
Kun kaikki vaatimukset on dokumentoitu, teknologiavalintoja on paljon helpompi tehdä.
Kannatan kaikkia upeita DevOps-automaatiotyökaluja, jotka tekevät työstämme helpompaa ja hallittavampaa. Mutta päivittäinen työmme on työtä ihmiset . Panostetaan jonkin aikaa parantamaan DevOpsin parhaiden käytäntöjen tätä näkökohtaa sen sijaan, että saisimme uuden teknologiasertifikaatin.
DevOps-tiimit yhdistävät kehityksen ja toiminnan toimittaa ohjelmistojen lisäykset paljon nopeammin ja vankemmalla tavalla kuin aiemmin oli mahdollista.
DevOps-tiimin vastuualueisiin kuuluu laaja poikkileikkaus rooleista: laadunvalvontasuunnittelijat, pilvialustan insinöörit, sivuston luotettavuusinsinöörit, automaatioinsinöörit, tuotesuunnittelijat, tuotekehittäjät, tuotteen omistaja ja ohjelmistoarkkitehti ovat kaikki osa sitä.
DevOpsin periaatteina ovat jätteiden välttäminen, asiakaslähtöinen toiminta, vastuu kaikesta toiminnasta, toimintojen väliset itsenäiset tiimit, jatkuva parantaminen, hyvä viestintä ja mahdollisuuksien mukaan automaatio.
DevOps on tapa tuoda yhteen ihmiset kehitys- ja operatiivisista ryhmistä auttamalla heitä kommunikoimaan paremmin - sekä suullisesti että käyttämällä yhteisiä prosesseja ja työkaluja.
DevOpsia käytetään ketterien tiimien valtuuttamiseen korkealaatuisten ohjelmistojen lisäysten toimittamiseen.
