Å være en moderne DevOps-ingeniør er en alvorlig kompleks rolle fra et teknologiperspektiv.
Det krever at du er kjent med vanlige programmeringsspråk som Node.JS, batch-skript, Python eller batch-skripting. En annen forventning er å forstå hvordan man kan inkorporere testautomatisering i distribusjonsprosessene.
Som kodeintegrator i automatiserte rørledninger må du i det minste kjenne til den grunnleggende funksjonaliteten til ulike skytjenester.
Til tross for denne teknologiske kompleksiteten, er ikke alltid tekniske ferdigheter i forkant av ferdighetene DevOps-ingeniørene mangler. Selv om det forventes å anta at mestring av tekniske ferdigheter er nøkkelen, viser ulike innsikter samlet fra ekte DevOps-utøvere at deres myke ferdigheter ofte er enda viktigere.
Innholdsfortegnelse
Viktige DevOps-ferdigheter
Kilde: devopsuniversity.org
Å se en DevOps-ingeniørs interaksjon i et Scrum-team er ofte en ganske interessant observasjon. Mesteparten av tiden har de svært få detaljer om det konkrete innholdet i historiene resten av teamet implementerer, bare på grunn av teknisk informasjon om konkrete funksjoner i historier for teamet.
Likevel må de være i stand til å inkorporere resultatet fra teamet i én brukbar distribusjonspipeline, sammen med utførelse og validering av ulike automatiserte tester.
Det er her å være en teknisk ekspert på lavt nivå ikke lenger er nok. Kommunikasjon er i ferd med å bli en sentral del av suksessen. Så la oss utforske de viktigste DevOps-ferdighetene som kreves.
Myke ferdigheter
Det er faktisk samarbeidet og diskusjonen i det smidige teamet som er hovedårsaken til at mangelen på myke ferdigheter toppet listen over DevOps-ferdigheter. Hvis du fortsatt lurer på hvorfor, her er noen av de mest fornuftige argumentene:
- DevOps-ingeniører kan ikke være effektive uten tilpasning til resten av utviklingsteamet. Dette teamet bygger grunnlaget for programvaren eller plattformfunksjonene. Det er opp til DevOps-ingeniøren å skape et levende miljø for alt og få det til å fungere.
- Bortsett fra å være synkronisert med sitt eget utviklerteam, er de et sentralt kontaktpunkt for eksterne interessenter som streber etter å få tilgang til programvareplattformen. De må være i stand til å forstå slike forespørsler og oversette all den tekniske kompleksiteten til det automatiserte skymiljøet til ikke-tekniske ekvivalenter slik at interessentene faktisk kan forstå dem. Og være den ultimate mellomvare mellom utviklingsteamet og de eksterne interessentene.
- Mens du vanligvis kan bygge et læringssystem for å tilegne deg spesifikke tekniske ferdigheter, krever modning i de rette myke ferdighetene at du går mye dypere inn i din integritet og personlighet. Å lære å se på deg selv fra et annet perspektiv i tid og identifisere vekstområdene. Dette er ikke noe alle kan gjøre med letthet.
Nettverk
Når du ser på teknologilandskapet til moderne skyplattformer, skal det ikke mye til for å miste deg selv. Du må takle filsystemtjenester, flere databasetjenester, backend-API-er, server- eller serverløse arkitekturer, front-end-tjenester, maskinlæringsmodeller, hybridmiljøer, virtuelle private nettverk, lastbalansere med høy tilgjengelighet, ulike sanntidsstrømmetjenester og mange flere.
Det er umulig å vite alt om alt. Men det er absolutt nødvendig for DevOps-ingeniører å vite hvordan man kobler alt sammen til én funksjonell programvareplattform. Å bygge et sterkt nettverkssamfunn er et must.
Å finne den optimale balansen mellom enkelheten og effektiviteten til distribuert systemkommunikasjon er en utfordring de må være klar over og klare til å gi teamet en løsning.
Vanligvis vet du at infrastrukturen du bygger er moden nok først når du begynner å håndtere sikkerhetsspørsmål og utfordringer på plattformen mer seriøst. Og gjett hva – det er igjen domenet til en DevOps-ingeniør.
I stedet for å holde deg til gamle velprøvde kontakter, må du hele tiden søke etter nye for å dekke den nye tjenesten du nettopp har bedt om av teamet ditt.
Programvaretester
Spesielt i den smidige verden er fleksibilitet i programvareutgivelser avgjørende. Du kan ha et scrum-oppsett med to ukers sprintperioder. Deretter er en ny produksjonsutgivelse annenhver uke en forventning.
Hvis du tenker på hele prosjektets livssyklus som inkluderer planlegging, estimering, utvikling, testing og utgivelse, kan du umulig oppnå det uten seriøs automatisering på så mange av disse trinnene som mulig.
Hovedforutsetningen for å lykkes i dette oppsettet (og til slutt muliggjøre raskere tid å distribuere til produksjon) er et stort fokus på automatisering av testing. Raskere distribusjoner sammen med automatiserte tester resulterer i kortere tid for brukernes tilbakemelding til utviklere.
For en DevOps-ingeniør betyr det integrasjon av ulike testteams utganger i en CI/CD-pipeline:
- Aktiver kjøring av enhetstestskript etter hver repository-commit. Hvis de ikke eksisterer, forhandle med utviklere for å lage dem.
- Inkluder integrasjonstesttilfeller i CI/CD-rørledningene som distribueres til et fullt integrert og konsistent testmiljø. Det gir ikke mening å kjøre integrasjonstester på hvert utviklingsmiljø som utviklerteamet bruker. Integrasjonstestsakene må kjøre feilfritt i miljøet der alle tjenestene er distribuert, og dataene er konsistente.
- Inkorporer virkelige ende-til-ende-testsaker i CI/CD-rørledningen. Gjør det til en obligatorisk kjøring for hver masterkode-distribusjon i integrasjonstesten eller brukergodkjenningstestmiljøet. Dette sikrer at alle viktige og kritiske forretningsprosesser kan kjøre uten feil.
Å skrive effektive testcases på en slik måte at du ikke overdriver, men også dekker alle de kritiske prosessene er en annen utfordring å mestre. DevOps-ingeniører trenger ikke nødvendigvis å være her alene.
Forretningsanalytikere eller kvalitetssikringsledere kan være en del av nettverket (hvis ikke en del av teamet direkte) for å hjelpe med det og definere de nøyaktige trinnene. Men det er da rollen til DevOps-ingeniøren å oversette det til automatisert kjørbar kode.
CI/CD og Infrastruktur som kode
Vi har allerede vært inne på det flere steder. Likevel kan det ikke benektes at IaC (og deretter dens utførelse via CI/CD-rørledninger) er hovedutgangene til DevOps-ingeniører. Det er her alle input fra utviklerteamet (i form av ulike tjenestefunksjoner) kobles sammen med noen reelle infrastrukturmiljøer. Deretter danner de brukbar programvare som en tjenesteutgang, som kan distribueres gjentatte ganger til forskjellige miljøer.
Ikke rart at dette er en av hovedutfordringene for hver DevOps-ingeniør. Enda mer, hvis kravet er å forbli skyagnostisk, betyr dette vanligvis å skrive IaC på Terraform-språket og sikre at koden ikke inneholder skyleverandørspesifikke nyanser. Erfaringen viser det tydelig. Å bytte til skyagnostiske infrastrukturkodeskript kan være en svært vanskelig oppgave, selv for erfarne ingeniører.
Det er ganske umulig å vedlikeholde skyinfrastruktur ved å bruke kun manuelle trinn for distribusjoner. Under tidene på stedet var dette standarden. Men på samme måte var det den bunnsolide standarden å levere via fossemåter å jobbe på. Det er ingen sjanse til å overleve med manuelle distribusjoner i et smidig miljø. Overgangen må gjøres, noe som nesten alltid er smertefullt.
Men når det er gjort ordentlig, er du der.
- Trenger du en produksjonsdistribusjon? Bare kjør utgivelsespipelinen som inneholder kodedistribusjonen til produksjon.
- Trenger du et annet utviklingsmiljø for ikke å overlappe med annet utviklingsarbeid innad i teamet? Deretter finner du utviklingsrørledningen og trykker på Kjør-knappen. All utviklingsinfrastruktur vil bli utført og opprettet automatisk, inkludert testdata.
- Når behovet for en miljøeksistens er borte, kan den samme utviklingspipelinen utføre ødeleggelseskommandoene for alle tjenester som tidligere er distribuert til miljøet.
Det er uunngåelig for et vellykket Agile-team å implementere infrastruktur som en kode og plassere den i CI/CD-rørledninger som kan gjøre jobben når som helst og hver gang. DevOps-ingeniører er her for å levere.
Containerisering
Kilde: aws.amazon.com
I store prosjekter er muligheten for rask replikering avgjørende. Å lage hundrevis av kopier av de samme miljøene på samme tid ville egentlig ikke vært mulig uten containeriserte miljøer. Containerisering er en ferdighet som krever en bratt læringskurve. Det er også grunnen til at bare noen få av prosjektene faktisk bruker det seriøst.
Beholderserveren er en mal som skal brukes så ofte som nødvendig, og utgangen vil alltid være den samme. Identisk infrastruktur og identiske data. Det er en egenskap som bare DevOps-ingeniører kan bygge for teamet. De må lære å lage det ved å bruke forskjellige verktøy.
Beholdere er designet for å enkelt lages og destrueres. DevOps-ingeniører skal implementere containerorkestreringsverktøy som Kubernetes eller Docker Swarm, som automatisk kan administrere containerdistribusjon, skalering og gjenoppretting.
Containere deler samme vertsoperativsystem. Hvis én beholder er kompromittert, kan den potensielt kompromittere andre beholdere på samme vert. Dessuten, hvis containere er bygget fra tredjepartsbilder, kan de inneholde sårbarheter inne i koden. DevOps-ingeniører skal gjøre en innsats for å implementere sikkerhetsfunksjoner som beholderisolering, tilgangskontroll og sårbarhetsskanning for å redusere disse risikoene.
Skalerbarhet er en annen innebygd egenskap til containere. Du kan enkelt skalere dem horisontalt for å håndtere den økte arbeidsmengden. Dette kan føre til ressursstrid og ytelsesproblemer. DevOps-ingeniører skal implementere ressursstyringsverktøy som cgroups eller Kubernetes ressurskvoter, som kan begrense antall ressurser som hver container kan forbruke.
DevOps-ingeniører må næ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. Det er også grunnen til at bare noen få av prosjektene faktisk bruker det seriøst.
Konklusjon
DevOps-utøver er et unikt medlem av ditt smidige team. Du har kanskje bare én eller to av dem for hele prosjektet, men selv da vil de være avgjørende for suksessen.
Forventningene fra DevOps-ingeniørene er høye, siden de må være i mange roller samtidig:
- De må være sterke tekniske utviklere,
- lagspillere fulle av empati, forståelse og samarbeidsklare,
- effektiv mellomvare mellom utviklingsteamet og ikke-tekniske eksterne interessenter,
- koble hele teamet på automatisering og kodetestverifikasjoner,
- muliggjør de vanlige utgivelsene av prosjektet,
- og konsekvent bygge et nettverk av eksperter som endrer seg fra dag til dag.
Til tross for all den tekniske kompleksiteten, er det det menneskelige elementet som spiller en avgjørende rolle for suksessen til ethvert DevOps-initiativ. Hvis du er på nippet til å bli en av dem, har du full rett til å være stolt av avgjørelsen din og ta utdanningstilnærmingen fra et mye bredere perspektiv, og ikke begrense deg til kun teknisk kunnskap.
Deretter kan du sjekke ut ofte stilte DevOps-intervjuspørsmål og svar.