Il tifone è passato senza danni: come un product manager supera l'ora più buia, come si resiste a un tifone

Comincio con una frase che forse darà fastidio a qualcuno: la stragrande maggioranza delle «ore più buie» che vivrai nella tua vita finirà esattamente come questo tifone — tanto rumore per nulla. E quelle quattro parole, «tanto rumore per nulla», uccidono un product manager più del tifone stesso.

Il tifone n. 9 di quest’anno, «Bawei», ieri notte ha virato a sud. Non ha colpito Zhoushan in pieno, si è indebolito a livello di tempesta tropicale e si è diretto verso la costa tra Wenling, nel Zhejiang, e Xiapu, nel Fujian. E così a Zhoushan e a Putuo i traghetti fermati fin dal 9 luglio, i voli cancellati, quei pescherecci portati uno dopo l’altro nella notte dagli ancoraggi al molo ovest di Shenjiamen — col senno di poi, sembra tutta fatica sprecata. Stamattina qualcuno già scriveva nel gruppo: «Se lo sapevo, non stavamo lì a portare via le barche in piena notte.»

Fermiamoci su questa frase. Perché la cosa più interessante di tutta la vicenda si nasconde proprio in quel «se lo sapevo, non serviva».

Nell’articolo precedente scrivevo di Putuoshan, e dicevo di non andare a pregare Guanyin perché ti fermi il tifone, ma di andare a costruire la diga. Non attribuire il «non essere stati colpiti» a una misteriosa protezione divina: è un’attribuzione sbagliata. Questo articolo fa un passo avanti: la diga è costruita, l’allarme suona davvero — quella notte, tu che tieni il timone, cosa devi fare esattamente?

La mia risposta è: resistere a un tifone non è mai un solo gesto, sono tre gesti concatenati — prima che il tifone arrivi, prepararsi a fondo; nel pieno del tifone, reggere il vento e la pioggia; dopo che il tifone è passato, spazzare via le macerie. Queste tre cose, anche se nove volte su dieci non succede nulla, non puoi permetterti di saltarne nemmeno una. È così che un product manager attraversa la sua ora più buia.

1. Prima che il tifone arrivi: la calma che hai è tutta roba che ti sei messo da parte prima

Nell’ora più buia, la cosa più ingannevole è la «calma».

Vedrai persone il cui sistema è andato in crash nel cuore della notte, con i dati sballati e il capo al telefono, e che restano comunque sedute lì a mettere in ordine le cose una per una. Pensi che sia una dote naturale, un sangue freddo innato, improvvisazione sul momento. Non è così. Nell’ora più buia, la calma non nasce mai lì per lì: è tutta roba che ti sei messo da parte, poco alla volta, in quei «giorni senza tifone».

Per chi fa prodotto, per chi fa sistemi, ciò che «metti da parte» sono cose molto concrete: un interruttore di rollback che puoi premere in qualsiasi momento; un sistema di rilascio graduale che ti lascia far uscire prima l’1% del traffico per sbagliare in piccolo, invece di buttare in acqua il 100% degli utenti in un colpo solo; una cintura di monitoraggio e allarmi che ti fa sapere dove stai perdendo sangue prima che siano gli utenti a insultarti; un piano d’emergenza scritto nero su bianco e davvero provato; e quel margine di fiducia e di liquidità che ti sei accumulato poco alla volta, quando ancora non serviva.

La parola chiave qui è «davvero provato».

