Kuigi PaaS-lahendused ("Platvorm teenusena") iseenesest ei suuda muuta üksikisikute ja meeskondade koostööviise, toimivad need sageli Kiirendajana organisatsioonilistele muudatustele vastuseks suurenenud IT-tehnoloogiate paindlikkusele.
Tegelikkuses on PaaS-i investeeringute maksimaalne toimetulek sageli võimalik ainult siis, kui muutuvad organisatsioonilised rollid, vastutusvaldkonnad (ülesanded) ja suhete skeemid. Õnneks on PaaS-lahendustel, näiteks OpenShift Container Platform, piisavalt paindlikkust, et iga IT-organisatsioon saaks iseseisvalt määrata muutuste tempot ja ulatust kaasatud inimeste ja toimuva protsessi osas.
Esimesel etapil ettevõtte konteineriseerimisel on põhieesmärgiks rakenduste juurutamise uue süsteemi, konteineriplatvormi, rakendamine. Sel hetkel seovad organisatsioonid tuttavaid ülesandeid tuttavate rollidega, et reageerida arendusmeeskondade standardsetele nõudmistele sellistes küsimustes nagu salvestussüsteemid, juurutamiskeskkonnad jne. Järgmistel konteineriseerimise etappidel on juba juttu automatiseerimisest või arendajate iseteenindusvõimaluste pakkumisest, et vähendada süsteemiadministraatorite koormust ning tõsta arendajate iseseisvust ja operatiivsete võimete taset. Nii hakkab organisatsioon liikuma DevOpsi suunas. Kuni konteineriseerimise lõppfaasini jõuab ettevõte puhtama, klassikalise DevOsi mudelini, kus paljud varasemad ülesanded ja tööd lähevad üle funktsiooniliste meeskondade kontrolli alla, mis grupivad mitte platvormide või tehnoloogiate alusel, vaid rakenduste või rakenduslike teenuste toimimise tagamise seisukohalt.
Selles postituses esitame juhendi vajalike organisatsiooniliste muudatuste läbiviimiseks ja räägime sellest, kuidas traditsioonilised IT-rollid muutuvad konteineritehnoloogiate juurutamisega ettevõttes.
Uute ülesannete sidumine vanade rollidega
Oma põhivormis on PaaS-i korraldusmudel loodud, et paindlikumalt ja tõhusamalt eraldada IT-ressursse rakendustele jooksukeskkonnana. Kuigi see annab süsteemiadministraatoritele teatud eeliseid, ei saa arendajad tavaliselt mingit märkimisväärset kasu ega uusi võimalusi, kuna sellel etapil võib ettevõte täiesti hästi läbi saada ilma automatiseerimise, eneseuuendamise või juurutuse konveieri radikaalse parandamiseta. PaaS, minimeerides arendusprotsesside mõju, tõstab siiski IT-süsteemi dünaamilisust, mis võimaldab administraatoritel paremini teenindada arendajate nõudeid. Näiteks kui varem võttis arenduskeskkonna loomine mitmete virtuaalmasinate ja salvestusruumide puhul aega päevi või isegi nädalaid, vajades mitmete erinevate administraatorite osalust, siis PaaS-is toimub kõik palju kiiremini ja ainult ühe administraatori abiga. Teisisõnu, arendustiimid esitlevad päringuid nagu varem, kuid nende päringute täitmine toimub uue skeemi järgi.
Teel DevOps-organisatsiooni
Loodud PaaS ja viidud sellele IT-süsteemide ja rakenduste arendamise spetsialistid, saab organisatsioon jätkata DevOps'i metodoloogia rakendamist, mis sisaldab lisaks järgmisi põhialuseid:
- Jagada töö väikesteks etappideks, et saada tagasisidet varases etapis, vähendada riske ja vältida "analüütilist paralüüsi";
- Automatiseerida tegevusi piisavas ulatuses, et mitte luua takistusi ega kitsaskohti rakenduse juurutamise protsessis;
- Teadmiste jagamine on usalduse loomise võti;
- Regulaarselt maksta tehnilisi võlgu, eraldades igas töötsüklis teatud aja süsteemseteks parandusteks.
Teise etapi käigus konteineritehnoloogiate juurutamisel hakkavad arendusteamid loomulikult nägema parendamise võimalusi ning organisatsioon kaldub rohkem kanoniseeritud DevOpsi mudeli poole. Traditsiooniline mehhanism hooldusavalduste esitamiseks ja täitmiseks hakkab nüüd tunduma kitsaskohana, seetõttu püüab organisatsioon automatiseerida korduvaid tegevusi ja pakkuda arendajatele iseteeninduse võimalusi. Arendajate iseteeninduse võimalused sõltuvad vastava avalduse raames IT spetsialistide ja rakenduste tarnijate koostööst. Teisisõnu, süsteemiadministraatorite asemel, kes täidavad arendajate taotlusi, astuvad esile kaks eelpool nimetatud töötajate kategooriat, kes vastutavad poliitikate määratlemise ja rakendamise eest, mis reguleerivad, mida arendajatele on lubatud iseseisvalt teha. Automatiseeritud protseduurid aitavad tagada nimetatud nõuete täitmise ja koordineerida tegevusi juhtudel, kui olukord väljendab olemasolevaid poliitikaid.
Üleminek iteratiivsele ajakavale, kus IT keskkond ja tegevusmudel läbivad aja jooksul iteratiivseid muutusi, on kriitiliselt oluline verstapost organisatsiooni küpse DevOpsi süsteemi välja töötamisel. DevOpsi metodoloogia vastuvõtmise aste sõltub iga konkreetse organisatsiooni tolerantsist muutuste suhtes ja sellest, millised muutused toovad suurimat kasu. Näiteks kui vajadus uute keskkondade või rakenduste loomiseks esineb harva, siis on vastavate tegevuste optimeerimine vähem oluline kui arendajate kontrolli tugevdamine rakenduste elutsükli üle.
Uued väljakutsed, millega IT-organisatsioonid silmitsi seisavad OpenShiftile üleminekul.
Selles jaotises vaatleme rolle ja ülesandeid, mida OpenShiftile üleminevad organisatsioonid tavaliselt rakendavad automatiseerimise ja iseteeninduse kiirendamiseks PaaS-tehnoloogiate abil.
Alljärgnevas tabelis on loetletud peamised kõrgema taseme ülesanded, mis eksisteerivad igas organisatsioonis, mis on rakendanud OpenShift'i, koos vastava töö ja oskuste näidetega. See ülesannete loetelu ei ole sama, mis tööjaotuse skeem või meeskondade organisatsioonistruktuur; see on lihtsalt ülesannete kogum, mis peab olema täidetud IT-keskkonna toetamise eest vastutavate isikute poolt, et container platvormi seadistamine oleks edukas. Tegelikult näitame allpool, et konteineritehnoloogiate rakendamine loob eeldused küpsemate DevOps-strateegiate kujunemiseks ettevõttes, mis omakorda suurendab meeskondade ristfunktsionaalsust ja vähendab kitsaste erialade riske nii üksikute töötajate kui ka meeskondade tasandil.
Tabel 1. OpenShift'i ülesannete määratlemine
Ülesanded
Nõutavad oskused
IT-infrastruktuuride automatiseerimine ja seadistamine (provisioning)
Tööd:
- Riistvaralahenduste projekteerimine ja ehitamine
- Algse seadistamise automatiseerimise korraldamine ja toetamine
- Virtuaalmasinate ja hostide seadistamise projekteerimine ja automatiseerimine
- Andmekeskuste projekteerimine ja rakendamine
- Linuxi süsteemihaldus
- Automatiseerimise skriptid
- Salvestussüsteemide tundmine
- Võrgulahenduste projekteerimise ja rakendamise teadmised
- Turvalisus
OpenShift'i platvormi seadistamine ja haldamine
Tööd:
- Klastri seadistamise teostamine
- Infrastruktuuri teenuste haldamine
- Platvormi skaleerimise haldamine
- Platvormi autentimise ja autoriseerimise kontrollimine
- Linuxi süsteemihaldus
- Võrgutehnoloogia tundmine
- Automatiseerimise skriptid (Ansible)
- Salvestussüsteemide tundmine
- Konteineritehnoloogiate ja arhitektuuride tundmine
- Kubernetes ja OpenShift tehnoloogiate arhitektuuride tundmine
- Platvormide turvalisus
- Monitooringu integreerimine
Kliendikeskkondade (tenant provisioning) ettevalmistamise ja IT-resursside isoleerimise haldamine
Tööd:
- Kasutajate ja meeskondade loomine platvormi piires
- Kvootide projekteerimine ja haldamine
- RBAC'i projekteerimine ja rakendamine
- Kubernetes ja OpenShift tehnoloogiate arhitektuuride tundmine
- Konteineritehnoloogiate ja arhitektuuride tundmine
- Automatiseerimise skriptid
- Hea arusaam projektidest, kvootidest, rollide seotamisest ja ajastamise haldamisest
Põhja-piltide kogumine ja haldamine
Tööd:
- Piltide muutmise tööprotsessi arendamine
- Standardite kohaste piltide arendamine
- Linuxi süsteemihaldus
- Automatiseerimise skriptid
- Rakenduste ja vahendite runtime-komponentide seadistamine
- Konteinerite arhitektuuride tundmine
- Rakenduste kogumissüsteemid (application build frameworks)
- Hea arusaam piltidest, imagestream'ist ja mallidest
Käidete kavandamine ja haldamine
Tööd:
- Käigute standardite kavandamine ja dokumenteerimine
- Lühiõpikute ja mallide arendamine
- Arendajate koolitus
- Allika koodihalduse
- Rakenduste kavandamine ja rakendamine
- Automatiseerimise skriptid
- Automatiseeritud testimine
- Koodi kvaliteedi testimine
- Konteinerite arhitektuuride tundmine
- Tunne immutable infrastruktuure
- Turvalisus – käigu ligipääsu haldamine, tööprotsesside kinnitamine jne.
- Hea OpenShift mallide, buildconfigs, deploymentconfigs, teenuste, marsruutide, configmaps tundmine
Rakenduste ja testide arendamine
Tööd:
- Rakenduste kodeerimine
- Automatiseeritud testide arendamine
- Testide ebaõnnestumistele reageerimine käidete käigus
- Rakenduste tõrgete lahendamine
- Kasutajakontrollide testimine
- Rakenduste kavandamine ja rakendamine
- Automatiseeritud testimine
- Allika koodihalduse
- Rakenduste jälgimine
- Cloud native rakenduste arhitektuuride tundmine
Rakenduste operatiivne jälgimine ja haldamine
Tööd:
- Rakenduste kavandamine jõudluse kontekstis
- Rakenduste jälgimine täitmise etapis
- Rakenduste skaleerimine (või automaatne skaleerimine)
- Rakenduste kergesti kättesaadavuse haldamine
- Päringute kvoodid ja ressursside haldamise piirangud
- Jõudluse ja IT-mahtude testimine
- Rakenduste jõudluse kavandamine ja rakendamine
- Rakenduste jõudluse jälgimine
- Jõudluse testimine ja koormustestimine
Kasutajakontrollide testimine
Tööd:
- UI testimine (disain ja kasutajaga suhtlemine)
- Automatiseeritud testide arendamine
- Kasutajaliideste kavandamine ja kontrollimine
- Automatiseeritud testimise mallid
- Testimisraamistikud
- Rakenduste kavandamise mallid
Uued rollid, mis tekivad IT-organisatsioonis üleminekul OpenShiftile
OpenShiftile ülemineku käigus vähenevad tavaliselt rollide spetsialiseerumine ning suureneb ristsuunaliste meeskondade ja rollide arv, et maksimeerida koostöö tõhusust. Meie arvates näeb välja peamiste ametikohtade loetelu OpenShiftit kasutavas IT-organisatsioonis:
- Rakenduste operatsioonide insener (Application Operations Engineer) VÕI Veebi usaldusväärsuse insener (Site Reliability Engineer). Varem võidi selle ametikoha nimeks olla 'Rakenduste serveri administraator'.
- Rakenduste arendaja / tarkvaraarendaja / programmeerija.
- Klastri / rakenduste platvormi administraator. Varem võidi seda rolli nimetada 'Süsteemi administraatoriks' või 'Linuxi platvormide administraatoriks'.
- Tarkvara väljalaskejuht (Release Manager) / Koostamisinsener (Build Engineer).
RACI rollide ja ülesannete maatriks
Lõpuks liigume edasi eelnevalt käsitletud ametikohtade ja ülesannete sobitamise juurde, et anda ülevaade sellest, kuidas peaks välja nägema organisatsiooni struktuur, mis rakendab DevOps OpenShift platvormil. Alguses saavad alltoodud rollid olla erinevate vana, traditsioonilise organisatsioonistruktuuri harude täidetud. Aga ajapikku toimub konsolideerimine ja tekivad uued, rakenduste ümber rajatud meeskonnad, mis võtavad endale enamikud või isegi kõik allpool loetletud ülesanded.
Ülesanded
Rollid
Rakenduste tööinsener / Veebisaidi usaldusväärsuse insener
Rakenduste arendaja / Tarkvaraarendaja / Programmeerimisinstruktor
Klastri / rakenduste platvormi administraator
Tarkvara väljalaskejuht / Koostamisinsener
IT-infrastruktuuride automatiseerimine ja seadistamine (provisioning)
I
I
R/A
C
OpenShift'i platvormi seadistamine ja haldamine
C
I
R/A
C
Käidete kavandamine ja haldamine
C
C
I
R/A
Kliendi keskkondade (tenant provisioning) haldamine, isoleerimine ja IT-võimsused
C
I
R/A
I
Põhja-piltide kogumine ja haldamine
R
C
R/A
C
Rakenduste ja testide arendamine
C
R/A
I
I
Rakenduste operatiivne jälgimine ja haldamine
R/A
C
C
I
Kasutajakontrollide testimine
C
R
I
I
RACI maatriksi sümbolid
Allikas:
- Responsible – Teostaja – see, kes teeb vajalikud toimingud ülesande täitmiseks.
- Accountable – Vastutav – töötaja, kes lõpuks vastutab ülesande või tulemuse õige ja põhjaliku täitmise eest; samuti ainus, kes võib delegeerida tööd täitjatele.
- Consulted – Nõustajad – tavaliselt on need eriala eksperdid, kelle nõuandeid küsitakse; nendega peetakse pidevalt kahekordset suhtlust.
- Informed – Teavitavad isikud – inimesed, keda hoitakse asjaoludest kursis (ja mõnikord ainult ülesande lõpetamisel või tulemuse saavutamisel); nad saavad teavet ühesuunaliselt.
Kuidas meeskondade koostöö DevOps-organisatsioonis on korraldatud
Traditsiooniline ressursihangete skeem kujutab endast tavaliselt ressursside eraldamise taotlemise tsüklit, mida seejärel täidavad mitmed meeskonnad. Lõpuks eraldatakse ja kinnitatakse kõik vajalikud ressursid taotleva poole poolt. Sageli viiakse need protsessid osaliselt, kui mitte täielikult, läbi käsitsi ja nõuavad sagedasi ja arvukalt meeskondade vahelist suhtlust iga taotluse edukaks töötlemiseks.
Joonis 1. Traditsiooniline IT-organisatsioon
Ülaltoodud diagramm illustreerib tüüpilisi suhteid erinevate meeskondade vahel traditsioonilises IT-organisatsioonis. Selle skeemi kohaselt pöörduvad ühed meeskonnad teiste meeskondade poole, et paluda vajalike tööde teostamist, kasutades rohkem või vähem formaalseid suhtlemisvahendeid, nagu piletihaldussüsteem või e-post. Seejärel lähevad need taotlused järjekorda ja ootavad oma korda, kusjuures pikk ooteaeg viib sageli suhete halvenemiseni või isegi pingete süvenemiseni meeskondade vahel. Pinget suurendab veelgi see, et erinevate meeskondade liikmed kohtuvad üksteisega harva ja jagavad tavaliselt vaid minimaalset vajalikku teavet.
Joonis 2. IT-organisatsioon DevOps
Selles diagrammis on näidatud, kuidas korraldatakse koostööd DevOps-organisatsioonis. Siin on samad meeskonnad, mis olid eelmisel diagrammil, loobunud ebatõhusatest suhtlemisviisidest, mis suurendasid killustatust, ja asendanud need isiklike kontaktidega, luues seeläbi püsivad suhtlemiskanali meeskondade vahel. Need kanalid toetavad hübriidsete oskuste kogumi tekkimist, mis aitab töötajatel paremini mõista ja tajuda nende esindatavate meeskondade vajadusi, probleeme ja võimalusi. Meeskonnad võimaldavad üksteisel teostada vajalikke töid automatiseeritud iseteenindusportaalide kaudu, selle asemel et käsitsi hallata teiste muudatusettepanekute taotlusi, nagu see enne oli. Ja tänu suhtlemiskanali olemasolule suudavad need iseteenindussüsteemid kiiresti kohanduda meeskondade vajadustega, kelle jaoks need on loodud. Veelgi suurema vastastikuse mõistmise ja teadmiste vahetamise saavutamiseks organisatsioonis pöörduvad meeskondade liikmed perioodiliselt rollide vahetusest, et saada kogemusi koostöös erinevate meeskondadega ja paremini mõista IT-süsteemide üldpilti, mida nad teenindavad, tõstes seeläbi oma ristfunktsionaalsuse ja kasulikkuse taset.
Kokkuvõtteks
Selles postituses räägime, kuidas PaaS-lahenduste rakendamine võib organisatsiooni innustada DevOpsi metoodika kasutusele võtmiseks ning kuidas selle protsessi käigus muutuvad traditsioonilised rollid ja ülesanded. Seetõttu loetleme peamised IT-ülesanded, mis tekivad organisatsioonis üleminekul OpenShiftile, ning oskused, mis on nende täitmiseks vajalikud. Me toome välja ka põhikomplekti organisatsioonilisi rolle, mis tekivad ristfunktsionaalsete DevOpsi meeskondade loomisel, ja RACI-matriisi, mis seob uued rollid uute ülesannetega. Lõpuks räägime, kuidas OpenShift ja sellega seotud DevOpsi metoodika võivad muuta organisatsiooni struktuuri, liikumisel traditsiooniliselt hierarhiliselt süsteemilt ülesannete töötlemiseks ristfunktsionaalsetele meeskondadele, kus on kõrgem isiklik suhtlemise tase.
Allikas: habr.com
