Agentic SRE

Site Reliability Engineering eli SRE tekee verkkopalvelujen luotettavuudesta mitattavaa ja kehitettävää. Agentic SRE tuo tähän työhön tekoälyagentteja, jotka voivat kerätä tietoa, tutkia häiriöitä ja suorittaa rajattuja korjaustoimia. Azure SRE Agent ja OpenSRE edustavat kahta erilaista tapaa toteuttaa tätä.

Mitä Site Reliability Engineering on?

Vakiintunut termi on Site Reliability Engineering, vaikka aiheesta puhutaan myös palvelujen luotettavuuden kehittämisenä. Googlen kehittämässä SRE-ajattelussa tuotantopalvelujen operointiin sovelletaan ohjelmistokehityksen menetelmiä: toistuvaa käsityötä automatisoidaan, luotettavuutta mitataan ja häiriöistä opitaan järjestelmällisesti.

SRE ei ole pelkkä valvontatyökalu tai päivystysrooli. Se kattaa saatavuuden, vasteajat, kapasiteetin, muutosten turvallisuuden ja palautumisen. Luotettavuutta tarkastellaan käyttäjän kokemuksen kautta: palvelin voi olla käynnissä, vaikka asiakas ei onnistu tekemään tilausta.

Miksi SRE:tä tarvitaan?

Monimutkaisessa palvelussa häiriön syy ei aina näy ensimmäisestä hälytyksestä. Hidas verkkokaupan kassa voi liittyä tietokantaan, maksupalveluun, verkkoon, kapasiteettiin tai juuri julkaistuun muutokseen. Ilman yhteisiä mittareita ja toimintatapoja ylläpito muuttuu helposti samojen ongelmien toistuvaksi sammuttamiseksi.

SRE auttaa tasapainottamaan kehitysnopeuden ja vakauden. Tavoitteena ei ole luvata kaikille palveluille täydellistä virheettömyyttä, vaan sopia käyttötarkoitukseen sopiva luotettavuustaso ja tehdä sen saavuttamisesta mitattavaa. Demokaupan ja kriittisen terveydenhuollon järjestelmän riskirajat eivät ole samat.

Keskeiset käsitteet: SLI, SLO ja virhebudjetti

• SLI (Service Level Indicator): laatua kuvaava mittari, esimerkiksi onnistuneiden pyyntöjen osuus tai kassatoiminnon vasteaika.
• SLO (Service Level Objective): mittarille asetettu tavoite määritellyllä aikavälillä.
• Virhebudjetti (error budget): SLO:n sallima epäonnistumisen määrä. Jos onnistumistavoite on 99,9 prosenttia, epäonnistumisten budjetti on 0,1 prosenttia samalla mittausrajauksella.
• SLA (Service Level Agreement): palvelutasoa koskeva sopimus, johon voi liittyä hyvityksiä. Se ei ole sama asia kuin tiimin sisäinen SLO.
• Toil: toistuva operatiivinen käsityö, joka ei tuota pysyvää parannusta ja kasvaa palvelun mukana.

Jos virhebudjetti kuluu liian nopeasti, tiimi voi sovitun käytännön mukaan rajoittaa riskialttiita julkaisuja ja keskittyä luotettavuuteen. Mittauksen rajaus on tärkeä: pyyntöjen onnistumisprosenttia ei voi suoraan muuntaa katkominuuteiksi ilman aikapohjaista saatavuusmittaria.

Mitkä ovat SRE:n hyödyt?

• Parempi asiakaskokemus: huomio kohdistuu asiakkaalle tärkeisiin toimintoihin, ei vain palvelimien tilaan.
• Nopeampi palautuminen: selkeät vastuut, laadukkaat hälytykset ja harjoitellut toimintaohjeet auttavat palauttamaan palvelun.
• Vähemmän käsityötä: automatisointi vapauttaa aikaa pysyville parannuksille.
• Turvallisemmat julkaisut: asteittaiset käyttöönotot, testit ja palautusmenettelyt rajaavat virheiden vaikutusta.
• Yhteinen kieli: kehitys, operointi ja liiketoiminta voivat keskustella samoista luotettavuustavoitteista.
• Kustannusten hallinta: kapasiteettisuunnittelu ja resurssien mittaaminen auttavat välttämään tarpeetonta ylikapasiteettia.

Hyödyt eivät synny pelkästään työkalun asentamisesta. Ne vaativat omistajuutta, laadukasta telemetriaa ja sovittuja toimintatapoja.

Mitä Agentic SRE tarkoittaa?

Agentic SRE tarkoittaa työnkulkuja, joissa tekoälyagentti ei vain vastaa kysymykseen vaan etenee useassa vaiheessa: hakee lokit ja mittarit, tarkistaa julkaisut, muodostaa hypoteesin, hankkii lisänäyttöä ja ehdottaa toimenpidettä. Sallituissa rajoissa se voi myös suorittaa toiminnon ja tarkistaa tuloksen.