Il 31 gennaio 2017 GitLab ebbe un incidente di cui si parla ancora oggi. Un ingegnere, a notte fonda, lanciò un comando di cancellazione sul database sbagliato e cancellò i dati del database di produzione. La cancellazione in sé non è la fine del mondo — a far gelare il sangue a tutti fu ciò che accadde dopo: avevano cinque meccanismi di backup e replica, e alla resa dei conti nessuno di questi funzionava davvero. Il backup automatico con pg_dump, per un errore di configurazione, in realtà non era mai andato a buon fine; il fallimento del backup avrebbe dovuto generare un’email di allarme, ma quelle email venivano silenziosamente rifiutate a causa delle impostazioni DMARC, e nessuno le riceveva; c’erano sì gli snapshot dei dischi su Azure, ma per ripristinarli servivano più di 18 ore. Alla fine, ciò che riportò GitLab indietro dall’orlo del baratro fu uno snapshot che un ingegnere aveva fatto a mano, per puro caso, sei ore prima dell’incidente. Grazie a quell’unico «per caso» persero solo sei ore di dati.

Questa vicenda mette a nudo, in modo brutale, il vero significato delle parole «prepararsi a fondo»: credi di aver costruito la diga, ma quando arriva il tifone scopri che era solo disegnata. Cinque backup, che sulla carta sembravano una fortezza inespugnabile, e nessuno era stato verificato o provato sul serio. Un piano d’emergenza mai provato non è un piano, è un desiderio. Quella frase che hai scritto nella documentazione, «disponiamo di un solido piano di disaster recovery», prima che il tifone arrivi non vale più di un augurio.

Un approccio ancora più radicale è non aspettare nemmeno che il tifone arrivi. Netflix ha allevato un programma chiamato «Chaos Monkey», il cui lavoro quotidiano consiste nell’andare nell’ambiente di produzione e, proprio nelle belle giornate di calma piatta, spegnere a caso qualche macchina che sta servendo gli utenti. Sembra autolesionismo, ma in realtà è la forma più onesta di esercitazione: invece di aspettare che arrivi il tifone vero per scoprire che la diga era disegnata, tanto vale liberare ogni giorno una scimmia impazzita dentro la sala macchine, mandare in crash un sistema che ancora non ha avuto problemi, e vedere se regge o no. Solo la calma che sopravvive a Chaos Monkey è calma vera; la calma che non è mai stata messa così alla prova è solo fortuna non ancora esaurita.

E qui compare il primo livello di «tanto rumore per nulla»: quei rollback, quelle esercitazioni, quei backup che ti sei messo da parte, nella stragrande maggioranza dei casi non ti serviranno mai, nemmeno una volta in tutta la vita. Non usarli ti farà sentire di aver lavorato per niente. Ma prova a vederla da un’altra angolazione: i giorni sereni che hai vissuto non sono fortuna, sono comprati con la preparazione. Una persona che «prepara senza che serva mai» è semplicemente una a cui non è ancora toccato.

2. Nel pieno del tifone: devi stare in prima fila a prenderti la pioggia

Per quanto ti prepari a fondo, nell’istante in cui il tifone ti si scaglia in faccia fa comunque male. A quel punto si mette alla prova un’altra cosa: farsi carico.

Nel pieno della crisi, chi tiene il timone ha due cose che non deve fare in nessun caso — scappare, e scaricare la colpa.

Scappare significa nascondersi e aspettare che passi la buriana; scaricare la colpa significa correre subito a cercare «chi ha premuto quel pulsante». Questi due gesti, sul momento, ti fanno stare un po’ meglio, ma uccidono contemporaneamente la cosa più preziosa: la voglia del tuo team di continuare a buttarsi avanti. Farsi carico, in soldoni, è fare l’esatto contrario — portarsi in prima fila e prendere la decisione più difficile del momento, quella che però va presa subito. Prima fermi l’emorragia: se va fatto un rollback lo fai, se va messo offline lo metti, se va tagliato lo tagli, se va ammesso l’errore lo ammetti, se vanno avvisati gli utenti non rimandi a domani. Il conto, te lo prendi tu per primo.

