Suuren osan yritystietotekniikan historiasta vaikea ja arvostettu työ oli rakentamista. Operointi oli alavirran kustannuspaikka, joka miehitettiin pitämään valot päällä ja josta syytettiin, kun ne sammuivat. Tuo asetelma on hiljalleen romahtanut. Järjestelmät ovat nykyään oletusarvoisesti hajautettuja, ja ne koostuvat kymmenistä tai sadoista palveluista, kolmannen osapuolen API-rajapinnoista, hallituista tietovarastoista ja infrastruktuurista, joka on itsessään ohjelmistoa. Asiakkaalle merkityksellinen käyttäytyminen syntyy komponenttien välisistä vuorovaikutuksista, joita kukaan yksittäinen henkilö ei täysin hahmota. Tällaisessa maailmassa vaikea ongelma ei ole enää ominaisuuden kirjoittaminen; se on käynnissä olevan kokonaisuuden ymmärtäminen ja terveenä pitäminen.

Panokset ovat nousseet samaa tahtia. Digitaaliset palvelut ovat nykyään ensisijainen kanava, jonka kautta monet organisaatiot asioivat, ja käyttökatkot mitataan suoraan menetettynä liikevaihtona ja rapautuneena luottamuksena. Sääntelijät ovat panneet tämän merkille: operatiivinen kestävyys on yhä useammin valvonnallinen odotus pikemminkin kuin sisäinen tavoite, ja siihen liittyy nimenomaisia vaatimuksia kartoittaa kriittiset palvelut, asettaa vaikutustoleranssit ja todistaa palautuminen. Samaan aikaan muutosvauhti on kiihtynyt. Tiimit julkaisevat jatkuvasti, ja jokainen muutos on mahdollinen häiriö. Organisaatio, joka toimittaa muutoksia viisikymmentä kertaa päivässä, ei voi luottaa neljännesvuosittain kokoontuvaan muutoslautakuntaan suojanaan.

Tästä syystä palvelua ja ylläpitoa on pakotettu ammattimaistamaan. Vanha malli, jossa operointi tarkoitti joukkoa ihmisiä katselemassa dashboardeja ja reagoimassa, ei skaalaudu näin monimutkaisiin järjestelmiin eikä tähän muutosvauhtiin. Nyt ratkaisevaa on kyky vastata kolmeen kysymykseen nopeasti ja rehellisesti: onko palvelu terve käyttäjän näkökulmasta, jos ei niin miksi, ja mikä estää tämän ongelmaluokan palaamisen. Näihin vastaaminen hyvin on insinöörityötä, ja sen kohteleminen minään vähempänä on useimman operatiivisen tuskan juurisyy.

Kaksi perinnettä ohjaa kypsää operointia, ja tuottava asenne on pitää kiinni molemmista. Ensimmäinen on palvelunhallinta, joka ilmenee esimerkiksi ITIL:n kaltaisissa viitekehyksissä ja joka tuo mukanaan sanaston ja joukon toimintatapoja: eron häiriön (palauta palvelu) ja ongelman (poista taustalla oleva syy) välillä, käsitteen palvelusta, jolla on määritellyt tasot, muutoksen- ja konfiguraationhallinnan sekä ajatuksen siitä, että operatiivista työtä tulisi hallita eikä improvisoida. Sen vahvuus on rakenne ja vastuullisuus. Sen vikatila, kun sitä sovelletaan mekaanisesti, on byrokratia, joka optimoi prosessin noudattamista tulosten sijaan.

Toinen perinne on site reliability engineering, joka lähtee eri lähtökohdasta: luotettavuus on ominaisuus, jonka suunnittelet, mittaat ja jonka suhteen teet kompromisseja, ei hyve, johon kehotat. SRE vaatii, että operointia lähestytään ohjelmiston työkaluilla: versionhallittu konfiguraatio, automatisoitu korjaus ja hellittämätön hyökkäys manuaalista, toistuvaa työtä vastaan, jota se kutsuu nimellä toil. Sen keskeinen älyllinen liike on tehdä luotettavuudesta määrällistä palvelutasotavoitteiden avulla ja kohdella täydellisen ja tavoitteellisen luotettavuuden välistä eroa budjettina, joka voidaan käyttää.

Sovitus on suoraviivainen, kun se on kerran lausuttu. Palvelunhallinta tarjoaa organisatorisen kieliopin: mikä palvelu on, kuka omistaa sen, miten muutoksia ja häiriöitä käsitellään vastuullisesti. SRE tarjoaa insinöörimenetelmän: miten todella mittaat terveyttä, automatisoit vasteen ja päätät mihin investoit. Hyvin johdettu toiminto ei valitse toista; se käyttää ITIL:n selkeyttä rooleista ja elinkaaresta antaakseen SRE:n insinöörikäytännöille kestävän kodin. Epäonnistuminen on omaksua kumpi tahansa dogmina. ITIL:n mekaaninen soveltaminen tuottaa tikettien siirtelyä; SRE:n naiivi omaksuminen ilman organisatorista rakennetta tuottaa sankarillisia yksilöitä ja omistajattomia palveluita. Molempien taustalla oleva ensimmäinen periaate on sama: operointi on suunniteltava järjestelmä, ja sen käyttäytymisen tulisi olla havaittavaa, mitattavaa ja tarkoituksellisesti parannettavaa.