Agentti voi esimerkiksi havaita vasteaikojen kasvaneen julkaisun jälkeen, tutkia muutoksen ja ehdottaa palautusta aiempaan versioon. Ajallinen yhteys ei kuitenkaan todista juurisyytä. Johtopäätösten pitää nojata tarkistettavaan näyttöön, ja korjauksen onnistuminen on vahvistettava palvelun mittareista.

Agentti ei korvaa palvelun omistajaa tai päivystäjää. Vastuu tuotantoympäristön muutoksista pysyy organisaatiolla.

Azure SRE Agent: agenttipohjainen operointi

Microsoftin tuotteen nimi on Azure SRE Agent. Se yhdistää Azure-resurssien, valvonnan, häiriöhallinnan ja lähdekoodin tietoja samaan tutkintatyönkulkuun. Agentti voi arvioida todennäköisiä syitä ja ehdottaa tai sallituissa rajoissa suorittaa lieventäviä toimia.

Dokumentaation esimerkissä agentti tutkii muistinkulutuksen nousua, yhdistää sen aiempaan julkaisuun ja ehdottaa uudelleenkäynnistystä tai skaalauksen muutosta. Tämä kuvaa mahdollista työnkulkua, ei takuuta oikeasta diagnoosista.

• Telemetria: Azure Monitor, Application Insights ja Log Analytics sekä konfiguroidut ulkoiset tietolähteet.
• Häiriöhallinta ja lähdekoodi: esimerkiksi PagerDuty, ServiceNow, GitHub ja Azure DevOps.
• Ennakoiva operointi: ajastetut terveystarkistukset ja muut määritellyt operatiiviset tehtävät.
• Laajennukset: skills, mukautetut agentit, Python-työkalut, MCP-liitännät ja agent hooks.
• Hallinta: managed identity, Azure RBAC ja työkalukohtaiset allow-, ask- ja deny-käytännöt rajaavat toimintaa.

Review-tilassa hyväksyntää vaativat kirjoitustoiminnot odottavat ylläpitäjän hyväksyntää. Autonomous-tilassa sallitut toimet voidaan suorittaa ilman odotusta, mutta edelleen määritettyjen oikeuksien ja käytäntöjen sisällä.

Microsoftin GitHub-resurssit

microsoft/sre-agent on tuotteen virallinen yhteisö- ja resurssirepositorio. Se sisältää dokumentaatiolinkkejä, esimerkkiympäristöjä, käytännön laboratorioita ja paikan virheraporteille. Repositorion labs– ja sreagent-templates-hakemistot tukevat kokeiluja.

Resurssirepositorio ei tarkoita, että koko Azure SRE Agent -palvelu olisi avoimen lähdekoodin itse ylläpidettävä ohjelmisto. Repositorion MIT-lisenssi koskee siellä jaettua aineistoa lisenssin ehtojen mukaisesti; palvelun käyttöehdot ja laskutus ovat erillisiä. README kokoaa myös maaliskuun 2026 GA-julkistuksen eli yleisen saatavuuden julkaisuun liittyvät lähteet.

Ennen käyttöönottoa on tarkistettava ajantasainen alueellinen saatavuus, hinnoittelu, tietojenkäsittelyehdot ja integraatiot. Laboratorioiden pilviresurssit voivat aiheuttaa kustannuksia: kokeilut tehdään eristetyssä ympäristössä ja resurssit siivotaan ohjeiden mukaisesti.

Esimerkki: lokivirheestä tutkintaan ja hallittuun deploymentiin

Kuvitellaan verkkopalvelu, jonka uusi versio alkaa palauttaa HTTP 500 -virheitä tietyille pyynnöille. Seuraava viisivaiheinen työnkulku kuvaa, miten Agentic SRE voidaan rakentaa. Tämä on toteutusesimerkki, ei lupaus Azure SRE Agentin tai OpenSRE:n oletusominaisuuksista. Confluence- tai Wiki-haku, koodin muokkaaminen ja CI/CD-toimet edellyttävät erikseen konfiguroituja työkaluja, API- tai MCP-liitäntöjä ja rajattuja oikeuksia. Tarvittaessa SRE-agentti delegoi korjauksen erilliselle koodausagentille.

