Hej, nyansatte. Jeg har hørt om dig!
Du lærte Kubernetes ud og ind, automatiserede alt, der overhovedet kunne automatiseres, og administrerede pipelines. Du studerede CI/CD-strategier, IaC-værktøjer og YAML-finesser, som om dit liv afhang af det.
Tillykke, du fik jobbet som DevOps-ingeniør!
De gav dig adgang til cloud-konsollen, build-pipelinen og muligvis – horribelt nok – root-adgang på produktion (intet pres).
Det meste DevOps-onboarding er en skrøbelig cocktail af “læs dette tilfældige dokument fra 2021”, “spørg dig frem” og “rør ikke ved det script, vi tror stadig, det gør et eller andet”.
Rollen er sjældent veldefineret, og forventningerne er vanvittigt høje, mens dokumentationen er sparsom. Desuden … føles nogle implementeringer, som om de kunne vække en ældgammel forbandelse.
Selvom jobsamtalen måske handlede om værktøjer, handler dine første 90 dage om mennesker, processer og prioriteter. Det er her, du opbygger troværdighed, afdækker det udokumenterede og lægger fundamentet for den infrastruktur, dit team kan stole på.
Denne drejebog løser ikke dit teams infrastruktur fra den ene dag til den anden. Men den hjælper dig med at undgå at ligne den, der ødelagde den.
Stemmer fra felten
“Den vigtigste lektie, jeg har lært, er, hvor hurtigt du er nødt til at forstå dine kunder – altså udviklerne – og deres præferencer. Hos Pixar satte jeg engang et CI-system op, som ingen brugte, før jeg tilføjede e-mailnotifikationer. Det viste sig, at det var sådan, de gerne ville have besked. Hos en anden virksomhed øgede vi brugen af tests ved at gøre det til en konkurrence med live-ranglister på kontoret. Kultur er ikke bare en baggrundsdetalje – det er den egentlige leveringspipeline. -Tara Hernandez, VP of Developer Productivity hos MongoDB
Rollen: DevOps vs. Platformteknik vs. SRE
Lad os begynde med den evige ansvarsfraskrivelse: “DevOps er en kultur, ikke en jobtitel.” Jo jo, Jan – men jobtitlen findes stadig. Og i praksis betyder det ofte en hybrid af automatiseringsspecialist, systemarkitekt, SRE og ekspert i interne værktøjer.
Det er meningen, at du skal være en muliggører, en forstærker, en forkæmper for leveringshastighed. Men sandheden er, at du bliver den person, folk kommer til, når:
- Buildet fejler, og ingen ved hvorfor.
- Nogen har brug for et nyt staging-miljø lige nu.
- En compliance-revision nærmer sig, og hemmeligheder ligger frit tilgængelige i klartekst.
- “Vi burde virkelig automatisere det” bliver til “Kan du automatisere det?”
Platformteknik er DevOps med bedre branding.
SRE er DevOps med en SLA.
Uanset hvad de kalder det, er dit job at få ting til at skalere, forblive tilgængelige og ikke være noget bras.
De første 30 dage: Lad være med at røre noget (endnu)
Tip nr. 1: Kortlæg infrastrukturen, ikke kun arkitekturen
Find ud af, hvad du har ansvaret for: cloududbydere, CI/CD-pipelines, containerorkestrering, håndtering af hemmeligheder og workflows for hændelser. Opret dit eget “infrakort” for at visualisere stakken. Ekstra point, hvis du linker til live-dashboards eller scripts.
Have an account? Log In
Tip nr. 2: Find eksplosionsradius
Alle DevOps-organisationer har en opsætning, man helst ikke skal røre ved. Lav en fortegnelse over alt, der kan eksplodere, hvis det håndteres forkert. Det omfatter:
- Deploy-scripts, der bruger SSH til at logge på produktion (hvorfor … hvorfor dog?)
- Jenkins-jobs, der sidst blev ændret i 2019
- Manuelle kørselsvejledninger gemt i en PDF
- Terraform-filer, som aldrig rent faktisk er blevet anvendt
Spørg: Hvad er udokumenteret, men kritisk? Hvem ejer det? Og hvad er planen for tilbagerulning, hvis det fejler?
Tip nr. 3: Overvær en deploy – eller endnu bedre, følg en live
Du lærer mere af en enkelt deploy (og dens problemer) end af timevis af dokumentation. Hvilke trin er manuelle? Hvad er ustabilt? Hvad er erfaringsbaseret viden, og hvad er nedskrevet som kode? Du er ikke her for at komme med geniale idéer endnu. Du er her for at samle snavs.
Du bør kunne følge en commit fra merge til produktion med bind for øjnene. Forstå:
- CI/CD-pipelinen (hvor den går i stykker, hvor den bliver en flaskehals)
- Håndtering af hemmeligheder (lad dem venligst ikke være i miljøvariabler)
- Godkendelsesflows (udruller vi fra Slack helt uden omtanke?)
Du skal ikke levere kode. Hold bare øje med infrastrukturen, og skriv tingene ned.
Stemmer fra felten
“God onboarding kommer ikke altid med god dokumentation. Nogle gange er nysgerrighed og vedholdenhed den eneste vej gennem kaos. Da jeg blev en del af et team og fik overdraget en kompleks lancering uden dokumentation, reverse-engineerede jeg hele flowet. Den oplevelse lærte mig: Hvis dokumentationen mangler, bliver du selv dokumentationen.” –Anant Agarwal, teknologidirektør hos Aidora
De første 60 dage: Identificér risici, og reducér friktion
Tip nr. 4: Lever en gevinst på 5 minutter
Se efter opgaver med høj friktion og lav risiko, som du kan skrive scripts til eller gøre skabelonbaserede. Disse “1 %”-forbedringer gør dit liv lettere og opbygger goodwill i teamet. Find bare én ting, der tager 5 minutter for lang tid, og gør den hurtigere:
- Shell-wrapper til lokal udviklingsopsætning
- En CLI-hjælper
- Et genanvendeligt Terraform-modul
- Script til at fjerne fastlåste testmiljøer
- Slack-notifikation ved fejlslagne builds
Små gevinster opbygger tillid. Tillid giver dig spillerum til at gennemføre store ændringer.
Tip nr. 5: Gennemgå CI/CD-pipelinen med ekstrem grundighed
Se på buildtiderne. Se på testdækningen. Se på, hvad der går i stykker hver dag. Stil spørgsmål som:
- Kan vi køre testene parallelt?
- Kunne dette være blevet forhindret tidligere i CI?
- Cachelagrer vi afhængigheder?
- Udruller vi ved en merge … eller satser vi bare på, at det nok skal gå?
Du er ikke her for at placere skyld. Du er her for at gøre flowet friktionsfrit.
Stemmer fra felten
“Ved en nylig overtagelse af en app med høj trafik var der ingen dokumentation overhovedet – vi måtte hurtigt finde ud af alt gennem forsøg og fejl. Mit råd? Brug AI intensivt. Fra loganalyse til reverse engineering af API’er hjalp AI os med at komme ombord og stabilisere systemet hurtigere, end vi nogensinde kunne have gjort alene. Det forvandler rutinepræget slid til reelle fremskridt.” –Denis Tiumentsev, ledende DevOps-ingeniør hos Integro Technologies
Tip nr. 6: Opret dashboards, som folk rent faktisk bruger, og tydeliggør ejerskabet
Grafana, Prometheus, Datadog – det er ligegyldigt. Det vigtige er:
- Kan dit team se, hvor stor en andel af udrulningerne der lykkes?
- Betyder alarmerne noget, eller er de bare støj?
Er der nogen, der holder øje med fejlprocenterne, før brugerne klager? Hvem ejer buildpipelinen? Helm-diagrammerne? DNS-konfigurationerne? Grænserne for ejerskab er sjældent tydelige. Lav en liste over gråzonerne, og afklar dem med dit team. Det forebygger fingerpegning senere.
Du ejer synligheden nu. Få den til at tælle.
De første 90 dage: Opbyg tillid gennem pålidelighed
Tip nr. 7: Lever noget, der øger stabiliteten
Det kunne være:
- Tilføjelse af alarmer til et system med utilstrækkelig overvågning
- Forbedring af testdækningen i præproduktionsmiljøet
- Reduktion af ustabile tests i CI-pipelines
- Refaktorering af et bash-script, der var én rm -rf fra en katastrofe
Det behøver ikke være stort. Det skal gøre det lettere for dit team at trække vejret.
Stemmer fra felten
“En af de første succeser i en ny DevOps-rolle var at implementere en centraliseret CI/CD-pipeline med automatiseret tilbagerulning og GitOps-arbejdsgange. Før det var teamet afhængigt af fragmenterede scripts og manuelle nødløsninger. Det reducerede implementeringstiderne med over 50 % og flyttede os fra brandslukning til proaktiv pålidelighed. Den troværdighed, der fulgte med lanceringen, gjorde en enorm forskel.” –Divya Parashar, senioringeniør
Tip nr. 8: Skriv et feedbacknotat om “DevEx”
Indsaml anonym eller uformel feedback fra udviklere om, hvor infrastrukturen bremser dem. Præsenter dine indsigter, og foreslå eksperimenter (f.eks. hurtigere lokal udvikling, midlertidige miljøer og bedre logføring).
Skriv et dokument med titlen “Her er, hvad jeg har lært, og hvad jeg gør som det næste.” Det er en køreplan (og måske også en praleliste ;). Del den med din leder og dit team.
Opret en liste med “Det her må jeg ikke glemme”:
- De mærkelige særheder, du har opdaget
- Den skjulte infrastruktur, som ingen vil indrømme, at de ejer
- Den tavse viden, som det kun virker til, at Carl fra IT kender
Omsæt den liste til dokumenter, automatisering eller tickets – eller hav den ved hånden. Det viser ledelsen, at du bygger systemer, der er modstandsdygtige over for fejl.
Stemmer fra felten
“Fokuser på de resultater, du kan kontrollere i dag. Forankr dig i, hvorfor dit arbejde betyder noget for kunderne – det perspektiv gør hele forskellen i løbet af de første 90 dage.” –Rukmini Reddy, SVP for Engineering hos PagerDuty
More Articles
Tip nr. 9: Vælg ét projekt med stor effekt, og begynd at definere det
På nuværende tidspunkt bør du have tilstrækkeligt med information til at identificere et større forbedringsområde. Brug den sidste del af dine første 90 dage på at afgrænse det, præsentere det for andre og skabe fælles opbakning.
- Flyt ustabile jobs til GitHub Actions
- Erstat én specialtilpasset server med infrastruktur som kode
- Byg en standardvej, så udviklere kan oprette nye tjenester
Begynd i det små, og bevis din værdi. Dokumentér alt.
Det sidste ord
Forhåbentlig kan du inden for dine første 90 dage stabilisere tingene, få lortet implementeret og vigtigst af alt forhindre ingeniørerne i at skrige ud i tomheden.
De første dage handler om at skabe fremdrift på lang sigt. Find sprækkerne, og dokumentér som en vanvittig!
Stemmer fra felten
“Du behøver ikke bevise dig selv på én dag. Træk vejret. Fokuser på stabilitet først og hastighed bagefter. Stil dumme spørgsmål tidligt – de bliver kun sværere at stille senere. Og husk: Et kedeligt system, der virker, er bedre end et smart system, der går i stykker.” –Pablo Gerboles, CEO hos Alive DevOps
Er det ikke din første rodeotur i tech?
Dette DevOps-værktøjssæt er en del af en voksende serie for nyansatte, der vil gøre en forskel, før nogen giver dem “ansvaret for ældre systemer”.
👉 Er du lige begyndt i en rolle som sikkerhedsingeniør? Vi hjælper dig:
De første 90 dage: Udgaven om cybersikkerhed
👉 Er du mere til kodecommits end root-adgang? Så tjek:
De første 90 dage: Udgaven for softwareingeniører
Og ja – vi har flere roller på vej. Følg med, eller endnu bedre: tilmeld dig nyhedsbrevet, så du ikke går glip af den næste.
