5 färdigheter som alla DevOps-ingenjörer borde ha

Att vara en modern DevOps-ingenjör är en allvarligt komplex roll ur ett tekniskt perspektiv.

Det kräver att du är bekant med vanliga programmeringsspråk som Node.JS, batchskript, Python eller batchskript. En annan förväntan är att förstå hur man integrerar testautomatisering i distributionsprocesserna.

Som kodintegratör i automatiserade pipelines behöver du åtminstone känna till den grundläggande funktionaliteten hos olika molntjänster.

Trots denna tekniska komplexitet är tekniska färdigheter inte alltid i framkant av de färdigheter DevOps ingenjörer saknar. Även om man skulle förvänta sig att bemästra tekniska färdigheter är nyckeln, visar olika insikter från riktiga DevOps-utövare att deras mjuka färdigheter ofta är ännu viktigare.

Viktiga DevOps-färdigheter

Källa: devopsuniversity.org

Att se en DevOps-ingenjörs interaktion i ett Scrum-team är ofta en ganska intressant observation. För det mesta har de väldigt lite detaljer om det konkreta innehållet i berättelserna som resten av teamet implementerar, bara på grund av teknisk information om konkreta funktioner i berättelserna för teamet.

Ändå måste de kunna införliva resultatet från teamet i en fungerande distributionspipeline, tillsammans med exekvering och validering av olika automatiserade tester.

Här räcker det inte längre att vara en teknisk expert på låg nivå. Kommunikation blir en viktig del av framgången. Så låt oss utforska de viktigaste DevOps-färdigheterna som krävs.

Mjuka färdigheter

Det är verkligen samarbetet och diskussionen inom det agila teamet som är huvudorsaken till att bristen på mjuka färdigheter toppade listan över DevOps-färdigheter. Om du fortfarande undrar varför, här är några av de mest sunda argumenten:

  • DevOps-ingenjörer kan inte vara effektiva utan anpassning till resten av utvecklingsteamet. Detta team bygger grunden för programvaran eller plattformsfunktionerna. Det är upp till DevOps-ingenjören att skapa en livemiljö för allt och få det att fungera.
  • Förutom att de är i synk med sitt eget utvecklarteam, är de en viktig kontaktpunkt för externa intressenter som strävar efter att få tillgång till mjukvaruplattformen. De måste vara kapabla att förstå sådana förfrågningar och översätta all teknisk komplexitet i den automatiserade molnmiljön till icke-tekniska motsvarigheter så att intressenterna faktiskt kan förstå dem. Och vara den ultimata mellanvaran mellan utvecklingsteamet och de externa intressenterna.
  • Även om du vanligtvis kan bygga ett inlärningssystem för att förvärva specifika tekniska färdigheter, kräver att du mognar i rätt mjuka färdigheter att du går mycket djupare in i din integritet och personlighet. Att lära sig att se på sig själv ur ett annat perspektiv i tiden och identifiera tillväxtområdena. Detta är inte något alla kan göra med lätthet.

Nätverk

När du tittar på tekniklandskapet för moderna molnplattformar krävs det inte mycket för att förlora dig själv. Du måste klara av filsystemtjänster, flera databastjänster, backend-API:er, server- eller serverlösa arkitekturer, front-end-tjänster, maskininlärningsmodeller, hybridmiljöer, virtuella privata nätverk, belastningsutjämnare med hög tillgänglighet, olika streamingtjänster i realtid och många fler.

Det är omöjligt att veta allt om allt. Men det är absolut nödvändigt för DevOps-ingenjörer att veta hur man kopplar allt till en funktionell mjukvaruplattform. Att bygga en stark nätverksgemenskap är ett måste.

Att hitta den optimala balansen mellan enkelheten och effektiviteten i distribuerad systemkommunikation är en utmaning de behöver vara medvetna om och redo att ge teamet en lösning på.

