Mitä arkkitehtuuri voi opettaa meille itsehoitojärjestelmistä?

Julkaissut Platon

seuraajia: 0

DevOps-tiimit ja sivuston luotettavuusinsinöörit (SRE) käsittelevät koodia päivittäin. Se opettaa heitä tarkastelemaan maailmaansa, tekemään viisaita havaintoja ja luomaan odottamattomia yhteyksiä. Vaikka ohjelmistokehitys onkin luonteeltaan erittäin loogista ja matemaattista, se on ainakin osittain taidemuotoa.

Etkö ole vakuuttunut tästä lausunnosta? Mieti historian merkittävimpien arkkitehtonisten saavutusten ja nykyaikaisen ohjelmistosuunnittelun välisiä yhtäläisyyksiä. Se on osuva vertailu: aivan kuten ohjelmistosuunnittelu, arkkitehtuuri käyttää monimutkaisia matemaattisia laskelmia luodakseen jotain kaunista. Ja molemmilla aloilla pieni virhelaskenta voi johtaa merkittäviin seurauksiin. Kiehtovaa on, että monet kuuluisat arkkitehtoniset virheet ovat analogisia koodissa havaittujen ongelmien kanssa.

Muista, että inspiraatiota on kaikkialla – kunhan tiedät mistä etsiä. Tässä on muutamia oppitunteja, joita ohjelmistosuunnittelijat voivat oppia arkkitehtonisista vaiheista vuosisatojen aikana, erityisesti itsekorjautuvien järjestelmien tulevaisuudesta.

Oppitunti 1: Edge-tapaukset käyttävät aina hyväkseen järjestelmän haavoittuvuuksia

Citicorp Tower – jota nykyään kutsutaan nimellä 601 Lexington – valmistui New Yorkissa vuonna 1977, jolloin se oli maailman seitsemänneksi korkein rakennus. Pilvenpiirtäjän huippuluokan suunnittelu sisälsi kolme yli 100 jalan puujalat. Se oli ihme valmistuessaan. Kuitenkin eräs perustutkinto-opiskelija huomasi pian jotain järkyttävää: voimakkaat tuulet voi vaarantaa rakennuksen eheyden. Erityisesti, jos voimakkaat neljännestuulet osuivat Citicorp Towerin kulmiin, rakenne romahti – kirjaimellisesti reunalaukku.

Tornilla oli yksi 16:sta mahdollisuus romahtaa joka vuosi. Nämä todennäköisyydet saattavat houkutella jonkun pelipöydässä istuvan, mutta näkymät olivat synkät Citicorp Towerin takana oleville arkkitehdeille ja rakennesuunnittelijoille. Onneksi teknikot pystyivät vahvistamaan rakennuksen pulttiliitokset. Katastrofilta vältyttiin.

Rakennusinsinöörit tiesivät, että Citicorp Tower joutuisi lopulta kohtaamaan riittävän voimakkaan tuulen vaarantamaan sen laakerit. Samoin kokeneet ohjelmistosuunnittelijat tietävät, että vankka sovellusten suorituskyvyn valvonta (APM) ja tapahtumien hallinta eivät riitä suojaamaan järjestelmää väistämättömiltä reunatapauksilta. Tämä johtuu siitä, että staattiset järjestelmät ilman koneoppiminen (ML) kyvyt eivät pysty käsittelemään odottamattomia ja suunnittelemattomia uusia tilanteita, kuten tuulia. Kun järjestelmänvalvoja luottaa pelkästään valvontatyökaluihin, hänen on tulkittava virheet ja eskaloitava tapahtumanhallintaprosessia.

Keskimääräisen palautumisajan (MTTR) / keskimääräisen havaitsemisajan (MTTD) lyhentämiseksi DevOps-tiimien on hyväksyttävä reunatapausten suuri todennäköisyys ja pyrittävä ottamaan käyttöön itseoppivia ratkaisuja ennaltaehkäisevästi. Tämä oppitunti menee pitkälle, koska ennakointi on tekniikan kannalta kriittistä.

Oppitunti 2: "Koneen rakentaminen lennon aikana" luo loputtoman kierteen

Traagiset tapahtumat ovat saaneet aikaan useita ilmailuhistorian tärkeimmät oppitunnit. Kun lentokone kärsi valtavasta dekompressiosta lennon aikana ja putosi vuonna 1954, insinöörit totesivat, että neliömäiset matkustajaikkunat olivat tarpeeton stressipiste. Vastedes, lentokoneet varustettiin pyöristetyillä ikkunoilla. Palot laivoissa johtivat uusiin istuinjärjestelyihin, jotka asettivat etusijalle evakuoinnin helppouden. Nämä muutokset ovat pelastaneet lukemattomia ihmishenkiä.

