«`html
Å arbeide som en moderne DevOps-ingeniør innebærer et betydelig teknologisk kompleksitetsnivå.
Rollen krever kjennskap til populære programmeringsspråk som Node.JS, Python og skriptspråk. I tillegg forventes det at man forstår hvordan testautomatisering kan integreres i distribusjonsprosessene.
Som en integrator av kode i automatiserte pipelines, er det essensielt å ha innsikt i grunnleggende funksjonalitet i diverse skytjenester.
Til tross for denne tekniske kompleksiteten, er det ikke alltid de tekniske ferdighetene som er mest mangelfulle hos DevOps-ingeniører. Selv om det er naturlig å anta at mestring av tekniske ferdigheter er avgjørende, tyder erfaringer fra DevOps-eksperter på at de myke ferdighetene ofte er enda viktigere.
Viktige DevOps-kompetanser
Kilde: devopsuniversity.org
Det er ofte interessant å observere en DevOps-ingeniørs samhandling i et Scrum-team. Ofte har de begrenset informasjon om det spesifikke innholdet i historiene som resten av teamet implementerer, primært på grunn av teknisk fokus på funksjoner i historiene for teamet.
Likevel må de kunne integrere teamets arbeid i en velfungerende distribusjons-pipeline, inkludert utførelse og validering av forskjellige automatiserte tester.
Her blir det tydelig at teknisk ekspertise på lavt nivå ikke lenger er tilstrekkelig. Kommunikasjon blir en sentral faktor for suksess. La oss se nærmere på de viktigste DevOps-kompetansene som er nødvendige.
Myke ferdigheter
Samarbeid og diskusjoner i det smidige teamet er hovedårsaken til at mangel på myke ferdigheter ofte nevnes som en kritisk utfordring for DevOps-ingeniører. Hvis du fremdeles lurer på hvorfor, er her noen av de mest overbevisende argumentene:
- DevOps-ingeniører kan ikke være effektive uten å være tilpasset resten av utviklingsteamet. Dette teamet legger grunnlaget for programvaren eller plattformens funksjoner. Det er DevOps-ingeniørens ansvar å skape et operasjonelt miljø for alt dette, og sørge for at det fungerer.
- I tillegg til å være synkronisert med sitt eget utviklerteam, fungerer de som et viktig kontaktpunkt for eksterne interessenter som ønsker tilgang til programvareplattformen. De må kunne forstå slike forespørsler og oversette all den tekniske kompleksiteten i det automatiserte skymiljøet til enkle begreper som interessentene forstår. De fungerer som en viktig bro mellom utviklingsteamet og de eksterne interessentene.
- Mens man vanligvis kan utvikle et læringssystem for å tilegne seg spesifikke tekniske ferdigheter, krever utvikling av de rette myke ferdighetene at man går dypere inn i sin egen integritet og personlighet. Det handler om å lære å se seg selv fra et annet perspektiv over tid og identifisere områder for vekst. Dette er ikke like lett for alle.
Nettverksbygging
I det teknologiske landskapet for moderne skyplattformer, er det lett å miste oversikten. Man må håndtere filsystemtjenester, flere databasetjenester, backend-APIer, server- eller serverløse arkitekturer, front-end tjenester, maskinlæringsmodeller, hybridmiljøer, virtuelle private nettverk, lastbalansere med høy tilgjengelighet, diverse sanntidsstrømmetjenester og mye mer.
Det er umulig å være ekspert på alt, men det er avgjørende for DevOps-ingeniører å forstå hvordan alt henger sammen for å skape en fungerende programvareplattform. Å bygge et sterkt nettverk er derfor essensielt.
Det å finne den optimale balansen mellom enkelhet og effektivitet i distribuert systemkommunikasjon er en utfordring de må være bevisste på, og klare til å gi teamet en løsning.
Vanligvis vet man at infrastrukturen man bygger er moden når man begynner å håndtere sikkerhetsspørsmål og -utfordringer på plattformen mer seriøst. Og gjett hvem som har ansvaret her – det er igjen DevOps-ingeniøren.
I stedet for å holde fast ved gamle kontakter, må man hele tiden søke etter nye for å kunne håndtere nye tjenester som teamet etterspør.
Programvaretesting
Særlig i den smidige verden er fleksibilitet i programvareutgivelser avgjørende. Et typisk Scrum-oppsett innebærer ofte sprintperioder på to uker, hvor en ny produksjonsutgivelse forventes annenhver uke.
Om man tenker på hele prosjektets livssyklus, som inkluderer planlegging, estimering, utvikling, testing og utgivelse, er det umulig å oppnå dette uten omfattende automatisering av så mange av disse trinnene som mulig.
Hovedforutsetningen for å lykkes med dette (og dermed muliggjøre raskere distribusjon til produksjon) er et sterkt fokus på automatisering av testing. Raskere distribusjoner sammen med automatiserte tester fører til kortere tilbakemeldingssløyfer fra brukere til utviklere.
For en DevOps-ingeniør betyr dette integrering av ulike testteams resultater i en CI/CD-pipeline:
- Aktivere kjøring av enhetstestskript etter hver endring i repository. Hvis de ikke eksisterer, bør man forhandle med utviklere om å lage dem.
- Inkluder integrasjonstesttilfeller i CI/CD-pipelinene som distribueres til et fullt integrert og konsistent testmiljø. Det gir ikke mening å kjøre integrasjonstester i hvert utviklingsmiljø som utviklerteamet bruker. Integrasjonstestene må kjøre feilfritt i miljøet der alle tjenestene er distribuert, og dataene er konsistente.
- Inkluder virkelige ende-til-ende-tester i CI/CD-pipelinen. Gjør det obligatorisk for hver distribusjon til integrasjonstest- eller brukeraksepttestmiljøet. Dette sikrer at alle viktige og kritiske forretningsprosesser kjører feilfritt.
Å skrive effektive testcases som dekker alle kritiske prosesser uten å overdrive, er nok en utfordring å mestre. DevOps-ingeniører trenger ikke nødvendigvis å gjøre dette alene.
Forretningsanalytikere eller kvalitetssikringsledere kan være en del av nettverket (eller teamet) for å bistå med dette og definere de nøyaktige trinnene. Det er imidlertid DevOps-ingeniørens oppgave å oversette dette til automatiserbar kode.
CI/CD og Infrastruktur som kode
Vi har allerede berørt dette flere ganger. Det kan likevel ikke benektes at IaC (og utførelsen av den gjennom CI/CD-pipelines) er kjerneoppgavene for DevOps-ingeniører. Det er her alle bidrag fra utviklerteamet (i form av diverse tjenestefunksjoner) kobles sammen med faktiske infrastrukturmiljøer. Dette resulterer i fungerende programvare som en tjeneste, som kan distribueres gjentatte ganger til forskjellige miljøer.
Det er ikke overraskende at dette er en av hovedutfordringene for enhver DevOps-ingeniør. Spesielt hvis målet er å være skyagnostisk, innebærer dette vanligvis å skrive IaC i Terraform, og sørge for at koden ikke inneholder skyleverandørspesifikke detaljer. Erfaring viser at overgang til skyagnostiske infrastrukturkodeskript kan være svært krevende, selv for erfarne ingeniører.
Det er praktisk talt umulig å vedlikeholde skyinfrastruktur kun ved bruk av manuelle distribusjonstrinn. Tidligere var dette standarden, men det var også standard å jobbe etter fossefallsmetoden. Det er ikke mulig å overleve med manuelle distribusjoner i et smidig miljø. Overgangen må gjøres, selv om den nesten alltid er smertefull.
Men når det er gjort ordentlig, er man godt rustet.
- Trenger du en produksjonsdistribusjon? Bare kjør utgivelses-pipelinen som inneholder kodedistribusjonen til produksjon.
- Trenger du et annet utviklingsmiljø for å unngå konflikter med annet utviklingsarbeid i teamet? Bare finn utviklings-pipelinen og trykk på «Kjør»-knappen. All utviklingsinfrastruktur vil bli automatisk opprettet, inkludert testdata.
- Når behovet for et miljø er borte, kan den samme utviklingspipelinen utføre slettekommandoer for alle tjenester som tidligere er distribuert til miljøet.
Det er uunngåelig for et vellykket smidig team å implementere infrastruktur som kode, og plassere den i CI/CD-pipelines som kan utføre jobben når som helst. DevOps-ingeniører er ansvarlige for å levere dette.
Containerisering
Kilde: aws.amazon.com
I store prosjekter er muligheten for rask replikering avgjørende. Å lage hundrevis av kopier av de samme miljøene samtidig ville ikke vært mulig uten containeriserte miljøer. Containerisering er en ferdighet som krever en bratt læringskurve, og det er også grunnen til at bare noen få prosjekter faktisk bruker det på en seriøs måte.
En container er en mal som kan brukes så ofte som nødvendig, og resultatet vil alltid være det samme – identisk infrastruktur og identiske data. Dette er en egenskap som kun DevOps-ingeniører kan bygge for teamet. De må lære å lage dette ved hjelp av forskjellige verktøy.
Containere er designet for å enkelt kunne opprettes og slettes. DevOps-ingeniører bør implementere containerorkestreringsverktøy som Kubernetes eller Docker Swarm, som automatisk kan administrere containerdistribusjon, skalering og gjenoppretting.
Containere deler samme vertsoperativsystem. Hvis en container er kompromittert, kan det potensielt kompromittere andre containere på samme vert. Hvis containere er bygget fra tredjepartsbilder, kan de i tillegg inneholde sårbarheter i koden. DevOps-ingeniører bør implementere sikkerhetsfunksjoner som containerisolering, tilgangskontroll og sårbarhetsskanning for å redusere disse risikoene.
Skalerbarhet er en annen innebygd egenskap ved containere. Du kan enkelt skalere dem horisontalt for å håndtere økt arbeidsbelastning. Dette kan imidlertid føre til ressurskonflikter og ytelsesproblemer. DevOps-ingeniører bør implementere verktøy for ressursstyring som cgroups eller Kubernetes ressurskvoter, som kan begrense ressurser som hver container kan forbruke.
DevOps-ingeniører må tilnærme seg containerisering med sikkerhet, skalerbarhet og robusthet i tankene. Blant alle de andre tekniske ferdighetene, krever mestring av containerisering en spesielt bratt læringskurve. Kompleksiteten er rett og slett for høy, og det er også grunnen til at det kun er noen få prosjekter som bruker det på en seriøs måte.
Konklusjon
En DevOps-utøver er et unikt medlem av et smidig team. Det er ofte bare én eller to av dem for hele prosjektet, men de er likevel avgjørende for suksessen.
Forventningene til DevOps-ingeniører er høye, da de må fylle mange roller samtidig:
- De må være sterke tekniske utviklere,
- lagspillere fulle av empati, forståelse og samarbeidsvilje,
- fungere som en effektiv bro mellom utviklingsteamet og ikke-tekniske eksterne interessenter,
- integrere hele teamet med automatisering og kodetestverifikasjoner,
- muliggjøre jevnlige utgivelser av prosjektet,
- og kontinuerlig bygge et nettverk av eksperter som endrer seg fra dag til dag.
Til tross for all den tekniske kompleksiteten, er det det menneskelige aspektet som spiller en avgjørende rolle for suksessen til ethvert DevOps-initiativ. Hvis du vurderer å bli en av dem, har du all grunn til å være stolt av avgjørelsen din, og du bør ta en utdanningsmessig tilnærming fra et mye bredere perspektiv, og ikke begrense deg til bare teknisk kunnskap.
Du kan eventuelt sjekke ut vanlige spørsmål og svar i forbindelse med DevOps-intervjuer.
«`