Consulenza DevOps

Quando serve una consulenza DevOps

Di solito le aziende mi contattano quando si riconoscono in una di queste situazioni:

• Rilasci fragili. Ogni rilascio è un piccolo azzardo, così lo si fa meno spesso di quanto servirebbe e, quando qualcosa va storto, tornare indietro è complicato.
• Infrastruttura gestita a mano. Ambienti configurati uno a uno, poca documentazione, la conoscenza infrastrutturale e operativa concentrata in una o due teste. Ogni modifica costa tempo e attenzione.
• Agenti AI difficili da adottare. Il team vorrebbe usare gli agenti AI anche sull'infrastruttura, ma se l'infrastruttura non è descritta nel codice e documentata, l'agente non ha nulla di affidabile su cui lavorare.
• Costi cloud fuori controllo. La spesa cresce più in fretta del prodotto e nessuno sa dire con precisione dove finiscano i soldi.

Come lavoro

1. Valutazione della situazione

Parto da come stanno le cose: come si rilascia, come viene gestita l'infrastruttura, dove si annidano i rischi e quanto sono radicate nel team le pratiche DevOps. Mi serve una fotografia onesta, e per farla non occorre un audit interminabile.

2. Un piano con le priorità giuste

Da lì costruiamo un piano di intervento che separa ciò che è urgente da ciò che può aspettare e da ciò che non vale la pena fare. In una startup o in una PMI la risorsa più scarsa è il tempo del team, e il piano deve tenerne conto.

3. Prima i benefici, poi gli strumenti

Prima di parlare di tecnologia mettiamo a fuoco il risultato che si vuole ottenere: rilasci più frequenti, ripristini più rapidi, costi prevedibili, meno dipendenza dalle singole persone. Solo a quel punto si scelgono gli strumenti: la piattaforma di CI/CD (GitLab CI, GitHub Actions), l'Infrastructure as Code (Terraform, Ansible), il modello GitOps (Argo CD). Scelti perché adatti al contesto, non perché vadano di moda.

4. Implementazione e affiancamento del team

Lavoro fianco a fianco con il team: implemento in prima persona dove serve, rivedo il lavoro degli altri e faccio da tutor finché le nuove pratiche non entrano nelle abitudini di tutti. L'obiettivo è rendermi superfluo in tempi ragionevoli. Quando la collaborazione finisce, il team è in grado di mantenere e far evolvere quello che abbiamo costruito insieme.

Risultati

• Una valutazione chiara del punto di partenza e un piano con le priorità.
• Rilasci automatizzati, ripetibili e reversibili.
• Un'infrastruttura "as code", versionata e riproducibile.
• Visibilità sui costi cloud e su cosa li genera.
• Un team capace di lavorare in autonomia e una piattaforma su cui anche gli agenti AI possono operare in sicurezza.

DevOps e agenti AI

L'AI rende più veloce modificare codice e infrastruttura. Ma se la piattaforma è fragile, poco documentata o piena di eccezioni, a correre più veloci sono anche gli errori. Per questo la piattaforma deve essere dichiarativa, osservabile e comprensibile: così persone e agenti possono metterci le mani con più fiducia.

In concreto vuol dire dare agli agenti due cose:

• Un harness. È l'ambiente di lavoro dell'agente: il contesto che legge (repository, documentazione, convenzioni del progetto), gli strumenti che può usare (per esempio terraform plan, i test, la CLI del cloud provider) e il modo in cui propone le modifiche, di norma una pull request. Un buon harness dà all'agente le informazioni giuste e un modo verificabile di contribuire.
• Dei guardrail. Sono i limiti che impediscono a un agente, o a una persona, di fare danni: permessi ridotti al minimo, modifiche solo via pull request, plan e test automatici obbligatori, ambienti separati, approvazione umana per tutto quello che tocca la produzione.

Le stesse pratiche che rendono un'infrastruttura sicura per gli agenti la rendono anche più facile da gestire per le persone.

Come collaboriamo

Lavoro soprattutto da remoto, con aziende in Italia e nel resto dell'Unione Europea. Le sessioni strategiche e i workshop di formazione invece possono essere in presenza. Seguo pochi clienti alla volta, di solito due o tre.

• Sessione singola. Una conversazione mirata a una decisione precisa: un audit, una seconda opinione, una scelta architetturale, la revisione di un piano progettuale.
• Progetto. Un lavoro circoscritto, con un inizio e una fine chiari: per esempio introdurre il GitOps o trasformare un'infrastruttura configurata a mano in una infrastruttura "as code".
• Collaborazione fractional. Un lavoro continuativo accanto al team, per quando l'infrastruttura è critica ma assumere una figura senior a tempo pieno è ancora prematuro.