Vad arkitektur kan lära oss om självläkande system

Återutgiven av Platon

anhängare: 0

DevOps-team och webbplatstillförlitlighetsingenjörer (SRE) hanterar kod dagligen. Att göra det lär dem att granska sin värld, göra skarpsinniga observationer och dra oväntade kopplingar. Trots allt, även om det är mycket logiskt och matematiskt till sin natur, är mjukvaruutveckling, åtminstone delvis, konstform.

Inte övertygad av det uttalandet? Tänk på parallellerna mellan historiens mest anmärkningsvärda arkitektoniska bedrifter och modern mjukvaruteknik. Det är en lämplig jämförelse: precis som mjukvaruteknik använder arkitektur komplexa matematiska beräkningar för att skapa något vackert. Och inom båda disciplinerna kan en liten missräkning leda till betydande konsekvenser. Fascinerande nog är många kända arkitektoniska misstag analoga med problem vi hittar i kod.

Kom ihåg att inspiration finns överallt – så länge du vet var du ska leta. Här är några lektioner som mjukvaruingenjörer kan lära av arkitektoniska uppenbarelser genom århundradena, särskilt när det gäller framtiden för självläkande system.

Lektion 1: Edge-fall kommer alltid att utnyttja systemets sårbarheter

Citicorp Tower – nu kallat 601 Lexington – färdigställde konstruktionen i New York City 1977, då det var den sjunde högsta byggnaden i världen. Skyskrapans toppmoderna design inkluderade tre 100-plus-fots styltor. Det var ett under att avsluta. Men en student på grundutbildningen upptäckte snart något som skrämmer: Starka vindar kan äventyra byggnadens integritet. Närmare bestämt, om kraftfulla vindar träffade hörnen av Citicorp Tower, var strukturen föremål för kollaps - en bokstavlig kantväska.

Tornet hade en chans på 16 att kollapsa varje år. Dessa odds kan locka någon att sitta vid ett spelbord, men utsikterna var dystra för arkitekterna och konstruktionsingenjörerna bakom Citicorp Tower. Tack och lov kunde tekniker förstärka byggnadens skruvförband. Katastrof undveks.

Byggnadsingenjörer visste att Citicorp Tower så småningom skulle möta en vind stark nog att äventyra dess lager. På samma sätt vet erfarna mjukvaruingenjörer att robust övervakning av applikationsprestanda (APM) och händelsehantering inte räcker för att skydda ett system från de oundvikliga kantfallen. Det beror på att statiska system utan maskininlärning (ML) förmågor kan inte hantera oväntade och oplanerade nya situationer, såsom kvartsvindar. När den enbart förlitar sig på övervakningsverktyg måste en mänsklig administratör dechiffrera fel och eskalera incidenthanteringsprocessen.

För att minska medeltiden för återhämtning (MTTR)/medeltiden för att upptäcka (MTTD), måste DevOps-teamen acceptera den höga sannolikheten för edge-fall och arbeta för att distribuera självlärande lösningar förebyggande. Den här lektionen räcker långt, eftersom förutseende är avgörande inom teknik.

Lektion 2: "Att bygga planet medan det flyger" skapar en oändlig cykel

Tragiska händelser har levererat flera av de viktigaste lärdomarna i flyghistorien. När ett plan drabbades av enorm dekompression mitt under flygningen och kraschade 1954, konstaterade ingenjörer att fyrkantiga passagerarfönster var en onödig stresspunkt. hädanefter, flygplan var utrustade med rundade fönster. Bränder ombord ledde till nya sittplatser som prioriterade enkel evakuering. Dessa förändringar har räddat otaliga liv.

I många branscher – inklusive flyget – finns det inget sätt att uttömmande stresstesta en produkt. Som nämnts tidigare är kantfall oundvikliga. Den största fördelen här är att mjukvaruingenjörer måste uppmärksamma deras systems sårbarheter när de presenterar sig själva. Därifrån måste de ta itu med dem på ett ändamålsenligt sätt. Att göra det kräver två saker: (1) att identifiera och spåra rätt nyckelprestandaindikatorer (KPI:er) och (2) att investera tid och resurser för att förbättra system baserat på relevanta mätvärden.

Det genomsnittliga ingenjörsteamet investerar i 16 till 40 övervakningsverktyg, men de missar ofta märket på vilka mätvärden som visar framgång. Färre än 15 % av teamen spårar MTTD, så de missar 66 % av incidentens livscykel. Och en fjärdedel av lagen rapporterar saknar sina servicenivåavtal (SLA) trots betydande investeringar i tillgänglighetsspårning. Detta säger oss att datainsamlingen kräver en grundlig, systematisk analys för att skära ner det – punktlösningar räcker inte längre.

Programvaruingenjörer, DevOps-team och SRE måste prioritera processer och verktyg som extraherar värde från överväldigande mängder information om tillgänglighet. Istället för att bara observera ett kritiskt fel måste de ta en sida från en flygingenjörs bok och fatta kritiska beslut, snabbt. Hemligheten med att göra det ligger i AI.

Lektion 3: AI är en grundläggande byggsten för självläkande system

Ett helt autonomt, perfekt fungerande, självläkande system är idealiskt för alla mjukvaruingenjörer. System som korrigerar sig själva är bra för kundnöjdheten, eftersom de eliminerar kostsamma stilleståndstider för konsumenterna. Dessutom är de otroligt fördelaktiga för IT-tjänster (ITSM)-funktioner, eftersom de avsevärt minskar behovet av tråkig biljetthantering. Att bygga ett sådant system kräver flera komponenter, av vilka många för närvarande är utom räckhåll. Men vi är närmare en självläkande verklighet än vad vissa kanske inser.

Bristen på utbredd användning av AI är fortfarande det största hindret som självläkande system står inför idag. Även om många företag har antagit rudimentära AI- eller ML-baserade verktyg, är integriteten hos dessa verktyg tveksam. Det vill säga många ingenjörer sysslar med artificiell intelligens för IT-drift (AIOps)-tekniker som följer regelbaserad automationslogik istället för autonoma AI-algoritmer. Skillnaden kan tyckas liten, men i praktiken är det skillnaden mellan timmar av förlorad produktivitet och miljoner i möjliga förluster.

Saken är att regelbaserade AIOps-verktyg analyserar interaktionerna mellan olika punktlösningar och kan sannolikt identifiera vanliga datafel. Men automationsbaserade system kan inte bearbeta utvecklingen av helt nya fel över tiden, och de kan inte heller förutsäga nya fel i data. Det beror på att de mänskliga administratörerna som kodar dessa funktioner ber systemet att följa en om detta, då det logiskt mönster. Genuint effektiva AIOps-verktyg mildrar fel som uppstår vid alla fyra klassiska telemetripunkter – från upptäckt till upplösning – genom att klassificera nya och problematiska mönster innan mänskliga tekniker ens är medvetna om deras existens.

Medan vi väntar på förestående tredje vågen av AI, den här versionen av AIOps är det närmaste vi har självläkande system. Det kommer att bli intressant att spåra hur nuvarande AIOps-applikationer blöder in i framtiden för AI, vilket kommer att inkludera fullt realiserad automatisering och oberoende tankemöjligheter. Kanske kommer även strukturingenjörer då att skörda frukterna av ett AI-baserat, självläkande system.