I Primi 90 Giorni: Guida Passo-Passo per Ingegneri DevOps
Ehi, nuovo assunto. Ho sentito parlare di te!
Hai imparato Kubernetes in ogni dettaglio, hai automatizzato tutto ciò che era possibile automatizzare e hai gestito le pipeline. Hai studiato strategie CI/CD, strumenti IaC e le stranezze di YAML come se la tua vita ne dipendesse.
Complimenti, hai ottenuto il lavoro di DevOps Engineer!
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Ti hanno consegnato l'accesso alla console cloud, alla pipeline di build e forse—terribilmente—l'accesso root in produzione (nessuna pressione).
La maggior parte degli onboarding DevOps sono un fragile mix tra "leggi questa documentazione a caso del 2021", "chiedi in giro" e "non toccare quello script, pensiamo faccia ancora qualcosa".
Il ruolo è raramente ben definito, le aspettative sono alle stelle mentre la documentazione scarseggia. Inoltre… alcuni deployment sembrano poter risvegliare una maledizione antica.
Anche se il colloquio poteva riguardare gli strumenti, i tuoi primi 90 giorni sono dedicati a persone, processi e priorità. Qui guadagni credibilità, scopri l'indocumentato e getti le basi per un'infrastruttura su cui il tuo team può contare.
Questo playbook non risolverà l'infrastruttura del tuo team dall'oggi al domani. Ma ti aiuterà a evitare di sembrare quello che l'ha rotta.
Il Ruolo: DevOps vs. Platform vs. SRE
Partiamo dall'avvertimento di sempre: "DevOps è una cultura, non un titolo di lavoro." Certo, Jan – ma il titolo esiste ancora. E in pratica, spesso significa un ibrido di specialista in automazione, architetto di sistemi, SRE ed esperto di strumenti interni.
Dovresti essere un abilitatore, un moltiplicatore, un campione della velocità di delivery. Ma la verità è che sarai la persona a cui tutti si rivolgono quando:
- La build si rompe e nessuno sa perché.
- Qualcuno ha bisogno subito di un nuovo ambiente di staging proprio ora.
- Si avvicina un audit di compliance e i segreti sono in chiaro.
- "Dovremmo proprio automatizzare quello" diventa "Puoi automatizzare quello?"
Platform Engineering è DevOps con un branding migliore.
SRE è DevOps con un SLA.
Comunque venga chiamato, il tuo compito è far sì che tutto sia scalabile, sempre attivo e funzionante bene.
I primi 30 giorni: non toccare nulla (ancora)
Consiglio #1: Mappa l'infrastruttura, non solo l'architettura
Scopri di cosa sei responsabile: cloud provider, pipeline CI/CD, orchestrazione dei container, gestione dei segreti e flussi di lavoro per gli incidenti. Crea la tua “mappa infra” per visualizzare lo stack. Punti extra se inserisci link a dashboard live o script.
Consiglio #2: Individua il raggio d'azione
Ogni organizzazione DevOps ha un setup "per favore non toccare quello". Fai l'inventario di tutto ciò che potrebbe esplodere se gestito male. Questo include:
- Script di deploy che fanno SSH in produzione (perché... perchéèè?)
- Job Jenkins modificati per l'ultima volta nel 2019
- Runbook manuali salvati in PDF
- File Terraform che non sono mai stati effettivamente applicati
Chiedi: cosa è fondamentale ma non documentato? Chi ne è responsabile? E qual è il piano di rollback se fallisce?
Consiglio #3: Assisti a un deploy—meglio ancora, seguilo dal vivo
Imparerai di più da un singolo deploy (e dai suoi intoppi) che da ore di documentazione. Quali passaggi sono manuali? Quali non sono affidabili? Cosa è conoscenza tribale e cosa è codificato? Non sei qui per proporre idee geniali (per ora). Sei qui per raccogliere informazioni.
Dovresti essere in grado di seguire un commit dal merge alla produzione a occhi chiusi. Devi capire:
- La pipeline CI/CD (dove si interrompe, dove si creano colli di bottiglia)
- Gestione dei segreti (per favore, non negli env vars)
- Flussi di approvazione (stiamo facendo deploy senza controllo da Slack?)
Non inviare codice in produzione. Osserva solo il funzionamento e prendi appunti.
I Primi 60 Giorni: Identifica i Rischi, Riduci gli Attriti
Consiglio #4: Porta a casa una vittoria da 5 minuti
Cerca attività a basso rischio e ad alta frizione che puoi automatizzare o strutturare con uno script o un template. Questi miglioramenti dell'1% rendono la tua vita più semplice e ti fanno guadagnare la fiducia del team. Trova solo una cosa che richiede 5 minuti di troppo e rendila più veloce:
- Script shell per il setup di sviluppo locale
- Un helper CLI
- Un modulo Terraform riutilizzabile
- Script per eliminare ambienti di test bloccati
- Notifica Slack per build fallite
Le piccole vittorie costruiscono fiducia. La fiducia ti permette di fare grandi cambiamenti.
Consiglio #5: Analizza la pipeline CI/CD senza pietà
Guarda i tempi di build. Guarda la copertura dei test. Nota cosa si rompe ogni giorno. Fatti domande come:
- Possiamo parallelizzare i test?
- Poteva essere prevenuto prima in CI?
- Stiamo facendo caching delle dipendenze?
- Deployamo al merge... o facciamo tutto a casaccio sperando che funzioni?
Non sei qui per puntare il dito. Sei qui per rendere il flusso senza attriti.
Consiglio #6: Crea dashboard realmente utili e chiarisci le responsabilità
Grafana, Prometheus, Datadog—non importa quale. Ciò che conta è:
- Il tuo team vede il tasso di successo dei deploy?
- Le notifiche sono utili o solo rumore?
Qualcuno monitora i tassi di errore prima delle segnalazioni degli utenti? Chi è responsabile della pipeline di build? Dei file Helm? Delle configurazioni DNS? I confini di responsabilità sono raramente chiari. Fai una lista delle zone grigie e chiariscile con il tuo team. Questo eviterà accuse future.
Ora la visibilità è una tua responsabilità. Fallo bene.
I Primi 90 Giorni: Costruisci Fiducia Attraverso l’Affidabilità
Consiglio #7: Consegna qualcosa che aumenti la stabilità
Potrebbe essere:
- Aggiungere alerting a un sistema poco monitorato
- Migliorare la copertura dei test in pre-produzione
- Ridurre la fluttuazione nei pipeline CI
- Refactoring di uno script bash che era a un rm -rf dal disastro
Non deve essere qualcosa di enorme. Deve aiutare il tuo team a lavorare con più serenità.
Consiglio #8: Scrivi un memo di feedback sulla “DevEx”
Raccogli feedback anonimi o informali dagli sviluppatori su dove è l’infrastruttura a rallentarli. Presenta ciò che hai appreso e suggerisci degli esperimenti (es. sviluppo locale più rapido, ambienti effimeri, logging migliore).
Scrivi un documento intitolato “Ecco cosa ho imparato e cosa farò dopo”. Questa è una roadmap (e forse anche una lista di successi ;). Condividila con il tuo manager e il team.
Crea una lista “Da non dimenticare”:
- Le stranezze che hai scoperto
- L’infrastruttura ombra di cui nessuno ammette la proprietà
- Le conoscenze tribali che solo Carlo dell’IT sembra conoscere
Trasforma questa lista in documenti, automazioni o ticket — o tienila a portata di mano. Così mostri alla leadership che stai costruendo sistemi a prova di fuoco.
Consiglio #9: Scegli un singolo progetto ad alto impatto e inizia a incorniciarlo
Ormai dovresti avere abbastanza segnali per individuare un’area chiave di miglioramento. Usa l’ultima parte dei tuoi primi 90 giorni per definirne i confini, socializzarla e ottenere allineamento.
- Migra job instabili su GitHub Actions
- Sostituisci un server “unicorno” con l’infrastructure-as-code
- Costruisci un percorso “golden path” per i dev che creano nuovi servizi
Inizia in piccolo e dimostra il tuo valore. Documenta tutto.
Considerazioni finali
Si spera che, entro i primi 90 giorni, tu possa stabilizzare la situazione, distribuire qualcosa in produzione e, cosa più importante, impedire che gli sviluppatori urlino nel vuoto.
Quei primi giorni sono tutti incentrati sul costruire abbrivio per il lungo termine. Trova le crepe e documenta come un ossesso!
Non è la tua prima esperienza nel settore tech?
Questo playbook DevOps fa parte di una serie in crescita pensata per i nuovi assunti che vogliono avere un impatto prima che venga assegnata loro la “legacy ownership”.
👉 Hai appena iniziato in un ruolo di Security Engineer? Siamo pronti per te:
I primi 90 giorni: versione Cybersecurity
👉 Ti piace più scrivere codice che gestire i permessi di root? Dai un’occhiata a:
I primi 90 giorni: versione Software Engineer
E sì, presto arriveranno altre guide. Resta sintonizzato o, ancora meglio, iscriviti alla newsletter così non ti perderai la prossima.
