De første 90 dagene: En trinnvis håndbok for DevOps-ingeniører

Hei, nyansatte. 

Du lærte Kubernetes ut og inn, automatiserte alt som kunne automatiseres, og administrerte pipelines. Du studerte CI/CD-strategier, IaC-verktøy og YAML-egenheter som om livet ditt var avhengig av det.

Gratulerer, du fikk jobben som DevOps-ingeniør!

De ga deg tilgang til sky-konsollen, byggepipelinen og muligens – skremmende nok – root-tilgang i produksjon (ingen press).

Det meste av introduksjonen til DevOps er en skjør cocktail av «les dette tilfeldige dokumentet fra 2021», «spør deg rundt» og «ikke rør det skriptet, vi tror fortsatt det gjør noe». 

Rollen er sjelden tydelig definert, og forventningene er idiotisk høye, mens dokumentasjonen er mangelfull. Dessuten … enkelte utrullinger føles som om de kan vekke en eldgammel forbannelse.

Selv om intervjuet kanskje handlet om verktøy, handler de første 90 dagene dine om mennesker, prosesser og prioriteringer. Det er nå du bygger troverdighet, avdekker det udokumenterte og legger grunnlaget for infrastrukturen teamet ditt kan stole på.

Denne håndboken løser ikke teamets infrastruktur over natten. Men den hjelper deg med å unngå å se ut som personen som ødela den.

Stemmer fra feltet

«Den viktigste lærdommen jeg har fått, er hvor raskt du må forstå kundene dine – det vil si utviklerne – og preferansene deres. Hos Pixar satte jeg en gang opp et CI-system som ingen brukte før jeg la til e-postvarsler. Det viste seg at det var slik de likte å bli varslet. I et annet selskap økte vi bruken av testing ved å gjøre det til en konkurranse med live-resultattavler på kontoret. Kultur er ikke bare en bakgrunnsdetalj – den er den virkelige leveringspipelinen.» -Tara Hernandez, VP for utviklerproduktivitet hos MongoDB

Rollen: DevOps kontra plattform kontra SRE

La oss begynne med den evige ansvarsfraskrivelsen: «DevOps er en kultur, ikke en stillingstittel.» Jada, særlig. Men stillingstittelen finnes fortsatt. Og i praksis betyr det ofte en hybrid av automatiseringsspesialist, systemarkitekt, SRE og ekspert på interne verktøy.

Det er meningen at du skal være en tilrettelegger, en forsterker, en forkjemper for leveringshastighet. Men sannheten er at du blir personen folk kommer til når:

• Bygget feiler, og ingen vet hvorfor.
• Noen trenger et nytt staging-miljø med en gang.
• En samsvarsrevisjon nærmer seg, og hemmeligheter ligger strødd i klartekst.
• «Vi burde virkelig automatisere det» blir til «Kan du automatisere det?»

Plattformutvikling er DevOps med bedre merkevarebygging.
SRE er DevOps med en SLA.

Uansett hva de kaller det, er jobben din å få ting til å skalere, holde seg oppe og ikke være elendige.

De første 30 dagene: Ikke rør noe (ennå)

Tips nr. 1: Kartlegg infrastrukturen, ikke bare arkitekturen 

Finn ut hva du har ansvar for: skyleverandører, CI/CD-pipelines, containerorkestrering, håndtering av hemmeligheter og hendelsesprosesser. Lag ditt eget «infrakart» for å visualisere stakken. Ekstrapoeng hvis du lenker til aktive dashbord eller skript.

Tips nr. 2: Finn nedslagsfeltet

Alle DevOps-organisasjoner har et oppsett man «ikke må røre». Kartlegg alt som kan eksplodere hvis det håndteres feil. Dette inkluderer:

• Utrullingsskript som kobler seg til produksjon via SSH (hvorfor … hvorfor?!?)
• Jenkins-jobber som sist ble endret i 2019
• Manuelle driftsprosedyrer lagret i en PDF
• Terraform-filer som aldri faktisk ble tatt i bruk

Spør: Hva er udokumentert, men kritisk? Hvem eier det? Og hva er planen for tilbakerulling hvis det feiler?

Tips nr. 3: Bli med på en utrulling – eller enda bedre, følg en i sanntid 