Sempre quel giorno di GitLab. Fecero una cosa che ancora oggi appare molto controintuitiva: ripristinarono il database in diretta pubblica. Migliaia di persone online li guardavano mentre stendevano davanti a tutti la figuraccia della cancellazione, mentre mettevano in piazza il fatto che tutti e cinque i livelli di backup fossero inutili, e mentre poco alla volta rimettevano le cose a posto. Non era una messinscena. È la forma più dura del «farsi carico»: ho fatto un casino, lo aggiusto davanti a tutti, non mi nascondo. Solo in un’azienda che ha il coraggio di fare così gli ingegneri imparano che, quando qui qualcosa va storto, il primo istinto è aggiustare, non nascondere.

Confronta tutto questo con quei posti dove, appena succede qualcosa, la prima cosa è convocare una riunione per cercare il colpevole. Appena scoppia l’incidente, la prima cosa che fanno tutti è pensare a come tirarsi fuori: subito a fare il backup dei log, subito a fare screenshot delle chat, «questo modulo non è di mia competenza» che esce di bocca da solo. Il contrario del farsi carico non è il panico, è lo scaricabarile. Chi spinge la responsabilità verso il basso, sul team, o verso l’esterno, sulla «sfortuna», quando il vento smette lascia agli altri un solo ricordo: quella sua schiena rannicchiata dietro.

Questo è il più difficile dei tre gesti, perché prendere la pioggia fa freddo davvero. Le tre di notte, la faccenda ancora senza capo né coda, tutti gli occhi puntati su di te: non è una bella sensazione. Ma ciò che il tuo team guarda in quell’istante non è mai se sei nel panico o se hai la risposta pronta — guarda se, quando il fuoco è al massimo, hai fatto un passo avanti o un passo indietro. Ciò che l’ora più buia sta davvero pesando è la direzione di quel passo.

3. Dopo che il tifone è passato: le macerie ovunque sono il vero banco di prova

Il tifone passa, il cielo si rischiara, e arriva il rilassamento più pericoloso. Molti reggono al vento e alla pioggia, ma alla fine muoiono per la «pigrizia di pulire».

Il disastro sparso ovunque dopo che il vento smette è il punto in cui si vede davvero il mestiere. Pulire non significa solo raccogliere i cocci e rimettere in moto il sistema — quello è solo ripristino. La vera pulizia è trasformare il dolore di questa volta in una regola che la prossima volta non calpesterai più: la retrospettiva deve arrivare fino al meccanismo, trasformare la lezione di stavolta in un controllo che la prossima volta scatta in automatico, in un rischio nascosto eliminato, in un piano d’emergenza aggiornato.

Knight Capital morì proprio per non aver pulito. La mattina del 1° agosto 2012, questa società di trading ad alta frequenza mise in produzione una nuova porzione di codice: un ingegnere la distribuì a mano su 8 server e ne saltò 1. E proprio su quel server era rimasto un pezzo di codice di una vecchia funzionalità, dismessa da tempo ma che nessuno aveva mai cancellato, con il nome in codice «Power Peg». Il nuovo codice riutilizzava un interruttore che aveva lo stesso nome, e così su quella macchina non aggiornata questo codice morto, che sarebbe dovuto restare nella tomba, si risvegliò e cominciò a sparare ordini sul mercato all’impazzata. In 45 minuti scambiò quasi 397 milioni di azioni su 154 titoli, con una perdita al lordo delle imposte di 440 milioni di dollari. Entro la fine di quell’anno l’azienda venne acquisita, e sparì.

Guarda quanto è corta questa catena: un pezzo di codice morto che andava cancellato ma che nessuno si era preso la briga di cancellare, più un rilascio senza controlli che ha saltato una macchina, hanno tolto la vita a un’intera azienda. È il «non pulire» portato all’estremo: la spazzatura lasciata nel sistema non sparisce da sola, se ne sta solo lì buona, ad aspettare la scintilla che la accenda.

Torniamo ancora a GitLab. Stesso tipo di incidente, potenzialmente letale, ma dopo scrissero una retrospettiva pubblica al limite dell’autoflagellazione, elencando uno per uno ogni singolo livello dei cinque backup e come ciascuno avesse fallito, per poi ripararli a uno a uno. Uno ha trasformato la spazzatura in immunità, l’altro l’ha lasciata dov’era ad aspettare che esplodesse. Come stanno oggi le due aziende, lo sai anche tu.

