Ndërsa zgjidhjet PaaS (“Platforma si Shërbim”) vetë nuk janë në gjendje të ndryshojnë mënyrat e ndërveprimit individual dhe të ekipit, ato shpesh shërbejnë si një katalizator për ndryshimet organizative si përgjigje ndaj fleksibilitetit të rritur të teknologjive IT.
Në praktikë, maksimumi i kthimit të investimeve në PaaS shpesh është i mundur vetëm në kushtet e ndryshimit të roleve organizative, fushave të përgjegjësisë (detyrave) dhe skemave të marrëdhënieve. Fatmirësisht, zgjidhjet PaaS, siç është OpenShift Container Platform, kanë mjaft fleksibilitet që secila organizatë IT të mund të përcaktojë vetë shpejtësinë dhe shkallën e ndryshimeve në lidhje me njerëzit e përfshirë dhe proceset që ndodhin.
Në fazën e parë të kontenjerizimit të ndërmarrjeve, prioritari kryesor është implementimi i platformës së kontenjerëve si një sistem i ri për shpërndarjen e aplikacioneve. Në këtë moment, organizatat lidhin punët e njohura me role të njohura për të përgjigjur ndaj kërkesave standard të ekipeve të zhvillimit në çështje si sistemet e ruajtjes, mjediset e shpërndarjes etj. Në fazat e mëvonshme të kontenjerizimit, tema kalon në automatizim ose ofrimin e mundësive të vetë-shërbimit për zhvilluesit, me qëllim që të reduktohet ngarkesa mbi administratorët e sistemeve dhe të rritet autonomi dhe efikasiteti i zhvilluesve në një nivel më të lartë. Kështu, organizata fillon të lëvizë drejt DevOps. Në fazën përfundimtare të kontenjerizimit, ndërmarrja arrin në një model më të pastër, kanonik të DevOps, ku shumë prej detyrave dhe punëve të mëparshme kalojnë nën kontrollin e ekipeve ndër-funksionale, të cilat grupohen jo sipas platformave ose teknologjive, por në aspektin e sigurisë së funksionimit të aplikacioneve ose shërbimeve aplikative.
Në këtë postim do të paraqesim një udhëzues për kryerjen e ndryshimeve organizative të nevojshme dhe do të flasim për mënyrën si ndryshojnë rolet tradicionale të IT-së me implementimin e teknologjive të konteinerëve në ndërmarrje.
Lidhja e punëve të reja me rolet e vjetra
Në formën e saj bazike, modeli organizativ i PaaS krijohet për të ofruar në mënyrë më të fleksibël dhe efikase burimet IT për aplikacionet si një mjedis ekzekutimi. Dhe ndërsa kjo ofron disa përfitime për administratorët e sistemit, zhvilluesit këtu zakonisht nuk fitojnë disa përfitime të rëndësishme dhe mundësi të reja, pasi në këtë fazë ndërmarrja mund të shpëtojë nga fillimi i automatizimit, hyrjes në vetë-shërbim ose ndjeshëm përmirësimit të linjës së shpërndarjes. Duke prekur minimalisht proceset e zhvillimit në këtë fazë, PaaS megjithatë rrit dinamikën e sistemit IT, duke lejuar administratorët të shërbejnë më mirë kërkesat e zhvilluesve. Për shembull, nëse më parë krijimi i një ambienti zhvillues nga disa makinave virtuale dhe volumet e ruajtjes mund të merrnin ditë, madje edhe javë, dhe kërkonin angazhimin e disa administratorëve të ndryshëm, ndërsa në PaaS gjithçka bëhet shumë më shpejt dhe me përpjekjet e vetëm një administratori. Me fjalë të tjera, ekipet e zhvilluesve paraqesin kërkesa si më parë, por puna për zbatimin e këtyre kërkesave bëhet sipas një skeme të re.
Në rrugën drejt organizatës DevOps
Duke nisur PaaS dhe duke kaluar specialistët e operacioneve të sistemeve IT dhe zhvilluesit e aplikacioneve në të, organizata mund të vazhdojë implementimin e metodologjisë DevOps, e cila përfshin, midis të tjerash, këto parime kryesore:
- Të ndajmë punën në etapa të vogla, për të marrë feedback në fazat e hershme, ulur rreziqet dhe shmangur 'paralizën analitike';
- Të automatizojmë operacionet në një masë të mjaftueshme, për të mos krijuar pengesa ose ngushtica në procesin e implementimit të aplikacionit;
- Ndërveprimi i njohurive është çelësi për ndërtimin e besimit;
- Të paguajmë borxhet teknike në mënyrë të rregullt, duke dedikuar në çdo cikël punë një kohë të caktuar për përmirësime sistematike.
Në fazën e dytë të zbatimit të teknologjive të kontejnerëve, ekipet e zhvillimit natyrisht fillojnë të shohin mundësi për përmirësim dhe organizata tendoset drejt një modeli më kanonik DevOps. Mekanizmi tradicional i dorëzimit dhe ekzekutimit të kërkesave për shërbim tani perceptohet si një ngushticë, prandaj organizata përpiqet të automatizojë veprimet e përsëritura dhe t'u ofrojë zhvilluesve mundësi vetë-shërbimi. Këto mundësi për zhvilluesit brenda kërkesës përkatëse përcaktohen nga bashkëpunimi i specialistëve IT të operacioneve të platformës dhe atyre që janë përgjegjës për ofrimin e aplikacioneve. Në këtë mënyrë, në vend të administratoreve të sistemeve që kryejnë veprime sipas kërkesave të zhvilluesve, vijnë dy kategoritë e mësipërme të punonjësve, të cilët janë përgjegjës për përshkrimin dhe zbatimin e politikave që rregullojnë atë që zhvilluesit lejohen të bëjnë vetë. Procedurat e automatizuara ndihmojnë në sigurimin e përputhshmërisë me kërkesat e përcaktuara dhe në koordinimin e veprimeve kur situata kalon përtej politikave në fuqi.
Kalimi në një grafik iterativ, në të cilin mjedisi IT dhe modeli operativ pësojnë ndryshime iterative me kalimin e kohës, është një pikë kyçe për formimin e një sistemi DevOps më të zhvilluar në një ndërmarrje. Shkalla e pranimit të metodologjisë DevOps varet nga toleranca e çdo organizate ndaj ndryshimeve dhe se cilat ndryshime sjellin më shumë përfitime. P.sh., nëse nevoja për krijimin e mjediseve ose aplikacioneve të reja ndodh rrallë, optimizimi i veprimeve përkatëse do të ketë rëndësi më të vogël se rritja e kontrollit të zhvilluesve mbi ciklin e jetës së aplikacioneve.
Detyrat e reja që lindin në organizatat IT kur kalojnë në OpenShift
Në këtë seksion ne do të shqyrtojmë rolet dhe detyrat që organizatat e kaluara në OpenShift zakonisht zbatojnë për të përshpejtuar automatizimin dhe vetë-shërbimin duke përdorur teknologji dhe PaaS.
Të dhënat në tabelën më poshtë përfshijnë detyrat kryesore të nivelit të lartë që ekzistojnë në çdo organizatë që ka implementuar OpenShift, me shembuj të punëve dhe aftësive përkatëse. Ky listë detyrash nuk duhet ngatërruar me strukturën e ndarjes së punës ose me strukturën organizative të ekipeve; përkundrazi, është thjesht një grup detyrash që duhen realizuar nga personat përgjegjës për mbështetje të mjedisit IT, për një implementim të suksesshëm të platformës së kontejnerëve. Në të vërtetë, më pas do të tregojmë se implementimi i teknologjive të kontejnerëve krijon premisat për formimin e një strategie më të zhvilluar DevOps në sipërmarrje, çka gjithashtu rrit nivelin e ndërveprimit të ekipeve dhe ul rreziqet e specializimit të ngushtë si në nivelin e individëve ashtu edhe të ekipeve.
Tabela 1. Përcaktimet e detyrave OpenShift
Detyrat
Aftësitë e kërkuara
Automatizimi dhe përgatitja (provisioning) e infrastrukturës IT
Punë:
- Projektimi dhe ndërtimi i zgjidhjeve harduerike
- Organizimi dhe mbështetje e automatizimit të konfigurimit fillestar
- Projektimi dhe automatizimi i përgatitjes së VM-ve dhe hosteve
- Projektimi dhe implementimi i qendrave të të dhënave
- Administrimi i sistemeve Linux
- Skenarët e automatizimit
- Njohuri mbi sistemet e ruajtjes
- Njohuri në projektimin dhe implementimin e rrjeteve
- Siguria
Instalimi dhe menaxhimi i platformës OpenShift
Punë:
- Kryerja e instalimit të klasterëve
- Menaxhimi i shërbimeve infrastrukturore
- Menaxhimi i shkallëzimit të platformës
- Verifikimi i autenticitetit dhe autorizimi në nivelin e platformës
- Administrimi i sistemeve Linux
- Njohuri mbi teknologjitë rrjet
- Skencar automatik (Ansible)
- Njohuri mbi sistemet e ruajtjes
- Njohuri mbi teknologjitë dhe arkitekturat e kontejnerëve
- Njohuri mbi arkitekturat Kubernetes dhe OpenShift
- Siguria e platformave
- Integrimi i monitorimit
Menaxhimi i përgatitjes së ambientit të klientëve (tenant provisioning), izolimi i burimeve IT
Punë:
- Krijimi i përdoruesve dhe grupeve brenda platformës
- Projektimi dhe menaxhimi i kuotave
- Projektimi dhe implementimi i RBAC
- Njohuri mbi arkitekturat Kubernetes dhe OpenShift
- Njohuri mbi teknologjitë dhe arkitekturat e kontejnerëve
- Skenarët e automatizimit
- Njohuri të mira mbi projektet, kuotat, ngarkesat e rolit dhe punën me planifikuesit
Konstruksioni dhe menaxhimi i imazheve bazë
Punë:
- Zhvillimi i procesit të ndryshimit të imazheve
- Zhvillimi i imazheve sipas standardeve
- Administrimi i sistemeve Linux
- Skenarët e automatizimit
- Konfigurimi i komponentëve runtime të aplikacioneve dhe middleware
- Njohuri mbi arkitekturat e kontejnerëve
- Kornizat e ndërtimit të aplikacioneve
- Njohuri të mira mbi imazhet, imagestream dhe mënyrat
Projektimi dhe menaxhimi i kanaleve të shpërndarjes
Punë:
- Projektimi dhe dokumentimi i standardeve të kanaleve
- Zhvillimi i udhëzimeve dhe shablloneve të shkurtër
- Trajnimi i zhvilluesve
- Menaxhimi i kodit burimor
- Projektimi dhe zbatimi i aplikacioneve
- Skenarët e automatizimit
- Testimi automatizuar
- Testimi i cilësisë së kodit
- Njohuri mbi arkitekturat e kontejnerëve
- Njohuri mbi infrastrukturat immutable
- Siguria – menaxhimi i aksesit në fazat e kanalit, miratimi i flukseve të punës etj.
- Njohuri të mira mbi shabllonet OpenShift, komponentët buildconfigs, deploymentconfigs, services, routes, configmaps
Zhvillimi i aplikacioneve dhe testeve
Punë:
- Kodimi i aplikacioneve
- Zhvillimi i testeve automatizuar
- Reagimi ndaj dështimeve të testeve gjatë kanalit të shpërndarjes
- Reagimi ndaj dështimeve të aplikacioneve
- Testimi pranues i përdoruesve
- Projektimi dhe zbatimi i aplikacioneve
- Testimi automatizuar
- Menaxhimi i kodit burimor
- Monitorimi i aplikacioneve
- Njohuri mbi arkitekturat e aplikacioneve cloud native
Monitorimi operacional dhe menaxhimi i aplikacioneve
Punë:
- Projektimi i aplikacioneve në kontekstin e performancës
- Monitorimi i aplikacioneve në fazën e ekzekutimit
- Dimensionimi i aplikacioneve (ose automatik i dimensionimit)
- Menaxhimi i disponueshmërisë së aplikacioneve
- Kufijtë e kërkesave dhe kufijtë e menaxhimit të burimeve
- Testimi i performancës dhe kapaciteteve IT
- Projektimi dhe realizimi i performancës së aplikacioneve
- Monitorimi i performancës së aplikacioneve
- Testimi i performancës dhe testimi nën ngarkesë
Testimi pranues i përdoruesve
Punë:
- Testimi UI (dizajni dhe ndërveprimi me përdoruesin)
- Zhvillimi i testeve automatizuar
- Projektimi dhe verifikimi i ndërfaqeve të përdoruesit
- Shabllone për testimin automatizuar
- Kornizat e testimit
- Shabllone të projektimit të aplikacioneve
Rolit e reja që shfaqen në organizatën IT gjatë migrimit në OpenShift
Me kalimin në një model organizativ të orientuar drejt DevOps, numri i specializimeve të roleve zakonisht zvogëlohet, ndërsa numri i skuadrave dhe roleve ndër-funksionale rritet për të maksimizuar efikasitetin e bashkëpunimit. Këtu është si mendojmë se duket lista e pozitat kryesore në një organizatë IT që përdor OpenShift:
- Inxhinieri i operacioneve të aplikacioneve (Application Operations Engineer) OSE Inxhinieri i qëndrueshmërisë së faqes (Site Reliability Engineer). Më parë, kjo pozita mund të ishte quajtur "Administrator i serverit të aplikacioneve".
- Zhvillues aplikacionesh / zhvillues softueri / inxhinier programi.
- Administrator i klasterit/platformat e aplikacioneve. Më parë, kjo rol mund të quhej "Administrator Sistemi" ose "Administrator i Platformave Linux."
- Menaxheri i lëshimit të softuerit (Release Manager)/Inxhinieri i ndërtimit (Build Engineer).
Matrica e roleve dhe detyrave RACI
Më në fund, ne kalojmë në përputhjen e pozitave dhe detyrave të shqyrtuara më lart, për të ofruar një përmbledhje se si duhet të duket struktura e organizatës që zbaton DevOps në platformën OpenShift. Fillimisht, pozitat e renditura më poshtë mund të përballohen nga degët e vjetrës strukturë organizative tradicionale. Por me kalimin e kohës ndodh konsolidimi dhe formohen ekipe të reja, të ndërtuara rreth aplikacioneve, të cilat mbulojnë shumicën ose madje të gjitha detyrat e renditura më poshtë.
Detyrat
Rollet
Inxhinieri i funksionimit të aplikacioneve/Inxhinieri i besueshmërisë së sitit
Zhvillues aplikacionesh/Zhvillues softueri/Inxhinier i programimit
Administrator i klasterit/platformat e aplikacioneve
Menaxher i lëshimit të softuerit/Inxhinier i ndërtimit
Automatizimi dhe përgatitja (provisioning) e infrastrukturës IT
I
I
R/A
C
Instalimi dhe menaxhimi i platformës OpenShift
C
I
R/A
C
Projektimi dhe menaxhimi i kanaleve të shpërndarjes
C
C
I
R/A
Menaxhimi i përgatitjes së ambientit të klientëve (tenant provisioning), izolimit dhe kapaciteteve IT
C
I
R/A
I
Konstruksioni dhe menaxhimi i imazheve bazë
R
C
R/A
C
Zhvillimi i aplikacioneve dhe testeve
C
R/A
I
I
Monitorimi operacional dhe menaxhimi i aplikacioneve
R/A
C
C
I
Testimi pranues i përdoruesve
C
R
I
I
Simbolet në matricën RACI
Burimi:
- Përgjegjës – Kryesuesi – ai që bën gjithçka të nevojshme për të përmbushur detyrën.
- Përgjegjës – Përgjegjës – punonjësi që në fund të fundit është përgjegjës për përmbushjen e saktë dhe të kujdesshme të detyrës ose arritjen e rezultatit; gjithashtu, ai është i vetmi që mund të delegojë punën te kryesuesit.
- Konsultuar – Konsulentët – zakonisht janë ekspertë në fushën përkatëse, të cilët kërkohet mendimi i të cilëve; me ta mbahet komunikim dypalësh.
- Informuar – Të informuarit – njerëzit që mbahen të informuar (ndonjëherë vetëm pas përfundimit të detyrës ose arritjes së rezultatit); ata marrin informacion në një mënyrë njëpalëshe.
Si funksionon bashkëpunimi i ekipeve në një organizatë DevOps
Sistemi tradicional i marrjes së burimeve shpesh përfshin një cikël kërkesash për alokimin e burimeve, të cilat më pas ekzekutohen nga disa ekipe. Në fund, të gjitha burimet e nevojshme alokohen dhe konfirmohen nga pala që ka bërë kërkesën. Shpesh, këto procese realizohen pjesërisht, ose madje plotësisht, manualisht dhe kërkojnë ndërveprime të shpeshta dhe të shumta mes ekipeve për një përpunim të suksesshëm të çdo kërkese.
Figura 1. Organizata tradicionale IT
Grafiku më sipër ilustron marrëdhëniet tipike ndërmjet ekipeve në një organizatë tradicionale IT. Në kuadër të kësaj skeme, disa ekipe i drejtohen ekipeve të tjera me kërkesa për përfundimin e punëve të nevojshme, duke përdorur mjete komunikimi më formale ose më pak formale, si sistemi i ticket-eve ose e-maili. Këto kërkesa pastaj hyjnë në rendin e pritjes dhe presin radhën e tyre, ku pritja e gjatë shpesh çon në përkeqësim, madje edhe përshkallëzim të marrëdhënieve ndërmjet ekipeve. Tensioni përkeqësohet gjithashtu nga fakti që anëtarët e ekipeve të ndryshme rrallë takohen personalisht dhe, zakonisht, ndajnë vetëm informacionin minimal të nevojshëm.
Figura 2. Organizata IT DevOps
Ky kjo diagramë tregohet se si funksionon bashkëpunimi në organizatën DevOps. Këtu janë të njëjtat ekipe nga diagrami i mëparshëm që lanë pas komunikimet e pasuksesshme, të cilat forconin ndarjet, dhe i zëvendësuan ato me kontaktet personale, duke krijuar kështu kanale të përhershme ndërveprimi midis ekipeve. Këto kanale ndihmojnë në formimin e një grupi hibrid aftësish, i cili ndihmon punonjësit të kuptojnë dhe paraqesin më mirë nevojat, problemet dhe mundësitë e atyre ekipeve që ata përfaqësojnë. Ekipet ofrojnë njëra-tjetrës mundësinë për të kryer punët e nevojshme përmes portaleve automatizuar të vetëshërbimit, në vend që të punojnë manualisht për kërkesat e ndryshimeve të të tjerëve, siç ndodhte më parë. Dhe falë pranisë së kanaleve të ndërveprimit, këto sisteme vetëshërbimi janë të afta të adaptohen shpejt ndaj nevojave të ekipeve për të cilat janë krijuar. Për të arritur akoma më shumë mirëkuptim dhe shkëmbim informacioni brenda organizatës, anëtarët e ekipeve kryejnë përkohësisht rotacionin e roleve, për të përfituar përvojë në ndërveprimin me ekipe të ndryshme dhe për të kuptuar më mirë pamjen e përgjithshme të sistemeve IT që ata mbulojnë, duke rritur kështu nivelin e tyre të ndërfunksionalitetit dhe përdorueshmërisë.
Në përfundim
Në këtë postim, ne shpjeguam se si zbatimi i zgjidhjeve PaaS mund të nxisë një organizatë të adoptojë metodologjinë DevOps, duke përfshirë në këtë proces ndryshimin e roleve dhe detyrave tradicionale. Prandaj, kemi renditur detyrat kryesore të IT-së që dalin në organizatë me kalimin në OpenShift, si dhe aftësitë e nevojshme për t'i kryer ato. Po ashtu, kemi paraqitur një grup themelor rolish organizative që lindin gjatë ndërtimit të ekipeve DevOps me funksione të ndryshme, si dhe një matriçë RACI që lidh rolet e reja me detyrat e reja. Dhe në fund, ne shpjeguam se si platforma OpenShift dhe metodologjia DevOps mund të ndryshojnë strukturën organizative të kompanisë duke kaluar nga hierarkia tradicionale dhe sistemet e menaxhimit të kërkesave në ekipe funksionale me një nivel më të lartë të komunikimeve personale.
Burimi: habr.com
