Quanto costa davvero l'affidabilità su larga scala
L’affidabilità sembra un obiettivo su cui tutti concordano, finché non chiedi quanto costa. “Più affidabile” non è mai gratis, il conto è raramente dove te lo aspetti, e il prezzo di ogni miglioramento non è lineare — sale ripidamente man mano che ti avvicini alla perfezione. Fingere il contrario è il modo in cui i team finiscono per pagare troppo l’affidabilità in un punto e investirci troppo poco dove conta davvero.
Su una piattaforma ad alto traffico in un settore regolamentato, questo compromesso è un compagno costante, quindi vale la pena essere onesti al riguardo.
Il conto non è lineare
Passare da “di solito funziona” a “funziona in modo affidabile” è economico e ovviamente ne vale la pena. Passare da molto affidabile a quasi-mai-fallisce è dove la curva dei costi si piega. Ogni nove di uptime aggiuntivo — dal 99,9% al 99,99% e oltre — tende a costare in modo sproporzionato più del precedente, perché non stai più chiudendo lacune ovvie. Stai progettando contro modalità di guasto sempre più rare, ognuna delle quali richiede più macchinario per essere intercettata.
Questo non significa fermarsi. Significa sapere dove ti trovi sulla curva, perché lo stesso sforzo che presto compra un guadagno enorme, più avanti ne compra uno marginale.
I costi che non compaiono su una fattura
Il costo ovvio è l’infrastruttura — ridondanza, failover, capacità di riserva. Ma i costi cari sono quelli silenziosi:
- Complessità. Ogni meccanismo di affidabilità — retry, repliche, fallback — è altro sistema da capire, gestire e debuggare. Oltre un certo punto, il macchinario che hai aggiunto per l’affidabilità diventa esso stesso una fonte di guasti.
- Velocità. Lo sforzo speso a blindare il caso raro è sforzo non speso a rilasciare. Un team che insegue un nove in più ovunque è un team che va piano ovunque.
- Persone. Reperibilità, gestione degli incidenti e la vigilanza che l’affidabilità richiede si pagano in attenzione umana, e quello è il budget più limitato che hai.
Nessuno di questi compare nella bolletta del cloud, ed è esattamente per questo che vengono sottopesati.
Scegliere il bersaglio di proposito
La trappola è trattare “più affidabile” come universalmente buono e applicarlo in modo uniforme. Non tutte le parti di un sistema hanno la stessa conseguenza. Un percorso di pagamento o un obbligo normativo possono davvero giustificare un’affidabilità estrema. Una dashboard interna quasi certamente no — e spendere lo stesso sforzo su entrambi è solo spreco travestito da diligenza.
Il vero lavoro è quindi decidere, deliberatamente, quanto affidabile debba essere ciascuna parte, e legare quel bersaglio all’impatto reale sull’utente e sulla normativa, invece che a un numero che suona rassicurante. Cinque nove dove conta; “abbastanza buono, e ce ne accorgeremo se si rompe” dove non conta.
La disciplina del “qui basta così”
La mossa matura — e quella difficile — è dire basta così su parti del tuo stesso sistema. Gli ingegneri non la amano; sembra accontentarsi. Ma l’affidabilità è un budget, non una virtù da massimizzare ovunque. Spesa in modo uniforme, finisce prima di raggiungere i punti che davvero non possono fallire.
I team di cui mi fido di più non sono quelli che inseguono la perfezione su tutta la linea. Sono quelli che sanno esattamente quali guasti si rifiutano di permettere, investono pesantemente lì, e sono onesti sull’accettare consapevolmente il resto. Non è abbassare l’asticella. È sapere dove l’asticella va davvero messa.