Selvom PaaS-løsninger ("Platform as a Service") i sig selv ikke kan ændre måden, hvorpå individer og teams interagerer, fungerer de ofte som en katalysator for organisatoriske ændringer som reaktion på den øgede fleksibilitet inden for it-teknologier.
I praksis er den maksimale udnyttelse af investeringer i PaaS ofte kun mulig, når der sker ændringer i organisatoriske roller, ansvarsområder og relationsstrukturer. Heldigvis har PaaS-løsninger som OpenShift Container Platform en tilstrækkelig fleksibilitet til, at hver it-organisation selv kan bestemme hastigheden og omfanget af forandringer i forhold til de involverede personer og de processer, der finder sted.
I den første fase af virksomhedens containerisering er det primære fokus at implementere en containerplatform som et nyt system til udrulning af applikationer. På dette tidspunkt knytter organisationer de velkendte opgaver til de kendte roller for at reagere på standardanmodninger fra udviklingsteams vedrørende spørgsmål som lagringssystemer, udrulningsmiljøer og lignende. I de følgende faser af containerisering handler det om at automatisere eller give udviklerne muligheder for selvbetjening for at mindske belastningen på systemadministratorerne og hæve autonomi og effektivitet for udviklerne til et højere niveau. På denne måde begynder organisationen at bevæge sig mod DevOps. I den afsluttende fase af virksomhedens containerisering når man til en renere, kanonisk model for DevOps, hvor mange af de tidligere opgaver og aktiviteter overgår til tværfunktionelle teams, som grupperer ikke efter platforme eller teknologier, men i forhold til at sikre drift af anvendelser eller applikationstjenester.
I dette indlæg vil vi præsentere en guide til de nødvendige organisatoriske ændringer og forklare, hvordan traditionelle it-roller ændres med implementeringen af containerteknologier i virksomheden.
Tilpasning af nye opgaver til gamle roller
I sin grundlæggende, indledende form oprettes PaaS-organisationsmodellen for mere fleksibelt og hurtigt at tildele IT-ressourcer til applikationer som en køreplatform. Selvom dette giver visse fordele til systemadministratorer, får udviklere generelt ikke nogen væsentlige fordele eller nye muligheder, da virksomheden på dette tidspunkt kan klare sig uden at begynde automatisering, indføre selvbetjening eller dramatisk forbedre implementeringsprocessen. Selvom PaaS kun minimal påvirker udviklingsprocesserne på dette stadium, øger det imidlertid IT-systemets dynamik, hvilket giver administratorer bedre mulighed for at imødekomme udviklernes anmodninger. For eksempel, hvis det tidligere kunne tage dage eller endda uger at oprette et udviklingsmiljø af flere virtual machines og lagringsvolumener, krævede det deltagelse af flere forskellige administratorer. Med PaaS gøres det dog meget hurtigere og kun af en administrator. Med andre ord indsender udviklingsteamene anmodninger som før, men arbejdet med at udføre disse anmodninger udføres nu efter en ny metode.
På vejen til en DevOps-organisation
Kan en organisation fortsætte med at implementere DevOps-metodologien ved at starte PaaS og overføre IT-systemdriftseksperter og applikationsudviklere til den, som blandt andet inkluderer følgende grundlæggende principper:
- At opdele arbejdet i små faser, for at få feedback tidligt, reducere risici og undgå "analytisk lammelse";
- At automatisere operationer i tilstrækkelig grad, for ikke at skabe hindringer eller flaskehalse i applikationsimplementeringsprocessen;
- Vidensdeling er nøglen til at opbygge tillid;
- At betale tekniske gæld regelmæssigt, ved at afsætte tid til systematiske forbedringer i hver arbejdscyklus.
I det andet trin i implementeringen af containerteknologierne begynder udviklingsteamene naturligvis at se muligheder for forbedringer, og virksomheden læner sig mod en mere kanonisk DevOps-model. Den traditionelle mekanisme med indgivelse og udførelse af serviceanmodninger opfattes nu som en flaskehals, derfor stræber organisationen efter at automatisere gentagne handlinger og give udviklerne selvbetjeningsmuligheder. Desuden defineres disse udvikleres muligheder inden for hver enkelt anmodning gennem et samarbejde mellem IT-specialister, der håndterer driftsplatforme, og dem, der har ansvaret for applikationslevering. Med andre ord kommer de to ovennævnte kategorier af medarbejdere, som har ansvaret for at beskrive og anvende politikker, som regulerer, hvad udviklerne har lov til at gøre selv, i stedet for systemadministratorerne, der udfører udviklernes anmodninger. Automatiserede procedurer hjælper med at sikre overholdelse af disse krav og koordinerer handlinger i de tilfælde, hvor situationen går uden for de gældende politikker.
Overgangen til en iterativ tidsplan, hvor IT-miljøet og driftsmodellen undergår iterative ændringer over tid, er en kritisk milepæl i opbygningen af et modent DevOps-system i virksomheden. Graden af accept af DevOps-metodologi afhænger af den enkelte organisations tolerance over for ændringer og af hvilke ændringer, der giver den største fordel. For eksempel, hvis behovet for at oprette nye miljøer eller applikationer sjældent opstår, vil optimering af de relevante handlinger være mindre vigtig end styrkelsen af udviklernes kontrol over applikationslivscyklussen.
Nye opgaver, der opstår i IT-organisationer ved overgangen til OpenShift
I dette afsnit vil vi se på de roller og opgaver, som organisationer, der er overgået til OpenShift, typisk anvender for at fremskynde automatisering og selvbetjening ved hjælp af teknologier og PaaS.
Nedenfor er en liste over de vigtigste opgaver på højeste niveau, der findes i enhver organisation, der har implementeret OpenShift, med eksempler på relevante opgaver og færdigheder. Denne liste over opgaver skal ikke forveksles med en arbejdsfordeling eller organisationsstruktur for teams; det er blot en samling af opgaver, der skal løses af de personer, der er ansvarlige for at støtte IT-miljøet, for en vellykket implementering af containerplatformen. Faktisk vil vi senere vise, at implementeringen af containerteknologier skaber forudsætninger for at udvikle en mere moden DevOps-strategi i virksomheden, hvilket igen øger graden af tværfunktionalitet blandt teams og reducerer risici for snæver specialisering på niveau med både individuelle medarbejdere og teams.
Tabel 1. Definitioner af OpenShift-opgaver
Opgaver
Nødvendige færdigheder
Automatisering og provisioning af IT-infrastrukturer
Opgaver:
- Design og opbygning af hardwareløsninger
- Organisering og vedligeholdelse af automatisering af den indledende opsætning
- Design og automatisering af VM- og hostforberedelse
- Design og implementering af datacentre
- Systemadministration af Linux
- Automatiseringsscenarier
- Kendskab til lagringssystemer
- Kendskab til design og implementering af netværk
- Sikkerhed
Installation og administration af OpenShift-platformen
Opgaver:
- Udførelse af klyngeinstallation
- Håndtering af infrastrukturtjenester
- Håndtering af platformens skalering
- Godkendelse og autorisation på platformniveau
- Systemadministration af Linux
- Kendskab til netværksteknologier
- Automatiseringsscenarier (Ansible)
- Kendskab til lagringssystemer
- Kendskab til containerteknologier og arkitekturer
- Kendskab til Kubernetes- og OpenShift-arkitekturer
- Platformssikkerhed
- Integration af overvågning
Håndtering af oprettelse af klientmiljøer (tenant provisioning) og isolering med IT-ressourcer
Opgaver:
- Oprettelse af brugere og teams inden for platformen
- Design og administration af kvoter
- Design og implementering af RBAC
- Kendskab til Kubernetes- og OpenShift-arkitekturer
- Kendskab til containerteknologier og arkitekturer
- Automatiseringsscenarier
- Gode kendskaber til projekter, kvoter, rollebind og arbejdet med planlæggere
Bygning og administration af grundlæggende billeder
Opgaver:
- Udvikling af arbejdsprocesser for ændring af billeder
- Udvikling af billeder baseret på standarder
- Systemadministration af Linux
- Automatiseringsscenarier
- Konfiguration af runtime-komponenter til applikationer og middleware
- Kendskab til containerarkitekturer
- Applikationsbygningsrammer
- Gode kendskaber til billeder, imagestreams og skabeloner
Design og administration af implementerings pipelines
Opgaver:
- Design og dokumentation af pipeline standarder
- Udvikling af korte vejledninger og skabeloner
- Uddannelse af udviklere
- Håndtering af kildekode
- Design og implementering af applikationer
- Automatiseringsscenarier
- Automatiseret testning
- Kvalitetstestning af kode
- Kendskab til containerarkitekturer
- Viden om immutable infrastruktur
- Sikkerhed – håndtering af adgang til pipeline trin, godkendelse af workflows osv.
- God viden om OpenShift skabeloner, buildconfigs, deploymentconfigs, tjenester, ruter, configmaps
Udvikling af applikationer og tests
Opgaver:
- Kodning af applikationer
- Udvikling af automatiserede tests
- Reaktion på testfejl under implementerings pipeline
- Reaktion på applikationsfejl
- Brugeraccepttestning
- Design og implementering af applikationer
- Automatiseret testning
- Håndtering af kildekode
- Overvågning af applikationer
- Viden om arkitekturer for cloud native applikationer
Operationel overvågning og administration af applikationer
Opgaver:
- Design af applikationer med fokus på ydeevne
- Overvågning af applikationer under udførelse
- Skalering af applikationer (eller automatisk skalering)
- Håndtering af applikations tilgængelighed
- Forespørgsels kvoter og ressourcebegrænsninger
- Ydelsestestning og IT-kapacitetstestning
- Design og implementering af applikationsydelse
- Overvågning af applikationsydelse
- Ydelsestestning og belastningstestning
Brugeraccepttestning
Opgaver:
- UI testning (design og brugerinteraktion)
- Udvikling af automatiserede tests
- Design og validering af brugergrænseflader
- Skabeloner for automatiserede tests
- Testframeworks
- Designmønstre for applikationer
Nye roller, der opstår i IT-organisationen ved overgangen til OpenShift
Ved overgangen til en DevOps-orienteret organisationsmodel reduceres specialiseringen af roller generelt, mens antallet af tværfaglige teams og roller stiger for at maksimere samarbejdets effektivitet. Her er, hvordan vi mener, at listen over nøglepositioner i en IT-organisation, der bruger OpenShift, ser ud:
- Applikationsdriftsingeniør (Application Operations Engineer) ELLER Site Reliability Engineer. Tidligere kunne denne position kaldes "Applikationsserveradministrator".
- Applikationsudvikler/softwareudvikler/programmeringsingeniør.
- Cluster-/applikationsplatformadministrator. Tidligere kunne denne rolle kaldes "Systemadministrator" eller "Linux-platformadministrator".
- Softwareudgivelsesansvarlig (Release Manager)/Bygningsingeniør (Build Engineer).
RACI-roller og opgave matrix
Endelig går vi videre til at matche de ovenfor nævnte positioner og opgaver for at give et generelt indtryk af, hvordan strukturen skal se ud i en organisation, der implementerer DevOps på OpenShift-platformen. De roller, der er angivet nedenfor, kan oprindeligt udføres af forskellige grene af den gamle, traditionelle organisationsstruktur. Men over tid sker der en konsolidering, og der opstår nye teams, der er bygget rundt om applikationer og som påtager sig de fleste, eller endda alle, af de opgaver, der er nævnt nedenfor.
Opgaver
Roller
Applikationsdriftsingeniør / Site Reliability Engineer
Applikationsudvikler / Softwareudvikler / Programmør
Cluster-/applikationsplatformadministrator
Softwareudgivelsesansvarlig / Bygningsingeniør
Automatisering og provisioning af IT-infrastrukturer
I
I
R/A
C
Installation og administration af OpenShift-platformen
C
I
R/A
C
Design og administration af implementerings pipelines
C
C
I
R/A
Forvaltning af forberedelse af kundemiljøer (tenant provisioning), isolation og IT-ressourcer
C
I
R/A
I
Bygning og administration af grundlæggende billeder
R
C
R/A
C
Udvikling af applikationer og tests
C
R/A
I
I
Operationel overvågning og administration af applikationer
R/A
C
C
I
Brugeraccepttestning
C
R
I
I
Betegnelser i RACI-matrixen
Kilde:
- Responsible – Udøver – den, der udfører det nødvendige for at fuldføre opgaven.
- Accountable – Ansvarlig – den medarbejder, der i sidste ende er ansvarlig for korrekt og grundig udførelse af opgaven eller opnåelse af resultatet; og den eneste, der kan delegere arbejdet til udøverne.
- Consulted – Konsulenter – Det er typisk eksperter inden for emnet, hvis råd bliver anmodet; der opretholdes tovejs kommunikation med dem.
- Informed – Informeres – personer der holdes opdateret (nogle gange kun efter opgaven er fuldført eller resultatet er opnået); de modtager information ensidigt.
Hvordan teams arbejder sammen i en DevOps-organisation
Den traditionelle model for ressourceindhentning er normalt en cyklus af anmodninger om tildeling af ressourcer, som derefter udføres af flere teams. I sidste ende bliver alle nødvendige ressourcer tildelt og bekræftet af den anmodende part. Ofte udføres disse processer delvist eller helt manuelt og kræver hyppige og gentagne interaktioner mellem teams for at behandle hver anmodning med succes.
Figur 1. Traditionel IT-organisation
Diagrammet ovenfor viser typiske relationer mellem teams i en traditionel IT-organisation. Inden for denne skema henvender nogle teams sig til andre teams med anmodninger om at udføre nødvendigt arbejde, ved brug af mere eller mindre formaliserede kommunikationsmidler, som ticketsystemer eller e-mail. Derefter bliver disse anmodninger sat i kø og venter på deres tur, hvor lang ventetid ofte fører til forringelse eller endda forværring af forholdet mellem teams. Spændingerne forstærkes yderligere af, at medlemmerne af forskellige teams sjældent mødes personligt og som regel kun deler det mindste nødvendige.
Figur 2. IT-organisation DevOps
Denne diagram viser, hvordan samarbejdet fungerer i en DevOps-organisation. Her har de samme teams fra det tidligere diagram opgivet ineffektive kommunikationsformer, der forstærkede splittelse, og har i stedet skabt personlige kontakter, hvilket resulterer i faste kommunikationskanaler mellem teams. Disse kanaler fremmer dannelsen af et hybrid færdighedssæt, der hjælper medarbejdere med bedre at forstå og representere behovene, problemerne og mulighederne for de teams, de repræsenterer. Teamene giver hinanden mulighed for at udføre nødvendigt arbejde via automatiserede selvbetjeningsportaler i stedet for at manuelt håndtere andres anmodninger om ændringer, som det var før. Og takket være tilgængeligheden af kommunikationskanaler kan disse selvbetjeningssystemer hurtigt tilpasse sig de behov, som de er designet til. For at opnå yderligere gensidig forståelse og vidensdeling i organisationen, roterer teammedlemmerne periodisk rollerne for at få erfaring med interaktion mellem forskellige teams og bedre forstå det overordnede billede af de IT-systemer, de vedligeholder, hvilket dermed hæver deres niveau af tværfaglighed og nytte.
Sammenfattende
I dette indlæg har vi beskrevet, hvordan implementeringen af PaaS-løsninger kan motivere organisationer til at adoptere DevOps-metodologien, hvor traditionelle roller og opgaver ændres i denne proces. Derfor har vi listet de vigtigste IT-opgaver, der opstår i organisationen ved overgangen til OpenShift, samt de færdigheder, der er nødvendige for at udføre dem. Vi har også præsenteret et grundlæggende sæt organisatoriske roller, der opstår ved opbygningen af tværfunktionelle DevOps-teams, samt en RACI-matrix, der forbinder de nye roller med de nye opgaver. Og endelig har vi forklaret, hvordan OpenShift-platformen og den dertil knyttede DevOps-metodologi kan ændre organisationsstrukturen ved overgangen fra traditionelle hierarkier og systemer til behandling af anmodninger til tværfunktionelle teams med en højere grad af personlig kommunikation.
Kilde: habr.com
