Esiste una convinzione implicita che governa il funzionamento di quasi tutte le aziende tecnologiche: quando qualcosa si rompe, un essere umano deve ripararlo. Questa convinzione ha plasmato decenni di cultura del servizio di guardia, runbook, NOC e avvisi mattutini. Il problema è che inizia ad essere falso. Non perché gli esseri umani siano diventati più veloci, ma perché i sistemi hanno iniziato ad autoripararsi.
Il calcolo autonomo, o l'autoguarigione, non è né fantascienza né una promessa da venditore. Si tratta di una categoria di pratiche e tecnologie che è già in produzione in aziende che operano su scala rilevante, e che sta rapidamente diventando mainstream. La domanda per i leader tecnici non è se ciò accadrà, ma cosa significherà quando il tuo stack non avrà più bisogno di svegliare nessuno.
Cosa significa un sistema che si ripara da solo?
L'autoguarigione non significa semplicemente riavviare un pod che è morto. È un ciclo completo: rilevare che qualcosa non va, diagnosticare la causa principale, decidere l'azione giusta e intraprenderla, il tutto prima che l'utente si accorga del peggioramento.
Questo ciclo si manifesta in diversi modi. Un cluster Kubernetes che rileva un nodo danneggiato, scarica i carichi di lavoro e sostituisce automaticamente l'istanza. Un servizio che rileva un aumento anomalo della latenza, isola la partizione problematica e reindirizza il traffico avvisando il team senza interrompere l'operazione. Una pipeline di dati che identifica le anomalie di acquisizione, inverte la trasformazione e attiva la rielaborazione senza intervento manuale.
Ciò che accomuna questi scenari è l’inversione dell’ordine delle operazioni: prima agisce il sistema, poi l’uomo revisiona. Ciò sembra piccolo finché non si realizza che la maggior parte degli incidenti notturni avrebbero potuto essere risolti – o non diventare mai incidenti – se il sistema avesse avuto i giusti riflessi.
##AIOps: quando l'osservabilità diventa intelligenza operativa
Il collegamento che rende possibile l’autoguarigione su larga scala è AIOps: l’applicazione dell’apprendimento automatico sui dati di osservabilità per identificare modelli, correlare eventi e consigliare o intraprendere automaticamente azioni.
Il monitoraggio tradizionale ti dice "La CPU è al 95%". AIOps ti dice "questo picco della CPU si verifica ogni martedì alle 14:00 dopo una distribuzione specifica, non è un incidente, è un comportamento previsto, ed ecco gli altri tre segnali che lo confermano". Il primo è faticoso; il secondo educa.
Strumenti come Dynatrace, Datadog AIOps, Google Cloud Operations e piattaforme più piccole stanno incorporando questo tipo di ragionamento sulle serie temporali e sulla topologia del servizio. Il risultato non è un sistema onnisciente, ma un sistema che ha commesso errori e ha imparato dagli stessi incidenti che il tuo team ha già sperimentato e che, la prossima volta, non avrà bisogno di svegliare nessun altro per risolverli.
L'ingegneria del caos e la disciplina del fallire di proposito
C’è un’ironia nel cuore dell’informatica autonoma: per costruire sistemi in grado di riprendersi dai guasti, è necessario far sì che i sistemi falliscano di proposito, in modo controllato, prima che si verifichi il guasto effettivo.
Questa è ingegneria del caos. L'idea, resa popolare da Netflix con Chaos Monkey, è semplice: se non sai come si comporta il tuo sistema in caso di guasto, non sai se è resiliente. Tu pensi che lo sia. Per dimostrarlo è necessario insinuare il problema e osservare cosa succede.
Nella pratica moderna, l'ingegneria del caos si è evoluta dalla "eliminazione di istanze casuali" a esperimenti chirurgici: latenza artificiale nelle chiamate tra servizi, esaurimento delle risorse di memoria in pod specifici, guasto simulato di dipendenze esterne, partizionamento della rete tra zone. Ogni esperimento rivela un’ipotesi che il team aveva sulla resilienza e che, senza il test, rimarrebbe un’illusione finché non diventerebbe un incidente.
La disciplina dell'ingegneria del caos è, in sostanza, la disciplina che consiste nell'ammettere che il sistema fallirà e nel decidere che si vuole saperlo prima che lo faccia l'utente.
Come dovrebbe considerare la cosa un leader
Il costo dell’implementazione dell’autoguarigione è visibile e specifico. Il costo di non averlo è dispersivo e cronico: ore di reperibilità, incidenti che si ripetono, ingegneri senior impegnati in compiti che l’automazione potrebbe risolvere. Questo secondo numero appare raramente nel budget, ma appare nel fatturato.
L’autoguarigione cambia la composizione e il ritmo della squadra operativa. I team che dedicavano metà del loro tempo alla risposta reattiva agli incidenti ora hanno quel tempo liberato per lavori di maggior valore: migliorare i sistemi di rilevamento stessi, costruire esperimenti sul caos, rivedere le azioni autonome intraprese dal sistema e decidere se erano corrette. Il lavoro umano sale al livello successivo; non scompare.
Ciò ha implicazioni dirette per la cultura del servizio di guardia. Un turno che si sveglia per eseguire un runbook manuale è un turno che esaurisce gli ingegneri e genera turnover. Un cambiamento che si risveglia solo quando l’automazione non è stata in grado di risolversi – ed è già arrivato con un contesto completo di ciò che è stato tentato – è un modello sostenibile. L’obiettivo non è eliminare l’essere umano dal ciclo, ma garantire che l’essere umano entri nel ciclo al momento giusto, con informazioni sufficienti per prendere decisioni di qualità.
Per i leader che stanno valutando da dove iniziare: il punto di ingresso più conveniente non è assumere un team AIOps o adottare una nuova piattaforma. Sta mappando i cinque incidenti più frequenti degli ultimi sei mesi e chiedendo, per ciascuno di essi: cosa avrebbe dovuto essere vero affinché il sistema riuscisse a risolverlo da solo? Le risposte rivelano esattamente dove investire.
Leggi anche
- Kubernetes in produzione: quello che nessuno ti dice prima della migrazione
- Edge computing in fabbrica: quando lavorare localmente ha più senso
- Edge computing: perché l'informatica lascia il cloud e si avvicina ai dati
- Elettrificazione: cosa cambia quando tutto comincia ad accendersi alla presa
- Energia: il collo di bottiglia che nessuno ha inserito nella roadmap informatica
- Sensori e reti quantistiche: le applicazioni che vengono prima di tutto