Cosa può insegnarci l'architettura sui sistemi autoriparanti

I team DevOps e gli ingegneri dell'affidabilità del sito (SRE) si occupano quotidianamente del codice. In questo modo insegna loro a scrutare il loro mondo, fare osservazioni astute e tracciare connessioni inaspettate. Dopotutto, sebbene di natura altamente logica e matematica, lo sviluppo del software è, almeno in parte, una forma d'arte. 

Non sei convinto di questa affermazione? Considera i parallelismi tra le imprese architettoniche più straordinarie della storia e la moderna ingegneria del software. È un paragone appropriato: proprio come l'ingegneria del software, l'architettura utilizza complessi calcoli matematici per creare qualcosa di bello. E in entrambe le discipline, un leggero errore di calcolo può portare a conseguenze significative. Affascinante, molti famosi errori di architettura sono analoghi ai problemi che troviamo nel codice.

Ricorda, l'ispirazione è ovunque, purché tu sappia dove cercare. Ecco alcune lezioni che gli ingegneri del software possono imparare dalle epifanie architettoniche nel corso dei secoli, in particolare per quanto riguarda il futuro dei sistemi di autoriparazione.

Lezione 1: i casi limite sfrutteranno sempre le vulnerabilità del sistema

La Citicorp Tower - ora chiamata 601 Lexington - terminò la costruzione a New York City nel 1977, momento in cui era il settimo edificio più alto del mondo. Il design all'avanguardia del grattacielo includeva tre palafitte di oltre 100 piedi. È stata una meraviglia al completamento. Tuttavia, uno studente universitario scoprì presto qualcosa di stridente: forti venti potrebbe compromettere l'integrità dell'edificio. Nello specifico, se potenti venti di squartamento colpivano gli angoli della Citicorp Tower, la struttura era soggetta a crollare, letteralmente caso limite.

La torre aveva una possibilità su 16 di crollare ogni anno. Queste probabilità potrebbero attirare qualcuno seduto a un tavolo da gioco, ma le prospettive erano cupe per gli architetti e gli ingegneri strutturali dietro la Citicorp Tower. Per fortuna, i tecnici sono stati in grado di rinforzare i giunti bullonati dell'edificio. Il disastro è stato evitato.

Gli ingegneri strutturali sapevano che la Citicorp Tower alla fine avrebbe affrontato un vento abbastanza forte da comprometterne l'orientamento. Allo stesso modo, gli ingegneri del software esperti sanno che un solido monitoraggio delle prestazioni delle applicazioni (APM) e la gestione degli eventi non sono sufficienti per proteggere un sistema dagli inevitabili casi limite. Questo perché i sistemi statici senza apprendimento automatico (ML) le capacità non possono gestire nuove situazioni impreviste e non pianificate, come i venti in quarti. Quando si affida esclusivamente agli strumenti di monitoraggio, un amministratore umano deve decifrare gli errori e intensificare il processo di gestione degli incidenti.

Per ridurre il tempo medio di ripristino (MTTR)/tempo medio di rilevamento (MTTD), i team DevOps devono accettare l'elevata probabilità di casi limite e lavorare per implementare preventivamente soluzioni di autoapprendimento. Questa lezione fa molta strada, poiché la lungimiranza è fondamentale nell'ingegneria.

Lezione 2: "Costruire l'aereo mentre vola" crea un ciclo senza fine

Gli eventi tragici hanno consegnato molti di le lezioni più importanti nella storia dell'aviazione. Quando un aereo subì un'enorme decompressione durante il volo e si schiantò nel 1954, gli ingegneri accertarono che i finestrini quadrati dei passeggeri erano un punto di stress non necessario. D'ora in poi, gli aerei erano dotati di finestre arrotondate. Gli incendi a bordo hanno portato a una nuova disposizione dei posti a sedere che privilegia la facilità di evacuazione. Questi cambiamenti hanno salvato innumerevoli vite.

