Il giudizio

Immagina Bruno, un esperto DevOps, durante un incidente. Uno dei pod di un servizio, su uno dei nodi del cluster, ha smesso di comportarsi come gli altri: la readiness probe fallisce a intermittenza, il pod entra ed esce dagli endpoint del Service e le richieste che gli erano state instradate tornano indietro con errori.¹ La prima tentazione ha già la sua battuta: «Ha provato a spegnere e riaccendere?». Roy la ripete in The IT Crowd²; il guaio è che spesso funziona. Applicata all’incidente di Bruno, quella battuta vuol dire cancellare quel pod e lasciare che il Deployment ne pianifichi uno nuovo. È un rimedio familiare e potrebbe funzionare davvero.

Questa volta, però, Bruno si ferma e si pone la domanda essenziale: che cosa è cambiato?

Non è prudenza. Con il pod se ne andrebbero il filesystem del container e tutto ciò che vive nella memoria del processo: nessun dump da prendere, nessun file temporaneo da guardare, e dei log resterebbero soltanto quelli dell’istanza appena terminata. Se la causa fosse sul nodo o a monte, il pod nuovo potrebbe ricadere poco dopo nello stesso stato, con meno informazioni per individuarla. Prima di agire, Bruno confronta il costo del disservizio con quello della diagnosi³ e apre alcune ipotesi.

Il sintomo può dipendere dalla rete o dal nodo, dalla pressione sulla memoria, dall’I/O o da una modifica recente nel comportamento dell’applicazione. Non esiste un ordine buono per ogni incidente. Qui contano i segnali di questo sistema:

• gli eventi del pod e del nodo, che invecchiano in fretta;
• l’andamento di memoria e CPU, in cui un processo terminato per esaurimento della memoria e uno rallentato dal proprio limite di CPU lasciano tracce diverse;
• la distribuzione della latenza;
• gli ultimi rilasci;
• ciò che l’osservabilità conserva anche dopo un riavvio e ciò che invece andrebbe perso.

La sequenza di controlli non è ancora giudizio: anche una buona diagnosi può ridursi a una checklist⁴. Il giudizio compare quando Bruno sceglie quali ipotesi meritano attenzione, valuta il costo di perdere evidenze e decide quale compromesso accettare tra ripristino immediato e comprensione della causa.

La domanda che introduce attrito è sempre quella, ora rivolta ai precedenti e non solo al sistema: che cosa ha di diverso questo caso rispetto a quelli che ricordo?

Un agente può proporre ipotesi, cercare segnali e formulare la stessa domanda. Se riceve soltanto il sintomo, però, dispone soprattutto di pattern generali. Per pesare le alternative gli servono la storia dei deploy, i vincoli operativi, le conseguenze tollerabili e le ragioni delle scelte precedenti. Il Senior non possiede necessariamente tutte queste informazioni; risponde però di quali vadano cercate e di come incidano sulla direzione.

Il discrimine, allora, non passa fra chi conosce più comandi e chi ne conosce meno, né, come si crede, fra l’umano che pensa e la macchina che si limita a eseguire: passa fra l’applicare un pattern e il riconoscere che, nel caso presente, quel pattern potrebbe non bastare.

L’esperienza accumula esposizione: sistemi visti rompersi, rimedi tentati, conseguenze osservate. Da qui nascono pattern, riflessi e scorciatoie che permettono di arrivare in fretta a una risposta plausibile.

Quella velocità ha valore: durante un incidente non si può rimettere in discussione ogni comando come se fosse il primo. Ma la risposta che arriva subito è un riflesso: la produce la somiglianza con i casi già visti, non l’esame del caso corrente. Aiuta quando la somiglianza è reale, inganna quando è solo apparente. Così anche chi ha visto molti incidenti può applicare con sicurezza il precedente sbagliato.

La durata, quindi, non basta. Accumulare anni significa accumulare esposizione, non necessariamente giudizio: si possono attraversare molti incidenti applicando sempre gli stessi riflessi, senza chiedersi se reggano ancora. Il giudizio cresce soltanto se i precedenti vengono confrontati con ciò che accade adesso.

