DevOps-intervjufrågor: Infrastruktur, CI/CD och vad de verkligen testar

DevOps-intervjuer har rykte om sig att vara svåra att förbereda sig för. En del av anledningen är att "DevOps-ingenjör" täcker ett enormt antal roller – från infrastrukturintensiva SRE-positioner på stora techföretag, till CI/CD-pipeline-specialister på medelstora SaaS-företag, till molnmigrationsningenjörer på företag som migrerar från äldre system. Verktygen och prioriteringarna varierar avsevärt.

Men det finns ett mer konsekvent underliggande ting som DevOps-intervjuare försöker bedöma: hur du resonerar om system. Kan du spåra ett fel tillbaka till dess grundorsak? Kan du tänka om en distributionspipeline från slut till slut? Förstår du avvägningarna mellan tillförlitlighet och hastighet? Vet du när du ska automatisera och när du ska lämna något manuellt? Dessa resonemangsmönster dyker upp i varje DevOps-intervju, oavsett den specifika teknologistapeln.

Den här guiden täcker de frågor du faktiskt kommer att bli tillfrågad, vad de verkligen testar och hur du svarar på ett sätt som demonstrerar de tankemönster erfarna DevOps-ingenjörer uppvisar.

Vad DevOps-intervjuare verkligen utvärderar

Innan vi dyker in i specifika frågor är det värt att förstå de utvärderingsaxlar DevOps-intervjuare använder.

Systemtänkande: Förstår du hur komponenter interagerar? När något går sönder, spårar du problemet uppströms och nedströms, eller åtgärdar du det uppenbara symptomet och går vidare? Intervjuare testar detta med felscenariofrågor och postmortem-diskussioner.

Operativ mognad: Har du levererat saker som andra är beroende av? Har du haft jourvakt och hanterat verkliga incidenter? Kandidater som bara har arbetat i rent greenfield- eller rent utvecklingssammanhang kämpar ofta med de operativa frågorna – vad som brister i skala, hur du hanterar toil, hur en bra varning ser ut.

Samarbete och kommunikation: DevOps är i sig tvärfunktionellt. Arbetar du effektivt med utvecklare som inte vet mycket om infrastruktur? Kan du förklara en distributionsarkitektur för en icke-teknisk intressent? Hur hanterar du spänningen mellan utvecklarehastighet och infrastrukturstabilitet?

Automatiseringsinstinkt: Den kulturella kärnan i DevOps är att automatisera toil. Intervjuare vill se att du reflexmässigt frågar "kan detta automatiseras?" när du beskriver manuella processer – inte som ett buzzword, utan som en genuin operativ instinkt.

Infrastruktur- och systemfrågor

"Gå igenom vad som händer när en Kubernetes-pod kraschar."

Det här är en diagnostisk fråga. Intervjuaren testar inte om du känner till crash loop backoff-sekvensen utantill – de vill se om du kan resonera igenom ett systems beteende från slut till slut.

Ett starkt svar täcker: containern avslutas (med vilken exit-kod, och varför exit-koder spelar roll för att skilja applikationsfel från OOM-dödar från hälsokontrollfel), kubelet identifierar tillståndsändringen, poden går in i en omstartscykel, crash loop backoff startar (exponentiell backoff upp till fem minuter som standard), liveness-prober är relevanta här och de observerbarhetsverktyg du skulle använda (kubectl describe, kubectl logs --previous, händelser i namnrymden).

Intervjuaren ser också om du ställer clarifierande frågor: "Vilken sorts pod – stateless deployment, statefulset? Är det i produktion eller dev? Finns det resursbegränsningar satta?" Den krympa-instinkten är en signal på verklig felsökningserfarenhet.

"Hur skulle du designa nätverket för en tre-lagers webbapplikation på AWS?"

Det här är en arkitekturfråga som testar hur du tänker om säkerhet, tillgänglighet och trafikflöde simultant. Ett välstrukturerat svar täcker:

• Offentligt subnät för lastbalanseraren (ALB) med internet gateway
• Privata subnät för applikationslagret (ECS, EKS eller EC2), helst över flera AZ:er
• Privata subnät för datakikret (RDS med Multi-AZ för HA)
• Säkerhetsgrupper som primärt åtkomstkontrollager – principen om lägsta privilegium, tillåter bara trafik från lagret ovan
• VPC-flödesloggar för observerbarhet
• NAT-gateway för utgående internet från privata subnät om det behövs

