I colloqui DevOps verificano se sai portare il software in produzione in modo affidabile: come il codice passa dal laptop alla produzione, come sai che è in salute e cosa fai quando non lo è. Qui sotto trovi 20 domande con risposte, dalle basi alle domande di scenario che decidono la maggior parte dei colloqui. Dove viene mostrato un comando, si tratta di un comando standard che puoi verificare nella documentazione dello strumento stesso.
Fondamenti
1. Cos'è il DevOps?
Un modo di lavorare che unisce sviluppo e operations, così che il software venga costruito, testato, rilasciato ed eseguito attraverso lo stesso processo condiviso. Gli obiettivi sono rilasci più rapidi e sicuri e un recupero più veloce quando qualcosa si rompe. È una cultura e un insieme di pratiche, con gli strumenti a supporto, non solo un titolo professionale.
2. Qual è la differenza tra continuous integration, continuous delivery e continuous deployment?
| Pratica | Cosa significa |
|---|---|
| Continuous integration | Gli sviluppatori integrano spesso piccole modifiche, e ogni merge attiva una build e un'esecuzione di test automatizzate |
| Continuous delivery | Ogni modifica che supera la pipeline è pronta al rilascio, e una persona decide quando |
| Continuous deployment | Ogni modifica che supera la pipeline viene rilasciata in produzione automaticamente |
3. Quali sono le metriche chiave per il rilascio del software?
Quattro sono ampiamente utilizzate, dal programma di ricerca DORA: frequenza di deployment, lead time delle modifiche, tasso di fallimento delle modifiche e tempo di ripristino del servizio. Le prime due misurano la velocità, le ultime due la stabilità. Una buona risposta spiega che tieni traccia di tutte e quattro per non migliorare la velocità sacrificando la stabilità.
4. Come deve essere una buona pipeline di CI?
- Fai il checkout del codice e ripristina le dipendenze in cache.
- Esegui la build.
- Esegui prima i test veloci (unit test), poi quelli più lenti.
- Esegui i controlli statici, come il linting e una scansione delle vulnerabilità delle dipendenze.
- Crea un artefatto (un'immagine container o un pacchetto) una sola volta e taggalo con il commit.
- Pubblicalo e distribuisci lo stesso artefatto in ogni ambiente.
L'idea chiave è creare una volta sola e promuovere lo stesso artefatto, così ciò che hai testato è ciò che rilasci.
Controllo di versione e rilasci
5. Come gestisci i branch e i rilasci?
Due approcci comuni. Il trunk-based development integra spesso piccole modifiche al branch principale, con i feature flag per nascondere il lavoro non finito. I workflow basati sui branch come GitFlow usano branch di lunga durata per i rilasci. Il trunk-based development di solito si abbina meglio alla continuous delivery, perché i merge sono piccoli e frequenti.
6. Cosa sono i deployment blue-green e canary?
| Strategia | Come funziona | Rollback |
|---|---|---|
| Blue-green | Due ambienti identici. Fai il deploy su quello inattivo, lo testi, poi sposti il traffico | Riporta il traffico indietro |
| Canary | Manda una piccola quota di traffico alla nuova versione, osserva le metriche e aumenta gradualmente | Riporta la quota a zero |
| Rolling | Sostituisci le istanze poche alla volta | Procedi in avanti o inverti il roll |
Il blue-green costa capacità extra. Il canary richiede buone metriche, perché decidi in base ai dati.
7. Cos'è un feature flag e perché usarlo?
Un interruttore nella configurazione che attiva o disattiva una funzionalità senza un deployment. Separa il deploy del codice dal rilascio di una funzionalità, ti permette di testare con un piccolo gruppo e ti dà un interruttore rapido da spegnere se qualcosa va storto. Il costo è che i vecchi flag si accumulano, quindi rimuovili una volta che una funzionalità è stabile.
8. Come fai un rollback in sicurezza?
Mantieni disponibile l'artefatto precedente, rendi i deploy ripetibili e rendi le modifiche al database retrocompatibili, così la vecchia versione funziona ancora con il nuovo schema. Un piano di rollback che ignora il database non è un piano. Per le modifiche rischiose, preferisci procedere in avanti con una correzione quando un rollback comporterebbe una perdita di dati.
Infrastruttura e container
9. Cos'è l'infrastructure as code?
Definire server, reti e permessi in file versionati invece di fare clic in una console. Rende gli ambienti riproducibili, verificabili e facili da ricostruire. Gli strumenti più comuni includono Terraform, Pulumi e i template propri dei provider cloud. Vedi le nostre domande di colloquio su Terraform.
10. Qual è la differenza tra un container e una macchina virtuale?
Una macchina virtuale include un sistema operativo guest completo sopra hardware virtualizzato. Un container condivide il kernel dell'host e impacchetta solo l'applicazione e le sue dipendenze, quindi si avvia più velocemente e usa meno memoria. I container offrono meno isolamento rispetto a una macchina virtuale.
11. Cosa deve contenere un buon Dockerfile?
Usa un'immagine di base piccola e specifica, ordina i layer in modo che quelli che cambiano meno stiano per primi (per sfruttare la cache di build), copia i file delle dipendenze e installale prima di copiare il codice sorgente, esegui come utente non root e non inserire segreti nell'immagine. Le build multi-stage tengono gli strumenti di build fuori dall'immagine finale.
12. Perché Kubernetes?
Distribuisce i container tra le macchine, riavvia quelli falliti, li scala e gestisce aggiornamenti rolling e service discovery. Aggiunge anche molta complessità, quindi una buona risposta dice quando non lo useresti, ad esempio per una piccola app che sta su pochi server o su una piattaforma gestita. Vedi le nostre domande di colloquio su Kubernetes.
13. Come gestisci i segreti?
Non metterli mai nel controllo di versione o nelle immagini. Usa un secrets manager o il secret store della piattaforma, concedi a ogni servizio il minimo accesso necessario, ruota i segreti ed evita di stamparli nei log. Di' cosa faresti se uno trapelasse: revocalo, ruotalo e controlla i log per verificare se è stato usato.
Affidabilità e operazioni
14. Cosa sono monitoring, logging e tracing?
| Segnale | Cosa ti dice |
|---|---|
| Metriche | Come sta andando il sistema nel tempo, ad esempio tasso di errore e latenza |
| Log | Cosa è successo in uno specifico evento |
| Trace | Come una singola richiesta si è mossa attraverso diversi servizi |
Genera alert sui sintomi che gli utenti percepiscono, come errori e risposte lente, più che sulle cause, come un'alta CPU su una macchina.
15. Cosa sono SLI, SLO e SLA?
Un service level indicator è una misurazione, ad esempio la percentuale di richieste che vanno a buon fine. Un service level objective è l'obiettivo per quella misurazione, ad esempio il 99,9 per cento su 30 giorni. Un service level agreement è una promessa ai clienti, spesso con conseguenze se non viene rispettata. La differenza tra il 100 per cento e l'SLO è un error budget: il margine che hai per rischio e cambiamenti.
16. Un servizio in produzione è lento. Cosa fai?
- Verifica se è reale e chi è coinvolto, usando dashboard e tassi di errore.
- Controlla cosa è cambiato di recente: un deployment, una modifica di configurazione, un picco di traffico.
- Restringi il campo: un endpoint, una regione o una dipendenza specifica.
- Guarda le risorse (CPU, memoria, connessioni) e i servizi a valle.
- Se un cambiamento recente è la causa probabile, fai prima il rollback e indaga dopo.
- Comunica lo stato mentre lavori.
I selezionatori cercano un approccio calmo e ordinato e la capacità di mitigare prima di trovare la causa principale.
17. Cos'è un postmortem blameless?
Una revisione scritta dopo un incidente che si concentra su come il sistema e il processo hanno permesso il guasto, non su chi ha commesso un errore. Copre la cronologia, l'impatto, le cause e azioni di follow-up concrete con responsabili. Lo scopo è imparare e rendere più difficile ripetere lo stesso guasto.
18. Qual è la differenza tra scaling orizzontale e verticale?
Lo scaling verticale dà più risorse a una macchina. Lo scaling orizzontale aggiunge più macchine. Il verticale è semplice ma ha un tetto e un singolo punto di guasto. L'orizzontale scala di più e sopravvive alla perdita di una macchina, ma richiede servizi stateless o stato condiviso.
Pratica
19. Come proteggi una pipeline?
Limita chi può modificare la pipeline e chi può fare deploy in produzione. Scansiona dipendenze e immagini alla ricerca di vulnerabilità note, firma e verifica gli artefatti, mantieni le credenziali a breve scadenza e con ambito ristretto e revisiona le modifiche ai file della pipeline come faresti con il codice. Un build agent con permessi ampi è un bersaglio preferito.
20. Raccontami di un deployment andato male.
Questa è una domanda comportamentale dentro un colloquio tecnico. Usa una storia breve: cosa è cambiato, come te ne sei accorto, cosa hai fatto per primo (di solito mitigare, spesso con un rollback), cosa hai scoperto e cosa hai cambiato dopo perché non si ripeta. Un linguaggio blameless e un follow-up concreto sono ciò che i selezionatori cercano.
Come prepararsi
- Costruisci una piccola pipeline end to end: un repository, una build, un test run, un container e un deployment verso qualcosa che puoi raggiungere.
- Sii pronto a raccontare un incidente o un rilascio fallito della tua esperienza.
- Esercitati a dire ad alta voce la risposta al caso "il servizio è lento" finché non diventa un elenco calmo e ordinato.
- Conosci bene uno strumento per ogni area, come CI, container, infrastructure as code e monitoring, invece di un lungo elenco di nomi.
Per esercitarti su argomenti correlati, consulta le nostre guide alle domande di colloquio su AWS, domande di colloquio su Terraform, domande di colloquio su Kubernetes e domande di colloquio sul networking informatico.
Esercitati ad alta voce e con parole tue. Una trascrizione successiva ti mostra dove hai divagato o saltato il punto. Rispetta le regole del datore di lavoro sugli strumenti di AI in qualsiasi colloquio o valutazione dal vivo.
Esercita le tue risposte con YesToTheOffer
Esercitati ad alta voce, ottieni risposte costruite dal tuo curriculum e rivedi la trascrizione dopo. 30 minuti gratuiti, nessun abbonamento.