Useat kehityskulut muokkaavat sitä, miten terveet järjestelmät pidetään terveinä. Merkittävin on havaittavuuden (observability) kypsyminen erillisenä valvonnasta (monitoring). Valvonta vastaa kysymyksiin, jotka osasit kysyä etukäteen, seuraamalla ennalta määriteltyjä mittareita kynnysarvoja vasten. Havaittavuus on järjestelmän ominaisuus, jonka avulla voit esittää siitä uusia kysymyksiä jälkikäteen tuottamalla rikasta, korkean kardinaliteetin telemetriaa: rakenteisia tapahtumia, hajautettuja jälkiä (traces), jotka seuraavat pyyntöä palvelurajojen yli, ja mittareita, joissa on riittävästi ulottuvuuksia, jotta niitä voidaan pilkkoa asiakkaan, alueen tai version mukaan. Käytännön ajuri on se, että hajautetuissa järjestelmissä et voi ennustaa vikatilojasi, joten sinun on instrumentoitava kysymyksiä varten, joita et ole vielä kuvitellut.

Standardointi on kiihdyttänyt tätä. OpenTelemetry on noussut yhteiseksi tavaksi tuottaa ja viedä jälkiä, mittareita ja lokeja, mikä irrottaa instrumentoinnin minkään yksittäisen toimittajan taustajärjestelmästä ja tekee realistiseksi vaihtaa työkaluja instrumentoimatta IT-ympäristöä uudelleen. Sen rinnalla käytäntö korreloida nämä kolme signaalityyppiä, niin että mittarin poikkeama johtaa suoraan sen selittäviin jälkiin ja lokeihin, on siirtynyt tavoitteesta odotukseksi.

Toinen kehityssuunta on siirtymä reaktiivisesta ennakoivaan operointiin. Chaos engineering syöttää tarkoituksella vikoja järjestelmiin löytääkseen heikkoudet ennen asiakkaita, muuttaen kestävyyden oletuksesta testatuksi ominaisuudeksi. Progressive delivery, canary-julkaisujen ja feature flagien kautta, kohtelee jokaista käyttöönottoa kokeena, joka voidaan pysäyttää sillä hetkellä, kun telemetria kääntyy huonoksi, mikä kutistaa muutoksen ja perumisen välisen etäisyyden. Kolmas kehitys on koneoppimisen varovainen mutta todellinen soveltaminen operointiin: poikkeamien havaitseminen, joka oppii normaalin käyttäytymisen sen sijaan että luottaisi staattisiin kynnysarvoihin, ja korrelaatio, joka ryhmittää hälytysmyrskyn yhdeksi todennäköiseksi syyksi. Rehellinen arvio on, että nämä työkalut vähentävät kohinaa ja nostavat esiin ehdokkaita; ne eivät vielä korvaa insinööriharkintaa, ja niiden kohteleminen oraakkelina tuo takaisin juuri sen läpinäkymättömyyden, jonka havaittavuuden oli tarkoitus poistaa.

Luotettavuus määräytyy suurelta osin jo ennen kuin yksikään häiriö tapahtuu, suunnittelussa tehdyillä valinnoilla. Perustavanlaatuinen periaate on, että järjestelmän on oltava havaittava jo rakenteeltaan. Instrumentointi ei ole jotain, joka pultataan päälle kun ongelmia ilmenee; palveluiden tulisi tuottaa rakenteista, korreloitua telemetriaa ensiluokkaisena tuotoksena kantaen tunnisteita, joiden avulla yksittäisen käyttäjän polku voidaan rekonstruoida jokaisen koskettamansa komponentin läpi. Järjestelmää, jota ei voida kuulustella, ei voida operoida, vaan siitä voidaan vain arvailla.

Toinen periaate on suunnitella hallittua heikkenemistä varten binäärisen saatavuuden sijaan. Hyvin arkkitehdoidut järjestelmät eristävät vian niin, että yhden riippuvuuden menetys vähentää toiminnallisuutta sen sijaan että romahduttaisi koko kokonaisuuden. Aikakatkaisut, uudelleenyritykset porrastuksella ja hajonnalla, katkaisijat (circuit breakers), jotka lopettavat kaatuvan riippuvuuden jankuttamisen, ja väliseinät (bulkheads), jotka rajaavat resurssien ehtymisen, eivät ole valinnaisia hienosäätöjä; ne ovat ero rajatun vian ja kaskadoivan käyttökatkon välillä. Käyttäjälle näkyvä tavoite on, että osittainen vika tuottaa heikentyneen kokemuksen, ei tyhjää sivua.

