Nessuno ha toccato nulla

Narratore: Attenzione: questo podcast è prodotto con voci sintetiche. Le persone che sentirete non esistono, le disfunzioni che raccontano, purtroppo, sì.

Narratore: Sabato notte, l'una e ventidue. Il monitoring ha appena inviato l'ennesimo alert di sempre. È quello noto da due anni, classificato come falso positivo. Questa volta, però, è vero.

Senior Developer: Okay, vedo... vedo tutto rosso. L'CPU, la memoria, le code. Insomma, il rosso completo.

Junior Developer: Scusa, mi collego anche io. È la mia prima rotazione on-call, quindi... chiedo subito la cosa ovvia: chi è l'owner di questo servizio?

Senior Developer: Guarda la dashboard. Ti dico io chi è l'owner.

Junior Developer: Okay, qui scritto ci sono tre team: Platform, Digital Factory e... Infinity Business Solutions?

Senior Developer: Platform si chiama adesso Digital Factory. Digital Factory si chiamava prima Platform. E Infinity Business Solutions è il nome che qualcuno aveva messo come segnaposto sette anni fa, e che non ha mai esistito davvero.

Junior Developer: Quindi l'owner è... nessuno?

Senior Developer: L'owner è noi due, adesso.

Narratore: Il team si mette al lavoro sulla diagnosi. La prima osservazione è tecnicamente corretta e moralmente rassicurante.

Senior Developer: Primo punto: nessun deploy da due settimane. Quindi questo disastro non è colpa nostra. Ripeto, per iscritto: non è colpa nostra.

Junior Developer: Se non è un deploy, cos'è? Nella timeline di monitoring c'è un job che è partito alle una in punto. Job di pulizia dati, esecuzione mensile.

Senior Developer: Ah. Quello.

Junior Developer: Che vuol dire 'quello'? Chi l'ha scritto? C'è un nome nel commento in cima al file: si firmano i job di pulizia dati?

Senior Developer: A quel punto il sistema era in producedi collassare da tempo. Io direi di guardare altrove, per ora. Tipo, ovunque.

Narratore: Il Senior non ha detto chi ha scritto quel job. Non lo dirà per il resto della notte. Alla war room si aggiunge il Chief Technology Officer. Si è collegato dal ristorante. È l'una e quaranta di notte.

Chief Technology Officer: Ragazzi, vi sento dal telefono, ho un ambiente un po' rumoroso, scusate. Detto questo, sono entusiasta: questo incidente è una straordinaria opportunità di resilienza. Il sistema ci sta chiedendo di crescere.

Junior Developer: Il sistema è giù, in realtà. Da quaranta minuti.

Chief Technology Officer: Proprio per questo. La board domani chiederà cosa è successo, quindi mi serve una timeline dettagliata entro stasera. E propongo di definire subito la versione per i clienti: una frase chiara, rassicurante. Magari parliamo di manutenzione straordinaria programmata.

Senior Developer: Non sappiamo ancora la causa.

Chief Technology Officer: Ancora meglio. Una versione nota prima della causa è più flessibile. Passo ora, il dolce sta arrivando. Siete fantastici.

Junior Developer: Per la timeline, cosa scrivo esattamente? Tipo: alle una e ventidue il sistema ha deciso di crescere?

Senior Developer: Scrivi che è stato rilevato un degrado e che le indagini procedono. Sono parole che non impegnano a niente, e questo è il loro unico pregio.

Narratore: Poco dopo, arriva anche il Software Architect. Finora l'incidente riguardava un job mensile di pulizia dati.

Software Architect: Buongiorno a tutti, anche se tecnica direi notte. Ho letto l'alert: esaurimento memoria. Questo conferma empiricamente quanto sostenuto da mesi. Il monolite non regge più. Serve smontarlo.

Junior Developer: Sorry, ma l'esaurimento di memoria è causato da un job specifico, non dal monolite in sé. Il job è scritto in... un linguaggio che gira dentro il monolite, comunque.

Software Architect: Proprio così. Ecco perché propongo una root cause analysis strutturata, in cui l'esito prevedibile, e dico prevedibile, sarà la trasformazione del sistema in un'architettura event-driven. Il job diventa un servizio, la pulizia diventa un evento, la memoria diventa scalabile.