Nel libro, giudizio ingegneristico indica la capacità situata di scegliere in condizioni incomplete, riconoscere i vincoli strutturali, valutare i compromessi e assumere la responsabilità delle conseguenze.

L’esperienza offre pattern. Il giudizio decide se valgono qui: riconosce ciò che non torna, pesa il compromesso e ne assume la responsabilità.

Nel caso di Bruno, non conta ricordare il maggior numero di incidenti. Conta capire se il costo di fermarsi a raccogliere evidenze sia giustificato dal rischio di applicare il rimedio consueto alla causa sbagliata.

Qui si distinguono anche i tre livelli introdotti nei Fondamenti:

• il principio da preservare è la capacità di scegliere alla luce dei vincoli e delle conseguenze del caso;
• il metodo introduce attrito: confronta il precedente con i segnali presenti, cerca ciò che è cambiato e mette alla prova l’ipotesi più comoda;
• i controlli su Kubernetes sono un’implementazione contingente di quel metodo, e possono cambiare senza rendere falsa la distinzione fra esperienza e giudizio.

Il giudizio comprende anche la misura. Chiedere sempre «che cosa è cambiato?» può diventare a sua volta un automatismo, che ritarda una risposta urgente senza che l’attesa riveli nulla. Occorre decidere quando la domanda merita tempo e quando il margine è già sufficiente per agire.

La misura non risponde a una regola astratta: dipende dal sistema in cui si decide. Il giudizio, infatti, vive dentro un sistema, con la sua storia, i suoi vincoli e le promesse che non si possono rompere⁵.

Poiché dipende dal momento e dalle conseguenze della scelta, il giudizio non si trasferisce in blocco. Sposta lo stesso ingegnere su un altro sistema, con vincoli diversi: una parte dei suoi precedenti resta utile, ma il giudizio deve riformarsi sul nuovo terreno. Questo limite non vuol dire che nulla si possa affidare. Si delegano l’esecuzione, l’analisi delle alternative e decisioni operative circoscritte: quali artefatti esplorare, quale ipotesi controllare per prima, come intervenire entro un contratto già deciso.

Restano al Senior le decisioni direzionali designate e la responsabilità finale. Il confine non cade su ogni scelta tecnica: passa dove cambiano il principio da proteggere, il compromesso accettabile o l’ampiezza delle conseguenze.

L’agente può riconoscere e confrontare molti pattern presenti nel modello linguistico, nella documentazione e nel contesto che gli viene fornito. Può contestare l’ipotesi del Senior, trovare un precedente dimenticato, segnalare una modifica recente o mostrare che il caso non segue la regola abituale.

Così l’agente partecipa alla deliberazione: il giudizio del Senior non nasce dall’isolamento, ma migliora nel confronto. L’apporto dell’agente non è risolvere l’incidente al posto del Senior, ma aiutarlo a valutare se i pattern che il Senior ricorda valgano in questo caso: è un catalizzatore⁶ della deliberazione, non un sostituto del giudizio.

L’ampiezza dei pattern disponibili non consegna però automaticamente la storia corrente del sistema, i compromessi già accettati o le conseguenze che il progetto può tollerare. Questi elementi vanno resi accessibili e pesati. Anche quando l’agente contribuisce a far emergere la scelta migliore, non assorbe per questo la direzione e la responsabilità finale.

Accanto a Bruno, l’agente può riconoscere che l’incidente mette in discussione il riflesso «non risponde, quindi cancellalo e aspetta quello nuovo». Decidere se sacrificare alcune evidenze per ripristinare subito il servizio può diventare una scelta direzionale quando coinvolge vincoli strutturali, impatti rilevanti e responsabilità designate al Senior.

La responsabilità finale resta al Senior, ma non per questo il Senior esercita il giudizio da solo: un collega o un agente può costringerlo a rendere esplicito il compromesso che il rimedio consueto lasciava implicito.

Uno scambio del genere può migliorare la decisione. Può anche esaurirsi nell’incidente che lo ha reso necessario: se resta soltanto nella conversazione, di quel percorso non rimane una forma riutilizzabile.

Il confronto ha prodotto giudizio. Non ha ancora prodotto un metodo.