Jun 15, 2018
Sbagliando si impara
La buona pratica del postmortem nell’industria IT applicata alle tecnologie della Pubblica Amministrazione
This post is available also in English
Errare humanum est, perseverare autem diabolicum, “commettere errori è umano, ma perseverare è diabolico” è una famosa locuzione latina che riassume un luogo comune e mette in evidenza come l’errore umano dovrebbe essere considerato fonte di ispirazione per migliorare se stessi ed evitare gli errori in futuro. Un luogo comune antico ma che solo di recente è stato seriamente preso in considerazione nell’industria dell’information technology.
Chiunque abbia mai lavorato con la tecnologia sa bene che errori e incidenti sono comuni ed è praticamente impossibile evitarli. Tali incidenti a volte possono creare danni molto ingenti: si pensi a cosa succede quando un’applicazione si blocca e con essa centinaia di impiegati non riescono più a svolgere il loro lavoro, oppure quando vengono persi o corrotti accidentalmente dei dati. Anche la semplice interruzione di un sito web può causare una perdita di fiducia dei cittadini e in questo modo ritardare il processo di adozione dei nuovi strumenti digitali, portando a inefficienze che si trascinano negli anni successivi.
Mano a mano che i processi digitali vengono adottati e diventano interconnessi, come quando le procedure di sportello di tutti i comuni si basano su una infrastruttura condivisa ministeriale, si ottengono significative efficienze ma dall’altra parte aumenta la criticità e il bisogno di garanzie sulla stabilità e il buon funzionamento.
Negli ultimi anni, grazie allo studio di operazioni IT su larga scala condotte in grandi aziende (Google, Facebook, ecc.) e all’adozione di tecniche tipiche del mondo industriale¹ è stato possibile creare metodologie per affrontare in maniera efficace questi temi.
Sulla base di tali analisi, gli incidenti non sono da considerarsi come il risultato di azioni isolate commesse da singoli individui o singole componenti di un sistema, ma sono piuttosto situazioni che accadono quando mancano determinate tutele al verificarsi di situazioni impreviste. Tale cambio di paradigma consente di analizzare gli incidenti sotto un’altra prospettiva e di implementare metodologie per risolverli velocemente e ridurne l’incidenza, elaborando le informazioni sulle cause attraverso la scrittura di documenti postmortem.
Il postmortem² è un concetto ben noto nell’ambito tecnologico: si tratta di un documento in cui vengono registrate le attività, l’impatto che avuto l’incidente, le decisioni prese per arginare il problema ecc.
Una sorta di scatola nera che consente di capire cosa non è andato bene, ma soprattutto che permette di comprendere le cause dell’incidente e di trarne quindi lezioni per il futuro.
Gli obiettivi primari di un documento di postmortem sono quelli di assicurare che l’incidente sia ben documentato, che tutte le cause principali siano comprese, e soprattutto che siano state studiate e messe in atto efficaci contromisure per ridurre la probabilità e l’impatto di un’eventuale ricorrenza futura dello stesso incidente. Inoltre, è opportuno che tale documento sia prodotto entro le 48 ore successive all’incidente, al fine di non perdere dettagli e informazioni preziose.
È di fondamentale importanza che l’analisi e la redazione del documento di postmortem siano condotte concentrandosi sulle cause dell’incidente evitando di accusare persone o gruppi di lavoro di essersi comportati in maniera non corretta o inappropriata (blameless postmortem).
Crediamo che sia fondamentale introdurre la cultura DevOps³ (come già descritto nel post relativo all’impatto del Cloud nella Pubblica Amministrazione) e in particolare la redazione dei documenti di postmortem per la PA e i suoi fornitori, affinché molte delle problematiche più diffuse nella gestione dei servizi della PA vengano individuate e messe a fattor comune.
Vogliamo dare il nostro piccolo contributo alla diffusione di questa pratica condividendo il postmortem che abbiamo prodotto in seguito all’interruzione dei servizi di Cloud SPC Lotto 1 che ha causato disservizi al Team per la Trasformazione Digitale e ad altre 30 pubbliche amministrazioni per oltre 40 ore consecutive in alcuni casi. Il fornitore del contratto Cloud SPC, nonostante non sia consueto rilasciare documenti di postmortem dettagliati alla PA, si è dimostrato collaborativo fornendoci tali informazioni, anche se ci sono voluti 19 giorni dall’incidente.
Ci auguriamo che questa pratica in futuro diventi consuetudine nella pubblica amministrazione e tra i suoi fornitori; auspichiamo, inoltre, che i documenti di postmortem vengano pubblicati entro pochi giorni per gli incidenti più gravi che riguardano servizi pubblici. Questa pratica dovrebbe sempre essere inserita nei requisiti delle gare.
Il documento di postmortem che presentiamo fornisce una lettura del disservizio dal punto di vista di utilizzatori del servizio Cloud SPC e riguarda esclusivamente l’impatto avuto sui siti web del Team Digitale.
La riuscita del processo di trasformazione digitale della PA è strettamente legata alle persone, quindi, oltre a ridefinire i processi, è necessario favorire un cambiamento culturale attraverso l’introduzione di queste pratiche che consentono di migliorare la qualità dell’ambiente di lavoro nella PA ma soprattutto la qualità dei servizi.
Incidente connettività Cloud SPC – Postmortem
Documento prodotto da:
Data: 23–05–2018
Sommario
Impatto: i seguenti servizi sono stati resi irraggiungibili:
Durata: 28 ore
Causa: OpenStack network outage – cloud provider “Cloud SPC Lotto 1”
Contesto
I siti web del Team Digitale sono prevalentemente basati su codice HTML statico generato a partire dal contenuto sorgente dei repository GitHub. Il codice HTML viene pubblicato mediante un web server (nginx) ed esposto su protocollo HTTPS. Forum Italia (http://forum.italia.it) rappresenta l’unica eccezione a questo modello di dispiegamento, tale servizio viene infatti gestito separatamente mediante container Docker. Uno o più web server possono essere dispiegati in qualsiasi momento su macchine virtuali OpenStack del fornitore cloud – Cloud SPC Lotto 1, utilizzando le API messe a disposizione dalla piattaforma.
Le risorse Cloud (macchine virtuali e volumi dati) utilizzate per i servizi sono allocate nell’ambito contratto Cloud SPC dell’Agenzia per l’Italia Digitale.
Impatto
Il 19/05/2018 i seguenti servizi sono diventati irraggiungibili in seguito ad un problema di connettività del Cloud provider “Cloud SPC” :
Causa e fattore scatenante
Secondo quanto riportato dal fornitore, nel documento di postmortem diffuso il 07/06/2018, l’interruzione della connettività per le 31 utenze (tenant) del servizio Cloud SPC è stata innescata dalle attività di aggiornamento programmato della piattaforma OpenStack, effettuate nella notte di giovedì 17/05/2018. Il problema è stato rilevato il mattino seguente (18/05/2018) grazie alle segnalazioni degli utenti che non erano più in grado di accedere ai servizi erogati mediante la piattaforma di Cloud SPC.
Nel documento si legge che il riavvio dei nodi di controllo della piattaforma OpenStack (nodi che gestiscono i servizi di management di OpenStack : neutron, glance, cinder, ecc.) ha causato “un’anomalia” nell’infrastruttura di rete bloccando così il traffico su alcuni dei nodi di computing (i nodi dove sono eseguite le istanze virtuali), rendendo così irraggiungibili le macchine virtuali degli utenti (31 utenze differenti).
Il documento di postmortem spiega anche come un bug nei playbook (script di aggiornamento) avrebbe bloccato le attività di rete modificando i permessi del file “/var/run/neutron/lock/neutron-iptables”, come indicato anche nella documentazione ufficiale della piattaforma.
Sempre secondo quanto dichiarato dal fornitore il riavvio dei nodi si era reso necessario per applicare gli aggiornamenti di sicurezza dovuti a Meltdown e Spectre (CVE-2017–5715, CVE-2017–5753 e CVE-2017–5754).
L’indisponibilità dell’infrastruttura Cloud SPC è stata senza dubbio la causa principale del problema ma la mancanza di un meccanismo di protezione a livello applicativo per i servizi del Team Digitale ha contribuito a prolungare l’irraggiungibilità degli stessi. Infatti non avendo tenuto in considerazione, durante la fase di progettazione dei servizi, dell’eventualità che l’intero cloud provider potesse diventare irraggiungibile non è stato possibile rispondere adeguatamente a tale evento. Pur disponendo di numerose risorse virtuali presso il fornitore Cloud SPC, i servizi web non sono stati protetti da disservizi generalizzati che avrebbero potuto investire l’intera infrastruttura dell’unico fornitore Cloud a nostra disposizione.
Lezione appresa
La piattaforma Cloud SPC al momento non offre la possibilità di distribuire le macchine virtuali su data center o regioni differenti (OpenStack region) e quindi sarebbe stato utile poter disporre di risorse virtuali su infrastrutture indipendenti, anche dello stesso fornitore.
In prospettiva, la Pubblica Amministrazione dovrebbe poter disporre di più fornitori cloud, in modo da poter assicurare una resilienza ai propri servizi anche quando si verificano interruzioni del fornitore cloud principale.
Da questa esperienza la lezione più importante che abbiamo appreso riguarda la necessità di continuare ad investire per la costruzione di un modello di Cloud ibrido, multipiattaforma e multi fornitore. Un modello che consenta di disporre di applicazioni Cloud capaci di garantire l’affidabilità dei servizi della Pubblica Amministrazione anche quando il principale fornitore cloud è affetto da problemi che lo rendono irraggiungibile per lungo periodo di tempo.
Timeline
17–05–2018
22.30 CEST: Il servizio di alert MaaS di SPC invia gli alert via mail indicando che alcuni nodi non sono più raggiungibili. <INIZIO delle attività programmate>
19–05–2018
06:50 CEST: I servizi sopra indicati disponibili all’indirizzo ip 91.206.129.249 non sono più raggiungibili <INIZIO INTERRUZIONE>
19–05–2018
08:00 CEST: Il problema viene rilevato e segnalato al fornitore
09:30 CEST: Le macchine risultano accessibili dall’interfaccia di amministrazione di OpenStack (API e GUI) e la connettività interna non riscontra problemi. Le macchine virtuali possono comunicare nella rete privata del tenant, ma non hanno connettività verso internet.
15:56 CEST: Il Team Digitale invia un sollecito al fornitore e CONSIP via email
18:00 CEST: Il fornitore ci comunica che hanno individuato il problema, stesso problema del progetto DAF, lavorano ad un workaround manuale.
19:00 CEST: Il fornitore ci comunica che è stato prodotto un fix e che verrà applicato alle macchine virtuali delle 31 pubbliche amministrazioni (tenant) coinvolte.
20–05–2018
11:10 CEST: Il fornitore ripristina la connettività sulle VM interessate del tenant di AgID
11:30 CEST: Il Team Digitale riavvia i servizi web e i siti sono nuovamente raggiungibili <FINE INTERRUZIONE>
Note
[1] Le metodologie provenienti dall’ambito manifatturiero in particolare la produzione snella (lean production) derivata dal sistema produttivo Toyota e adattata all’ambito IT (Lean IT).
[2] È un documento in cui si riportano i risultati derivati dal processo di Root Cause Analysis che aiuta a identificare cosa, come e perché ha causato un determinato evento in modo tale da adottare le misure necessarie a prevenirlo in futuro. La cultura SRE in Google ha sviluppato particolarmente questa metodologia applicandola alle operations dei servizi IT.
[3] Per approfondimenti, senza pretesa di esaustività: L. Fong-Jones, N. R. Murphy; B. Beyer, How SRE relates to DevOps, O’Reilly Media, Inc., 2018; N.Forsgren, J. Humble, G. Kim, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, 2018; N. R. Murphy, J. Petoff, C. Jones, B. Beyer, Site Reliability Engineering, O’Reilly Media, Inc., 2016
Lavora con noi | Seguici su Twitter e LinkedIn | Visita il nostro sito | GitHub
