Hva arkitektur kan lære oss om selvhelbredende systemer

Publisert av Platon

Følgere: 0

DevOps-team og nettstedspålitelighetsingeniører (SRE) håndterer kode daglig. Å gjøre det lærer dem å granske sin verden, gjøre skarpe observasjoner og trekke uventede forbindelser. Tross alt, selv om det er svært logisk og matematisk av natur, er programvareutvikling, i det minste delvis, kunstform.

Ikke overbevist av den uttalelsen? Tenk på parallellene mellom historiens mest bemerkelsesverdige arkitektoniske bragder og moderne programvareteknikk. Det er en passende sammenligning: Akkurat som programvareteknikk, bruker arkitektur komplekse matematiske beregninger for å skape noe vakkert. Og i begge disipliner kan en liten feilberegning føre til betydelige konsekvenser. Fascinerende nok er mange kjente arkitektoniske feil analoge med problemer vi finner i kode.

Husk at inspirasjon er overalt – så lenge du vet hvor du skal lete. Her er noen leksjoner programvareingeniører kan lære av arkitektoniske åpenbaringer gjennom århundrene, spesielt angående fremtiden til selvhelbredende systemer.

Leksjon 1: Edge-saker vil alltid utnytte systemsårbarheter

Citicorp Tower – nå kalt 601 Lexington – ble ferdigstilt i New York City i 1977, da det var den syvende høyeste bygningen i verden. Skyskraperens toppmoderne design inkluderte tre 100-pluss-fots stylter. Det var et vidunder å fullføre. Imidlertid oppdaget en student snart noe skurrende: Sterk vind kan sette bygningens integritet i fare. Nærmere bestemt, hvis kraftige kvartervinder traff hjørnene av Citicorp Tower, var strukturen utsatt for kollaps - en bokstavelig talt spesielt tilfelle.

Tårnet hadde en en-av-16 sjanse til å kollapse hvert år. Disse oddsene kan lokke noen til å sitte ved et spillebord, men utsiktene var dystre for arkitektene og konstruksjonsingeniørene bak Citicorp Tower. Heldigvis klarte teknikere å forsterke bygningens bolteforbindelser. Katastrofe ble unngått.

Strukturingeniører visste at Citicorp Tower til slutt ville møte en vind sterk nok til å kompromittere lagrene. På samme måte vet erfarne programvareingeniører at robust overvåking av applikasjonsytelse (APM) og hendelsesadministrasjon ikke er nok til å beskytte et system fra de uunngåelige kantsakene. Det er fordi statiske systemer uten maskinlæring (ML) kapasiteter kan ikke håndtere uventede og uplanlagte nye situasjoner, for eksempel kvartervind. Når man kun stoler på overvåkingsverktøy, må en menneskelig administrator tyde feil og eskalere hendelseshåndteringsprosessen.

For å redusere gjennomsnittlig tid til gjenoppretting (MTTR)/middeltid til gjenoppretting (MTTD), må DevOps-team akseptere den høye sannsynligheten for edge-tilfeller og arbeide for å distribuere selvlærende løsninger forebyggende. Denne leksjonen går langt, siden framsyn er avgjørende i ingeniørfag.

Leksjon 2: «Å bygge flyet mens det flyr» skaper en uendelig syklus

Tragiske hendelser har levert flere av de viktigste leksjonene i luftfartshistorien. Da et fly fikk enorm dekompresjon midt i flyet og styrtet i 1954, konstaterte ingeniører at firkantede passasjervinduer var et unødvendig stresspunkt. Fra nå av flyene var utstyrt med avrundede vinduer. Brann ombord førte til nye sitteplasser som prioriterte enkel evakuering. Disse endringene har reddet utallige liv.

I mange bransjer – inkludert luftfart – er det ingen måte å uttømmende stressteste et produkt på. Som nevnt tidligere er kantsaker uunngåelige. Den største takeawayen her er at programvareingeniører må ta hensyn til systemets sårbarheter når de presenterer seg selv. Derfra må de henvende seg til dem på en hensiktsmessig måte. Å gjøre det krever to ting: (1) identifisere og spore de riktige nøkkelytelsesindikatorene (KPIer) og (2) investere tid og ressurser i å forbedre systemer basert på relevante beregninger.

Det gjennomsnittlige ingeniørteamet investerer i 16 til 40 overvåkingsverktøy, men de savner ofte merket for hvilke beregninger som viser suksess. Færre enn 15 % av teamene sporer MTTD, så de går glipp av 66 % av hendelsens livssyklus. Og en fjerdedel av lagene rapporterer mangler sine servicenivåavtaler (SLAer) til tross for betydelige investeringer i tilgjengelighetssporing. Dette forteller oss at datainnsamling trenger grundig, systematisk analyse for å kutte det – punktløsninger er ikke lenger nok.

Programvareingeniører, DevOps-team og SRE-er må prioritere prosesser og verktøy som trekker ut verdi fra overveldende mengder informasjon om tilgjengelighet. I stedet for bare å observere en kritisk feil, må de ta en side fra en luftfartsingeniørs bok og ta kritiske avgjørelser, raskt. Hemmeligheten bak å gjøre det ligger i AI.

Leksjon 3: AI er en grunnleggende byggestein for selvhelbredende systemer

Et helt autonomt, perfekt fungerende, selvhelbredende system er ideelt for enhver programvareingeniør. Systemer som lapper seg selv er bra for kundetilfredsheten, siden de eliminerer kostbar nedetid for forbrukeren. Dessuten er de utrolig fordelaktige for IT-tjenesteadministrasjonsfunksjoner (ITSM), siden de reduserer behovet for kjedelig billettadministrasjon betydelig. Å bygge et slikt system krever flere komponenter, hvorav mange for tiden er utenfor rekkevidde. Men vi er nærmere en selvhelbredende virkelighet enn noen kanskje er klar over.

Mangelen på utbredt AI-adopsjon er fortsatt det største hinderet som selvhelbredende systemer står overfor i dag. Selv om mange virksomheter har tatt i bruk rudimentære AI- eller ML-baserte verktøy, er integriteten til disse verktøyene tvilsom. Det vil si, mange ingeniører håndtere kunstig intelligens for IT-drift (AIOps) teknologier som følger regelbasert automatiseringslogikk i stedet for autonome AI-algoritmer. Skillet kan virke lite, men i praksis er det forskjellen mellom timer med tapt produktivitet og millioner i mulig tap.

Saken er at regelbaserte AIOps-verktøy analyserer interaksjonene mellom ulike punktløsninger og kan sannsynligvis identifisere vanlige datafeil. Men automatiseringsbaserte systemer kan ikke behandle utviklingen av helt nye feil over tid, og de kan heller ikke forutsi nye funksjonsfeil i data. Det er fordi de menneskelige administratorene som koder disse funksjonene, ber systemet følge en hvis dette, så det logisk mønster. Genuint effektive AIOps-verktøy reduserer feil som oppstår ved alle de fire klassiske telemetripunktene – fra deteksjon til oppløsning – ved å klassifisere nye og problematiske mønstre før menneskelige teknikere i det hele tatt er klar over deres eksistens.

Mens vi venter på forestående tredje bølge av AI, er denne versjonen av AIOps det nærmeste vi har selvhelbredende systemer. Det vil være interessant å spore hvordan nåværende AIOps-applikasjoner blør inn i fremtiden til AI, som vil inkludere fullt realisert automatisering og uavhengige tankemuligheter. Kanskje da også konstruksjonsingeniører vil høste fruktene av et AI-basert, selvhelbredende system.