Lägg sedan till nyans: "I en verklig implementering skulle jag också tänka på VPC-endpoints för att undvika att trafik lämnar AWS-nätverket för S3 och DynamoDB-anrop, och om vi behöver en WAF framför ALB."

Starka kandidater bygger svaret inkrementellt och nämner avvägningar. Svaga kandidater rabblar en lista med AWS-tjänster utan att förklara varför de används eller vilka alternativen är.

"Vad är skillnaden mellan en rullande distribution och en blå-grön distribution?"

En till synes enkel fråga som testar om du förstår distributionsstrategier och när var och en är lämplig.

Rullande distribution: ersätt gradvis instanser av den gamla versionen med den nya versionen. Vid varje punkt under distributionen träffar viss trafik den gamla versionen och viss trafik den nya. Enklare att implementera, använder färre resurser, men riskerar blandade versionstillstånd som kan orsaka problem med databasmigreringar eller bryta API-ändringar.

Blå-grön distribution: kör två identiska miljöer (blå = aktuell, grön = ny). Byt trafik på en gång (eller gradvis via viktad routing). Omedelbar rollback (flippa tillbaka till blå), inget blandat versionstillstånd, men kräver dubbla infrastrukturresurser under övergångsfönstret.

Canary-release är ett tredje alternativ värt att nämna: routa en liten andel av trafiken (1 %, 5 %) till den nya versionen, övervaka, expandera gradvis. Bättre för riskhantering men mer komplex att implementera och övervaka.

Det rätta svaret inkluderar också när du väljer var och en: "Blå-grön när en ren övergång är kritisk och du har råd med resurskostnaden. Rullande när du behöver spara infrastrukturkostnad och ändringarna är bakåtkompatibla. Canary när du gör en ändring med hög osäkerhet och vill ha verklig trafikvalidering innan fullständig utrullning."

CI/CD-pipeline-frågor

"Berätta om en CI/CD-pipeline du byggde eller förbättrade avsevärt."

Beteendefråga, men teknisk till innehållet. Intervjuaren vill veta: vilket var utgångstillståndet, vad ändrade du, vilka var resultaten och vad lärde du dig?

Ett starkt svar är specifikt om verktyget (GitHub Actions, Jenkins, GitLab CI, CircleCI, ArgoCD, etc.), de specifika problem du löste (långsamma byggen, opålitliga tester, manuella distributionssteg, brist på miljöparitet) och de mätbara resultaten (byggtid minskad från 45 till 12 minuter, distributionsfrekvens ökad från veckovis till daglig, rollbacktid från 2 timmar till 5 minuter).

Det som gör svaret starkt är inte de specifika verktygen – det är att demonstrera att du förstod systemet tillräckligt bra för att diagnostisera flaskhalsar, hade omdömet att prioritera rätt förbättringar och mätte resultaten i termer som kopplar till utvecklarupplevelse och affärshastighet.

"Hur hanterar du hemligheter i en CI/CD-pipeline?"

Det här är både en säkerhetsfråga och en praktisk. Vanliga tillvägagångssätt: miljövariabler injicerade vid körning, HashiCorp Vault med dynamiska hemligheter, AWS Secrets Manager eller GCP Secret Manager med IAM-baserad åtkomst, Kubernetes-hemligheter (med förbehållet att de bara är base64-kodade, inte krypterade, som standard – ETCD-kryptering i vila är ett separat steg).

Starka svar täcker också vad man inte ska göra: hemligheter i miljövariabler som loggas, hemligheter i kodförråd, hemligheter skickade som byggargument som bakas in i Docker-bildlager.

Uppföljningen är ofta: "Vad händer om en hemlighet av misstag commitas till repot?" Ett starkt svar täcker: rotera omedelbart, skanna git-historik (git-secrets, truffleHog, GitHubs egna hemlighetsskanning), kontrollera om hemligheten användes i några byggloggar och genomföra en kort incidentgranskning för att förstå hur det hände och förhindra återfall.