C’è poi un aspetto della pulizia che è facilissimo fare al contrario: spazza il meccanismo, non le persone. Lo scopo della retrospettiva è fare in modo che «la prossima volta questa buca si riempia da sola», non stanare il malcapitato che ha premuto il pulsante sbagliato. Nel momento in cui cominci a prendertela con le persone, la prima cosa che tutti imparano è che la prossima volta, se qualcosa va storto, meglio nasconderlo; se invece aggiusti solo il meccanismo e non chiedi chi è stato, allora tutti hanno il coraggio di gridare il problema al primo istante. Questa retrospettiva «sui fatti, non sulle persone» non l’ha inventata Internet, è nata nell’aviazione: quando cade un aereo, l’unico scopo della commissione d’inchiesta è far sì che gli aerei dello stesso modello non cadano più dal cielo, non inchiodare quel pilota alla gogna — perché appena si comincia a inchiodare le persone, il prossimo equipaggio che sbaglia sceglierà di nascondere, e nascondere farà cadere il prossimo aereo in modo ancora più tragico. Google in seguito mise per iscritto questo approccio nel suo manuale SRE, dandogli un nome: «blameless postmortem». L’ingegnere di GitLab che aveva cancellato il database non fu giustiziato in pubblico, e non fu per tenerezza, fu per lucidità — aver sofferto una volta non è crescita; crescita è trasformare quel dolore in una regola che non si ripete più.

4. Torniamo a quel «se lo sapevo, non serviva trasferire le barche in piena notte»

Ora torniamo all’inizio, a quella frase di stamattina: «se lo sapevo, non stavamo lì a portare via le barche in piena notte».

Questa frase, in realtà, è lo specchio dell’attribuzione sbagliata dell’articolo precedente. L’altra volta la gente attribuiva la «salvezza» alla protezione di Guanyin; questa volta la attribuisce al fatto che «tanto non sarebbe successo niente». Uno assegna il merito alla dea, l’altro lo assegna alla fortuna — ed entrambi, di nascosto, ti stanno cancellando la preparazione della prossima volta.

Ma la verità è: la stragrande maggioranza dei «tanto rumore per nulla» è esattamente l’aspetto che ha la preparazione quando funziona. Se un’organizzazione, in tutti questi anni, non ha mai vissuto un «tanta fatica per niente», ci sono solo due possibilità — o si sta illudendo, scambiando ogni colpo di fortuna per «il nostro sistema è a posto»; oppure è già stata davvero ribaltata una volta, ha pagato la lezione col sangue. Knight Capital non aveva mai avuto un «tanto rumore per nulla», perché ogni volta che, prima di un rilascio, non era successo niente, lo leggeva come «il processo è impeccabile», e continuò a leggerlo così fino a quei 45 minuti.

Il tifone «Bawei» stavolta è andato a sud, e con ogni probabilità Zhoushan ne uscirà indenne. Ma ciò che fa dormire tranquilli quei pescatori stanotte non è quel briciolo d’umore che ha fatto cambiare idea al tifone all’ultimo momento, sono quelle barche portate via nella notte dagli ancoraggi.

Se la prossima ora più buia ti colpirà in pieno oppure no, non lo decidi tu. L’unica cosa che puoi decidere sono quelle tre cose che chi resiste ai tifoni non salta mai: prima che il tifone arrivi, costruire la diga così che regga davvero le onde, e non lasciarla disegnata sulla carta; nel pieno del tifone, portarsi in prima fila della squadra a prendere quella pioggia; dopo che il tifone è passato, spazzare via le macerie sparse ovunque e trasformarle in una regola che non si ripete più. Se fai per intero queste tre cose, gli altri diranno che sei stato fortunato; se ci vai a risparmiare, quei 45 minuti di Knight Capital, prima o poi, toccheranno anche a te.