Du lærer mer av én utrulling (og problemene underveis) enn av timevis med dokumentasjon. Hvilke trinn er manuelle? Hva er ustabilt? Hva er erfaringsbasert kunnskap, og hva er formalisert? Du er ikke her for å komme med geniale ideer ennå. Du er her for å samle skittentøy.

Du bør kunne følge en commit fra fletting til produksjon med bind for øynene. Forstå:

• CI/CD-pipelinen (hvor den bryter sammen, hvor den blir en flaskehals)
• Håndtering av hemmeligheter (ikke legg dem i miljøvariabler)
• Godkjenningsflyter (distribuerer vi direkte fra Slack uten å tenke oss om?)

Ikke lever kode. Bare følg med på røropplegget og skriv ned ting.

Stemmer fra felten

«God onboarding kommer ikke alltid med god dokumentasjon. Noen ganger er nysgjerrighet og utholdenhet den eneste veien gjennom kaoset. Da jeg begynte i et team og fikk ansvar for en kompleks lansering uten dokumentasjon, baklengskonstruerte jeg hele flyten. Den erfaringen lærte meg dette: Hvis dokumentasjonen mangler, blir du dokumentasjonen.» –Anant Agarwal, teknologidirektør i Aidora

De første 60 dagene: Identifiser risikoer og reduser friksjon

Tips nr. 4: Lever en rask seier på 5 minutter

Se etter oppgaver med mye friksjon og lav risiko som du kan skripte eller lage maler for. Disse «1 %»-forbedringene gjør livet enklere og bygger goodwill i teamet. Finn bare én ting som tar 5 minutter for lang tid, og gjør den raskere:

• Shell-omslag for lokalt utviklingsoppsett
• En CLI-hjelper 
• En gjenbrukbar Terraform-modul
• Skript for å slette fastlåste testmiljøer
• Slack-varsling for bygg som mislykkes

Små seire bygger tillit. Tillit gir deg spillerom til å gjøre store endringer.

Tips nr. 5: Revider CI/CD-pipelinen grundig

Se på byggetidene. Se på testdekningen. Se på hva som bryter sammen hver dag. Still spørsmål som:

• Kan vi kjøre testene parallelt?
• Kunne dette ha blitt forhindret tidligere i CI?
• Bufrer vi avhengigheter?
• Distribuerer vi ved sammenslåing … eller baserer vi oss på håp og en bønn?

Du er ikke her for å peke ut syndebukker. Du er her for å gjøre flyten friksjonsfri.

Stemmer fra felten

«Da vi nylig overtok en app med mye trafikk, fantes det null dokumentasjon – vi måtte finne ut av alt gjennom prøving og feiling, og det måtte gå raskt. Mitt råd? Bruk KI offensivt. Fra logganalyse til baklengskonstruksjon av API-er hjalp KI oss med å komme raskere inn i arbeidet og stabilisere løsningen raskere enn vi noen gang kunne klart alene. Det gjør rutinepreget slit om til reell fremgang.” –Denis Tiumentsev, ledende DevOps-ingeniør i Integro Technologies

Tips nr. 6: Lag dashbord folk faktisk bruker, og tydeliggjør eierskapet 

 Grafana, Prometheus, Datadog – det spiller ingen rolle. Det som betyr noe:

• Kan teamet ditt se hvor stor andel av distribusjonene som lykkes?
• Betyr varslene noe, eller er de bare støy?

Er det noen som følger med på feilratene før brukerne klager? Hvem eier byggpipelinen? Helm-diagrammene? DNS-konfigurasjonene? Eierskapsgrensene er sjelden tydelige. Lag en liste over gråsonene, og avklar dem med teamet ditt. Dette forhindrer pekefinger senere.

Du eier synligheten nå. Sørg for at den teller.

De første 90 dagene: Bygg tillit gjennom pålitelighet

Tips nr. 7: Lever noe som øker stabiliteten 

Dette kan være:

• Å legge til varsling i et system som overvåkes for lite
• Å forbedre testdekningen i preproduksjon
• Å redusere ustabilitet i CI-pipeliner
• Å refaktorere et Bash-skript som var én rm -rf unna en katastrofe