Monilla toimialoilla – myös lentoliikenteessä – tuotetta ei ole mahdollista testata kattavasti. Kuten aiemmin mainittiin, reunakotelot ovat väistämättömiä. Suurin huomio tässä on, että ohjelmistosuunnittelijoiden on otettava huomioon järjestelmänsä haavoittuvuudet, kun he esittelevät itsensä. Sieltä heidän on puututtava niihin tarkoituksenmukaisesti. Tämän tekeminen edellyttää kahta asiaa: (1) oikeiden keskeisten suorituskykyindikaattoreiden (KPI) tunnistamista ja seurantaa ja (2) ajan ja resurssien sijoittamista järjestelmien parantamiseen relevanttien mittareiden perusteella.

Keskimääräinen suunnittelutiimi investoi 16–40 seurantatyökaluun, mutta he eivät useinkaan jätä sitä merkkiä, jonka perusteella mittarit osoittavat menestystä. Alle 15 % joukkueista seuraa MTTD:tä, joten heiltä jää 66 % väliin tapahtuman elinkaaresta. Ja neljäsosa joukkueista raportoi puuttuvat palvelutasosopimukset (SLA) huolimatta huomattavista investoinneista saatavuuden seurantaan. Tämä kertoo meille, että tiedonkeruu vaatii perusteellista, systemaattista analysointia sen leikkaamiseksi – pisteratkaisut eivät enää riitä.

Ohjelmistoinsinöörien, DevOps-tiimien ja SRE:n on priorisoitava prosessit ja työkalut, jotka poimivat arvoa valtavasta määrästä saatavuutta koskevaa tietoa. Sen sijaan, että he vain havaitsivat kriittistä virhettä, heidän on otettava sivu ilmailuinsinöörin kirjasta ja tehtävä kriittisiä päätöksiä nopeasti. Sen salaisuus piilee tekoälyssä.

Oppitunti 3: Tekoäly on itseparantumisjärjestelmien perustavanlaatuinen rakennuspalikka

Täysin itsenäinen, täydellisesti toimiva, itsestään paraneva järjestelmä on ihanteellinen kaikille ohjelmistosuunnittelijoille. Itsestään korjaavat järjestelmät ovat hyviä asiakastyytyväisyyden kannalta, koska ne eliminoivat kalliita kuluttajille aiheutuvia seisokkeja. Lisäksi ne ovat uskomattoman hyödyllisiä IT-palvelunhallinnan (ITSM) toiminnoille, koska ne vähentävät merkittävästi ikävän lipunhallinnan tarvetta. Tällaisen järjestelmän rakentaminen vaatii useita komponentteja, joista monet ovat tällä hetkellä ulottumattomissa. Mutta olemme lähempänä itsensä parantavaa todellisuutta kuin jotkut saattavat ymmärtää.

Tekoälyn laajan käyttöönoton puute on edelleen suurin itsekorjautumisjärjestelmien este. Vaikka monet yritykset ovat ottaneet käyttöön alkeellisia tekoäly- tai ML-pohjaisia työkaluja, näiden työkalujen eheys on kyseenalainen. Toisin sanoen monet insinöörit käsittelevät tekoälyä IT-toimintoihin (AIOps) -teknologiat, jotka noudattavat sääntöihin perustuvaa automaatiologiikkaa autonomisten tekoälyalgoritmien sijaan. Ero saattaa tuntua vähäiseltä, mutta käytännössä se on ero tuntien menetettyjen tuottavuuden ja miljoonien mahdollisten menetysten välillä.

Asia on siinä, että sääntöihin perustuvat AIOps-työkalut analysoivat erilaisten pisteratkaisujen välisiä vuorovaikutuksia ja voivat todennäköisesti tunnistaa yleiset tietovirheet. Mutta automaatiopohjaiset järjestelmät eivät pysty käsittelemään täysin uusien virheiden kehitystä ajan myötä, eivätkä ne pysty ennustamaan uusia virheitä tiedoissa. Tämä johtuu siitä, että näitä toimintoja koodaavat järjestelmänvalvojat pyytävät järjestelmää noudattamaan jos tämä, niin se logiikka malli. Aidosti tehokkaat AIOps-työkalut vähentävät virheitä, joita esiintyy kaikissa neljässä perinteisessä telemetrian pisteessä – havaitsemisesta ratkaisuun – luokittelemalla uusia ja ongelmallisia kuvioita ennen kuin teknikot ovat edes tietoisia niiden olemassaolosta.

Kun odotamme lähestyvä tekoälyn kolmas aalto, tämä AIOps-versio on lähimpänä itsekorjautuvia järjestelmiä. On mielenkiintoista seurata, kuinka nykyiset AIOps-sovellukset vuotavat tekoälyn tulevaisuuteen, joka sisältää täysin toteutettua automaatiota ja itsenäisiä ajattelumahdollisuuksia. Ehkä silloin myös rakennesuunnittelijat saavat palkinnot tekoälypohjaisesta itsekorjautuvasta järjestelmästä.