In molti settori, aviazione inclusa, non c'è modo di testare in modo esaustivo un prodotto. Come accennato in precedenza, i casi limite sono inevitabili. Il più grande vantaggio qui è che gli ingegneri del software devono prestare attenzione alle vulnerabilità del loro sistema quando si presentano. Da lì, devono affrontarli opportunamente. Fare ciò richiede due cose: (1) identificare e tenere traccia degli indicatori chiave di prestazione (KPI) corretti e (2) investire tempo e risorse nel miglioramento dei sistemi sulla base di metriche pertinenti.

Il team di ingegneri medio investe in 16-40 strumenti di monitoraggio, ma spesso manca il segno su cui le metriche dimostrano il successo. Meno del 15% dei team tiene traccia dell'MTTD, quindi perde il 66% del ciclo di vita dell'incidente. E un quarto delle squadre riferisce mancano i loro accordi sul livello di servizio (SLA) nonostante i significativi investimenti nel monitoraggio della disponibilità. Questo ci dice che la raccolta dei dati richiede un'analisi approfondita e sistematica per eliminarla: le soluzioni puntuali non sono più sufficienti.

Ingegneri del software, team DevOps e SRE devono dare la priorità a processi e strumenti che estraggono valore da enormi quantità di informazioni sulla disponibilità. Invece di limitarsi a osservare un errore critico, devono prendere una pagina dal libro di un ingegnere aeronautico e prendere rapidamente decisioni critiche. Il segreto per farlo sta nell'intelligenza artificiale.

Lezione 3: L'intelligenza artificiale è un elemento fondamentale per i sistemi di auto-guarigione

Un sistema completamente autonomo, perfettamente funzionante e autorigenerante è l'ideale per qualsiasi ingegnere del software. I sistemi che si autoinstallano sono utili per la soddisfazione del cliente, in quanto eliminano i costosi tempi di inattività per i consumatori. Inoltre, sono incredibilmente utili per le funzioni di gestione dei servizi IT (ITSM), in quanto riducono significativamente la necessità di una noiosa gestione dei ticket. Costruire un tale sistema richiede diversi componenti, molti dei quali sono attualmente fuori portata. Ma siamo più vicini a una realtà che si autoguarisce di quanto alcuni possano realizzare.

La mancanza di un'adozione diffusa dell'IA rimane il più grande ostacolo che i sistemi di auto-riparazione devono affrontare oggi. Sebbene molte aziende abbiano adottato rudimentali strumenti basati su IA o ML, l'integrità di questi strumenti è discutibile. Vale a dire, molti ingegneri se ne occupano intelligenza artificiale per le operazioni IT (AIOps) che seguono una logica di automazione basata su regole anziché algoritmi di intelligenza artificiale autonomi. La distinzione può sembrare minima, ma in pratica è la differenza tra ore di produttività perse e milioni di possibili perdite.

Il fatto è che gli strumenti AIOps basati su regole analizzano le interazioni tra soluzioni puntuali disparate e possono probabilmente identificare errori di dati comuni. Ma i sistemi basati sull'automazione non possono elaborare l'evoluzione di errori completamente nuovi nel tempo, né possono prevedere nuovi malfunzionamenti nei dati. Questo perché gli amministratori umani che codificano queste funzioni chiedono al sistema di seguire un file se questo, allora quello schema logico. Gli strumenti AIOps veramente efficienti mitigano gli errori che si verificano in tutti e quattro i punti di telemetria classici, dal rilevamento alla risoluzione, classificando modelli nuovi e problematici prima ancora che i tecnici umani ne siano a conoscenza. 

Mentre attendiamo il imminente terza ondata di IA, questa versione di AIOps è quanto di più vicino abbiamo ai sistemi di autoriparazione. Sarà interessante tenere traccia di come le attuali applicazioni AIOps sanguinino nel futuro dell'IA, che includerà l'automazione completamente realizzata e le possibilità di pensiero indipendente. Forse allora anche gli ingegneri strutturali raccoglieranno i frutti di un sistema di auto-guarigione basato sull'intelligenza artificiale.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
• Fonte: https://www.dataversity.net/what-architecture-can-teach-us-about-self-healing-systems/