Vanligtvis vet du att infrastrukturen du bygger är mogen nog först när du börjar ta itu med säkerhetsfrågor och utmaningar på plattformen på allvar. Och gissa vad – det är återigen domänen för en DevOps-ingenjör.

Istället för att hålla fast vid gamla beprövade kontakter måste du ständigt söka efter nya för att täcka den nya tjänsten som ditt team just efterfrågat.

Programvarutest

Speciellt i den agila världen är flexibilitet i programvaruversioner avgörande. Du kanske har ett scrum-upplägg med två veckors sprintperioder. Sedan är en ny produktionssläpp varannan vecka en förväntan.

Om du tänker på hela projektets livscykel som inkluderar planering, uppskattning, utveckling, testning och frisläppande, kan du omöjligt uppnå det utan seriös automatisering av så många av dessa steg som möjligt.

Den främsta förutsättningen för framgång i denna installation (och för att i slutändan möjliggöra snabbare tid att distribuera till produktion) är ett stort fokus på automatisering av testning. Snabbare implementeringar tillsammans med automatiserade tester resulterar i en kortare tid för användarnas feedback till utvecklare.

För en DevOps-ingenjör innebär det integrering av olika testteams utdata i en CI/CD-pipeline:

  • Aktivera exekvering av enhetstestskript efter varje repository-commit. Om de inte finns, förhandla med utvecklare för att skapa dem.
  • Inkludera integreringstestfall i CI/CD-pipelines som distribueras till en helt integrerad och konsekvent testmiljö. Det är inte vettigt att köra integrationstester på alla utvecklingsmiljöer som utvecklarteamet använder. Integrationstestfallen måste fungera felfritt i miljön där alla tjänster är utplacerade och data är konsekventa.
  • Inkorporera verkliga end-to-end-testfall i CI/CD-pipelinen. Gör det till en obligatorisk körning för varje huvudkoddistribution i integrationstestet eller testmiljön för användaracceptans. Detta säkerställer att alla viktiga och kritiska affärsprocesser kan köras utan fel.

Att skriva effektiva testfall på ett sådant sätt att du inte överdriver utan också täcker alla kritiska processer är en annan utmaning att bemästra. DevOps-ingenjörer behöver inte nödvändigtvis vara här ensamma.

Affärsanalytiker eller kvalitetssäkringschefer kan vara en del av nätverket (om inte en del av teamet direkt) för att hjälpa till med det och definiera de exakta stegen. Men det är då DevOps-ingenjörens roll att översätta det till automatiserad körbar kod.

CI/CD och Infrastruktur som kod

Vi har redan berört det på flera ställen. Ändå går det inte att förneka att IaC (och därefter dess exekvering via CI/CD-pipelines) är DevOps-ingenjörernas huvudutgångar. Det är här alla ingångar från dev-teamet (i form av olika tjänstefunktioner) kopplas ihop med några riktiga infrastrukturmiljöer. Sedan bildar de användbar programvara som en tjänsteutgång, som kan distribueras upprepade gånger till olika miljöer.

Inte konstigt att detta är en av de största utmaningarna för varje DevOps-ingenjör. Ännu mer så, om kravet är att förbli moln-agnostisk, innebär detta vanligtvis att skriva IaC på Terraform-språket och se till att koden inte innehåller molnleverantörsspecifika nyanser. Erfarenheten visar det tydligt. Att byta till moln-agnostiska infrastrukturkodskript kan vara en mycket svår uppgift, även för erfarna ingenjörer.

Det är helt omöjligt att underhålla molninfrastruktur med enbart manuella steg för implementeringar. Under tiderna på plats var detta standarden. Men på samma sätt var det den stenhårda standarden att leverera via vattenfall arbetssätt. Det finns ingen chans att överleva med manuella distributioner i en agil miljö. Övergången måste göras, vilket nästan alltid är smärtsamt.

