Även om PaaS-lösningar (Platform as a Service) i sig själva inte kan förändra sätten för individuellt och teaminteraktion, fungerar de ofta som en katalysator för organisatoriska förändringar i takt med den ökade flexibiliteten hos IT-teknologier.
I praktiken är den maximala avkastningen på investeringar i PaaS ofta endast möjlig genom förändring av organisatoriska roller, ansvarsområden (uppgifter) och relationsscheman. Lyckligtvis har PaaS-lösningar som OpenShift Container Platform tillräcklig flexibilitet för att varje IT-organisation själv kan bestämma hastigheten och omfattningen på förändringarna i förhållande till involverade personer och pågående processer.
Under den första fasen av företagscontainrar är den främsta prioriteringen att implementera en containerplattform som ett nytt system för applikationsutplacering. Vid denna tidpunkt kopplar organisationer vanliga arbeten till välkända roller för att reagera på standardförfrågningar från utvecklingsteam när det gäller lagringssystem, distributionsmiljöer etc. I de följande faserna av containeriseringen handlar det om automatisering eller att ge utvecklare självbetjäningsmöjligheter för att minska belastningen på systemadministratörer och höja autonomi och smidighet för utvecklarna. Det är så som organisationen börjar röra sig mot DevOps. I den avslutande fasen av företagscontainrar når man en renare, kanonisk DevOps-modell, där många av de tidigare uppgifterna och arbetena flyttas under kontroll av tvärfunktionella team, som grupperar inte efter plattformar eller teknologier, utan utifrån att säkerställa driften av applikationer eller tillämpningstjänster.
I detta inlägg kommer vi att presentera en guide för att genomföra nödvändiga organisatoriska förändringar och beskriva hur traditionella IT-roller förändras med införandet av containerteknologier i företaget.
Koppling av nya arbeten till gamla roller
I sin grundläggande, initiala form skapas organisationsmodellen PaaS för att mer flexibelt och snabbt tilldela IT-resurser till applikationer som en körningsmiljö. Och även om detta ger vissa fördelar till systemadministratörer, får utvecklare i allmänhet inga betydande fördelar eller nya möjligheter här, eftersom företaget på detta stadium kan klara sig utan att börja automatisera, införa självbetjäning eller radikalt förbättra distributionspipen. Med minimal påverkan på utvecklingsprocesserna vid detta skede ökar PaaS ändå dynamiken i IT-systemet, vilket gör att administratörer kan bättre tillgodose utvecklarnas förfrågningar. Till exempel, om det tidigare kunde ta dagar eller till och med veckor att skapa en utvecklingsmiljö från flera virtuella maskiner och lagringvolymer, och det krävdes deltagande från flera olika administratörer, så görs allt mycket snabbare i PaaS och med hjälp av endast en administratör. Med andra ord, utvecklingsteamen lämnar in förfrågningar som tidigare, men arbetet med att genomföra dessa förfrågningar utförs nu enligt en ny modell.
På vägen mot en DevOps-organisation
Genom att lansera PaaS och överföra IT-systemets driftsspecialister och applikationsutvecklare till den, kan organisationen fortsätta att implementera DevOps-metodologin, som bland annat inkluderar följande grundprinciper:
- Att dela upp arbetet i små steg, för att få feedback i ett tidigt skede, minska riskerna och undvika "analytisk förlamning";
- Att automatisera operationer i tillräcklig grad, för att inte skapa hinder eller flaskhalsar i applikationsdistributionsprocessen;
- Kunskapsdelning är nyckeln till att bygga förtroende;
- Att regelbundet betala tekniska skulder, genom att avsätta tid i varje arbetscykel för systematiska förbättringar.
I det andra steget av implementeringen av containerteknologier börjar utvecklingsteamen naturligtvis att se möjligheter till förbättringar, och företaget lutar sig mot en mer kanonisk DevOps-modell. Den traditionella mekanismen för att lämna in och utföra serviceförfrågningar uppfattas nu som en flaskhals, vilket gör att organisationen strävar efter att automatisera repetitiva åtgärder och ge utvecklarna möjlighet till självbetjäning. Dessa utvecklaralternativ inom ramen för en viss begäran bestäms av ett samarbete mellan IT-specialister som sköter plattformarna och de som ansvarar för applikationsleveransen. Med andra ord, i stället för systemadministratörer som utför åtgärder på utvecklarnas förfrågningar, kommer dessa två ovan nämnda kategorier av anställda att ansvara för att beskriva och tillämpa policyer som reglerar vad utvecklarna faktiskt får göra på egen hand. Automatiserade procedurer hjälper till att säkerställa att dessa krav följs och att åtgärder koordineras i de fall situationen går utanför gällande policyer.
Övergången till en iterativ tidsplan där IT-miljön och den operativa modellen genomgår iterativa förändringar över tid är en kritiskt viktig milstolpe i skapandet av ett moget DevOps-system inom företaget. Graden av antagande av DevOps-metodologin beror på varje enskild organisations tolerans för förändringar och vilka förändringar som ger mest nytta. Om behovet av att skapa nya miljöer eller applikationer inte uppstår ofta, så blir optimalisering av de relevanta åtgärderna mindre viktig än att stärka kontrollen för utvecklarna över applikationens livscykel.
Nya uppgifter som uppstår i IT-organisationer vid övergången till OpenShift
I det här avsnittet kommer vi att granska de roller och uppgifter som organisationer som har övergått till OpenShift vanligtvis tillämpar för att snabba på automatiseringen och självbetjäningen med hjälp av teknologier och PaaS.
Nedan i tabellen listas de viktigaste övergripande uppgifterna som finns i varje organisation som har implementerat OpenShift, med exempel på relaterade arbetsuppgifter och färdigheter. Denna lista över uppgifter får inte förväxlas med en arbetsfördelning eller en organisationsstruktur för team; det är endast en uppsättning uppgifter som måste utföras av personer som ansvarar för att stödja IT-miljön, för en framgångsrik implementering av containerplattformen. Faktiskt kommer vi senare att visa att införandet av containerteknologier skapar förutsättningar för att utveckla en mer mogen DevOps-strategi inom företaget, vilket i sin tur ökar graden av tvärfunktionalitet inom teamen och minskar riskerna för snäv specialisering på nivåer som berör både individuella anställda och team.
Tabell 1. Definitioner av OpenShift-uppgifter
Uppgifter
Krävda färdigheter
Automatisering och upprättande (provisioning) av IT-infrastrukturer
Arbetsuppgifter:
- Design och konstruktion av hårdvarulösningar
- Organisering och stöd för automatisering av initial konfiguration
- Design och automatisering av förberedelse av VM och värdar
- Design och implementering av datacenter
- Linux-systemadministration
- Automatiseringsskript
- Kunskap om lagringssystem
- Kunskap om design och implementering av nätverk
- Säkerhet
Installation och hantering av OpenShift-plattformen
Arbetsuppgifter:
- Genomföra klusterinstallation
- Hantering av infrastrukturtjänster
- Hantering av plattformens skalning
- Autentisering och auktorisering på plattformsnivå
- Linux-systemadministration
- Kunskap om nätverksteknologier
- Automatiseringsskript (Ansible)
- Kunskap om lagringssystem
- Kunskap om containerteknologier och arkitekturer
- Kunskap om Kubernetes- och OpenShift-arkitekturer
- Plattformssäkerhet
- Integration av övervakning
Hantering av förberedelse av kundmiljöer (tenant provisioning), isolering med hjälp av IT-resurser
Arbetsuppgifter:
- Skapande av användare och team inom plattformen
- Utformning och hantering av kvoter
- Design och implementering av RBAC
- Kunskap om Kubernetes- och OpenShift-arkitekturer
- Kunskap om containerteknologier och arkitekturer
- Automatiseringsskript
- Goda kunskaper om projekt, kvoter, rollbindningar och arbete med schemaläggare
Byggande och hantering av basbilder
Arbetsuppgifter:
- Utveckling av arbetsflöden för bildändringar
- Utveckling av bilder baserat på standarder
- Linux-systemadministration
- Automatiseringsskript
- Konfigurering av runtime-komponenter för applikationer och middleware
- Kunskap om containerarkitekturer
- Applikationsbyggnadsramverk (application build frameworks)
- Goda kunskaper om bilder, imagestreams och mallar
Design och hantering av distributionskanaler
Arbetsuppgifter:
- Utformning och dokumentation av kanalstandarder
- Utveckling av korta vägledningar och mallar
- Utbildning av utvecklare
- Hantering av källkod
- Design och implementering av applikationer
- Automatiseringsskript
- Automatiserad testning
- Kvalitetstestning av kod
- Kunskap om containerarkitekturer
- Kunskap om immutable infrastruktur
- Säkerhet - hantering av åtkomst till kanalsteg, godkännande av arbetsflöden etc.
- God kunskap om OpenShift-mallar, byggkonfigurationer, distributionskonfigurationer, tjänster, rutter, konfigurationskartor
Utveckling av applikationer och tester
Arbetsuppgifter:
- Kodning av applikationer
- Utveckling av automatiserade tester
- Reagering på tester som misslyckas under distributionskanalen
- Reagering på applikationsfel
- Användaracceptanstestning
- Design och implementering av applikationer
- Automatiserad testning
- Hantering av källkod
- Övervakning av applikationer
- Kunskap om arkitekturer för molnbaserade (cloud native) applikationer
Operativ övervakning och hantering av applikationer
Arbetsuppgifter:
- Design av applikationer med avseende på prestanda
- Övervakning av applikationer under körning
- Skalning av applikationer (eller automatiserad skalning)
- Hantering av applikationstillgänglighet
- Begärningskvoter och resursstyrningsgränser
- Prestandatestning och IT-kapaciteter
- Design och implementering av applikationens prestanda
- Övervakning av applikationsprestanda
- Prestandatestning och belastningstestning
Användaracceptanstestning
Arbetsuppgifter:
- UI-testning (design och användarinteraktioner)
- Utveckling av automatiserade tester
- Design och granskning av användargränssnitt
- Mall för automatiserad testning
- Testningsramverk
- Designmallar för applikationer
Nya roller som uppstår inom IT-organisationer vid övergång till OpenShift
I takt med övergången till en DevOps-orienterad organisationsmodell minskar vanligtvis specialiseringen av roller, medan antalet tvärfunktionella team och roller ökar för att maximera samarbetseffektiviteten. Så här ser vi på hur listan över nyckelroller i en IT-organisation som använder OpenShift kan se ut:
- Applikationsdriftsingenjör (Application Operations Engineer) ELLER Site Reliability Engineer. Tidigare kunde denna position kallas "Applikationsserveradministratör".
- Applikationsutvecklare/programvaruutvecklare/programmeringsingenjör.
- Klustrets / applikationsplattformens administratör. Tidigare kunde denna roll kallas "Systemadministratör" eller "Administratör för Linux-plattformar".
- Release Manager / Byggingenjör.
RACI-roll- och uppgiftsmatris
Till slut går vi vidare till att matcha de ovan beskrivna rollerna och uppgifterna för att ge en allmän bild av hur strukturen bör se ut för en organisation som implementerar DevOps på OpenShift-plattformen. De roller som anges nedan kan ursprungligen utföras av olika grenar av den gamla, traditionella organisationsstrukturen. Men över tid sker en konsolidering och nya team byggs kring applikationerna som tar ansvar för de flesta eller till och med alla uppgifter som anges nedan.
Uppgifter
Roller
Applikationsdriftsingenjör / Webbplatsens driftsäkerhetsingenjör
Applikationsutvecklare / Programvaruutvecklare / Programmeringsingenjör
Klustrets / applikationsplattformens administratör
Release Manager / Byggingenjör
Automatisering och upprättande (provisioning) av IT-infrastrukturer
I
I
R/A
C
Installation och hantering av OpenShift-plattformen
C
I
R/A
C
Design och hantering av distributionskanaler
C
C
I
R/A
Hantera beredningen av kundmiljöer (tenant provisioning), isolering och IT-resurser
C
I
R/A
I
Byggande och hantering av basbilder
R
C
R/A
C
Utveckling av applikationer och tester
C
R/A
I
I
Operativ övervakning och hantering av applikationer
R/A
C
C
I
Användaracceptanstestning
C
R
I
I
Beteckningar i RACI-matrisen
Källa:
- Ansvarig – Utförare – den som gör vad som krävs för att utföra uppgiften.
- Ansvarig – Ansvarig – den anställde som i slutändan ansvarar för korrekt och noggrant utförande av uppgiften eller uppnåendet av resultat; och den som ensamt kan delegera arbete till utförarna.
- Konsulterad – Konsulter – som regel experter inom sitt område vars råd efterfrågas; de har en tvåvägskommunikation.
- Informerad – Informerade – personer som hålls informerade (och ibland endast efter att uppgiften har slutförts eller resultatet har uppnåtts); de får information på ett ensidigt sätt.
Hur samarbete mellan team är organiserat i en DevOps-organisation
Den traditionella modellen för resursfördelning är oftast en cykel av förfrågningar om resursallokering, som sedan utförs av flera team. Slutligen bekräftas alla nödvändiga resurser av den begärande parten. Ofta utförs dessa processer delvis eller helt manuellt och kräver frekventa och många interaktioner mellan teamen för att varje begäran ska behandlas framgångsrikt.
Figur 1. Traditionell IT-organisation
Diagrammet ovan illustrerar typiska relationer mellan team i en traditionell IT-organisation. Inom denna struktur vänder sig vissa team till andra team med förfrågningar om att utföra nödvändiga arbeten, vilket görs med mer eller mindre formaliserade kommunikationsmedel som tickethanteringssystem eller e-post. Dessa förfrågningar hamnar sedan i kö och väntar på sin tur, där lång väntetid ofta leder till försämringar och till och med en förvärring av relationerna mellan teamen. Spänningarna förvärras också av att medlemmar från olika team sällan träffas personligen och vanligtvis bara delar med sig av minimal nödvändig information.
Figur 2. IT-organisation DevOps
Denna diagram visar hur samarbetet är organiserat inom DevOps. Här har samma team som i den föregående diagrammet övergivit ineffektiva kommunikationsmetoder som förstärkte splittringen och ersatt dem med personliga kontakter, vilket skapar bestående kommunikationskanaler mellan teamen. Dessa kanaler bidrar till att bilda en hybriduppsättning av färdigheter som hjälper medarbetarna att bättre förstå och uppskatta behoven, problemen och möjligheterna för de team de representerar. Teamen ger varandra möjlighet att utföra nödvändiga arbeten via automatiserade självhjälpsportaler istället för att manuellt hantera andras förändringsförfrågningar som tidigare. Tack vare dessa kommunikationskanaler kan dessa självhjälpssystem snabbt anpassa sig till behoven hos de team de skapats för. För att uppnå ännu större ömsesidig förståelse och kunskapsutbyte inom organisationen roterar teammedlemmarna periodiskt i sina roller för att få erfaranhet av interaktion med olika team och bättre förstå den övergripande bilden av de IT-system de underhåller, vilket ökar deras nivå av tvärfunktionalitet och nytta.
Sammanfattningsvis
I det här inlägget har vi förklarat hur implementeringen av PaaS-lösningar kan uppmuntra organisationer att införa DevOps-metodik, där traditionella roller och uppgifter förändras inom denna process. Därför har vi listat de viktigaste IT-uppgifterna som uppstår i en organisation vid övergången till OpenShift, samt de färdigheter som krävs för att utföra dem. Vi har också presenterat ett grundläggande set av organisatoriska roller som uppstår vid uppbyggnaden av tvärfunktionella DevOps-team, samt en RACI-matris som kopplar nya roller till nya uppgifter. Slutligen har vi diskuterat hur OpenShift-plattformen och den tillhörande DevOps-metodiken kan förändra organisationens struktur när man går ifrån traditionell hierarki och ärendehanteringssystem till tvärfunktionella team med högre nivåer av personlig kommunikation.
Källa: habr.com
