Hvad arkitektur kan lære os om selvhelbredende systemer

Hvad arkitektur kan lære os om selvhelbredende systemer

Tidsstempel: 2. marts 2023 kl. 3:25
Kildeknude: 1988904

DevOps-teams og site reliability engineers (SRE'er) håndterer kode dagligt. Det lærer dem at granske deres verden, foretage skarpsindige observationer og tegne uventede forbindelser. Selvom softwareudvikling er meget logisk og matematisk af natur, er softwareudvikling i det mindste delvist kun en kunstform. 

Ikke overbevist af den udtalelse? Overvej parallellerne mellem historiens mest bemærkelsesværdige arkitektoniske bedrifter og moderne softwareteknik. Det er en passende sammenligning: Ligesom software engineering anvender arkitektur komplekse matematiske beregninger til at skabe noget smukt. Og i begge discipliner kan en lille fejlberegning føre til betydelige konsekvenser. Fascinerende nok er mange berømte arkitektoniske fejl analoge med problemer, vi finder i kode.

Husk, inspiration er overalt – så længe du ved, hvor du skal lede. Her er et par lektioner, softwareingeniører kan lære af arkitektoniske åbenbaringer gennem århundreder, især med hensyn til fremtiden for selvhelbredende systemer.

Lektion 1: Edge-sager vil altid udnytte systemets sårbarheder

Citicorp Tower - nu kaldet 601 Lexington - færdiggjorde byggeriet i New York City i 1977, på hvilket tidspunkt det var den syvende højeste bygning i verden. Skyskraberens topmoderne design omfattede tre 100-plus-fods stylter. Det var et vidunder ved afslutningen. En bachelorstuderende opdagede dog hurtigt noget rystende: Stærk vind kunne bringe bygningens integritet i fare. Specifikt, hvis kraftige vinde ramte hjørnerne af Citicorp Tower, var strukturen udsat for kollaps - en bogstavelig talt kant sag.

Tårnet havde en en-i-16 chance for at kollapse hvert år. Disse odds kan lokke nogen til at sidde ved et spillebord, men udsigterne var dystre for arkitekterne og bygningsingeniørerne bag Citicorp Tower. Heldigvis var teknikere i stand til at forstærke bygningens boltesamlinger. Katastrofen blev undgået.

Konstruktionsingeniører vidste, at Citicorp Tower i sidste ende ville møde en vind, der var stærk nok til at kompromittere dens lejer. Tilsvarende ved erfarne softwareingeniører, at robust overvågning af applikationsydelse (APM) og hændelsesstyring ikke er nok til at beskytte et system mod de uundgåelige kanttilfælde. Det er fordi statiske systemer uden maskinlæring (ML) kapaciteter kan ikke håndtere uventede og uplanlagte nye situationer, såsom kvartervind. Når en menneskelig administrator udelukkende er afhængig af overvågningsværktøjer, skal den dechifrere fejl og eskalere hændelseshåndteringsprocessen.

For at reducere middeltid til gendannelse (MTTR)/middeltid til at blive opdaget (MTTD), skal DevOps-teams acceptere den høje sandsynlighed for kanttilfælde og arbejde for at implementere selvlærende løsninger forebyggende. Denne lektion rækker langt, da fremsyn er afgørende i teknik.

Lektion 2: "At bygge flyet, mens det flyver" skaber en uendelig cyklus

Tragiske begivenheder har leveret flere af de vigtigste lektioner i luftfartshistorien. Da et fly blev ramt af enorm dekompression midt under flyvningen og styrtede ned i 1954, konstaterede ingeniører, at firkantede passagervinduer var et unødvendigt stresspunkt. Fremover fly var udstyret med afrundede vinduer. Brande ombord førte til nye siddearrangementer, der prioriterede nem evakuering. Disse ændringer har reddet utallige liv.

I mange industrier – inklusive luftfart – er der ingen måde at udtømmende stressteste et produkt på. Som tidligere nævnt er kantsager uundgåelige. Den største takeaway her er, at softwareingeniører skal være opmærksomme på deres systems sårbarheder, når de præsenterer sig selv. Derfra skal de rette henvendelse til dem. At gøre det kræver to ting: (1) at identificere og spore de rigtige nøglepræstationsindikatorer (KPI'er) og (2) investere tid og ressourcer i at forbedre systemer baseret på relevante målinger.

Det gennemsnitlige ingeniørteam investerer i 16 til 40 overvågningsværktøjer, men alligevel savner de ofte mærket, som målinger viser succes. Færre end 15 % af holdene sporer MTTD, så de går glip af 66 % af hændelsens livscyklus. Og en fjerdedel af holdene melder mangler deres serviceniveauaftaler (SLA'er) trods betydelige investeringer i tilgængelighedssporing. Dette fortæller os, at dataindsamling kræver en grundig, systematisk analyse for at skære den – punktløsninger er ikke længere nok.

Softwareingeniører, DevOps-teams og SRE'er skal prioritere processer og værktøjer, der udvinder værdi fra overvældende mængder af information om tilgængelighed. I stedet for blot at observere en kritisk fejl, skal de tage en side fra en luftfartsingeniørs bog og træffe kritiske beslutninger hurtigt. Hemmeligheden bag at gøre det ligger i AI.

Lektion 3: AI er en grundlæggende byggesten til selvhelbredende systemer

Et helt autonomt, perfekt fungerende, selvhelbredende system er ideelt for enhver softwareingeniør. Systemer, der reparerer sig selv, er gode for kundetilfredsheden, da de eliminerer dyr nedetid i forhold til forbrugerne. Desuden er de utroligt gavnlige for IT-servicestyringsfunktioner (ITSM), da de reducerer behovet for kedelig billethåndtering markant. At bygge et sådant system kræver flere komponenter, hvoraf mange i øjeblikket er uden for rækkevidde. Men vi er tættere på en selvhelbredende virkelighed, end nogle måske er klar over.

Manglen på udbredt AI-adoption er fortsat den største hindring, som selvhelbredende systemer står over for i dag. Selvom mange virksomheder har brugt rudimentære AI- eller ML-baserede værktøjer, er integriteten af ​​disse værktøjer tvivlsom. Det vil sige, mange ingeniører beskæftiger sig med kunstig intelligens til IT-drift (AIOps) teknologier, der følger regelbaseret automatiseringslogik i stedet for autonome AI-algoritmer. Forskellen kan virke lille, men i praksis er det forskellen mellem timers tabt produktivitet og millioner i mulige tab.

Sagen er, at regelbaserede AIOps-værktøjer analyserer interaktionerne mellem forskellige punktløsninger og kan sandsynligvis identificere almindelige datafejl. Men automationsbaserede systemer kan ikke behandle udviklingen af ​​helt nye fejl over tid, og de kan heller ikke forudsige nye fejlfunktioner i data. Det er fordi de menneskelige administratorer, der koder disse funktioner, beder systemet om at følge en hvis dette, så det logisk mønster. Virkelig effektive AIOps-værktøjer afhjælper fejl, der opstår ved alle fire klassiske telemetripunkter – fra detektion til opløsning – ved at klassificere nye og problematiske mønstre, før menneskelige teknikere overhovedet er klar over deres eksistens. 

Mens vi venter på forestående tredje bølge af AI, denne version af AIOps er det tætteste vi er på selvhelbredende systemer. Det vil være interessant at spore, hvordan nuværende AIOps-applikationer bløder ind i fremtiden for AI, som vil omfatte fuldt realiseret automatisering og uafhængige tankemuligheder. Måske vil konstruktionsingeniører så også høste frugterne af et AI-baseret, selvhelbredende system.

Tidsstempel:

Mere fra DATAVERSITET