La parola “interruzione” può far pensare al blocco totale di un servizio, che mette improvvisamente fuori uso l'intera catena di erogazione. Tuttavia, se andiamo più a fondo nella nostra analisi, nella maggior parte dei casi è raro (sebbene non impossibile) che ci troviamo di fronte a un black-out totale.
Di recente, abbiamo notato un aumento dei cosiddetti “guasti funzionali”: in questi casi, il guasto riguarda solo una parte del servizio, ma con effetti a valle che si ripercuotono sull'intera catena di erogazione. Può trattarsi, ad esempio, di un errore nel gateway di pagamento o di un problema nel processo di autenticazione dell'utente. Spesso, questi componenti sono forniti da terze parti e sfuggono al controllo del provider, ma possono avere un impatto devastante sull'erogazione del servizio.
Solo un attento esame delle interruzioni consente di mitigarle, sia dal punto di vista del provider di servizi che da quello del cliente. Capire meglio le modalità con cui si verificano le interruzioni aiuta a ridurre i rischi di guasto a lungo termine.
L'aumento dei guasti funzionali
Chi ascolta regolarmente il podcast The Internet Report, negli ultimi mesi avrà sentito parlare dell'aumento dei guasti funzionali in alcuni dei servizi Internet più importanti del mondo. Spesso, in presenza di un guasto funzionale, il servizio risulta “non disponibile” per l'utente. Ma, esaminando l'interruzione più da vicino, in genere vediamo che il guasto riguarda solo una piccola parte dell'applicazione, come un plugin esterno, un gateway di pagamento o il provider di autenticazione.
In un'architettura distribuita, i servizi sono composti da più elementi che devono interagire in armonia. Questa configurazione offre molti vantaggi, tra cui l'ottimizzazione del servizio e una latenza ridotta. Ad esempio, è probabile che un rivenditore online non gestisca direttamente il gateway di pagamento. Perché dovrebbe farlo? Non è la sua competenza chiave e comporta rischi per la sicurezza; inoltre, affidarsi a un provider esterno è quasi sempre la scelta più conveniente dal punto di vista economico, perché il rivenditore non deve sostenere i costi di sviluppo o manutenzione. Anche le aziende tecnologiche più importanti del mondo usano componenti di terze parti nelle loro applicazioni. Non si tratta di una scelta fatta solo in nome della tecnologia, ma è un modo per ottimizzare le prestazioni e ridurre i costi di gestione.
Tuttavia, questo approccio comporta anche dei rischi. I componenti esterni possono guastarsi e compromettere l'intero servizio. Se, ad esempio, l'utente non riesce ad eseguire l'autenticazione in un social network, non importa se la parte di messaggistica continua a funzionare alla perfezione. L'utente non può accedere e quindi non usufruisce del servizio.
In altri casi, l'utente riesce ad autenticarsi e l'app sembra funzionare correttamente. E invece, per un guasto funzionale del servizio di backend, quando tenta di compiere una qualsiasi azione, come inviare un messaggio o completare un acquisto, il servizio risulta non disponibile.
Anche se molti provider integrano la ridondanza nei propri servizi, a volte il rapporto rischi-benefici rende difficile giustificare un sistema di failover. Ad esempio, implementare un gateway di pagamento di riserva è una soluzione costosa e tecnicamente complessa, e molti provider di servizi preferiscono farne a meno. Allo stesso modo, è raro che i clienti tornino ad acquistare lo stesso tipo di servizio se la prima volta le prestazioni sono state insoddisfacenti.
Questo, però, non vuol dire che l'unica soluzione sia mettersi l'anima in pace e accettare le interruzioni occasionali come un male inevitabile.
Comprendere le interruzioni
Che cosa si può fare in questi casi? Innanzitutto, bisogna comprendere l'anatomia delle interruzioni.
Per prima cosa, è necessario individuare il dominio di errore, ovvero l'origine del problema e il soggetto responsabile di risolverlo. Ad esempio, si tratta di un servizio esterno o del data center che ospita il servizio?
Ma attribuire le responsabilità non basta. Bisogna capire l'impatto del guasto e le ripercussioni che potrebbe avere sull'intera catena di erogazione se dovesse ripetersi. Il servizio era totalmente assente o si è verificato solo un calo delle prestazioni? Quali conseguenze ha avuto l'aumento della latenza in una specifica parte della catena di erogazione del servizio? Solo dopo aver pienamente compreso le conseguenze di un'interruzione possiamo iniziare a pensare a come evitarla o mitigarne l'impatto in futuro.
Le aziende devono decidere dove e quando è sensato pensare alla ridondanza. Come abbiamo detto, è molto improbabile che un'azienda abbia due gateway di pagamento, perché in genere i costi da sostenere sono troppo elevati. Tuttavia, potrebbe decidere di affidarsi a due provider di reti CDN o di suddividerli nelle varie aree geografiche. Questo incide sull'elaborazione, ma rientra nella valutazione dei rischi.
Anche i clienti che usufruiscono di questi servizi devono valutare i rischi, ad esempio per determinare il costo di potenziali guasti e delle misure correttive. Chi si affida a un provider di servizi cloud deve magari decidere se investire in due zone di disponibilità separate. Questa scelta richiede un'analisi dei costi per calcolare quanto incide sull'elaborazione. Come sincronizzare i dati tra le due zone? Servono più reti CDN? Affidarsi a un provider di servizi cloud di secondo livello è più conveniente?
Per rispondere a queste domande, è necessario avere una visione completa della catena di erogazione del servizio, ovvero sapere perché si è verificata l'interruzione, qual è la probabilità che si ripeta in futuro, qual è il livello di rischio e quali azioni intraprendere per prevenirla.
Invece di “correggere gli errori solo quando si verificano,” bisogna adottare un approccio orientato al miglioramento continuo, prevenendo i potenziali problemi e mitigandone l'impatto ancora prima che si presentino.
Ascolta la puntata "The Anatomy of an Outage" del nostro podcast, scopri com'è fatta un'interruzione ed approfondisci insieme a noi alcuni casi di aziende reali.
Identificare le informazioni chiave
Invece di limitarsi a reagire quando si presenta un problema, le aziende devono adottare un approccio preventivo e continuare a cercare modi per migliorare le prestazioni della rete. A tale scopo, bisogna concentrarsi sui dati giusti.
Tentare di tenere sotto controllo ogni aspetto e analizzare ogni singola metrica disponibile non è consigliabile. Si tratta di un approccio troppo dispendioso in termini di tempo e denaro. E anche se l'azienda può permettersi di raccogliere tutti questi dati, molto presto sarà come cercare un ago in un pagliaio.
Un approccio migliore consiste nell'individuare le informazioni più pertinenti che possono fare la differenza per il business e consentono di ottimizzare le operazioni per il futuro, perché si conoscono bene i rischi e il rapporto costi-benefici associato alla gestione dei potenziali problemi o delle possibili soluzioni.
Nell'arco della mia carriera, ho lavorato con un noto operatore nel settore del gioco d'azzardo che aveva deciso di spostare le operazioni dal data center interno al cloud con una migrazione dell'infrastruttura di tipo “Lift and Shift”. All'azienda era stato detto che bastava replicare la configurazione attuale in un'architettura cloud per ridurre i costi e migliorare le prestazioni.
Invece, una volta completata la migrazione, le prestazioni sono scese, nonostante le apparecchiature più moderne, perché l'architettura non era stata progettata secondo i requisiti della nuova infrastruttura cloud. Nel settore del gioco d'azzardo, un ritardo nelle prestazioni delle app può causare problemi critici, perché i clienti scommettono sugli eventi in tempo reale e reagiscono immediatamente ai cambiamenti durante il gioco. Con la nuova infrastruttura, scommettere richiedeva il doppio del tempo, e questo rischiava di allontanare i clienti.
Non solo: poiché l'azienda aveva spostato l'infrastruttura on-premises nel cloud senza ottimizzare il sistema di backend, i costi di elaborazione stavano aumentando.
Per risolvere il problema, il team ha dovuto ripartire da zero e rivedere l'intera configurazione. Il codice è stato riprogettato in base alla piattaforma cloud per riportare i costi a livelli accettabili, senza compromettere le prestazioni. In effetti, era necessario aumentare l'efficienza. A tale scopo, il servizio è stato suddiviso in più parti e l'infrastruttura cloud è stata fisicamente portata più vicino agli utenti, in modo da evitare ritardi importanti durante le scommesse.
Individuare i punti di rottura
Questa esperienza conferma che un approccio proattivo orientato al miglioramento continuo è fondamentale. La cosa più importante che un'azienda può fare è individuare i punti deboli all'interno del proprio ambiente e i potenziali colli di bottiglia.
Non è necessario identificare ogni singola vulnerabilità, ma è importante capire quali aree sono più soggette a un calo delle prestazioni, perché è qui che più probabilmente si verificheranno i problemi. Di fatto, la perdita di prestazioni è l'indicatore principale di un'interruzione. In questi casi si rilevano prestazioni ridotte, ritrasmissione, aumento della latenza e tutti i principali segnali di un guasto.
Individuare questi colli di bottiglia prima che qualcosa smetta di funzionare permette di ottimizzare il servizio ed è proprio in quest'ambito che l'investimento in soluzioni IT offre i vantaggi maggiori. Non solo: adottando questo approccio si evita di perdere tempo a esaminare una miriade di dati, cercando di capire che cosa è andato storto.