Kolmas on palvelutasotavoitteiden käytäntö organisoivana mittarina. Hyvä SLO määritellään käyttäjän näkökulmasta palvelutasoindikaattoreiden kautta, jotka heijastavat sitä mitä ihmiset todella kokevat: onnistuneesti ja riittävän nopeasti palveltujen pyyntöjen osuus, ei sellaisen koneen suoritinkäyttö, jota he eivät koskaan näe. Tavoite asettaa päämäärän tälle indikaattorille, ja ero tavoitteen ja sadan prosentin välillä muodostaa virhebudjetin. Tämä muotoilee luotettavuuden uudelleen taloudelliseksi päätökseksi. Jos budjetti on koskematon, tiimi voi käyttää sen nopeuteen, toimittamalla nopeammin ja ottamalla enemmän riskiä. Jos se on käytetty loppuun, sama mittaus edellyttää taukoa investoidakseen vakauteen. Virhebudjetti muuttaa toimittaa haluavien kehittäjien ja suojata haluavien operaattoreiden välisen kiistan yhteiseksi, määrälliseksi sopimukseksi. Hälytysten tulisi seurata näistä tavoitteista myös: kypsä malli hälyttää siitä nopeudesta, jolla budjettia kulutetaan, niin että hälytykset vastaavat aitoja uhkia käyttäjälle eivätkä jokaista ohimenevää häilähdystä.

Hälytysväsymys on yleisin ja syövyttävin vika. Kun jokainen poikkeama hälyttää jollekulle, insinöörit oppivat sivuuttamaan hälytykset, ja se yksi merkityksellinen hukkuu kohinaan. Syy on lähes aina hälyttäminen syistä oireiden sijaan ja sisäisistä mittareista käyttäjälle näkyvän vaikutuksen sijaan. Parannus on kuria: hälytä vain tavoitteen uhkista ja ohjaa kaikki muu jonoon tarkasteltavaksi, ei ihmiselle kolmelta aamuyöllä.

Paikkaamaton ympäristö on laiminlyönnin kautta syntynyt vika. Paikkaus ja elinkaaren hallinta ovat epäglamouristista ja helppo lykätä, ja lykkääminen kertautuu. Jokainen korjaamaton haavoittuvuus laajentaa hyökkäyspintaa, ja jokaisesta tuetun elinkaarensa ohittaneesta komponentista tulee järjestelmä, johon kukaan ei uskalla koskea eikä kukaan voi turvallisesti päivittää. Tehokas käytäntö kohtelee paikkausta jatkuvana, automatisoituna virtana, jossa on porrastettu käyttöönotto ja terveyden varmistus, ei jaksottaisena projektina, ja se seuraa jokaisen komponentin elinkaarta niin, että tuen päättyminen suunnitellaan ennalta eikä havaita häiriön aikana.

Syyllistävä häiriönjälkeinen kulttuuri tuhoaa hiljalleen minkä tahansa käyttökatkon arvokkaimman tuotoksen: oppimisen. Kun katselmoinnit etsivät henkilöä pidettäväksi vastuussa, insinöörit pidättävät sen suoran yksityiskohdan, joka estäisi toistumisen. Syyttömät häiriönjälkeiset katselmoinnit, jotka kohtelevat vikaa järjestelmän ja sen suojamekanismien ominaisuutena eikä henkilökohtaisena vikana, ovat ainoa luotettava tapa muuntaa häiriöt kestäviksi parannuksiksi. Häiriön- ja ongelmanhallinnan sekoittaminen on siihen liittyvä ansa: palvelun palauttaminen päättää häiriön mutta ei ongelmaa, ja organisaatiot, jotka eivät koskaan miehitä jatkotoimia, elävät saman käyttökatkon uudelleen loputtomiin. Lopuksi konfiguraation ajautuminen, jossa käynnissä olevat järjestelmät poikkeavat tarkoitetusta ja dokumentoidusta tilastaan dokumentoimattomien manuaalisten muutosten kautta, muuttaa jokaisen ympäristön hauraaksi kertaluontoiseksi kappaleeksi ja tekee luotettavasta palautumisesta mahdotonta. Vastalääke on määritellä infrastruktuuri ja konfiguraatio koodina, niin että tarkoitettu tila on versionhallittu, auditoitava ja toistettava.

