Consulenza DevOps
Il DevOps non è uno strumento da installare: è il modo in cui il codice arriva in produzione. Quando quel percorso è manuale, non documentato o custodito da una sola persona, ogni rilascio diventa un evento rischioso — e col tempo si rilascia sempre meno spesso, che è esattamente il contrario di quello che serve.
Mi occupo di rendere quel percorso automatico, ripetibile e verificabile: dalla pipeline che costruisce e collauda il codice fino all'infrastruttura descritta in file versionati invece che configurata a mano.
Quando serve una consulenza DevOps: i sintomi che la rendono urgente
Non si parte da «ci serve il DevOps», si parte dai sintomi. Questi sono quelli che incontro più spesso:
- Il rilascio occupa una serata. Se mandare in produzione richiede una finestra concordata e una persona sveglia, la frequenza dei rilasci scende e i cambiamenti si accumulano — rendendo ogni rilascio successivo più rischioso.
- Solo una persona sa come si fa. L'infrastruttura è nella testa di qualcuno. Funziona finché quella persona c'è.
- Gli ambienti non coincidono. «Sul mio computer funziona» non è una battuta: è la descrizione di un ambiente di sviluppo che non somiglia alla produzione.
- Un guasto si scopre dai clienti. Senza monitoraggio, il primo allarme è una telefonata.
- Tornare indietro è un problema. Se non esiste un modo rapido di ripristinare la versione precedente, ogni rilascio è una scommessa.
Se ne riconosci due o tre, il problema non è la tecnologia che usi: è che manca il percorso automatico fra il codice e la produzione.
Pipeline CI/CD: dal commit alla produzione senza intervento manuale
La pipeline è la spina dorsale: a ogni modifica del codice costruisce l'applicazione, esegue i test, produce un artefatto tracciabile e lo rilascia nell'ambiente giusto. Lavoro con GitLab CI e GitHub Actions, adattandomi a dove il codice vive già invece di imporre uno spostamento.
Quello che cambia davvero non è il tempo risparmiato sul singolo rilascio, ma il fatto che il rilascio smetta di richiedere una decisione. Quando è automatico si rilascia più spesso, e rilasciando più spesso ogni cambiamento è più piccolo — quindi più facile da capire quando qualcosa va storto.
Le fasi che metto sempre: costruzione riproducibile, test automatici come condizione di passaggio, analisi statica del codice, e la separazione fra ciò che va in ambiente di collaudo e ciò che va in produzione.
Infrastructure as Code con Terraform e Ansible: infrastrutture riproducibili
Un'infrastruttura configurata a mano è un pezzo unico: non si replica, non si verifica e non si ricostruisce dopo un guasto. Descriverla in codice cambia tre cose.
- Si versiona. Ogni modifica ha un autore, una data e un motivo, esattamente come il codice applicativo.
- Si replica. L'ambiente di collaudo si genera dalla stessa descrizione della produzione, quindi gli somiglia davvero.
- Si ricostruisce. Se una macchina si perde, si ricrea da zero con un comando invece che da una procedura scritta a memoria.
Uso Terraform per creare le risorse presso il fornitore cloud e Ansible per configurare ciò che ci gira sopra. Sono due strumenti con compiti diversi e funzionano bene insieme: il primo decide cosa esiste, il secondo come è configurato.
Container e orchestrazione: Docker e Kubernetes senza sovradimensionare
Docker conviene quasi sempre: impacchetta l'applicazione con le sue dipendenze, e da lì l'ambiente smette di essere una variabile.
Kubernetes è un'altra cosa. Risolve problemi reali — scalabilità automatica, riavvio dei servizi caduti, rilasci gradual — ma introduce una complessità che va mantenuta. Per molte applicazioni un paio di macchine con Docker Compose e un bilanciatore davanti fanno lo stesso lavoro con un decimo della superficie da presidiare.
La domanda giusta non è «usiamo Kubernetes?» ma «quale problema stiamo risolvendo, e qual è la cosa più semplice che lo risolve?». Se la risposta è Kubernetes lo diciamo; se non lo è, risparmiare quella complessità è già un risultato.
Monitoraggio e allarmi: Prometheus e Grafana su ciò che conta davvero
Il monitoraggio serve a due cose distinte: accorgersi di un guasto prima dei clienti, e capire cosa è successo dopo. Sono esigenze diverse e richiedono strumenti diversi — allarmi per la prima, cronologia per la seconda.
Con Prometheus e Grafana costruisco i pannelli su ciò che descrive il servizio dal punto di vista di chi lo usa: tempi di risposta, tasso di errore, saturazione delle risorse. Un allarme che scatta spesso e non richiede azione viene ignorato dopo due settimane: gli allarmi vanno pochi e credibili.
Deploy zero-downtime e piano di rientro
Un rilascio senza interruzione di servizio si ottiene mandando avanti la nuova versione accanto alla vecchia e spostando il traffico solo quando la nuova risponde correttamente. È un meccanismo standard, ma va predisposto: richiede che l'applicazione tolleri di avere due versioni attive contemporaneamente, cosa non sempre vera quando c'è di mezzo il database.
Insieme al rilascio predispongo sempre la strada del ritorno. Sapere in anticipo come si torna alla versione precedente, e averlo provato, è ciò che rende accettabile rilasciare spesso.
Come lavoriamo insieme
Si parte da una ricognizione: come si rilascia oggi, dove vive l'infrastruttura, cosa è documentato e cosa no. Da lì esce un elenco di interventi ordinati per rapporto fra beneficio e sforzo — quasi sempre i primi due o tre risolvono la maggior parte del disagio quotidiano.
Lavoro sia in autonomia sia affiancando il team interno. La seconda modalità costa più tempo ma lascia la competenza in casa: se il tuo obiettivo è non dipendere da un consulente esterno, è quella giusta. Molti dei miei interventi nascono in infrastrutture cloud che avevo già progettato o che vanno riordinate prima di automatizzarle.
Parliamone
Descrivimi in poche righe la situazione e cosa vorresti ottenere: rispondo con una prima valutazione e con le domande che servono a inquadrare il lavoro.
- E-mail: angelo.derrico.itconsultant@gmail.com
- WhatsApp: +39 347 857 6817
- PEC: angelo.derrico@pec.cloud