IT knowledge base
CTRL+F per cercare la tua parola chiave

The Ultimate DevOps Engineer Interview Guide - Cosa chiedere e cosa prepararsi


Ho iniziato a fare networking a scuola e lavoro per soldi da oltre 16 anni. Ho trovato lavoro in molti posti, in aziende grandi e piccole, poi ho aperto una mia attività e assumo regolarmente personale io stesso. Nel corso degli anni e dell'esperienza, io e molti altri sviluppiamo l'intuizione del colloquio.
Questo è quando non c'è un algoritmo chiaro. Parli semplicemente con una persona e capisci qualcosa per te stesso. Chiedi cosa ha fatto il candidato nel lavoro precedente, ti aggrappi all'argomento - e ora stai solo discutendo di argomenti di ingegneria, più o meno allo stesso livello dei colleghi. Se la conversazione va bene e alla persona piace, allora va tutto bene.
Tale intuizione difficilmente può essere appresa da libri e testi, arriva da sola con l'esperienza. Insieme a lei, frasi come "Non mi interessa la conoscenza specifica tanto quanto una visione generale, la capacità di cercare informazioni, capire se lavoreremo insieme" e così via si insinuano nel pensiero.
Ma a volte, per non perdere la presa, devi comunque ricordare a te stesso quale conoscenza dovrebbe avere un ingegnere e quali domande puoi valutare in modo più oggettivo la persona che vedi per la prima volta nella tua vita.

Per prima cosa, esamino rapidamente tutti i curriculum

Mentre leggo le risposte, presto attenzione alle parole chiave e ai luoghi di lavoro. Leggo sempre la lettera di presentazione: molti candidati vengono eliminati in questa fase. Sto pubblicando un annuncio di lavoro per trovare un ingegnere DevOps e ricevo una risposta da uno sviluppatore Python, uno sviluppatore golang o un corriere attuale che è "molto interessato e vorrebbe provare".
Passano i curriculum, che indicano l'esperienza di lavoro nelle agenzie governative, qualcosa nello spirito di "l'amministratore di prima categoria nella Banca centrale della Federazione Russa". Tutte queste storie prolisse sulla "amministrazione dei sistemi informativi" le interrompo subito senza esitazione. Più è burocratica e burocratica la descrizione del lavoro passato, maggiore è la possibilità che un tale candidato non abbia visto nulla nella sua vita tranne Windows e backup utilizzando un'interfaccia grafica.
La regola empirica nella selezione rapida di un curriculum è che più tecnologia incontro, meglio è. Se il curriculum di una persona dice MySQL, Linux, Postgres, Apache e così via, ci sono possibilità. La persona ha almeno sentito parlare di tecnologia e, chissà, forse ha anche lavorato con loro. Ma siamo onesti: puoi scrivere qualsiasi cosa sul tuo curriculum.

Al colloquio, la prima cosa che faccio è controllare il database.

Quando diventerò un vecchio fragile e verrò ribattuto ostinatamente, comincerò a battere con un bastone sulla schiena di tutti coloro che non conoscono la rete! Questo è un must per ogni ingegnere. Viviamo in un mondo in cui tutto accade nelle reti. Anche in un settore pubblico chiuso, c'è un contorno locale. E c'è uno sviluppatore che scrive un servizio proxy o compone un servizio che funziona con un'API e non capisce nulla dell'API.
Non ho bisogno di conoscenze particolari, non ti chiedo di configurare MPLS per me. Ma cos'è una subnet mask, cos'è un indirizzo IP: nel 21° secolo, tutti gli specialisti IT dovrebbero saperlo. Non ho idea di cosa stia succedendo nella testa di una persona quando non capisce cosa sia 127.0.0.1. Si siede su una macchina locale, ha un servizio in esecuzione su una macchina virtuale. Il servizio ha un endpoint 127.0.0.1, una connessione al database. Per ignoranza, il nostro eroe guida la stessa cosa. Di conseguenza: "Non riesco a connettermi alla base". Certo, dannazione, non si connette!
Se una persona ha un certificato CCNA, va bene, anche se non l'ha superato, non l'ha ricevuto fisicamente, ma preparato - questo fatto mi basta.

Ad esempio, ecco un puzzle standard CCNA per capire come funzionano le reti.


Ci sono due switch di reti diverse, c'è un router tra di loro. Il computer A vuole inviare dati al computer B.

Cosa succede in questo momento?
È importante per me sentire qualcosa del tipo: "Sì, esaminiamo la tabella di routing, vediamo che puoi accedere a questa rete tramite un router. Il computer invia una richiesta alla rete, cerca di trovare, determina l'indirizzo MAC dall'indirizzo IP di questo router, gli trasmette i dati. Il router vede che la rete è connessa, trasmette i dati al computer B. Il computer B li riceve, lieto fine. "