Senior Developer: L'incidente è ancora in corso.

Software Architect: Certo, e infatti propongo la call per mercoledì. In pieno incidente si ragiona meglio, l'adrenalina aiuta la visione di sistema.

Narratore: Domenica mattina, ore nove. Il sistema è ancora giù, ma la war room ha cambiato argomento almeno tre volte. Entra il Commerciale.

Commerciale: Ragazzi, buongiorno, ascolta, situazione delicata ma gestibile. Il cliente mi ha scritto direttamente, ha mandato una mail al nostro CEO perché il gestionale era lento da sabato sera. Ho già risposto che l'intervento è in corso e che avremo prioritario assoluto. Non sono entrato nel tecnico, ovviamente.

Junior Developer: Ma 'in corso' è tecnicamente vero. Il problema è che l'intervento non è ancora... iniziato.

Commerciale: Guarda, per il cliente 'in corso' significa 'ci stiamo facendo carico', e questo è vero al cento per cento. Mi dite solo che tra un paio d'ore torna tutto, così chiudo la loop con il CEO?

Senior Developer: Dipende. Ci serve capire il job.

Commerciale: Perfetto, allora due ore. Uso 'due ore', è un numero che funziona bene nelle mail.

Junior Developer: Scusa, ma due ore da quando? Ancora non sappiamo nemmeno la causa.

Senior Developer: Da quando lui l'ha scritta. Nelle mail il tempo parte quando viene promesso.

Narratore: Alle nove e trenta la squadra prova la soluzione che il legacy mette a disposizione in questi casi.

Senior Developer: Lancio il riavvio del servizio. Tre, due, uno.

Junior Developer: È... è tornato tutto online. In tre minuti. Perché funziona? Qualcuno sa perché funziona?

Senior Developer: No. E consiglio caldamente a nessuno di scoprirlo.

Junior Developer: Ok, documento qualcosa? C'è almeno un runbook per questo servizio?

Senior Developer: C'è il runbook della migration, nel vecchio wiki. Un documento. Con una riga: 'in caso di problemi, riavviare il servizio'. Aggiungo: 'se non funziona, riprovare'. Ora anche chi verrà dopo noi non saprà il perché.

Commerciale: Quindi per la mail al cliente scrivo downtime, o meglio... manutenzione straordinaria? O è maintenance programmata? Qualcosa che non faccia pensare a un problema, insomma.

Junior Developer: Ma se è un incidente, è un incidente. Dovremmo classificarlo come downtime, no? È più onesto.

Senior Developer: Visto che il riavvio era previsto in nessun runbook, chiamiamolo manutenzione. Nessuno potrà mai smentirci.

Commerciale: Manutenzione programmata, perfetto. Nel report trimestrale sembrerà persino una buona notizia.

Narratore: Tre giorni dopo, il team è di nuovo nella stessa call. Si tiene il post-mortem blameless dell'incidente.

Chief Technology Officer: Ragazzi, prima cosa: congratulazioni. Incidente gestito con successo, downtime contenuto, comunicazione verso il cliente impeccabile. La board è soddisfatta e ho annunciato un piano pluriennale di affidabilità. Tre anni, roadmap con milestone, la voglio nelle slide di novembre.

Software Architect: E come anticipato, la root cause analysis conferma la direzione: job monolitico, memoria non scalabile, mancanza di disaccoppiamento. La migration event-driven è la risposta strutturale. Mercoledì presento la proposta di ripiattaforma.

Senior Developer: Quindi nessuno ha capito perché è caduto il sistema.

Chief Technology Officer: In un'ottica blameless, la domanda non è chi, né perché. La domanda è cosa abbiamo imparato.

Junior Developer: Io ho imparato una cosa. Che nessuno sa cosa fa quel job di pulizia dati.

Chief Technology Officer: Ottimo, questa è la nostra prima action item. Capire cosa fa quel job. La assegno a te, che sei nuovo e hai fresco il contesto. Bene, chiudo io.

Narratore: La rotazione on-call viene aggiornata quella settimana. Il runbook no. Il job di pulizia dati, nel frattempo, è ripartito regolarmente. Il primo del mese.