Linux- och skriptfrågor

"En server körs långsamt. Hur diagnostiserar du det?"

Den diagnostiska metodikfrågan. Svaret demonstrerar om du har ett systematiskt tillvägagångssätt eller bara provar slumpmässiga saker.

Ett strukturerat tillvägagångssätt: börja med de fyra huvudresurskategorierna – CPU, minne, disk-I/O, nätverk. Kommandon för var och en:

• CPU: top, htop, mpstat, vmstat – finns det en specifik process som förbrukar CPU? Är det user-space eller kernel-space? Finns det CPU-stöld (vanligt på delade molninstanser)?
• Minne: free -h, vmstat, /proc/meminfo – finns det minnestryck? Swap-användning? Är OOM-dödaren aktiv (dmesg | grep -i oom)?
• Disk: iostat -x 1, iotop – hög I/O-väntan? Vilka processer gör I/O:n? Är det läsningar eller skrivningar?
• Nätverk: netstat -s, ss -s, iftop – finns det anslutningstabell-utmattningsproblem? Paketförluster? Återöverföringar?

Sedan: "När jag har identifierat resursstopp, tittar jag på applikationsloggarna tillsammans med resurstidslinjen för att korrelera nedgången med specifika förfrågningar eller händelser."

"Skriv ett skript för att hitta de 10 processer som använder mest minne."

Skriptfrågor testar om du kan skriva funktionell kod snabbt, inte perfekt optimerad kod. Ett korrekt svar: ps aux --sort=-%mem | head -11 (eller awk med ps aux för mer kontroll). Bonuspoäng för att nämna att ps ögonblicksbilder kanske inte återspeglar övergående toppar och att du kanske föredrar top -b -n 1 för en enda-pass batchutdata eller /proc/<pid>/status för mer detaljer.

Incident- och tillförlitlighetsfrågorna

"Berätta om en incident du hanterade. Vad hände, och vad gjorde du?"

Den viktigaste beteendefrågan i en DevOps-intervju. Intervjuaren utvärderar: hur du diagnostiserar under tryck, hur du kommunicerar under en incident, djupet av din tekniska förståelse och dina post-incident-vanor.

En bra incidentberättelse har: en tydlig tidslinje (när märkte du det först, vad var de initiala symptomen, vad var affärspåverkan), en diagnos-narrativ (vad du kontrollerade, vad du uteslöt, vad grundorsaken visade sig vara), en lösning (tillfällig lindring kontra permanent fix) och en retrospektiv (vad incidenten avslöjade om systemets svagheter och vad som förändrades efteråt).

De bästa kandidaterna visar att de lärde sig något från incidenten som förändrade hur de bygger eller driver system. Den lärandecykeln – incident → förståelse → systemisk förbättring – är signatur för en mogen DevOps-ingenjör.

Förberedelse för systemdesignkomponenten

Många seniora DevOps-intervjuer inkluderar en systemdesignfråga specifik för infrastruktur: "Designa ett loggning- och övervakningssystem för en mikrotjänstarkitektur" eller "Hur skulle du designa infrastrukturen för ett globalt distribuerat API med 99,99 % SLA?"

Dessa frågor handlar inte primärt om att känna till de exakta rätta svaren. De handlar om att demonstrera en strukturerad tankeprocess: klargör krav först (trafikvolym, geografisk distribution, latensSLA, kostnadsbegränsningar), identifiera nyckeldesignbeslut och avvägningar, bygg upp från grunden och var explicit om vad du optimerar för.

Att förbereda ditt CV för att återspegla den här typen av systemtänkande – inte bara verktygskännedom – är grunden för dessa samtal. Verktyg som NextCV kan hjälpa dig att rama in din erfarenhet i termer av de resultat och resonemangsmönster som DevOps-intervjuare letar efter, snarare än bara listan med teknologier du har använt.

Den underliggande sanningen om DevOps-intervjuer är att verktygen i stor utsträckning är utbytbara – Kubernetes kontra ECS, Jenkins kontra GitHub Actions, Prometheus kontra Datadog. Vad som inte är utbytbart är tankesättet: operativt ägarskap, systemtänkande och disciplinen att bygga saker som är observerbara, tillförlitliga och underhållbara.