Site Reliability Engineering (suomeksi)

Viimeisen 15 vuoden aikana IT-organisaatiot ovat omaksuneet uusia menetelmiä kehittää sovelluspalveluita pystyäkseen vastaamaan ripeästi jatkuvasti kehittyviin tarpeisiin. Näistä suosituimmaksi on noussut DevOps-kulttuuri, joka korostaa yhteistyötä yhdistämällä sovellusten ja sovellusympäristöjen kehityksen.

Samoihin aikoihin kun DevOps otti tuulta alleen, Google oli omaksunut oman menetelmän kehittää ja hallita sovelluspalveluita. Google käyttää tästä termiä Site Reliability Engineering (SRE). Tämän menetelmän juuret johtavat vuoteen 2003, kun Ben Treynor Sloss perusti seitsemän kehittäjän tiimin ylläpitämään Googlen web-palveluja. Hänen mukaansa SRE on sitä, mitä tapahtuu kun kysytään sovelluskehittäjää suunnittelemaan IT-operaatiotiimiä. Tänä päivänä SRE:iä hyödyntää Googlen lisäksi mm. Netflix, Amazon, ja Microsoft.

Kehitystyön ohjaaminen riskejä hallitsemalla

SRE:in kantavana periaatteena toimii riskienhallinta. Sen sijaan, että yritettäisiin optimoida jokaisen järjestelmän luotettavuus maailman tappiin asti, hyväksytään järjestelmien toimivan tiettyjen palvelutasotavoitteiden (engl. Service Level Objective, SLO) puitteissa.

Palvelutasotavoitteet ovat tyypillisesti lähtöisin tuotteen kaupallisista näkökulmasta. Esimerkiksi eräällä palvelulla voi olla tavoitteena olla alhaalla maksimissaan 4 minuuttia kuukaudessa (n. 99.99 % ylhäällä), kun toinen voi olla jopa päivän kuukaudessa alhaalla (n. 96.66 % ylhäällä).

Tavoitteita hyödynnetään SRE:ssä myös käänteisestä näkökulmasta: kuinka paljon voi rapatessa roiskua, kun uusia ominaisuuksia tuodaan palveluun. Toisin sanoen palvelutasotavoitteet määräävät kehitystiimin virhebudjetin (engl. Error Budget).

Mitä matalampi palvelutasotavoite, sitä enemmän kehitystiimillä on varaa tuottaa virheitä muutoksia julkaistessa. Kun tavoitteissa ei pysytä, ainoastaan virheitä korjaavat toimenpiteet sallitaan.

Riskejä on kuitenkin mahdoton hallita, jos luotettavuutta ei voida havaita. Tarvitaan siis keino mitata, kuinka hyvin palvelu pysyy sille asetettujen tavoitteiden sisällä. Käytännössä mittaus voidaan pohjata palveluista saatavaan metriikka- ja lokidataan.

Mittaa, korjaa, automatisoi.

IT-operaatio automaation kautta

SRE:ssä palvelujen ylläpitoa kohdellaan sovelluskehityshaasteena. Sen sijaan, että kehittäjät itse käsin korjaavat palveluissa havaitut ongelmat, tavoitteena on automatisoida mahdollisimman moni ylläpitotehtävistä. Ilman automatisointia ylläpitäjien määrää on kasvatettava palvelun järjestelmien kasvaessa. Yksi tapa hallita tilannetta on asettaa raja puurtamiselle (engl. toil), eli manuaaliselle ylläpitotehtäville.

Esimerkiksi Googlen SRE-kehittäjät saavat puurtaa maksimissaan puolet kehitykseen käytetystä ajasta, ja loput ajasta on käytettävä ratkaisujen automatisointiin. Tällä tavalla varmistetaan, että palvelu kehittyy koko ajan eteenpäin eikä jää junnaamaan vikojen korjaamiseen.

Kaikki SRE:iin liittyvä työ hoidetaan yhteistyönä kehitystiimin kanssa. SRE-kehittäjät liittyvät osaksi kehitystiimiä ja jakavat työkalut, tekniikat ja lähdekoodit keskenään. Palvelujen luotettavuutta edistävän kehityksen lisäksi SRE-kehittäjät kouluttavat muun kehitystiimin ottamaan haltuun SRE-periaatteet ja -toimintatavat.

Koska SRE:ssä otetaan huomioon koko palvelun luotettavuus, SRE-kehittäjien taustat juontuvat yleensä sovelluskehityksen tai IT-operaation puolelta. Parhaimmillaan tiimi sisältää jäseniä useista taustoista koko palvelun kattamiseksi. SRE-kehittäjille yhteinen taito on kyky automatisoida eli ohjelmoida ratkaisuja.

Lisää tietoa SRE:stä

SRE:n tarina ei pääty pelkkiin periaatteisiin. Niiden ympärille on rakentunut laaja kokoelma käytänteitä niin tuotanto-ongelmien tehokkaaseen ratkaisemiseen kuin luotettavien ja itsekorjautuvien järjestelmien kehittämiseen.

Alan tärkeimpänä teoksena tunnetaan vuonna 2016 julkaistu kirja, Site Reliability Engineering, joka kertoo Googlen näkemyksen SRE:stä ja kuinka Google hyödyntää SRE:iä heidän sovelluspalveluiden kehityksessä.

Me Polar Squadilla olemme omaksuneet SRE:n osaksi kulttuuriamme. Jos haluat tietää lisää miten voit hyödyntää SRE:iä organisaatiossasi, ota meihin yhteyttä.