Engineering
Software Engineer
Cinque livelli da Junior a Principal, sei competenze: dal rilascio del codice alla crescita del team.
- 5 livelli
- 6 competenze
Modello di scala di carriera
Modello di scala di carriera per DevOps engineer
Quattro livelli da Junior a Staff DevOps Engineer, su sei competenze: dall’infrastruttura al supporto agli sviluppatori.
Piano Gratuito · Nessuna carta di credito richiesta
Questa scala di carriera è pensata per DevOps, platform e infrastructure engineer in aziende di circa 20–200 persone. A queste dimensioni il team di infrastruttura conta di solito da una a sei persone, che gestiscono gli account cloud, le pipeline di rilascio, il monitoraggio e la reperibilità, e che dedicano tanto tempo ad aiutare gli sviluppatori quanto a mettere mano ai server. Descrive quattro livelli, da chi apporta modifiche ben circoscritte all’infrastruttura alla persona responsabile della direzione della piattaforma aziendale. Il livello più alto, Staff DevOps Engineer, è un livello specialistico: gestire il team di infrastruttura è un lavoro a parte.
Ogni livello è definito da ciò che una persona fa e da quanta parte del sistema le viene affidata, non dagli anni di esperienza o dal numero di strumenti nel CV. Leggi una riga della matrice delle competenze da sinistra a destra per vedere come cresce un’aspettativa; leggi la sezione di un livello per vedere tutto ciò che ci si aspetta a quel livello. Usala per spiegare cosa significa il livello successivo, per strutturare i check-in e per prendere decisioni di promozione che sai motivare.
Adattala prima di pubblicarla. Sostituisci le formulazioni generiche con il tuo stack e le tue pratiche ed elimina le parti che spettano a un altro team — ad esempio se la sicurezza o i database sono gestiti altrove.
I livelli in sintesi
Junior DevOps Engineer
Apporta modifiche ben circoscritte a infrastruttura e pipeline con una review e impara come funziona la produzione.
- Ambito
- Singole modifiche al codice di infrastruttura e alle pipeline esistenti, pianificate e revisionate da qualcuno con più esperienza.
DevOps Engineer
È responsabile di parti dell’infrastruttura dall’inizio alla fine e copre la sua piena quota di reperibilità.
- Ambito
- Servizi, ambienti o pipeline per uno o due team di prodotto, dalla progettazione alla gestione quotidiana.
Senior DevOps Engineer
Progetta e guida progetti di infrastruttura da cui dipendono più team e alza il livello di affidabilità.
- Ambito
- L’infrastruttura condivisa usata dalla maggior parte dell’engineering e progetti, come le migrazioni, che toccano ogni team.
Staff DevOps Engineer
Definisce la direzione della piattaforma aziendale e risponde della sua affidabilità, sicurezza e dei suoi costi.
- Ambito
- L’intera piattaforma di produzione, la sua direzione pluriennale e il suo budget, per tutti i team di engineering.
Matrice delle competenze
Ogni riga è una competenza e ogni colonna un livello. Leggi una riga da sinistra a destra per vedere come crescono le aspettative.
Cosa significa ogni competenza
- Infrastructure as code
- Costruire e modificare l’infrastruttura con codice revisionato e ripetibile, non a mano.
- Pipeline di build e di rilascio
- Portare il codice da una pull request unita alla produzione in modo rapido e sicuro.
- Affidabilità e risposta agli incidenti
- Mantenere la produzione disponibile e ripristinarla rapidamente quando non lo è.
- Monitoraggio e osservabilità
- Rendere possibile vedere cosa sta facendo la produzione e sapere quando qualcosa va storto.
- Sicurezza e accessi
- Proteggere sistemi e dati con impostazioni sicure di default, privilegi minimi e patch tempestive.
- Supporto agli sviluppatori e collaborazione
- Aiutare gli sviluppatori a gestire i propri servizi e condividere la conoscenza perché la piattaforma non dipenda da una sola persona.
| Competenza | Junior DevOps Engineer | DevOps Engineer | Senior DevOps Engineer | Staff DevOps Engineer |
|---|---|---|---|---|
| Infrastructure as code | Modifica il codice di infrastruttura esistente seguendo i pattern già in uso, controlla il diff pianificato prima di applicarlo e non modifica mai la produzione a mano senza prima chiedere. | Scrive moduli di infrastruttura riutilizzabili per nuovi servizi e ambienti, gestisce in modo sicuro state e secret e rimuove le risorse non più utilizzate. | Progetta l’organizzazione del codice di infrastruttura e degli ambienti dell’azienda, guida modifiche come aggiornamenti di rete o di cluster con un piano di rollback testato e rende visibile la spesa cloud per ogni team. | Sceglie i componenti fondamentali e i fornitori della piattaforma per i prossimi anni, definisce gli standard che l’infrastruttura di ogni team deve seguire ed è responsabile del budget di infrastruttura insieme al management. |
| Pipeline di build e di rilascio | Corregge gli step delle pipeline che si rompono, aggiunge job semplici alle pipeline esistenti e spiega a uno sviluppatore perché la sua build è fallita. | Costruisce e mantiene l’intera pipeline di un servizio — build, test, artefatti, deploy in ogni ambiente — e accorcia gli step lenti di cui si lamentano gli sviluppatori. | Progetta template di pipeline condivisi usati da tutti i team, introduce metodi di rilascio più sicuri come i deploy canary o blue-green e monitora frequenza dei deploy e tasso di fallimento. | Definisce come l’intera azienda rilascia il software, dal branching al rollback, ed elimina i colli di bottiglia che rallentano la consegna in tutti i team. |
| Affidabilità e risposta agli incidenti | Affianca chi è reperibile, segue i runbook per gli alert noti e fa escalation rapidamente con le informazioni che servono alla persona successiva. | Copre la sua piena quota di reperibilità, risolve senza aiuto la maggior parte degli incidenti nella propria area, scrive runbook per ciò che ha risolto e testa i backup ripristinandoli davvero. | Guida la risposta agli incidenti gravi, conduce post-mortem senza colpevolizzare nessuno e segue le azioni conseguenti fino in fondo, e pianifica capacità e failover per i sistemi critici. | Fissa gli obiettivi di affidabilità con prodotto e management, progetta il processo di reperibilità e di gestione degli incidenti per tutto l’engineering e pianifica i disastri, come la perdita di una region o di un fornitore. |
| Monitoraggio e osservabilità | Aggiunge dashboard e alert seguendo gli esempi esistenti e controlla per prima cosa log e metriche quando qualcosa sembra non andare. | Configura log, metriche e alert per i nuovi servizi, calibra gli alert in modo che ogni chiamata richieda un intervento e aiuta gli sviluppatori a trovare nei dati ciò che cercano. | Progetta l’approccio all’osservabilità per i sistemi principali dell’azienda, definisce i segnali di salute dei servizi su cui vengono misurati i team e riduce il rumore degli alert in tutti i team. | Sceglie gli strumenti di osservabilità dell’azienda e il loro modello di costo, e si assicura che il management possa vedere la salute della piattaforma senza doverlo chiedere a un engineer. |
| Sicurezza e accessi | Segue le regole del team per secret e accessi, applica le patch di routine e segnala subito tutto ciò che sembra un problema di sicurezza. | Gestisce accessi e secret dei propri servizi secondo il principio del privilegio minimo, corregge le vulnerabilità in base alla loro gravità e risolve i problemi emersi dalle scansioni di sicurezza. | Progetta i confini di rete, la gestione delle identità e dei secret su tutta la piattaforma, prepara la documentazione per le verifiche di sicurezza dei clienti e guida la risposta agli incidenti di sicurezza. | È responsabile, insieme al management, del livello di sicurezza della piattaforma, definisce i controlli richiesti dalla conformità (ad esempio SOC 2 o ISO 27001) e fa sì che la strada sicura sia la più semplice per ogni team. |
| Supporto agli sviluppatori e collaborazione | Risponde alle domande degli sviluppatori su ambienti e pipeline, documenta le correzioni che fa e chiede presto una review. | Scrive guide chiare per le attività comuni, lavora in coppia con gli sviluppatori sul deploy e sul debug dei loro servizi e accompagna i nuovi colleghi nell’onboarding sull’infrastruttura. | Costruisce strumenti self-service che permettono ai team di creare servizi e ambienti senza aprire un ticket, fa mentoring ad altri DevOps engineer e partecipa alle selezioni. | Imposta la piattaforma come un prodotto interno che ha gli sviluppatori come utenti, decide di cosa sono responsabili i team e di cosa il team di piattaforma, e fa crescere i futuri senior engineer. |
Scorri la tabella lateralmente per vedere tutti i livelli.
Scarica in CSV Si apre in Excel, Google Sheets o Numbers.
Junior DevOps Engineer: cosa ci si aspetta
Apporta modifiche ben circoscritte a infrastruttura e pipeline con una review e impara come funziona la produzione. Singole modifiche al codice di infrastruttura e alle pipeline esistenti, pianificate e revisionate da qualcuno con più esperienza.
- Infrastructure as code
- Modifica il codice di infrastruttura esistente seguendo i pattern già in uso, controlla il diff pianificato prima di applicarlo e non modifica mai la produzione a mano senza prima chiedere.
- Pipeline di build e di rilascio
- Corregge gli step delle pipeline che si rompono, aggiunge job semplici alle pipeline esistenti e spiega a uno sviluppatore perché la sua build è fallita.
- Affidabilità e risposta agli incidenti
- Affianca chi è reperibile, segue i runbook per gli alert noti e fa escalation rapidamente con le informazioni che servono alla persona successiva.
- Monitoraggio e osservabilità
- Aggiunge dashboard e alert seguendo gli esempi esistenti e controlla per prima cosa log e metriche quando qualcosa sembra non andare.
- Sicurezza e accessi
- Segue le regole del team per secret e accessi, applica le patch di routine e segnala subito tutto ciò che sembra un problema di sicurezza.
- Supporto agli sviluppatori e collaborazione
- Risponde alle domande degli sviluppatori su ambienti e pipeline, documenta le correzioni che fa e chiede presto una review.
DevOps Engineer: cosa ci si aspetta
È responsabile di parti dell’infrastruttura dall’inizio alla fine e copre la sua piena quota di reperibilità. Servizi, ambienti o pipeline per uno o due team di prodotto, dalla progettazione alla gestione quotidiana.
- Infrastructure as code
- Scrive moduli di infrastruttura riutilizzabili per nuovi servizi e ambienti, gestisce in modo sicuro state e secret e rimuove le risorse non più utilizzate.
- Pipeline di build e di rilascio
- Costruisce e mantiene l’intera pipeline di un servizio — build, test, artefatti, deploy in ogni ambiente — e accorcia gli step lenti di cui si lamentano gli sviluppatori.
- Affidabilità e risposta agli incidenti
- Copre la sua piena quota di reperibilità, risolve senza aiuto la maggior parte degli incidenti nella propria area, scrive runbook per ciò che ha risolto e testa i backup ripristinandoli davvero.
- Monitoraggio e osservabilità
- Configura log, metriche e alert per i nuovi servizi, calibra gli alert in modo che ogni chiamata richieda un intervento e aiuta gli sviluppatori a trovare nei dati ciò che cercano.
- Sicurezza e accessi
- Gestisce accessi e secret dei propri servizi secondo il principio del privilegio minimo, corregge le vulnerabilità in base alla loro gravità e risolve i problemi emersi dalle scansioni di sicurezza.
- Supporto agli sviluppatori e collaborazione
- Scrive guide chiare per le attività comuni, lavora in coppia con gli sviluppatori sul deploy e sul debug dei loro servizi e accompagna i nuovi colleghi nell’onboarding sull’infrastruttura.
Senior DevOps Engineer: cosa ci si aspetta
Progetta e guida progetti di infrastruttura da cui dipendono più team e alza il livello di affidabilità. L’infrastruttura condivisa usata dalla maggior parte dell’engineering e progetti, come le migrazioni, che toccano ogni team.
- Infrastructure as code
- Progetta l’organizzazione del codice di infrastruttura e degli ambienti dell’azienda, guida modifiche come aggiornamenti di rete o di cluster con un piano di rollback testato e rende visibile la spesa cloud per ogni team.
- Pipeline di build e di rilascio
- Progetta template di pipeline condivisi usati da tutti i team, introduce metodi di rilascio più sicuri come i deploy canary o blue-green e monitora frequenza dei deploy e tasso di fallimento.
- Affidabilità e risposta agli incidenti
- Guida la risposta agli incidenti gravi, conduce post-mortem senza colpevolizzare nessuno e segue le azioni conseguenti fino in fondo, e pianifica capacità e failover per i sistemi critici.
- Monitoraggio e osservabilità
- Progetta l’approccio all’osservabilità per i sistemi principali dell’azienda, definisce i segnali di salute dei servizi su cui vengono misurati i team e riduce il rumore degli alert in tutti i team.
- Sicurezza e accessi
- Progetta i confini di rete, la gestione delle identità e dei secret su tutta la piattaforma, prepara la documentazione per le verifiche di sicurezza dei clienti e guida la risposta agli incidenti di sicurezza.
- Supporto agli sviluppatori e collaborazione
- Costruisce strumenti self-service che permettono ai team di creare servizi e ambienti senza aprire un ticket, fa mentoring ad altri DevOps engineer e partecipa alle selezioni.
Staff DevOps Engineer: cosa ci si aspetta
Definisce la direzione della piattaforma aziendale e risponde della sua affidabilità, sicurezza e dei suoi costi. L’intera piattaforma di produzione, la sua direzione pluriennale e il suo budget, per tutti i team di engineering.
- Infrastructure as code
- Sceglie i componenti fondamentali e i fornitori della piattaforma per i prossimi anni, definisce gli standard che l’infrastruttura di ogni team deve seguire ed è responsabile del budget di infrastruttura insieme al management.
- Pipeline di build e di rilascio
- Definisce come l’intera azienda rilascia il software, dal branching al rollback, ed elimina i colli di bottiglia che rallentano la consegna in tutti i team.
- Affidabilità e risposta agli incidenti
- Fissa gli obiettivi di affidabilità con prodotto e management, progetta il processo di reperibilità e di gestione degli incidenti per tutto l’engineering e pianifica i disastri, come la perdita di una region o di un fornitore.
- Monitoraggio e osservabilità
- Sceglie gli strumenti di osservabilità dell’azienda e il loro modello di costo, e si assicura che il management possa vedere la salute della piattaforma senza doverlo chiedere a un engineer.
- Sicurezza e accessi
- È responsabile, insieme al management, del livello di sicurezza della piattaforma, definisce i controlli richiesti dalla conformità (ad esempio SOC 2 o ISO 27001) e fa sì che la strada sicura sia la più semplice per ogni team.
- Supporto agli sviluppatori e collaborazione
- Imposta la piattaforma come un prodotto interno che ha gli sviluppatori come utenti, decide di cosa sono responsabili i team e di cosa il team di piattaforma, e fa crescere i futuri senior engineer.
Come adattare questa scala
Nomina il tuo stack nelle aspettative
Frasi generiche come «codice di infrastruttura» o «pipeline» sono facili da condividere e difficili da valutare. Sostituiscile con gli strumenti e le pratiche che usi davvero, così che un engineer junior sappia esattamente cosa deve imparare per primo.
Aspetta prima di introdurre il livello Staff
Con uno–tre DevOps engineer, i livelli junior, intermedio e senior di solito bastano. Aggiungi Staff quando qualcuno definisce davvero la direzione della piattaforma ed è responsabile del suo budget per tutto l’engineering, non come titolo per la persona più esperta di un team piccolo.
Scrivi le regole di reperibilità nella scala
Indica a quale livello le persone entrano nei turni, quando guidano gli incidenti e come viene compensato il tempo di reperibilità. Le aspettative non scritte sulla reperibilità sono uno dei motivi più comuni per cui gli infrastructure engineer vanno in burnout e se ne vanno.
Allinea i livelli alla scala di carriera per software engineer
Fai corrispondere ogni livello DevOps al livello software engineer con lo stesso perimetro e la stessa retribuzione. Il lavoro di piattaforma è lavoro di engineering, e mantenere allineate le due scale rende semplici i passaggi tra team di prodotto e team di piattaforma.
FAQ
Domande su questa scala
Qual è la differenza tra un DevOps engineer, un SRE e un platform engineer?
A rigore, DevOps è un modo di lavorare più che un titolo; in pratica, nelle aziende di 20–200 persone i titoli descrivono per lo più lo stesso lavoro con un’enfasi diversa: gli SRE si concentrano sugli obiettivi di affidabilità — di solito SLO ed error budget — e sugli incidenti, i platform engineer sugli strumenti self-service per gli sviluppatori e i DevOps engineer su pipeline e infrastruttura. Di solito una sola scala di carriera copre tutti e tre: adatta la formulazione delle competenze invece di creare scale separate.
Quando una startup ha bisogno del suo primo DevOps engineer?
Di solito quando gli sviluppatori passano una parte significativa della settimana su deploy, ambienti e problemi di produzione invece che sulle funzionalità, oppure quando i clienti iniziano a chiedere impegni di uptime e verifiche di sicurezza. In molte aziende succede intorno ai 15–30 engineer.
La reperibilità dovrebbe contare per la promozione di un DevOps engineer?
Sì, ma conta ciò che le persone imparano e migliorano, non quante chiamate hanno gestito. Guidare bene un incidente grave, scrivere post-mortem le cui azioni vengono portate a termine e ridurre il rumore degli alert sono prove chiare per il livello successivo. Essere spesso reperibili non lo è.
Le certificazioni cloud contano per il livello di un DevOps engineer?
Possono aiutare qualcuno a imparare una piattaforma, ma non dovrebbero decidere un livello. Valuta ciò che la persona ha costruito e gestito nel tuo ambiente rispetto alla matrice delle competenze. Una certificazione senza queste prove non dimostra il livello successivo; queste prove senza una certificazione sì.
Quanti livelli servono in una scala di carriera per DevOps engineer?
Tre o quattro, perché i team di infrastruttura nelle aziende di queste dimensioni sono piccoli. Questo modello ne usa quattro — Junior, DevOps Engineer, Senior e Staff — e funziona bene accanto a una scala di carriera per software engineer a cinque livelli, con i livelli Staff allineati.
Costruisci questa scala di carriera in LadderKit — gratis
Configura i suoi livelli e le sue competenze per il tuo team, valuta le persone su questa base nei check-in e mantieni coerenti le decisioni di promozione.
Piano Gratuito · Nessuna carta di credito richiesta
Modelli correlati
Engineering
QA Engineer
Quattro livelli da Junior QA a Lead QA Engineer, su sei competenze: dalla progettazione dei test alle pratiche di qualità.
- 4 livelli
- 6 competenze
Engineering
Engineering Manager
Quattro livelli da Engineering Manager a VP of Engineering, su sei competenze manageriali.
- 4 livelli
- 6 competenze