Nashua kohtelee operointia insinööritieteenä, ja sen toimeksiannot on rakennettu viemään asiakas reaktiivisesta tulipalojen sammuttamisesta kohti mitattua, parannettavissa olevaa luotettavuutta. Lähtökohta on aina arviointi: IT-ympäristön ymmärtäminen sellaisena kuin se todella toimii, liiketoiminnalle merkityksellisten palveluiden kartoittaminen ja rehellisyys siitä, missä havaittavuus on ohutta, missä toil on korkeaa ja missä elinkaaririskiä on kertynyt. Tämä tuottaa kuvan, joka perustuu käyttäjän kokemukseen eikä palvelinluetteloon, koska se on ainoa näkymä, josta järkeviä prioriteetteja voidaan johtaa.

Tästä lähtötasosta Nashua työskentelee tehdäkseen järjestelmistä havaittavia ja mitattavia. Se tarkoittaa telemetrian toteuttamista, joka korreloi mittarit, jäljet ja lokit, suosien avoimia standardeja niin ettei asiakas ole lukittu yhteen taustajärjestelmään, ja sitten tuon telemetrian käyttämistä palvelutasotavoitteiden määrittelyyn, jotka heijastavat todellisia käyttäjätuloksia. Tavoitteiden ollessa paikallaan virhebudjetit antavat organisaatiolle yhteisen kielen ikuiselle jännitteelle muutoksen ja vakauden välillä, ja hälytykset voidaan rakentaa uudelleen aitojen uhkien eikä kohinan ympärille. Rinnalla Nashua vakiinnuttaa operatiivisen silmukan, joka pitää järjestelmät terveinä ajan myötä: häiriönhallinta, joka palauttaa palvelun nopeasti, ongelmanhallinta, joka poistaa toistuvat syyt, syytön katselmointi, joka muuttaa jokaisen tapahtuman parannukseksi, sekä paikkaus ja elinkaari hallittuna jatkuvana, automatisoituna virtana lykätyn projektin sijaan.

Johdonmukainen tavoite on vähentää toilia automaation avulla ja juurruttaa käytäntö asiakkaan omiin tiimeihin, niin että kyvykkyys elää toimeksiantoa pidempään. Nashuan kanta on, että tavoite ei ole asentaa työkalu tai viitekehys ja lähteä, vaan jättää jälkeen toiminto, joka mittaa omaa luotettavuuttaan, ymmärtää omat vikansa ja parantaa itseään ilman ulkoista kehotusta. Luotettavuustekniikka siirretään toimintatapana, ei toimiteta kertaluontoisena artefaktina.

Ero, jonka Nashua vetää, on luotettavuuden ostamisen ja luotettavuuden kyvykkyytenä välillä. Työkaluja voidaan ostaa ja viitekehyksiä voidaan omaksua, mutta kumpikaan ei tuota terveitä järjestelmiä yksinään; molemmat ovat elottomia ilman insinööriharkintaa instrumentoida oikeat asiat, asettaa rehelliset tavoitteet ja toimia sen mukaan mitä telemetria paljastaa. Nashuan panos on tuo harkinta, sovellettuna tinkimättömästi ja siirrettynä tarkoituksellisesti, niin että käytännöstä tulee asiakkaan oma eikä riippuvuus ulkoisesta toimittajasta.

Tähän liittyy myös käytännöllinen seuraus, joka muuttaa sitä mitä työn sallitaan olettaa. Kun toimeksianto vaatii kyvykkyyttä, jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintasykliä tai toimittajan tiekarttaa. enterprise platform on rakennettu mukautumaan lähes mihin tahansa ominaisuuteen vauhdilla, agenttipohjaisen tekniikan kautta: tarvittava kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, niin ettei nopeus koskaan tule johdonmukaisuuden, tietoturvan tai hallinnan kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää tee-tai-osta-rajaa, pitää valinnaisuuden edullisena ja antaa arkkitehtuurin seurata strategiaa sen sijaan että strategia taipuisi sen mukaan mitä sattui olemaan hyllyllä.

Se mikä lopulta erottaa hyvin johdetun operoinnin kamppailevasta ei ole minkään yksittäisen työkalun kehittyneisyys vaan kokonaisuuden johdonmukaisuus: havaittavuus, joka vastaa todellisiin kysymyksiin, tavoitteet, jotka tekevät luotettavuudesta tarkoituksellisen valinnan, häiriö- ja ongelmasilmukka, joka oppii, ja elinkaarikuri, joka ei koskaan päästä IT-ympäristöä hiljalleen rappeutumaan. Nashuan rooli on rakentaa tuo johdonmukaisuus yhdessä asiakkaiden kanssa ja sitten astua taaksepäin, jättäen jälkeen organisaation, joka pitää omat järjestelmänsä terveinä tuotannossa insinöörirutiinina. Se on ero tuotannossa selviytymisen ja siellä luottavaisesti operoinnin välillä, ja se on ero, jonka tekemistä varten Nashua on olemassa.