Quindi chiedo a tutti i livelli del modello OSI

Qualcuno ha sentito parlare del protocollo Spanning Tree? Sul protocollo di root, sul livello IP? Ok, come funziona? Capisce come avviene il routing? Bene, alla rinfusa: tabelle di routing, protocollo di routing dinamico, livello di trasporto TCP. E così via e così via.
Voglio sentire la differenza tra TCP e UDP. Un buon specialista mi risponderà perché i sistemi critici (ad esempio, Domain Name System) utilizzano il protocollo senza consegna garantita dei messaggi (UDP).
La risposta è semplice: in questo modo è più veloce. Mentre organizzi una sessione TCP, puoi inviare un pacchetto UDP 3 volte lì e riceverlo indietro. E niente spese generali.

Faccio domande sul DNS

Quali sono i tipi di registrazione? Il mio interlocutore sa cos'è un record MX, come funziona spf o come funziona DKIM.
Sì, questa conoscenza potrebbe non essere utile nel lavoro. Ma per me è importante sapere se una persona comprende l'essenza della tecnologia, se è stato interessante per lui leggerla. Quindi ha aggiunto alcuni record al DNS e ha cercato su Google cos'è un record spf, o non lo ha cercato su Google?

Assolutamente ovunque ora viene utilizzato il protocollo HTTP, e chiedo a riguardo

Comincio ponendo le domande standard sulle differenze tra le versioni http 1.0, 1.1 e la versione due. Sono interessato a cosa sono le intestazioni e perché sono necessarie. Come fa il server web a capire di aver ricevuto una richiesta per un host virtuale specifico e non per nessun altro. E faccio sempre un paio di domande su Nginx.

Quindi passo senza problemi la mia attenzione al protocollo TLS

Come funziona SSL\TLS? Un ingegnere deve capirlo almeno a un livello di base: esiste un'autorità di certificazione radice, ha firmato il certificato e il certificato viene utilizzato da qualche parte.

In TLS, di solito sono interessato al processo di creazione di una connessione. Perché sono necessarie le chiavi private e pubbliche e come interagiscono? Se una persona annaspa, faccio una domanda trabocchetto: è possibile avere diversi certificati su un IP-shnik?

Rispondi sotto lo spoiler
Il fatto è che prima viene stabilita una connessione TLS, quindi segue il protocollo HTTP e il server Web può determinare a quale sito sta accedendo il client solo tramite il protocollo HTTP, dall'intestazione dell'host. Nginx non sa ancora a quale sito si sta accedendo, ma dovrebbe già fornire il certificato al client. Esistono estensioni al protocollo TLS che consentono al client di passare il nome host al server che contatta quando tenta di stabilire una connessione TLS. E quindi scegli il certificato richiesto. Quando questa estensione non era disponibile, solo un sito con SSL abilitato poteva essere ospitato su un IP-schnick.

Passando a Linux e BASH

Devi sapere tutto Unix, tutti i sistemi Unix-like. Devi essere in grado di lavorare con Shell e Bash, conoscere i comandi di base. ls, mkdir, ecc.
Bene, se il candidato può scrivere un po' in BASH, significa che ha cercato di automatizzare in qualche modo questa storia.
Su Linux chiederò come sostituire le righe in un file con altre righe. O come analizzare alcuni access.log in Nginx usando BASH. Per una persona parlare di awk, di gatto, di sorta, di tutto ciò che aiuta il lavoro veloce.
Ci sono file di testo ovunque, devi lavorarci correttamente. Se il candidato si offre di copiarli su Excel e fare qualcosa lì, mi sentirò in imbarazzo.

Quindi devi capire come stanno le cose con la virtualizzazione.

Virtualizzazione convenzionale, virtualizzazione tramite hypervisor. Se un candidato inizia a parlare di paravirtualizzazione, significa che sa qualcosa.
La mia domanda principale è: qual è la differenza tra la virtualizzazione dei container e la normale virtualizzazione dell'hypervisor? È bene se una persona confronta ciò che è meglio, ciò che è peggio, dove è appropriato usarlo.

Trasferirsi in container

Scopri se la persona con cui stai parlando ha lavorato con Docker? Ha compilato immagini, scritto file Docker, utilizzato Docker Compose, distribuito con esso. Perché sono necessari questi contenitori e come funzionano? Il nostro candidato ha presentato il sistema di orchestrazione dei container Swarm o Kubernetes? Puoi fare un intero blocco di domande, ma la cosa principale è capire se la persona ha fatto il lavoro con le proprie mani con i contenitori o no?

Fare domande sulla distribuzione di CI/CD /

