Operazioni automation-first — come un team ridotto regge un perimetro ampio

La constatazione. Oggi un piccolo team tecnico fa funzionare un'infrastruttura che, quindici anni fa, avrebbe richiesto un intero reparto. Non è una questione di organico : è una questione di metodo. L'ingegneria dell'ultimo decennio ha prodotto un corpus di pratiche — orchestrazione, osservabilità, controllo umano nel ciclo — che permette a una manciata di ingegneri di sorvegliare un perimetro ampio senza esserne travolti. La ricerca DORA lo documenta anno dopo anno : né gli strumenti né la dimensione del team predicono la performance, ma capacità precise e misurabili. A questa disciplina diamo qui il nome di automation-first.

Dall'automatizzare attività alle operazioni automatizzate

Automatizzare un'attività lo sanno fare tutti. Costruire uno strato di operazioni automatizzate è un altro mestiere. Google lo ha formalizzato in Site Reliability Engineering (2016) : il lavoro manuale ripetitivo — il toil — non è solo costoso, è tossico, perché cresce linearmente con il servizio mentre l'organico no. La risposta è lasciare che il sistema si governi da sé dove è sicuro e chiami un umano solo dove è necessario. Lo strato poggia su tre pilastri che funzionano solo insieme : orchestrazione, osservabilità e controllo umano nel ciclo.

Orchestrazione e osservabilità

L'orchestrazione moderna, resa popolare da strumenti come Kubernetes, poggia su un modello dichiarativo : si descrive lo stato desiderato e un controller riconcilia la realtà con quell'intenzione ; il sistema diventa idempotente e verificabile. L'osservabilità — poter porre domande nuove al sistema senza ridistribuirlo, normalizzata da OpenTelemetry attorno a tracce, metriche e log — si distingue dal semplice monitoring. Da qui nascono gli SLO e l'error budget dell'SRE.

L'umano nel ciclo

L'automazione matura non mira a rimuovere l'umano, ma a collocarlo dove il suo giudizio conta. Le azioni reversibili e frequenti possono eseguirsi da sole ; quelle irreversibili o ambigue esigono una validazione esplicita. L'ironia dell'automazione di Lisanne Bainbridge (1983) resta attuale : più un sistema è automatizzato, più il ruolo residuo dell'umano diventa critico e difficile.

La disciplina del « fatto invece che descritto »

Un'organizzazione lean si definisce meno per ciò che pianifica che per ciò che porta a termine. Il pensiero lean, dal Toyota Production System, tratta il lavoro iniziato ma non finito come scorta : capitale immobilizzato, non progresso. Preferire un piccolo incremento consegnato, verificato e osservabile a una grande intenzione mai messa in produzione è l'equivalente operativo della scoperta DORA su lotti piccoli e frequenza di rilascio.

Dove ci collochiamo

Montandor Andorra è una maison giovane con un team tecnico volutamente ridotto. Sin dall'inizio abbiamo scelto uno strato di operazioni automatizzato anziché la crescita dell'organico : orchestrazione dichiarativa, osservabilità end-to-end e — regola non negoziabile — un umano responsabile su ogni azione irreversibile. Non è una singolarità : è l'applicazione metodica di un corpus di ingegneria pubblico alla scala di una PMI.

“Un piccolo team non regge un perimetro ampio lavorando di più ; lo regge progettando meglio.”
— Wouter Meijboom, CEO, Montandor Andorra.

Fonti

• Beyer, Jones, Petoff & Murphy — Site Reliability Engineering, Google / O'Reilly, 2016.
• DORA — rapporti Accelerate State of DevOps, 2014-2023.
• Womack & Jones — Lean Thinking, 1996; Toyota Production System.
• Lisanne Bainbridge — Ironies of Automation, Automatica, 1983.
• Cloud Native Computing Foundation — Kubernetes; OpenTelemetry.
• Charity Majors et al. — letteratura sull'osservabilità.

Ricerca diretta da Margaux Lefèvre (CTO), in collaborazione con Marek Nowak (SRE & DevOps Lead), Ilona Pavlenko (Delivery / Scrum) e Kateryna Koval (Product Manager IT).