Men när det väl är gjort ordentligt är du där.

  • Behöver du en produktionsinstallation? Kör bara releasepipelinen som innehåller koddistributionen till produktion.
  • Behöver du en annan utvecklingsmiljö för att inte överlappa med annat utvecklingsarbete inom teamet? Hitta sedan utvecklingspipen och tryck på Kör-knappen. All utvecklingsinfrastruktur kommer att exekveras och skapas automatiskt, inklusive testdata.
  • När väl behovet av att existera en miljö är borta, kan samma utvecklingspipeline utföra förstörelsekommandon för alla tjänster som tidigare distribuerats till miljön.

Det är oundvikligt för ett framgångsrikt agilt team att implementera infrastruktur som en kod och placera den i CI/CD-pipelines som kan göra jobbet när som helst och varje gång. DevOps-ingenjörer är här för att leverera.

Containerisering

Källa: aws.amazon.com

I storskaliga projekt är möjligheten att replikera snabbt avgörande. Att göra hundratals kopior av samma miljöer samtidigt skulle inte vara riktigt möjligt utan containeriserade miljöer. Containerisering är en färdighet som kräver en brant inlärningskurva. Det är också anledningen till att bara ett fåtal av projekten faktiskt använder det på allvar.

Behållarservern är en mall att applicera så ofta som behövs, och utgången kommer alltid att vara densamma. Identisk infrastruktur och identisk data. Det är en egenskap som bara DevOps-ingenjörer kan bygga för teamet. De måste lära sig hur man skapar det med olika verktyg.

Behållare är designade för att lätt kunna skapas och förstöras. DevOps-ingenjörer ska implementera containerorkestreringsverktyg som Kubernetes eller Docker Swarm, som automatiskt kan hantera containerdistribution, skalning och återställning.

Behållare delar samma värdoperativsystem. Om en behållare äventyras kan den potentiellt äventyra andra behållare på samma värd. Om behållare är byggda från tredjepartsbilder kan de också innehålla sårbarheter i koden. DevOps-ingenjörer ska anstränga sig för att implementera säkerhetsfunktioner som containerisolering, åtkomstkontroll och sårbarhetsskanning för att minska dessa risker.

Skalbarhet är en annan inbyggd egenskap hos behållare. Du kan enkelt skala dem horisontellt för att hantera den ökade arbetsbelastningen. Detta kan leda till resursstridigheter och prestandaproblem. DevOps-ingenjörer ska implementera resurshanteringsverktyg som cgroups eller Kubernetes resurskvoter, vilket kan begränsa antalet resurser som varje container kan konsumera.

DevOps-ingenjörer måste närma sig containerisering med säkerhet, skalbarhet och motståndskraft i åtanke. Bland alla andra tekniska färdigheter kräver att bemästra containerisering en särskilt brant inlärningskurva. Komplexiteten är helt enkelt för hög. Det är också anledningen till att bara ett fåtal av projekten faktiskt använder det på allvar.

Slutsats

DevOps-utövaren är en unik medlem av ditt agila team. Du kanske bara har en eller två av dem för hela projektet, men även då kommer de att vara avgörande för framgången.

Förväntningarna från DevOps-ingenjörer är höga, eftersom de måste vara i många roller samtidigt:

  • De måste vara starka tekniska utvecklare,
  • lagspelare fulla av empati, förståelse och samarbetsvilliga,
  • effektiv mellanvara mellan utvecklingsteamet och icke-tekniska externa intressenter,
  • koppla ihop hela teamet på automatisering och verifieringar av kodtest,
  • möjliggör regelbundna utgivningar av projektet,
  • och konsekvent bygga ett nätverk av experter som förändras från dag till dag.

Trots all teknisk komplexitet är det det mänskliga elementet som spelar en avgörande roll för framgången för alla DevOps-initiativ. Om du är på väg att bli en av dem har du full rätt att vara stolt över ditt beslut och ta utbildningsstrategin från ett mycket bredare perspektiv, inte begränsa dig till enbart teknisk kunskap.

Kolla sedan in vanliga DevOps-intervjufrågor och svar.