Kuigi PaaS-lahendused ("Platvorm kui teenus") ei suuda iseseisvalt muuta individuaalset ega meeskondlikku suhtlemist, teenivad nad sageli katalüsaatorina organisatsioonilisi muutusi vastusena suurenenud IT-tehnoloogiate paindlikkusele.
Tõeliselt maksimaalne investeeringute tootlus PaaS-is on tihti võimalik vaid siis, kui muutuvad organisatsioonilised rollid, vastutusvaldkonnad (ülesanded) ning suhtlemismudelid. Õnneks on PaaS-lahendustel, nagu OpenShift Container Platform, piisavalt paindlikkust, et iga IT-organisatsioon saaks iseseisvalt määratleda muutuste kiirus ja ulatus, mis puudutab kaasatud inimesi ja toimuvaid protsesse.
Esimese etapi jooksul ettevõtte konteineriseerimisel on peamine prioriteet konteinerplatvormi juurutamine uue rakenduste juurutamise süsteemina. Sellel hetkel seovad organisatsioonid tuttavad tööd harjumuspäraste rollidega, et reageerida arendustiimide standardsetele nõudmistele, nagu salvestussüsteemid, juurutuskeskkonnad jne. Järgmistel konteineriseerimise etappidel keskendutakse juba automatiseerimisele või arendajate enesehoolduse võimaluste pakkumisele, et vähendada süsteemiadministraatorite koormust ning tõsta arendajate iseseisvust ja operatiivsust kõrgemale tasemele. Just nii hakkab organisatsioon liikuma DevOpsi suunas. Kokkuleppeliselt viimasel konteineriseerimise etapil jõuab ettevõte puhtama, kanonilise DevOpi mudelini, kus paljusid varasemaid ülesandeid ja töid kontrollivad ristfunktsionaalsed meeskonnad, mis grupeerivad mitte platvormide või tehnoloogiate põhjal, vaid rakenduste või rakendusteenuste töö tagamise seisukohalt.
Selles postituses esitame juhendi vajalike organisatsiooniliste muudatuste tegemiseks ja räägime, kuidas traditsioonilised IT-rollid muutuvad konteineritehnoloogiate rakendamisega ettevõttes.
Uute tööde sidumine vanade rollidega
Oma põhivormis on PaaS organisatsiooniline mudel loodud selleks, et paindlikumalt ja kiiremini eraldada IT-ressursse rakendustele täitmisaladena. Kuigi see pakub teatavaid eeliseid süsteemiadministraatoritele, ei saa arendajad tavaliselt mingeid olulisi eeliseid ja uusi võimalusi, kuna sel etapil võib ettevõte üsna hästi hakkama saada ilma automatiseerimise, iseteeninduse või oluliste deploymiskonveierite täiustamiseta. PaaS, puudutades arendusprotsesse minimaalselt, suurendab siiski IT-süsteemi dünaamilisust, võimaldades administraatoritel paremini rahuldada arendajate nõudmisi. Näiteks kui varem võttis arenduskeskkonna loomine mitu virtuaalmasinad Ja hoidmine võttis päevi või isegi nädalaid, nõudes mitme erineva administraatori osalust. PaaS-i puhul saab see kõik palju kiiremini ja ühe administraatori abil. Teisisõnu, arendusteamid esitavad taotlusi nagu varem, kuid nende taotluste elluviimine toimub nüüd uue skeemi kohaselt.
Teel DevOps-organisatsiooniks
PaaS-i käivitamine ja IT süsteemide haldamise spetsialistide ning rakenduste arendajate selle peale viimine võimaldab organisatsioonil jätkata DevOps metoodika rakendamist, mille hulka kuuluvad muu hulgas järgmised põhialused:
- Jagada töö väiksemateks etappideks, et saada tagasisidet varases etapis, vähendada riske ja vältida "analüütilist halvustust";
- Automatiseerida operatsioone piisavalt, et mitte luua tõkkeid või kitsaskohti rakenduse juurutamise protsessis;
- Teadmiste jagamine on usalduse ülesehitamise võti;
- Regulaarselt maksta tehnilisi võlgu, pidades igas töötsüklis ette nähtud aega süsteemseteks täiustusteks.
Teise etapi käigus konteineritehnoloogiate rakendamisel hakkavad arendusteamid loomulikult nägema parendamise võimalusi, ning ettevõte kalduvad rohkem traditsioonilisele DevOps mudelile. Traditsioonilist mehhanismi teenuse taotlemise ja täitmise jaoks nähakse nüüd kitsaskohana, mistõttu organisatsioon püüab automatiseerida korduvaid toiminguid ja pakkuda arendajatele iseteeninduse võimalusi. Need arendajate võimalused antud taotluse raames määratakse platformide väljatöötamise IT-spetsialistide ning rakenduste tarnimise eest vastutavate isikute ühiste jõudude kaudu. Teisisõnu, süsteemihaldurite rolli, kes täidavad arendajate taotlusi, asendavad kaks eelmainitud töötajate kategooriat, kes vastutavad poliitikate määratlemise ja rakendamise eest, mis reguleerivad, mida arendajad saavad iseseisvalt teha. Automatiseeritud protseduurid aitavad tagada nende nõuete täitmise ja kooskõlastada tegutsemist juhtudel, kui olukord ületab kehtivaid poliitikoid.
Üleminek iteratiivsele mudelile, kus IT-keskkond ja operatiivmudel läbivad aja jooksul iteratiivseid muudatusi, on ettevõtte küpse DevOpsi süsteemi kujundamisel kriitilise tähtsusega verstapost. DevOpi metodoloogia vastuvõtmise aste sõltub iga organisatsiooni muutuste taluvusest ning sellest, millised konkreetsed muudatused toovad kõige suuremat kasu. Näiteks, kui vajadus uute keskkondade või rakenduste loomise järele esineb harva, siis on vastavate tegevuste optimeerimine vähem oluline kui arendajate kontrolli tugevdamine rakenduste elutsükli üle.
Uued ülesanded, mis tekivad IT-organisatsioonides OpenShifti kasutusele võtmisel
Selles osas käsitleme rolle ja ülesandeid, mida OpenShifti ülemineku puhul tavaliselt rakendatakse, et kiirendada automatiseerimist ja enese teenindamist, kasutades tehnoloogiaid ja PaaS-i.
Allpool olevas tabelis on loetletud peamised kõrgema taseme ülesanded, mis eksisteerivad igas organisatsioonis, mis on rakendanud OpenShift'i, koos vastavate tööde ja oskuste näidetega. Need ülesanded ei ole segamini ajada tööjaotuse skeemi või meeskondade organisatsiooniliste struktuuridega, vaid need on lihtsalt ülesannete kogum, mis peab olema täidetud isikute poolt, kes vastutavad IT-keskkondade toetamise eest, et edukalt rakendada konteinerite platvormi. Tegelikult näitame edasi, et konteerimistoodete rakendamine loob eeltingimused ettevõttes küpsemate DevOps-strateegiate kujunemiseks, mis omakorda suurendab meeskondade ristfunktsionaalsust ja vähendab kitsaste spetsialiseerumise riske nii üksikisikute kui ka meeskondade tasemel.
Tabel 1. OpenShift'i ülesannete määratlemine
Ülesanded
Nõutavad oskused
IT-infrastruktuuri automatiseerimine ja ettevalmistamine (provisioning)
Tööd:
- Riistvaralahenduste projekteerimine ja ehitamine
- Algse seadistuse automatiseerimise korraldamine ja toetamine
- Virtuaalmasinate ja hostide ettevalmistamise projekteerimine ja automatiseerimine
- Andmekeskuste projekteerimine ja elluviimine
- Linuxi süsteemiadministreerimine
- Automatiseerimise skriptid
- Andmete salvestamise süsteemide tundmine
- Võrkude projekteerimise ja rakendamise valdkonna teadlikkus
- Ohutus
OpenShift platvormi seadistamine ja haldamine
Tööd:
- Klusteri paigaldamise teostamine
- Infrastruktuuri teenuste haldamine
- Platvormi skaleerimise haldamine
- Platvormi tasemel autentimine ja autoriseerimine
- Linuxi süsteemiadministreerimine
- Võrgutehnoloogiate tundmine
- Automatiseerimisskeemid (Ansible)
- Andmete salvestamise süsteemide tundmine
- Konteineritehnoloogiate ja arhitektuuride tundmine
- Kubernetes ja OpenShift arhitektuuride tundmine
- Platvormide turvalisus
- Jälgimise integreerimine
Kliendikeskkondade ettevalmistamise haldamine (tenant provisioning), IT-resursside isoleerimine
Tööd:
- Kasutajate ja rühmade loomine platvormi raames
- Kvootide projekteerimine ja haldamine
- RBAC projekteerimine ja rakendamine
- Kubernetes ja OpenShift arhitektuuride tundmine
- Konteineritehnoloogiate ja arhitektuuride tundmine
- Automatiseerimise skriptid
- Hea teadlikkus projektide, kvootide, rollide sidumise ja ajakava haldamise kohta
Baaspiltide koostamine ja haldamine
Tööd:
- Piltide muutmise töövoo arendamine
- Standardite kohaselt piltide arendamine
- Linuxi süsteemiadministreerimine
- Automatiseerimise skriptid
- Rakenduste ja tarkvara vahekihtide runtime-komponentide konfigureerimine
- Konteinerit arhitektuuride tundmine
- Rakenduste koostamisraamistikud (application build frameworks)
- Hea teadlikkus piltidest, imagestreamidest ja mallidest
Käivituskonveieride projekteerimine ja haldamine
Tööd:
- Käivitusstandardite projekteerimine ja dokumenteerimine
- Lühijuhendite ja mallide väljatöötamine
- Arendajate koolitamine
- Allika koodi haldamine
- Rakenduste projekteerimine ja elluviimine
- Automatiseerimise skriptid
- Automatiseeritud testimine
- Koodi kvaliteedi testimine
- Konteinerit arhitektuuride tundmine
- Tunne immutable infrastruktuuri
- Turvalisus – juurdepääsu haldamine konveierietappidele, töövoogude kinnitamine jne.
- Hea teadlikkus OpenShift'i mallidest, buildconfigs, deploymentconfigs, teenustest, marsruutidest, configmapsidest
Rakenduste ja testide väljatöötamine
Tööd:
- Rakenduste kodeerimine
- Automatiseeritud testide väljatöötamine
- Vastuolude lahendamine käivituskonveieri testimise käigus
- Rakenduste tõrgete lahendamine
- Kasutajapoolne vastuvõtutestimine
- Rakenduste projekteerimine ja elluviimine
- Automatiseeritud testimine
- Allika koodi haldamine
- Rakenduste jälgimine
- Tunne pilvepõhiste (cloud native) rakenduste arhitektuuri
Operatiivne jälgimine ja rakenduste haldamine
Tööd:
- Rakenduste projekteerimine jõudluse kontekstis
- Rakenduste jälgimine täitmise etapis
- Rakenduste skaleerimine (või automaatne skaleerimine)
- Rakenduste saadavuse haldamine
- Küsimuste kvotid ja ressursside haldamise piirangud
- Jõudluse ja IT-võimsuse testimine
- Rakenduste jõudluse projekteerimine ja rakendamine
- Rakenduste jõudluse jälgimine
- Jõudluse testimine ja koormustestimine
Kasutajapoolne vastuvõtutestimine
Tööd:
- Kasutajaliidese testimine (disain ja kasutajaga suhtlemine)
- Automatiseeritud testide väljatöötamine
- Kasutajaliideste projekteerimine ja kontrollimine
- Automatiseeritud testimise šabloonid
- Testimisraamistikud
- Rakenduste projekteerimise šabloonid
Uued rollid, mis tekivad IT-organisatsioonis üleminekul OpenShiftile
Üleminekul DevOps-le suunatud organisatsioonimudelile väheneb tavaliselt rollide spetsialiseerumine ja samas kasvab ristsfunktsionaalsete meeskondade ja rollide arv koostöö efektiivsuse maksimeerimiseks. Siin on meie arvates peamiste ametikohtade nimekiri OpenShift'i kasutavas IT-organisatsioonis:
- Rakenduste kasutuselevõtu insener (Application Operations Engineer) või Saidikindluse insener (Site Reliability Engineer). Varem võidi seda positsiooni nimetada "Rakenduste serveri administraatoriks".
- Rakenduse arendaja/programmide arendaja/software engineer.
- Klastri/rakenduste halduri administraator. Varasemalt võidi seda rolli nimetada „Süsteemiadministraatoriks“ või „Linuxi platvormide administraatoriks“.
- Programmi väljaandmise juht (Release Manager)/Kogumise insener (Build Engineer).
RACI rollide ja ülesannete maatriks
Lõpuks liigume edasi eelnevalt arutatud positsioonide ja ülesannete vastandamise juurde, et anda ülevaade, milline peaks olema organisatsiooni struktuur, mis rakendab DevOps'i OpenShifti platvormil. Alguses võivad allpool loetletud rollid tuleneda vana, traditsioonilise organisatsioonistruktuuri erinevatest harudest. Kuid aja jooksul toimub konsolideerimine ning tekivad uued, rakenduste ümber organiseeritud meeskonnad, mis võtavad enda kanda enamikud või isegi kõik loetelus toodud ülesanded.
Ülesanded
Rollid
Rakenduste tööinsener / Veebilehe usaldusväärsuse insener
Rakenduste arendaja / Tarkvara arendaja / Arendaja-programmeerija
Klastri/rakenduste halduri administraator
Programmi väljaandmise juht / Kogumise insener
IT-infrastruktuuri automatiseerimine ja ettevalmistamine (provisioning)
I
I
R/A
C
OpenShift platvormi seadistamine ja haldamine
C
I
R/A
C
Käivituskonveieride projekteerimine ja haldamine
C
C
I
R/A
Kliendi keskkondade haldamine (tenant provisioning), isolatsioon ja IT-ressursid
C
I
R/A
I
Baaspiltide koostamine ja haldamine
R
C
R/A
C
Rakenduste ja testide väljatöötamine
C
R/A
I
I
Operatiivne jälgimine ja rakenduste haldamine
R/A
C
C
I
Kasutajapoolne vastuvõtutestimine
C
R
I
I
Sümbolid RACI maatriksis
Allikas:
- Vastutav – Tegevusvõtja – see, kes teeb vajaliku töö ülesande täitmiseks.
- Vastutav – Vastutav – töötaja, kes lõpuks vastutab ülesande õige ja hoolika täitmise või tulemuse saavutamise eest; samuti ainus inimene, kes võib töö delegeerida tegevusvõtjatele.
- Konsulteeritud – Konsultandid – tavaliselt on need valdkonna eksperdid, kelle nõu küsitakse; nendega hoitakse kahetasandilist suhtlust.
- Teavitatud – Teavitavad – inimesed, keda hoitakse sündmustest kursis (mõnikord ainult pärast ülesande lõpetamist või tulemuse saavutamist); nad saavad teavet ühesuunaliselt.
Kuidas toimub meeskondade koostöö DevOps organisatsioonis
Traditsiooniline ressursside saamise skeem koosneb tavaliselt ressursside eraldamise taotlemise tsüklitest, mille täitmist viivad läbi mitmed meeskonnad. Lõpuks eraldatakse kõik vajalikud ressursid ja need kinnitab taotlev osapool. Tihti teostavad need protsessid osaliselt või isegi täielikult käsitsi ning nõuavad eduka taotluse töötlemiseks tihti ja rohkelt meeskondadevahelist suhtlemist.
Joonis 1. Traditsiooniline IT-organisatsioon
Ülemise diagrammi puhul on kujutatud tüüpilisi seoseid traditsioonilistes IT-organisatsioonides. Selle skeemi raames pöörduvad mõned meeskonnad teiste poole, et paluda vajalikke töid teha, kasutades rohkem või vähem struktureeritud suhtlusmeetodeid, nagu piletisüsteem või e-post. Seejärel lähevad need taotlused järjekorda ja ootavad oma aega, kusjuures pikk ooteaeg toob sageli kaasa halvenemise või kasvava pinget suhete seas meeskondade vahel. Pinget süvendab ka see, et erinevate meeskondade liikmed kohtuvad harva isiklikult ja jagavad enamikul juhtudel vaid minimaalset vajalikku teavet.
Joonis 2. IT-Organisatsioon DevOps
Selles diagrammis on näidatud, kuidas toimub koostöö DevOps organisatsioonis. Siin loobid samad meeskonnad varasemast diagrammist ebatõhusad suhtlused, mis suurendasid eraldatust, ning asendavad need isiklike kontaktidega, luues pidevad suhtluskanalid meeskondade vahel. Need kanalid aitavad kaasa hübriidskills'i kogumi kujunemisele, mis aitab töötajatel paremini mõista ja esindada nende meeskondade vajadusi, probleeme ja võimalusi, keda nad esindavad. Meeskonnad võimaldavad üksteisel oma töid teostada automatiseeritud eneseteenindusportaalide kaudu, selle asemel et käsitsi täita teise isiku muutmisettepanekuid nagu varem. Ja tänu suhtluskanalite olemasolule on need eneseteenindussüsteemid suutnud kiiresti kohaneda nende meeskondade vajadustega, kelle jaoks nad on loodud. Veelgi parema mõistmise ja teadmusvahetuse saavutamiseks organisatsiooni sees vahetavad meeskonnaliikmed aeg-ajalt rolle, et saada kogemusi teistes meeskondades ning paremini mõista IT-süsteemide tervikpilti, mida nad teenindavad, tõstes seeläbi oma funktsionaalset mitmekesisust ja kasulikku väärtust.
Kokkuvõtteks
Selles postituses käsitlesime, kuidas PaaS-lahenduste rakendamine võib organisatsiooni julgustada DevOpsi metodoloogia kasutusele võtmiseks. Selle protsessi käigus muutuvad traditsioonilised rollid ja ülesanded. Seetõttu oleme loetelenud peamised IT-ülesanded, mis organiseerimisel tekivad OpenShiftile üleminekul, samuti oskused nende täitmiseks. Oleme välja toonud ka põhikomplekti organisatsioonilisi rolle, mis tekivad, kui luuakse DevOps'i ristfunktsionaalsed meeskonnad, ning RACI-matriisi, mis seob uusi rolle uute ülesannetega. Lõpuks käsitlesime, kuidas OpenShifti platvorm ja sellega seotud DevOpsi metodoloogia võivad muuta organisatsiooni struktuuri traditsioonilisest hierarhiast ja taotluste töötlemise süsteemidest ristfunktsionaalseteks meeskondadeks, kus on suurem isiklike suhtlemiste tase.
Allikas: habr.com