Det trenger ikke å være enormt. Det må gjøre teamet ditt tryggere.

Stemmer fra felten

«En av de første seirene i en ny DevOps-rolle var å implementere en sentralisert CI/CD-pipeline med automatisert tilbakerulling og GitOps-arbeidsflyter. Før det var teamet avhengig av fragmenterte skript og manuelle nødløsninger. Dette reduserte utrullingstidene med over 50 % og flyttet oss fra brannslukking til proaktiv pålitelighet. Troverdigheten som fulgte med denne utrullingen, gjorde en stor forskjell.» -\u003cstrong data-start=\u00222473\u0022 data-end=\u00222506\u0022\u003eDivya Parashar, senioringeniør\u003c/strong\u003e

Tips nr. 8: Skriv et tilbakemeldingsnotat om «DevEx»

Samle inn anonym eller uformell tilbakemelding fra utviklere om hvor infrastrukturen gjør arbeidet deres tregere. Presenter det du har lært, og foreslå eksperimenter (f.eks. raskere lokal utvikling, midlertidige miljøer og bedre logging).

Skriv et dokument med tittelen «Dette har jeg lært, og dette gjør jeg videre». Dette er en veikartplan (og kanskje en skryteliste ;). Del den med lederen og teamet ditt.

Lag en liste over «Dette må jeg ikke glemme»:

• De merkelige særegenhetene du oppdaget
• Skyggeinfrastrukturen som ingen innrømmer å ha ansvar for
• Den interne kunnskapen som bare Carl fra IT ser ut til å kjenne til

Gjør denne listen om til dokumenter, automatisering eller oppgaver – eller ha den lett tilgjengelig. Dette viser ledelsen at du bygger robuste systemer.

Stemmer fra felten

«Fokuser på resultatene du kan påvirke i dag. Minn deg selv på hvorfor arbeidet ditt betyr noe for kundene – dette perspektivskiftet utgjør hele forskjellen i løpet av de første 90 dagene.» -\u003cstrong data-start=\u00223118\u0022 data-end=\u00223168\u0022\u003eRukmini Reddy, teknisk direktør hos PagerDuty\u003c/strong\u003e

Tips nr. 9: Velg ett prosjekt med stor innvirkning, og begynn å utforme det 

Nå bør du ha nok informasjon til å identifisere et viktig forbedringsområde. Bruk den siste delen av de første 90 dagene på å avgrense prosjektet, presentere det for andre og skape enighet.

• Flytt ustabile jobber til GitHub Actions
• Bytt ut én unik server med infrastruktur som kode
• Bygg en standardisert vei for utviklere som skal opprette nye tjenester

Begynn i det små, og bevis verdien din. Dokumenter alt.

Avsluttende ord

Forhåpentligvis kan du i løpet av de første 90 dagene stabilisere ting, få ting ut i produksjon og, viktigst av alt, hindre ingeniørene i å skrike ut i tomrommet.

De første dagene handler om å skape fremdrift for det lange løpet. Finn sprekkene, og dokumenter som en galning! 

Stemmer fra felten

«Du trenger ikke bevise deg selv på én dag. Pust. Fokuser på stabilitet først og hastighet deretter. Still dumme spørsmål tidlig – de blir bare vanskeligere å stille senere. Og husk: Et kjedelig system som fungerer, er bedre enn et prangende system som går i stykker.» -\u003cstrong data-start=\u00223597\u0022 data-end=\u00223636\u0022\u003ePablo Gerboles, administrerende direktør hos Alive DevOps\u003c/strong\u003e

Ikke din første teknologirunde?

Denne DevOps-håndboken er en del av en voksende serie for nyansatte som ønsker å gjøre en forskjell før noen gir dem «ansvaret for gamle systemer».

👉 Nettopp begynt i en rolle som sikkerhetsingeniør? Vi hjelper deg i gang:
De første 90 dagene: Utgaven for cybersikkerhet

👉 Mer interessert i kodeinnsjekkinger enn administratortilgang? Sjekk ut:
De første 90 dagene: Utgaven for programvareingeniører

Og ja – vi har flere roller på vei. Følg med, eller enda bedre: abonner på nyhetsbrevet, så går du ikke glipp av den neste.