Sono interessato a una lunga lista di cose: come imposta la distribuzione automatica, come imposta l'integrazione continua? Come vengono assemblate le sue applicazioni, utilizza sistemi di analisi del codice (PVS-Studio, SonarQube). Come scrive i test o come integra i test scritti dagli sviluppatori.
Fa qualche tipo di test di integrazione su questi assembly? Cosa succede dopo con ciò che ha raccolto? In qualche modo si aggiunge agli artfect o è impacchettato in contenitori docker, inserito nel registro? Lascia che ti dica quali sistemi ha usato per impostare il processo CI / CD. Può essere GitLab CI, Circle CI e qualche tipo di soluzione cloud. E forse Jenkins, beh, non dovresti dimenticare gli script scritti da te in PowerShell.
Dimmi come si schiera una persona e capirò tutto. Può essere distribuito utilizzando Helm in Kubernetes, Ansible, script o qualcos'altro autoscritto.

Informazioni sul sistema di gestione della configurazione

Parliamo Ansible più spesso. Perché la maggior parte delle persone lo conosce. Quindi, perché abbiamo bisogno di ruoli, come crittografare e archiviare dati segreti, come caricare password in un repository Git? E cose così.

Scopri la capacità di scrivere codice

È importante comprendere lo sviluppo per capire come interagiscono i servizi, perché sono necessarie API, protocolli di autenticazione, autorizzazione. È bello se il candidato ha scritto qualcosa da solo. Anche gli script di base in Python o Shell sono sufficienti per me. Ciò che conta non è il codice, ma quali compiti la persona voleva risolvere, cosa voleva ottenere.
La codifica è necessaria per supportare l'infrastruttura, scrivere script locali per i backup, monitoraggio personalizzato, al fine di estrarre con calma le metriche. Accade spesso nel lavoro che semplicemente non ci sia una soluzione standard per qualche problema.

Le domande finali dell'intervista riguardano l'archiviazione del database

SQL, NoSQL: quali sono le differenze, con cosa hai lavorato? Più spesso incontro persone con esperienza in PostgreSQL, meno spesso - MySQL. Faccio domande sugli indici, se il richiedente può impostare una replica, se può impostare una replica logica tra tabelle o solo dati. E cosa controllerà in questo caso? Come velocizzare la base?

A proposito, questa è una buona domanda. Diciamo che la base è ora seduta e appoggiata sul disco. E non ci si può fare nulla: nessuno comprerà più il server. Come fai a farlo funzionare più velocemente in questo momento?

Semplicemente...
Semplice: è necessario disattivare fsync in modo che il database non attenda la scrittura dei dati su disco, ma piuttosto li salvi. Linux può dare una scrittura di successo quando lo inserisce nel buffer e non quando viene caricato sul disco. Questa è una modalità operativa un po' stampella, anche piuttosto pericolosa e rischiosa. Il cibo verrà tagliato in questo momento e tutto inizierà. Ma d'altra parte, questo metodo accelera la registrazione di un ordine di grandezza. Ma non ripetere e non farlo mai. E sì, non te l'ho detto.
Per riassumere -
  • il network
  • Livello API
  • livello di trasporto TCP \ UDP
  • Protocolli DNS e HTTP
  • Linux
  • virtualizzazione di container e hypervisor
  • CI / CD
  • sistema di gestione della configurazione
  • contenitori
  • Banca dati

Tutto ciò ti consente di fare un quadro completo di una persona.

La cosa più critica sulla mia lista è la conoscenza di base. Se non conosci la base, è ora di finire il tuo compito di sicurezza sociale.
Se una persona non può rispondermi che cos'è una subnet mask o non capisce perché le intestazioni sono necessarie in HTTP, nella maggior parte dei casi un tale candidato ottiene il peggior svantaggio nel mio notebook. Non eri curioso di sapere come funzionano tutte queste cose che colpiscono il topo?
È molto difficile lavorare con persone che ripetono meccanicamente ciò che hanno imparato, invece di capire come funziona tutto. Un principiante che non conosce Docker può capirlo facilmente se ha una conoscenza di HTTP, TLS e reti.

Ma infine, il punto più importante: l'intero elenco non è necessario per seguirlo in una vera intervista. Devi esaminare tu stesso questo elenco prima di assumere persone.

E se tutto funziona, chiama il candidato per un colloquio e chiedigli solo una domanda: qual è stato il più grande fallimento che hai fatto sul lavoro, come l'hai risolto e quali conclusioni hai tratto dai tuoi errori.
Quando una persona ha qualcosa da raccontare, una tale sessione di sicurezza sociale passerà come una conversazione amichevole tra due ingegneri con la birra.
Bene, per tradizione, ti invito a unirti alla nostra comunità nel carrello : lì analizziamo regolarmente tutti questi argomenti e molti altri che saranno utili sia al colloquio che al lavoro.