Nors vien PaaS (Platforma kaip paslauga) sprendimai negali pakeisti asmenų ir komandų sąveikos būdo, jie dažnai yra organizacinių pokyčių katalizatorius, reaguojant į padidėjusį IT judrumą.
Tiesą sakant, maksimalią PaaS investicijų grąžą dažnai galima pasiekti tik pakeitus organizacinius vaidmenis, pareigas (užduotis) ir santykius. Laimei, PaaS sprendimai, tokie kaip „OpenShift Container Platform“, yra pakankamai lankstūs, kad kiekviena IT organizacija galėtų nustatyti pokyčių greitį ir mastą, atsižvelgiant į dalyvaujančius žmones ir vykstančius procesus.
Pirmajame įmonės konteinerizavimo etape pagrindinis prioritetas yra konteinerių platformos, kaip naujos programų diegimo sistemos, diegimas. Šiuo metu organizacijos susieja pažįstamus darbus su pažįstamais vaidmenimis, kad atsakytų į standartines kūrimo komandų užklausas tokiais klausimais kaip saugojimo sistemos, diegimo aplinka ir pan. Vėlesniuose konteinerizacijos etapuose jau kalbame apie automatizavimą arba savitarnos galimybių suteikimą kūrėjams, siekiant sumažinti sistemų administratorių naštą ir pakelti kūrėjų savarankiškumą bei efektyvumą į aukštesnį lygį. Taip organizacija pradeda judėti DevOps link. Paskutiniame konteinerizacijos etape įmonė pasiekia grynesnį, kanoninį „DevOps“ modelį, kuriame daugelį ankstesnių užduočių ir darbų kontroliuoja daugiafunkcinės komandos, sugrupuotos ne pagal platformas ar technologijas, o iš taško taikomųjų programų ar taikomųjų programų veikimo užtikrinimo tikslas .
Šiame įraše pateiksime gaires, kaip atlikti būtinus organizacinius pakeitimus ir kaip keičiasi tradiciniai IT vaidmenys įmonėje įdiegus konteinerių technologijas.
Naujų darbų susiejimas su senais vaidmenimis
Pradinėje, pagrindinėje formoje „PaaS“ organizacinis modelis yra sukurtas taip, kad lanksčiau ir greičiau paskirstytų IT išteklius programoms kaip vykdymo aplinka. Nors tai suteikia tam tikrų pranašumų sistemos administratoriams, kūrėjai paprastai negauna jokios reikšmingos naudos ar naujų galimybių, nes šiame etape įmonė gali lengvai apsieiti be automatizavimo, savitarnos ar radikalaus diegimo proceso patobulinimo. Nors šiame etape „PaaS“ minimaliai veikia kūrimo procesus, vis dėlto padidina IT sistemos lankstumą, leisdamas administratoriams geriau patenkinti kūrėjų užklausas. Pavyzdžiui, anksčiau kuriant kūrimo aplinką iš kelių... virtualios mašinos Nors saugyklų kūrimas ir diegimas gali užtrukti kelias dienas ar net savaites ir tam gali prireikti kelių skirtingų administratorių, „PaaS“ sistemoje viskas atliekama daug greičiau ir vos vieno administratoriaus. Kitaip tariant, kūrimo komandos teikia užklausas kaip ir anksčiau, tačiau jų įgyvendinimo darbas dabar atliekamas pagal naują modelį.
„DevOps“ organizacijos link
Paleidus PaaS ir į ją perkeliant IT operacijų specialistus bei programų kūrėjus, organizacija gali toliau diegti DevOps metodiką, kuri, be kita ko, apima šiuos pagrindinius principus:
- Padalinkite darbą į mažus žingsneliusgauti ankstyvą grįžtamąjį ryšį, sumažinti riziką ir išvengti analizės paralyžiaus;
- Pakankamai automatizuoti operacijaskad programos diegimo procese nesudarytų kliūčių ar kliūčių;
- Žinių mainai – raktas į pasitikėjimo kūrimą;
- Reguliariai mokėti technines skolas, kiekviename darbo cikle skiriant tam tikrą laiką sistemingiems tobulinimams.
Antrame konteinerių technologijų diegimo etape kūrėjų komandos natūraliai pradeda matyti tobulėjimo galimybes, o įmonė linksta prie tradicinio „DevOps“ modelio. Tradicinis paslaugų užklausų pateikimo ir vykdymo mechanizmas dabar suvokiamas kaip kliūtis, todėl organizacija siekia automatizuoti pasikartojančius veiksmus ir suteikti kūrėjams savitarnos galimybes. Be to, šios programuotojo galimybės konkrečioje programoje yra nulemtos bendromis platformas valdančių IT specialistų ir už programų pristatymą atsakingų asmenų pastangomis. Kitaip tariant, sistemų administratorius, atliekančius veiksmus pagal kūrėjų pageidavimą, pakeičia dvi aukščiau minėtos darbuotojų kategorijos, atsakingos už strategijų, reglamentuojančių tai, ką kūrėjai gali daryti patys, apibūdinimą ir taikymą. Automatizuotos procedūros padeda užtikrinti nustatytų reikalavimų laikymąsi ir koordinuoja veiksmus, kai situacija nepatenka į esamos politikos taikymo sritį.
Perėjimas prie kartotinio tvarkaraščio, kurio metu IT aplinka ir veikimo modelis nuolat keičiasi laikui bėgant, yra labai svarbus žingsnis siekiant brandžios „DevOps“ įmonės. DevOps metodikos pritaikymo laipsnis priklauso nuo kiekvienos individualios organizacijos tolerancijos pokyčiams ir nuo to, kokie pokyčiai atneša didžiausią naudą. Pavyzdžiui, jei poreikis kurti naujas aplinkas ar programas atsiranda retai, atitinkamos veiklos optimizavimas bus ne toks svarbus nei programos gyvavimo ciklo kūrėjo kontrolės didinimas.
Nauji iššūkiai, kylantys IT organizacijose pereinant prie OpenShift
Šiame skyriuje apžvelgsime vaidmenis ir užduotis, kurias paprastai naudoja organizacijos, kurios pritaikė OpenShift, kad paspartintų automatizavimą ir savitarną, naudodamos technologijas ir PaaS.
Žemiau esančioje lentelėje pateikiamos pagrindinės aukščiausio lygio užduotys, kurios egzistuoja bet kurioje organizacijoje, kuri įdiegė OpenShift, su susijusių darbų ir įgūdžių pavyzdžiais. Šis užduočių sąrašas neturėtų būti painiojamas su darbo suskirstymo struktūra ar komandos struktūra, o užduočių rinkiniu, kurį turi atlikti asmenys, atsakingi už IT aplinkos (-ių) palaikymą, kad būtų sėkmingai įdiegta konteinerių platforma. Tiesą sakant, toliau parodysime, kad konteinerių technologijų įdiegimas sukuria prielaidas formuoti brandesnę DevOps strategiją įmonėje, o tai savo ruožtu padidina komandų kryžminio funkcionalumo laipsnį ir sumažina siauros specializacijos riziką įmonėje. tiek individualiai, tiek komandoje.
1 lentelė. OpenShift užduočių apibrėžimai
užduotys
Reikalingi įgūdžiai
IT infrastruktūros automatizavimas ir aprūpinimas
Darbai:
- Techninių sprendimų projektavimas ir konstravimas
- Pradinės sąrankos automatizavimo organizavimas ir palaikymas
- VM projektavimas ir automatizavimas bei pagrindinio kompiuterio paruošimas
- Duomenų centrų projektavimas ir diegimas
- Linux sistemos administravimas
- Automatizavimo scenarijai
- Sandėliavimo sistemų išmanymas
- Tinklo projektavimo ir diegimo išmanymas
- saugumas
„OpenShift“ platformos diegimas ir valdymas
Darbai:
- Klasterio diegimas
- Infrastruktūros paslaugų valdymas
- Platformos mastelio valdymas
- Platformos lygio autentifikavimas ir autorizavimas
- Linux sistemos administravimas
- Tinklo technologijų išmanymas
- Automatizavimo scenarijai (galimas)
- Sandėliavimo sistemų išmanymas
- Konteinerių technologijų ir architektūros išmanymas
- Kubernetes ir OpenShift architektūrų išmanymas
- Platformos sauga
- Integracijos stebėjimas
Klientų aplinkų paruošimo (nuomininko aprūpinimo), IT pajėgumų izoliavimo valdymas
Darbai:
- Vartotojų ir komandų kūrimas platformoje
- Kvotų projektavimas ir valdymas
- RBAC projektavimas ir įgyvendinimas
- Kubernetes ir OpenShift architektūrų išmanymas
- Konteinerių technologijų ir architektūros išmanymas
- Automatizavimo scenarijai
- Geras projektų, kvotų, vaidmenų paskirstymo ir darbo su planuotojais išmanymas
Bazinių vaizdų kūrimas ir valdymas
Darbai:
- Vaizdo modifikavimo darbo eigos kūrimas
- Standartais pagrįstas įvaizdžio kūrimas
- Linux sistemos administravimas
- Automatizavimo scenarijai
- Vykdymo laiko programos komponentų ir tarpinės programinės įrangos konfigūravimas
- Konteinerių architektūros išmanymas
- Programų kūrimo karkasai
- Geras vaizdų, vaizdų srauto ir šablonų išmanymas
Projektuoti ir valdyti diegimo vamzdynus
Darbai:
- Konvejerio standartų projektavimas ir dokumentavimas
- Greitų vadovų ir šablonų kūrimas
- Kūrėjų mokymas
- Šaltinio kodo valdymas
- Programos projektavimas ir įgyvendinimas
- Automatizavimo scenarijai
- Automatinis testavimas
- Kodo kokybės patikrinimas
- Konteinerių architektūros išmanymas
- Nekintamų infrastruktūrų išmanymas
- Sauga – prieigos prie dujotiekio etapų valdymas, darbo eigos tvirtinimas ir kt.
- Geras OpenShift šablonų, komponentų buildconfig, diegimo konfigūracijų, paslaugų, maršrutų, konfigūracijų žemėlapių išmanymas
Programų ir testų kūrimas
Darbai:
- Programos kodavimas
- Automatizuotų testų kūrimas
- Reagavimas į bandymo gedimus diegimo dujotiekio metu
- Reagavimas į programos gedimus
- Vartotojo priėmimo testas
- Programos projektavimas ir įgyvendinimas
- Automatinis testavimas
- Šaltinio kodo valdymas
- Programų stebėjimas
- Debesų vietinių programų architektūrų išmanymas
Veiklos stebėjimas ir programų valdymas
Darbai:
- Programų projektavimas našumo kontekste
- Programų stebėjimas vykdymo metu
- Programos mastelio keitimas (arba automatinis mastelio keitimas)
- Programų prieinamumo valdymas
- Prašyti kvotų ir išteklių valdymo limitų
- Našumo ir IT pajėgumų tikrinimas
- Programos našumo projektavimas ir įgyvendinimas
- Programos veikimo stebėjimas
- Veikimo ir apkrovos testavimas
Vartotojo priėmimo testas
Darbai:
- UI testavimas (dizainas ir vartotojo patirtis)
- Automatizuotų testų kūrimas
- Sukurti ir išbandyti vartotojo sąsajas
- Automatiniai testavimo modeliai
- Testavimo sistemos
- Programų dizaino modeliai
Nauji vaidmenys, atsirandantys IT organizacijoje pereinant prie „OpenShift“.
Kai pereinate prie į „DevOps“ orientuoto organizacijos modelio, vaidmenų specializacija mažėja, o kelių funkcijų komandų ir vaidmenų skaičius savo ruožtu didėja, kad būtų padidintas bendradarbiavimo efektyvumas. Štai kaip, mūsų manymu, atrodo pagrindinių pozicijų IT organizacijoje, naudojančios OpenShift, sąrašas:
- Programų operacijų inžinierius ARBA Svetainės patikimumo inžinierius. Anksčiau ši pozicija galėjo būti vadinama „Application Server Administrator“.
- Programų kūrėjas / programinės įrangos kūrėjas / programinės įrangos inžinierius.
- Klasterio / programų platformos administratorius. Anksčiau šis vaidmuo galėjo būti vadinamas „Sistemos administratoriumi“ arba „Linux platformos administratoriumi“.
- Išleidimo vadovas / statybos inžinierius.
RACI vaidmenų ir užduočių matrica
Galiausiai pereiname prie aukščiau aptartų pozicijų ir užduočių palyginimo, kad susidarytume bendrą supratimą apie tai, kaip turėtų atrodyti organizacijos, diegiančios „DevOps“ „OpenShift“ platformoje, struktūra. Iš pradžių šiuos vaidmenis gali užimti įvairios senosios, tradicinės organizacijos struktūros atšakos. Tačiau laikui bėgant įvyksta konsolidacija ir naujos komandos kuriamos aplink programas, kurios atlieka daugumą ar net visas toliau išvardytas užduotis.
užduotys
Vaidmenys
Programų operacijų inžinierius / Svetainės patikimumo inžinierius
Programų kūrėjas / programinės įrangos kūrėjas / programinės įrangos inžinierius
Grupės / programų platformos administratorius
Programinės įrangos išleidimo vadovas / surinkimo inžinierius
IT infrastruktūros automatizavimas ir aprūpinimas
I
I
R / A
C
„OpenShift“ platformos diegimas ir valdymas
C
I
R / A
C
Projektuoti ir valdyti diegimo vamzdynus
C
C
I
R / A
Tvarkykite nuomininko aprūpinimą, izoliaciją ir IT pajėgumus
C
I
R / A
I
Bazinių vaizdų kūrimas ir valdymas
R
C
R / A
C
Programų ir testų kūrimas
C
R / A
I
I
Veiklos stebėjimas ir programų valdymas
R / A
C
C
I
Vartotojo priėmimo testas
C
R
I
I
Konvencijos RACI matricoje
Šaltinis:
- Atsakingas – Atlikėjas yra tas, kuris daro tai, kas būtina užduočiai atlikti.
- Atskaitingas – Atsakingas – darbuotojas, kuris galiausiai yra atsakingas už teisingą ir kruopštų užduoties atlikimą ar rezultato pasiekimą; ir taip pat vienintelis, kuris gali deleguoti darbus atlikėjams.
- Konsultavo – Konsultantai – paprastai tai yra dalyko ekspertai, kurių patarimo prašoma; Su jais palaikomas dvipusis bendravimas.
- Informavo – Informuoti – žmonės, kurie yra informuojami apie įvykius (o kartais tik atlikus užduotį ar pasiekus rezultatą); jie informaciją gauna vienašališkai.
Kaip komandos dirba kartu „DevOps“ organizacijoje
Tradicinis išteklių įsigijimas paprastai apima išteklių užklausų ciklą, kurį vėliau vykdo kelios komandos. Galiausiai visus reikiamus išteklius skiria ir patvirtina prašančioji šalis. Dažnai šie procesai yra iš dalies arba visiškai neautomatiniai, todėl norint sėkmingai apdoroti kiekvieną užklausą, reikia dažnai ir daug kartų bendrauti.
1 pav. Tradicinė IT organizacija
Aukščiau pateikta diagrama iliustruoja tipiškus tradicinės IT organizacijos komandų santykius. Pagal šią schemą kai kurios komandos kreipiasi į kitas komandas su prašymu atlikti reikiamus darbus, naudodamos daugiau ar mažiau formalias ryšio priemones, tokias kaip bilietų sistema ar el. Tada šie prašymai patenka į eilę ir laukia sparnuose, o ilgas laukimas dažnai pablogina ar net pablogina komandų santykius. Įtampą didina ir tai, kad skirtingų komandų nariai retai susitinka vienas su kitu ir yra linkę dalytis tik minimalia reikalinga informacija.
2 pav.: „DevOps“ IT organizacija
Šioje diagramoje parodyta, kaip bendradarbiavimas veikia „DevOps“ organizacijoje. Čia tos pačios komandos iš ankstesnės diagramos atsisakė neefektyvaus ryšio, kuris sustiprino silosus ir pakeitė juos asmeniniais kontaktais, taip sukurdamos nuolatinius komandų sąveikos kanalus. Šie kanalai skatina mišrų įgūdžių rinkinį, padedantį darbuotojams geriau suprasti ir įsivaizduoti atstovaujamų komandų poreikius, iššūkius ir galimybes. Komandos įgalina viena kitą atlikti darbą per automatizuotus savitarnos portalus, o ne rankiniu būdu tvarkyti kitų žmonių pakeitimų užklausas, kaip buvo anksčiau. Dėl sąveikos kanalų šios savitarnos sistemos gali greitai prisitaikyti prie komandos, kurioms jos skirtos, poreikių. Siekdami dar geresnio supratimo ir dalijimosi žiniomis organizacijoje, komandos nariai periodiškai keičia vaidmenis, kad įgytų patirties bendraudami su skirtingomis komandomis ir geriau suprastų bendrą jų palaikomų IT sistemų vaizdą, taip padidindami jų kryžminį funkcionalumą ir naudingumą.
Sumavimas
Šiame įraše aptarėme, kaip PaaS sprendimų priėmimas gali nukreipti organizaciją link „DevOps“, keičiant tradicinius vaidmenis ir užduotis kaip proceso dalį. Štai kodėl mes išvardijome pagrindinius IT iššūkius, su kuriais susiduria organizacija, pereidama prie „OpenShift“, taip pat įgūdžius, reikalingus jiems atlikti. Taip pat pateikėme pagrindinį organizacinių vaidmenų rinkinį, kuris atsiranda kuriant daugiafunkcines „DevOps“ komandas, ir RACI matricą, susiejančią naujus vaidmenis su naujomis užduotimis. Galiausiai aptarėme, kaip OpenShift platforma ir su ja susijusi DevOps metodika gali pakeisti organizacinę organizacijų struktūrą, kai jos pereina nuo tradicinių hierarchijų ir bilietų sistemų prie daugiafunkcinių komandų, turinčių aukštesnį asmeninio bendravimo lygį.
Šaltinis: www.habr.com