1. Käynnistys triggerillä tai viiden minuutin ajastuksella. Azure Monitor -hälytys tai muu tapahtumatriggeri käynnistää tutkinnan, kun virheraja ylittyy. Vaihtoehtoisesti ajastettu tehtävä tarkistaa palvelun tilan viiden minuutin välein tuetulla ajastuksella tai ulkoisen ajastimen kautta. Jos poikkeamaa ei ole, ajo päättyy ilman muutoksia. Saman häiriön toistuvat havainnot yhdistetään yhteen tutkintaan, eikä päällekkäisiä korjausajoja sallita.
2. Virheen tarkistus lokeista. Agentti hakee rajatun aikavälin lokit esimerkiksi Application Insightsista tai Log Analyticsista. Se tarkistaa virheviestin, stack tracen, request- tai correlation ID:n ja palveluversion sekä vertaa havaintoja mittareihin ja trace-tietoihin. Esimerkissä puuttuva kenttä näyttää aiheuttavan poikkeuksen uudessa versiossa. Tämä kirjataan hypoteesiksi, kunnes se voidaan toistaa ja todentaa.
3. Taustatiedon haku Knowledgebasesta. Agentti hakee Confluencesta tai Wikistä palvelun runbookin, rajapintasopimuksen, tunnetut ongelmat ja palautusohjeen. Dokumentaatio kertoo, että kenttä voi puuttua vanhojen asiakkaiden pyynnöistä. Agentti liittää tutkintaan lähdelinkit ja tarkistaa ohjeen ajantasaisuuden sekä soveltuvuuden kyseiseen versioon. Dokumentin sisältö ei saa ohittaa agentin oikeus- tai hyväksyntärajoja.
4. Koodin tutkiminen, korjaus ja build. Agentti lukee GitHubista tai Azure Reposista tuotannossa ajettavan commitin ja siihen johtaneet muutokset. Eristetyssä työhaarassa se tai erillinen koodausagentti lisää virheen toistavan regressiotestin, toteuttaa rajatun korjauksen ja avaa pull requestin. CI-pipeline ajaa testit, tarvittavat tietoturvatarkistukset ja buildin. Epäonnistunut tarkistus pysäyttää etenemisen; tuotannon koodia ei muokata suoraan.
5. Pipelinen ja deploymentin tarkistus tai korjauksen julkaisu. Agentti tarkistaa viimeisimmän deploymentin version, ajankohdan ja tulokset sekä vertaa niitä palvelun virheisiin. Vihreä pipeline ei yksin todista palvelun toimivan: tarvitaan myös terveystarkistukset ja käyttäjän toimintoja vastaavat testit. Jos uusi deployment osoittautuu vialliseksi, agentti voi ehdottaa tai hyväksytyn runbookin rajoissa käynnistää rollbackin. Vaihtoehtoisesti hyväksytty korjaus viedään testien jälkeen olemassa olevan CI/CD-pipelinen kautta ensin testiympäristöön ja sitten asteittain tuotantoon. Tuotantoon vienti vaatii tässä esimerkissä ihmisen hyväksynnän, ja agentti seuraa julkaisun jälkeen virhetasoa, vasteaikoja ja SLO-mittareita. Jos tilanne huononee, julkaisu keskeytetään ja käytetään testattua palautusmenettelyä.

Työnkulun lopuksi agentti kokoaa häiriöraportin: havainto, lähteet, todennettu syy tai avoimeksi jäänyt hypoteesi, pull request, testitulokset, deployment ja vaikutus palveluun. Jos näyttö ei riitä tai korjaus ylittää sallitut rajat, agentti siirtää asian päivystäjälle. Tarkoitus on lyhentää matkaa havainnosta turvalliseen palautumiseen, ei automatisoida kaikkia muutoksia hinnalla millä hyvänsä.

OpenSRE: avoin kehys omille AI SRE -agenteille

Tracer-Cloudin OpenSRE on avoimen lähdekoodin kehys AI SRE -agenttien rakentamiseen. README kuvaa sitä myös infrastruktuurihäiriöiden koulutus- ja arviointiympäristöksi. Tarkistushetkellä projekti on public alpha -vaiheessa: rajapinnat ja integraatiot kehittyvät, eikä tuotantovalmiutta pidä olettaa.

OpenSRE kokoaa yhdistettyjen järjestelmien lokeja, mittareita, trace-tietoja, julkaisuja ja runbook-ohjeita. Agentti tutkii niitä työkalukutsuilla ja pyrkii tuottamaan aineistoon linkitetyn vastauksen. Se voi ehdottaa seuraavia vaiheita ja konfiguraatiosta riippuen suorittaa korjaustoimia.

• Käyttötavat: interaktiivinen komentorivi, headless CLI automaatioon ja Python-rajapinta omiin sovelluksiin.
• Integraatiot: README ilmoittaa yli 60 työkalua ja palvelua esimerkiksi havainnoitavuuteen, infrastruktuuriin, tietokantoihin ja häiriöhallintaan. Oman integraation kypsyys on tarkistettava erikseen.
• Mallivalinnat: projektin mukaan vaihtoehtoihin kuuluvat muun muassa OpenAI, Anthropic, Gemini ja Ollama.
• Ajotavat: projekti dokumentoi itse ylläpidettäviä sekä hallittuja vaihtoehtoja. Paikallinen CLI-aloitus käyttää README:n mukaan kirjautumista ja hosted model -palvelua.
• Lisenssi: Apache 2.0. Avoin lähdekoodi ei poista infrastruktuurin, mallikutsujen tai ylläpidon kustannuksia.

