Costruire il team dietro una piattaforma ad alta scala
È facile parlare di una piattaforma come se fosse il diagramma dell’architettura — servizi, code, database, la forma della cosa. Ma il diagramma non si gestisce da solo. Ogni sistema affidabile è il prodotto di un team e di una serie di abitudini, e quando una piattaforma regge sotto carico reale è di solito perché le persone dietro di essa hanno costruito quelle giuste molto prima che il carico arrivasse.
Non lo compri con gli strumenti. Lo costruisci, allo stesso modo in cui costruisci il sistema — di proposito, e per lo più nelle parti poco affascinanti.
La piattaforma è a valle del team
L’architettura fissa il tetto di quanto buono un sistema possa essere. È il team a decidere quanto di quel tetto raggiungi davvero. Lo stesso progetto, nelle mani di un team con responsabilità chiare e buoni istinti, diventa qualcosa di affidabile; nelle mani di un team in cui nessuno possiede davvero nulla, marcisce lentamente a prescindere da quanto fosse pulito il diagramma originale.
Così, quando penso all’affidabilità, dedico almeno tanto tempo al team quanto alla tecnologia. Sono lo stesso problema visto da due angolazioni.
Responsabilità più che passaggi di consegne
La singola differenza più grande che ho visto è se le persone possiedono i risultati o si limitano a passare compiti. Quando un team possiede una parte del sistema dalla A alla Z — la costruisce, la gestisce, riceve le chiamate quando si rompe — la qualità segue quasi da sola, perché chi prende le decisioni è chi ne vive le conseguenze.
Quando invece il lavoro viene lanciato oltre il muro — costruito da un gruppo, gestito da un altro — gli incentivi si separano. Nessuno sente il costo pieno di una scorciatoia, così le scorciatoie si accumulano. Ho scritto altrove di quanto cara diventi la responsabilità poco chiara; su una piattaforma che deve restare in piedi, è la differenza tra un sistema che migliora e uno che si degrada in silenzio.
Assumere per il giudizio che il giorno brutto richiede
Gran parte dell’ingegneria su larga scala non è il regime stazionario — è l’eccezione, l’incidente, la decisione presa con informazioni incomplete mentre qualcosa va a fuoco. È per questo che assumo per il giudizio più che per la produttività grezza. Vuoi persone che, sotto pressione, ragionano con lucidità sui compromessi invece di bloccarsi o agitarsi a vuoto. La produttività è facile da misurare e facile da sopravvalutare; il giudizio è ciò che ti serve davvero quando il percorso felice si rompe.
Un processo che sopravvive al giorno brutto
I buoni team progettano il processo per il giorno brutto, non per quello buono. Runbook, post-mortem senza colpevoli, escalation chiare, una vera rotazione di reperibilità — niente di tutto questo conta quando è tutto calmo, e tutto conta quando non lo è. Il punto non è la burocrazia; è che un buon processo su cui puoi contare ogni giorno batte un atto occasionale di eroismo. Gli eroismi non scalano, e una piattaforma che dipende da essi è a una persona stanca di distanza da un’interruzione.
La cultura si vede nell’incidente
Scopri cos’è davvero la cultura di un team durante un incidente. Le persone cercano i fatti o qualcuno da incolpare? È sicuro dire “l’ho causato io”? La soluzione rende meno probabile il prossimo incidente, o chiude solo il ticket? Le risposte non le fissa una dichiarazione di valori appesa al muro — le fissa ciò che il team tollera, giorno dopo giorno, molto prima che arrivi la pressione.
Costruisci bene quella parte e l’architettura ha una possibilità. Trascurala, e nessun diagramma ti salverà.