Wat architectuur ons kan leren over zelfherstellende systemen

Heruitgegeven door Plato

volgers: 0

DevOps-teams en Site Reliability Engineers (SRE's) hebben dagelijks te maken met code. Hierdoor leren ze hun wereld onder de loep te nemen, scherpzinnige observaties te doen en onverwachte verbanden te leggen. Immers, hoewel zeer logisch en wiskundig van aard, is softwareontwikkeling, althans gedeeltelijk, kunstvorm.

Niet overtuigd door die verklaring? Overweeg de parallellen tussen de meest opmerkelijke architectonische hoogstandjes uit de geschiedenis en moderne software-engineering. Het is een treffende vergelijking: net als software-engineering gebruikt architectuur complexe wiskundige berekeningen om iets moois te creëren. En in beide disciplines kan een kleine misrekening grote gevolgen hebben. Fascinerend genoeg zijn veel beroemde architectonische fouten analoog aan problemen die we in code vinden.

Onthoud dat inspiratie overal is - zolang je maar weet waar je moet zoeken. Hier zijn een paar lessen die software-ingenieurs kunnen leren van architecturale openbaringen door de eeuwen heen, vooral met betrekking tot de toekomst van zelfherstellende systemen.

Les 1: Edge-cases maken altijd misbruik van systeemkwetsbaarheden

Citicorp Tower - nu 601 Lexington genoemd - voltooide de bouw in New York City in 1977, toen was het het zevende hoogste gebouw ter wereld. Het ultramoderne ontwerp van de wolkenkrabber omvatte drie stelten van meer dan 100 meter hoog. Het was een wonder bij voltooiing. Een niet-gegradueerde student ontdekte echter al snel iets schokkends: harde wind kan de integriteit van het gebouw in gevaar brengen. In het bijzonder, als krachtige kwartalenwinden de hoeken van de Citicorp Tower troffen, was de structuur onderhevig aan instorting – een letterlijke randgeval.

De toren had elk jaar een kans van één op 16 om in te storten. Deze kansen kunnen iemand verleiden om aan een goktafel te zitten, maar de vooruitzichten waren somber voor de architecten en bouwkundig ingenieurs achter Citicorp Tower. Gelukkig konden technici de boutverbindingen van het gebouw verstevigen. Een ramp werd vermeden.

Bouwkundige ingenieurs wisten dat de Citicorp Tower uiteindelijk te maken zou krijgen met een wind die sterk genoeg was om zijn posities in gevaar te brengen. Evenzo weten doorgewinterde software-engineers dat robuuste monitoring van applicatieprestaties (APM) en gebeurtenisbeheer niet voldoende zijn om een systeem te beschermen tegen de onvermijdelijke randgevallen. Dat komt omdat statische systemen zonder machinaal leren (ML) capaciteiten kunnen niet omgaan met onverwachte en ongeplande nieuwe situaties, zoals windstoten. Wanneer een menselijke beheerder uitsluitend op monitoringtools vertrouwt, moet hij fouten ontcijferen en het incidentbeheerproces escaleren.

Om de gemiddelde hersteltijd (MTTR)/mean time to detect (MTTD) te verminderen, moeten DevOps-teams de grote kans op randgevallen accepteren en preventief zelflerende oplossingen implementeren. Deze les gaat een lange weg, aangezien vooruitziendheid van cruciaal belang is in engineering.

Les 2: "Het vliegtuig bouwen terwijl het vliegt" creëert een nooit eindigende cyclus

Tragische gebeurtenissen hebben er verschillende opgeleverd de belangrijkste lessen uit de luchtvaartgeschiedenis. Toen een vliegtuig in 1954 een enorme decompressie onderging en in XNUMX neerstortte, stelden ingenieurs vast dat vierkante passagiersramen een onnodig stresspunt vormden. Voortaan, vliegtuigen waren uitgerust met ronde ramen. Branden aan boord leidden tot nieuwe zitplaatsen waarbij prioriteit werd gegeven aan gemakkelijke evacuatie. Deze veranderingen hebben talloze levens gered.

In veel sectoren – inclusief de luchtvaart – is er geen manier om een product uitvoerig te testen. Zoals eerder vermeld, zijn randgevallen onvermijdelijk. De grootste afhaalmogelijkheid hier is dat software-ingenieurs acht moeten slaan op de kwetsbaarheden van hun systeem wanneer ze zichzelf presenteren. Van daaruit moeten ze ze op gepaste wijze aanspreken. Hiervoor zijn twee dingen nodig: (1) het identificeren en volgen van de juiste key performance indicators (KPI's) en (2) tijd en middelen investeren in het verbeteren van systemen op basis van relevante statistieken.

Het gemiddelde technische team investeert in 16 tot 40 monitoringtools, maar ze missen vaak het doel waarop statistieken succes aantonen. Minder dan 15% van de teams volgt MTTD, waardoor ze 66% van de incidentlevenscyclus missen. En een vierde van de teams rapporteert missen hun service level agreements (SLA's) ondanks aanzienlijke investeringen in het bijhouden van beschikbaarheid. Dit vertelt ons dat het verzamelen van gegevens een grondige, systematische analyse vereist om het te beperken – puntoplossingen zijn niet langer voldoende.

Software-engineers, DevOps-teams en SRE's moeten prioriteit geven aan processen en tools die waarde halen uit overweldigende hoeveelheden informatie over beschikbaarheid. In plaats van simpelweg een kritieke fout te observeren, moeten ze een pagina uit het boek van een luchtvaartingenieur nemen en snel cruciale beslissingen nemen. Het geheim hiervoor ligt in AI.

Les 3: AI is een fundamentele bouwsteen voor zelfherstellende systemen

Een volledig autonoom, perfect functionerend, zelfherstellend systeem is ideaal voor elke software-engineer. Systemen die zichzelf patchen zijn goed voor de klanttevredenheid, omdat ze kostbare uitvaltijd voor consumenten elimineren. Bovendien zijn ze ongelooflijk gunstig voor IT-servicebeheer (ITSM) -functies, omdat ze de behoefte aan vervelend ticketbeheer aanzienlijk verminderen. Het bouwen van zo'n systeem vereist verschillende componenten, waarvan er vele momenteel buiten bereik zijn. Maar we zijn dichter bij een zelfgenezende realiteit dan sommigen misschien beseffen.

Het gebrek aan wijdverspreide acceptatie van AI blijft de grootste hindernis waarmee zelfherstellende systemen vandaag worden geconfronteerd. Hoewel veel bedrijven rudimentaire AI- of ML-gebaseerde tools hebben gebruikt, is de integriteit van deze tools twijfelachtig. Dat wil zeggen, veel ingenieurs hebben ermee te maken kunstmatige intelligentie voor IT-activiteiten (AIOps) technologieën die op regels gebaseerde automatiseringslogica volgen in plaats van autonome AI-algoritmen. Het onderscheid lijkt misschien miniem, maar in de praktijk is het het verschil tussen uren productiviteitsverlies en miljoenen mogelijke verliezen.

Het punt is dat op regels gebaseerde AIOps-tools de interacties tussen ongelijksoortige puntoplossingen analyseren en waarschijnlijk veelvoorkomende gegevensfouten kunnen identificeren. Maar op automatisering gebaseerde systemen kunnen de evolutie van geheel nieuwe fouten in de loop van de tijd niet verwerken, noch kunnen ze nieuwe storingen in gegevens voorspellen. Dat komt omdat de menselijke beheerders die deze functies coderen, het systeem vragen om een als dit, dan dat logisch patroon. Echt efficiënte AIOps-tools verminderen fouten die optreden op alle vier de klassieke telemetriepunten - van detectie tot resolutie - door nieuwe en problematische patronen te classificeren voordat menselijke technici zich zelfs maar bewust zijn van hun bestaan.

Terwijl we wachten op de naderende derde golf van AI, komt deze versie van AIOps het dichtst in de buurt van zelfherstellende systemen. Het zal interessant zijn om te volgen hoe de huidige AIOps-applicaties overvloeien in de toekomst van AI, die volledig gerealiseerde automatisering en onafhankelijke denkmogelijkheden zal omvatten. Misschien zullen dan ook constructeurs de vruchten plukken van een op AI gebaseerd, zelfherstellend systeem.