De första 90 dagarna: En steg-för-steg-handbok för DevOps-ingenjörer
Hej, nyanställda. Jag har hört talas om dig!
Du lärde dig Kubernetes utan och innan, automatiserade allt som överhuvudtaget gick att automatisera och hanterade pipelines. Du studerade CI/CD-strategier, IaC-verktyg och YAML:s egenheter som om ditt liv hängde på det.
Grattis, du fick jobbet som DevOps-ingenjör!
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
De gav dig åtkomst till molnkonsolen, byggpipelinen och kanske – skräckinjagande nog – root-åtkomst till produktion (ingen press).
De flesta introduktioner inom DevOps är en skör cocktail av ”läs det här slumpmässiga dokumentet från 2021”, ”fråga runt” och ”rör inte det där skriptet, vi tror att det fortfarande gör något”.
Rollen är sällan väldefinierad och förväntningarna är skyhöga medan dokumentationen är knapp. Dessutom … vissa driftsättningar känns som om de skulle kunna väcka en uråldrig förbannelse.
Även om intervjun kanske handlade om verktyg handlar dina första 90 dagar framför allt om människor, processer och prioriteringar. Det är nu du bygger upp förtroende, upptäcker det odokumenterade och lägger grunden för den infrastruktur som ditt team kan lita på.
Den här handboken kommer inte att fixa ditt teams infrastruktur över en natt. Men den hjälper dig att undvika att framstå som den som hade sönder den.
Rollen: DevOps kontra plattform kontra SRE
Vi börjar med den eviga brasklappen: ”DevOps är en kultur, inte en jobbtitel.” Visst, Jan – men jobbtiteln finns fortfarande. Och i praktiken innebär den ofta en kombination av automationsspecialist, systemarkitekt, SRE och expert på interna verktyg.
Det är meningen att du ska vara en möjliggörare, en multiplikator och en förkämpe för leveranshastighet. Men sanningen är att du blir personen som folk vänder sig till när:
- Bygget går sönder och ingen vet varför.
- Någon behöver en ny stagingmiljö just nu.
- En efterlevnadsrevision närmar sig och hemligheter ligger oskyddade i klartext.
- ”Vi borde verkligen automatisera det där” blir ”Kan du automatisera det där?”
Plattformsutveckling är DevOps med bättre varumärkesprofilering.
SRE är DevOps med ett SLA.
Vad de än kallar det är ditt jobb att få saker att skala, förbli tillgängliga och inte suga.
De första 30 dagarna: Rör ingenting (än)
Tips #1: Kartlägg infrastrukturen, inte bara arkitekturen
Ta reda på vad du ansvarar för: molnleverantörer, CI/CD-pipelines, containerorkestrering, hantering av hemligheter och incidentarbetsflöden. Skapa din egen ”infrastrukturkarta” för att visualisera stacken. Extra pluspoäng om du länkar till aktiva instrumentpaneler eller skript.
Tips #2: Hitta sprängradien
Alla DevOps-organisationer har en uppsättning saker som man ”inte bör röra”. Inventera allt som kan explodera om det hanteras fel. Det omfattar:
- Driftsättningsskript som ansluter via SSH till produktion (varför … varför dååå?)
- Jenkins-jobb som senast ändrades 2019
- Manuella driftinstruktioner lagrade i en PDF
- Terraform-filer som aldrig faktiskt har tillämpats
Fråga: Vad är odokumenterat men kritiskt? Vem äger det? Och vad är planen för återställning om det misslyckas?
Tips #3: Var med vid en driftsättning – eller ännu bättre, följ en i realtid
Du lär dig mer av en enda driftsättning (och dess problem) än av timmars dokumentation. Vilka steg är manuella? Vad är instabilt? Vad är tyst kunskap och vad är formaliserat? Du är inte här för att komma med geniala idéer ännu. Du är här för att samla på dig information.
Du ska kunna följa en commit från sammanfogning till produktion med förbundna ögon. Förstå:
- CI/CD-pipelinen (var den bryts, var den blir en flaskhals)
- Hantering av hemligheter (använd inte miljövariabler, tack)
- Godkännandeflöden (distribuerar vi YOLO direkt från Slack?)
Skicka inte kod. Håll bara koll på rörsystemet och skriv ner saker.
De första 60 dagarna: Identifiera risker och minska friktion
Tips nr 4: Leverera en vinst på 5 minuter
Leta efter uppgifter med hög friktion och låg risk som du kan skripta eller skapa mallar för. Dessa förbättringar på ”1 %” gör livet enklare och bygger goodwill i teamet. Hitta bara en sak som tar 5 minuter för lång tid och gör den snabbare:
- Skalomslag för lokal utvecklingskonfiguration
- En CLI-hjälpare
- En återanvändbar Terraform-modul
- Skript för att radera testmiljöer som har fastnat
- Slack-avisering vid misslyckade byggen
Små vinster bygger förtroende. Förtroende ger dig spelrum att göra stora förändringar.
Tips nr 5: Granska CI/CD-pipelinen med skoningslös noggrannhet
Titta på byggtiderna. Titta på testtäckningen. Titta på vad som går sönder varje dag. Ställ frågor som:
- Kan vi parallellisera testerna?
- Kunde detta ha förhindrats tidigare i CI?
- Cachelagrar vi beroenden?
- Distribuerar vi vid en merge … eller på ren tur och hopp?
Du är inte här för att peka ut syndabockar. Du är här för att göra flödet friktionsfritt.
Tips nr 6: Skapa instrumentpaneler som människor faktiskt använder och tydliggör ansvaret
Grafana, Prometheus, Datadog – det spelar ingen roll. Det viktiga är:
- Kan teamet se hur stor andel av distributionerna som lyckas?
- Betyder aviseringarna något, eller är de bara brus?
Är det någon som övervakar felfrekvenserna innan användarna klagar? Vem ansvarar för byggpipelinen? Helm-diagrammen? DNS-konfigurationerna? Ansvarsgränserna är sällan tydliga. Gör en lista över gråzonerna och tydliggör dem med teamet. Det förhindrar att ni pekar ut syndabockar senare.
Du ansvarar nu för synligheten. Se till att den gör skillnad.
De första 90 dagarna: Bygg förtroende genom tillförlitlighet
Tips nr 7: Leverera något som ökar stabiliteten
Det kan vara att:
- Lägga till övervakning och aviseringar i ett system som övervakas för lite
- Förbättra testtäckningen i förproduktionsmiljön
- Minska instabiliteten i CI-pipelines
- Refaktorera ett bash-skript som var ett enda rm -rf från katastrof
Det behöver inte vara enormt. Det måste få teamet att andas lättare.
Tips nr 8: Skriv ett återkopplingsmemo om ”DevEx”
Samla in anonym eller informell återkoppling från utvecklare om var infrastrukturen bromsar dem. Presentera dina insikter och föreslå experiment (t.ex. snabbare lokal utveckling, tillfälliga miljöer och bättre loggning).
Skriv ett dokument med titeln ”Det här har jag lärt mig och det här gör jag härnäst.” Det är en färdplan (och kanske även en lista över saker att skryta om ;). Dela den med din chef och ditt team.
Skapa en lista med ”Det här får jag inte glömma”:
- De märkliga egenheter du upptäckte
- Den skugginfrastruktur som ingen erkänner att de äger
- Den tysta kunskap som bara Carl från IT verkar känna till
Förvandla den listan till dokument, automatisering eller ärenden – eller ha den nära till hands. Det visar ledningen att du bygger system som är motståndskraftiga mot problem.
Tips nr 9: Välj ett projekt med stor påverkan och börja formulera det
Vid det här laget bör du ha tillräckligt med information för att identifiera ett större förbättringsområde. Använd den sista delen av dina första 90 dagar till att avgränsa projektet, förankra det och skapa samsyn.
- Flytta instabila jobb till GitHub Actions
- Ersätt en unik server med infrastruktur som kod
- Bygg en standardiserad väg för utvecklare att skapa nya tjänster
Börja i liten skala och bevisa ditt värde. Dokumentera allt.
Avslutningsvis
Förhoppningsvis kan du under dina första 90 dagar stabilisera saker, få ut skit i produktion och, viktigast av allt, hindra ingenjörerna från att skrika ut i tomma intet.
De första dagarna handlar helt och hållet om att bygga momentum för framtiden. Hitta sprickorna och dokumentera som en galning!
Inte din första tekniska rodeo?
Den här DevOps-handboken är en del av en växande serie för nyanställda som vill göra skillnad innan någon överlämnar ”ansvaret för äldre system” till dem.
👉 Har du precis börjat i en roll som säkerhetsingenjör? Vi hjälper dig:
De första 90 dagarna: cybersäkerhetsutgåvan
👉 Mer intresserad av kodändringar än administratörsåtkomst? Kolla in:
De första 90 dagarna: utgåvan för programvaruingenjörer
Och ja – fler roller kommer snart. Håll utkik eller, ännu bättre, prenumerera på nyhetsbrevet så att du inte missar nästa.
