DevOps (Development eli kehitys ja Operations eli tuotanto) on ketterä malli palveluiden tuottamiseen. Se pyrkii edistämään palveluiden kehitys- ja tuotantotoimintojen keskinäistä vuoropuhelua. Tavoitteena on erityisesti parempi ja nopeampi kyky toimittaa muutoksia tuotantoon.
DevOps on erinomainen ajattelumalli, mutta ongelmaksi saattaa muodostua, miten se integroidaan organisaatioiden toiminnan ytimeen.
Tätä ongelmaa ratkaisemaan Google kehitti SRE:n (Site Reliability Engineering), joka sitoo Devin ja Opsin yhteen. Menetelmän juuret johtavat vuoteen 2003, jolloin Ben Treynor Sloss perusti seitsemän kehittäjän tiimin ylläpitämään Googlen web-palveluja. SRE-ammattilaisten kysyntä kasvaa jatkuvasti sekä kansainvälisesti että Suomessa. Mutta mistä siinä on kyse käytännössä?
SRE kuroo umpeen kuilun Devin ja Opsin välillä
SRE soveltaa DevOps-periaatteita kehitettäessä järjestelmiä ja ohjelmistoja, jotka auttavat lisäämään palveluiden luotettavuutta ja suorituskykyä. DevOps-ajattelutavan ja -taitojen soveltaminen ohjelmiston luotettavuuteen auttaa vähentämään siiloja kehityksen ja toimintojen välillä jakamalla vastuun luotettavuus- ja suorituskykyongelmien havaitsemisesta kehityksen elinkaaren varhaisessa vaiheessa. Kehittäjien, toimintojen ja tuotteiden omistajien yhteistyön avulla sivuston luotettavuusinsinöörit voivat määrittää ja täyttää palvelutaso- ja käytettävyystavoitteet.
Automaatio keskiössä
SRE:n päätavoitteena on vähentää päällekkäistä työtä ja päällekkäistä tietoa mahdollisimman paljon. SRE-tiimit keskittyvät manuaalisten tehtävien automatisointiin, kuten käyttöoikeuden ja infrastruktuurin valmisteluun, tilien määrittämiseen ja itsepalvelutyökalujen rakentamiseen, jotta kehittäjät voivat keskittyä ominaisuuksien toimittamiseen ja toimintatiimit voivat keskittyä infrastruktuurin hallintaan.
Keskittyminen prosessien automatisointiin on entistäkin kriittisempää, kun organisaatiot ottavat käyttöönsä enemmän pilvinatiivia teknologiaa, kuten kontteja, kubernetes ja palvelimettomia sovelluksia. DevOps-tiimien on jatkuvasti mukauduttava käyttämällä ketteriä menetelmiä ja nopeita toimitusmalleja, kuten CI / CD. Nämä menetelmät lisäävät tehokkuutta ja nopeutta, mutta ne vaativat myös johdonmukaisia, toistettavia prosesseja, jotka vähentävät riskejä ja tarjoavat palautesilmukoita mittaustoimintaan, jotta tiimit voivat tunnistaa parannuskohteita.
”Shift left” -ajattelutapa
Palveluiden luotettavuussuunnittelu on jatkuvasti kehittyvä tieteenala, joka tarjoaa mahdollisuuksia rakentaa toimitusputkeen menetelmiä, käytäntöjä ja prosesseja, joiden avulla sovellukset voivat “korjata automaattisesti” tai jotta käyttäjät voivat ratkaista omat ongelmansa. SRE:ssä ”Shift left” tarkoittaa, että luotettavuus leivotaan sisään jokaiseen prosessiin, sovellukseen ja koodin muutokseen.
Tavoitteena on ryhtyä varhaisiin, ennakoiviin toimiin laadun ja luotettavuuden varmistamiseksi heti alusta alkaen. SRE voi myös laajentua koordinoimaan testausta koko yrityksen tasolla jatkuvan ohjelmistointegraation ja -toimituksen tueksi.
Palvelutasotavoite kertoo, kuinka paljon rapatessa saa roiskua
Yksi SRE:n tavoitteista on optimoida aika, jona palvelut ovat alhaalla. Palvelutasotavoite riippuu usein kaupallisista näkökulmista. Esimerkiksi jos Ihannetavoitteena on, että palvelu toimii moitteettomasti 99,999 % ajasta, se tarkoittaa, että palvelukatkoksia on vuoden aikana vain hiukan yli 5 minuuttia. Toisaalta toiselle palvelulle riittää, että se toimii moitteettomasti vain 99,1 % ajasta.
Tavoitteita hyödynnetään SRE:ssä myös käänteisestä näkökulmasta: kuinka paljon rapatessa saa roiskua, kun uusia ominaisuuksia tuodaan palveluun. Toisin sanoen palvelutasotavoitteet määräävät kehitystiimin virhebudjetin (engl. Error Budget).
SRE:t rakentavat palveluita ja työkaluja toiminnan ja tuen avuksi
Sovitun palvelutasotavoitteen saavuttamiseksi SRE-tiimit rakentavat palveluita, jotka parantavat toimintaa ja helpottavat julkaisuprosessia. Ne voivat olla mitä tahansa valvonnasta koodimuutosten tekemiseen tuotannossa. Palvelun luotettavuusinsinöörit rakentavat usein mukautettuja työkaluja alusta alkaen vastaamaan ohjelmiston toimituksen tai tapahtumienhallinnan työnkulun erityistarpeita.
SRE-lähestymistavan omaksuminen edellyttää myös, että tiimit standardoivat käyttämäänsä teknologiaa ja työkaluja. Standardointi helpottaa toimintojen hallintaa ja vähentää yhteensopimattomien teknologioiden hallinnasta aiheutuvaa taakkaa, mikä vapauttaa tiimit yhteistyöhön ja innovoimiseen.
Tarvitaan myös kulttuurista muutosta
Koska SRE on toimintamalli, se edellyttää muutosta siihen, miten eri tiimit kommunikoivat keskenään, ratkovat ongelmia ja toteuttavat ratkaisuja. Menestyksekkään SRE-kulttuurin omaksuminen edellyttää, että organisaatiot ottavat käyttöön uusia lähestymistapoja riskienhallintaan. Se tarkoittaa myös investointeja oikeaan osaamiseen sekä osaamisen kehittämiseen. Tarvitaan lahjakkaita osaajia, SRE-asiantuntijoita, jotka omaksuvat nopeasti uutta ja osaavat viedä omaksumansa asiat ketterästi käytäntöön.
SRE:t työskentelevät DevOpsin elinkaaren eri vaiheissa
Kehitys- ja testaustiimeille SRE:n asiantuntijat kehittävät automaatiota, joka auttaa kehittäjiä testaamaan varhaisessa vaiheessa. Järjestelmätasolla SRE-asiantuntijat kehittävät työkaluja, jotka koordinoivat julkaisuja ja lanseerauksia, arvioivat järjestelmäarkkitehtuurin valmiutta ja täyttävät järjestelmän laajuiset SLO:t. Hallintotasolla SRE-asiantuntijat auttavat määrittämään ja valvomaan yritysarkkitehtuuria, luomaan parhaita käytäntöjä ja valitsemaan työkaluja ja resursseja, jotka tukevat yrityksenlaajuista luotettavuutta.
Haluatko oppia lisää?
Tervetuloa Site Reliability Engineering (SRE) Foundation℠ -valmennukseen.