Consulenza DevOps

Quando serve una consulenza DevOps

Di solito le aziende mi contattano quando si riconoscono in uno di questi segnali:

• Rilasci fragili. Ogni rilascio è un piccolo azzardo, si rilascia meno spesso di quanto servirebbe e, quando qualcosa va storto, tornare indietro è complicato.
• Infrastruttura gestita a mano. Ambienti configurati a mano, poca documentazione, la conoscenza infrastrutturale e operativa concentrata in una o due teste. Ogni modifica costa tempo e attenzione.
• Difficoltà di implementazione degli strumenti AI. Il team vorrebbe usare gli agenti AI anche sull'infrastruttura, ma senza un contesto robusto 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. Non serve un audit interminabile. Serve una fotografia onesta da cui partire.

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é vanno 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 pratiche non diventano patrimonio 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.

Cosa ottieni

• Una valutazione chiara del punto di partenza e un piano con le priorità.
• Rilasci automatizzati, ripetibili e reversibili.
• Un'infrastruttura descritta come codice, 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.

Il DevOps nell'era degli agenti AI

L'AI rende più veloce modificare codice e infrastruttura. Ma se la piattaforma è fragile, poco documentata o piena di eccezioni, accelera anche il rischio. È quindi necessario costruire una piattaforma dichiarativa, osservabile e comprensibile, in modo che persone e strumenti AI possano intervenire 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 portare l'infrastruttura a Infrastructure as Code.
• Collaborazione fractional. Un lavoro continuativo accanto al team, per quando l'infrastruttura è critica ma una figura senior a tempo pieno è ancora prematura.