Itse ylläpidetty ei automaattisesti tarkoita, että kaikki tieto pysyy paikallisena. Ulkoiselle kielimallille voidaan lähettää tutkinnan tietoja. Projektin tunnisteiden peittäminen on valinnainen ominaisuus, ei takuu kaiken arkaluonteisen tiedon poistamisesta. README kertoo myös oletuksena käytössä olevasta, pois kytkettävästä tuoteanalytiikasta ja Sentry-virheraportoinnista.

Azure SRE Agent vai OpenSRE?

Azure SRE Agent tarjoaa Azureen integroidun tuotteen ja sen hallintamallit. Microsoftin GitHub-repositorio auttaa tutustumaan siihen laboratorioiden avulla. OpenSRE tarjoaa avoimen kehyksen, jossa voidaan muokata toteutusta, integraatioita ja mallivalintoja, mutta samalla käyttäjälle jää enemmän ylläpito- ja arviointivastuuta. Alpha-vaihe on huomioitava riskinarvioinnissa.

Valinta ei ole vain ominaisuuslistan vertailu. Olennaista on, mistä agentti saa tietonsa, mitä se saa muuttaa, missä tietoja käsitellään ja miten tulokset tarkistetaan. Kumpikaan ei korvaa SLO-tavoitteita, laadukasta valvontaa tai sovittua häiriöjohtamista.

Muut tärkeät asiat ennen käyttöönottoa

1. Aloita lukevasta agentista. Kokeile rajatulla palvelulla, tuottaako agentti hyödyllistä, lähteisiin perustuvaa tutkintaa ennen muutosoikeuksien antamista.
2. Rajaa oikeudet ja vaikutusalue. Anna vain tarvittavat oikeudet, erota tuotanto testistä ja määritä kielletyt toiminnot.
3. Vaadi hyväksyntä riskialttiisiin muutoksiin. Tietojen poistaminen, oikeuksien muuttaminen ja laajat palautukset tarvitsevat erityisen tarkat rajat. Säilytä mahdollisuus keskeyttää agentti.
4. Suunnittele palautus. Runbook, varmistukset ja testattu rollback ovat tarpeen myös tekoälyn ehdottamalle korjaukselle. Todennetaan palvelun tervehtyminen mittareista.
5. Suojaa data ja salaisuudet. Lokit voivat sisältää henkilötietoja ja tunnuksia. Huomioi säilytysajat, mallipalvelut ja prompt injection: tutkittava aineisto ei ole luotettu toimintaohje.
6. Pidä audit trail ja vastuut selkeinä. Tallenna, mitä agentti luki, ehdotti ja muutti, kuka hyväksyi muutoksen ja mitä sen jälkeen tapahtui.
7. Mittaa hyöty ja virheet. Seuraa palautumisaikaa, tutkinnan laatua, virheellisiä ehdotuksia, ihmisen työmäärää ja kustannuksia. Nopea vastaus ei yksin tarkoita nopeaa palautumista.

Häiriöiden jälkeen tarvitaan edelleen syyllistämätön postmortem: tapahtumaketju, vaikutus, myötävaikuttavat tekijät ja konkreettiset parannukset. Agentin yhteenveto voi auttaa, mutta ihmisten on tarkistettava se.

Yhteenveto

SRE tekee luotettavuudesta yhteisen tavoitteen. Agentic SRE voi nopeuttaa tiedon kokoamista ja tukea hallittua häiriöihin reagointia. Azure SRE Agent ja OpenSRE ovat kaksi erilaista tapaa kokeilla tätä: Azureen integroitu palvelu ja avoin, muokattava kehys.

Turvallisin etenemistapa on rajattu pilotti, aluksi lukuoikeuksilla. Laajempi autonomia ansaitaan testien, mitattujen tulosten ja toimivien turvarajojen kautta, ei pelkän vakuuttavan vastauksen perusteella.

Lähteet

• Google SRE Book: Introduction ja SRE:n periaatteet
• Microsoft Learn: Azure SRE Agent overview
• Microsoft: Azure SRE Agentin virallinen resurssi- ja laboratoriorepositorio
• OpenSRE: README, lisenssi ja projektin tila

Lähteet tarkistettu 3.10.2026. Saatavuus, ominaisuudet ja integraatiot voivat muuttua. Artikkeli ei tarkoita, että Nixu Racing Team käyttäisi näitä työkaluja tuotannossa.