Si OpenShift ndryshon strukturën organizative të IT-ndërmarrjeve. Evolucioni i modeleve organizative gjatë kalimit në PaaS

Megjithëse zgjidhjet PaaS ("Platformë si Shërbim") nuk janë në vetvete të afta të ndryshojnë mënyrat e bashkëpunimit individual dhe ekipor, ato shpesh shërbejnë si katalizator për ndryshime organizative në përgjigje të rritjes së fleksibilitetit të teknologjive IT.

Në praktikë, maksimizimi i kthimit të investimeve në PaaS shpesh është i mundur vetëm nëse ndryshojnë rolet organizative, sferat e përgjegjësive dhe skemat e marrëdhënieve. Fatmirësisht, zgjidhjet PaaS, të tilla si OpenShift Container Platform, kanë mjaft fleksibilitet që çdo IT-organizate t'i përcaktojë vetë shpejtësinë dhe shkallën e ndryshimeve në lidhje me njerëzit e angazhuar dhe proceset që ndodhin.

Në fazën e parë të containerizimit, prioriteti kryesor është implementimi i platformës së konteinerëve si një sistem të ri për shpërndarjen e aplikacioneve. Në këtë moment, organizatat i lidhin punët e njohura me rolet e njohura, për të reaguar ndaj kërkesave standarde të ekipeve të zhvillimit në çështje, si sistemet e ruajtjes, mjediset e shpërndarjes etj. Në fazat e mëvonshme të containerizimit, tashmë flitet për automatizimin ose ofrimin e mundësive të vetë-shërbimit nga zhvilluesit, për të reduktuar ngarkesën mbi administratorët e sistemeve dhe për të rritur autonominë dhe efikasitetin e zhvilluesve në një nivel më të lartë. Kështu, organizata fillon të lëvizë drejt DevOps. Në fazën përfundimtare të containerizimit, ndërmarrja arrin një model më të pastër dhe kanonik DevOps, ku shumë nga detyrat dhe punët e mëparshme kalojnë nën kontrollin e ekipeve ndër-funksionale, të cilat grupohen jo sipas platformave apo teknologjive, por nga pikëpamja e sigurimit të funksionimit të aplikacioneve ose shërbimeve aplikative.

Në këtë postim ne do të paraqesim një udhëzues për realizimin e ndryshimeve të nevojshme organizative dhe do të flasim për mënyrën se 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, model organizativ PaaS formohet për të ndarë burimet IT të aplikacioneve në një mjedis ekzekutimi më fleksibël dhe më të shpejtë. Ndërsa kjo ofron disa përfitime për administratorët e sistemeve, zhvilluesit zakonisht nuk fitojnë asnjë përfitim të konsiderueshëm dhe mundësi të reja, pasi në këtë fazë, kompania mund të funksionojë pa filluar automatizimin, të ofrojë vetë-shërbim ose të përmirësojë në mënyrë drastike procesin e shpërndarjes. Gjithsesi, duke prekur minimalisht proceset e zhvillimit në këtë fazë, PaaS 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ë mjedisi zhvillimi nga disa makinat virtuale dhe volume të ruajtjes mund të merrte ditë, madje edhe javë dhe kërkonte pjesëmarrjen e disa administratorëve të ndryshëm, në PaaS gjithçka bëhet shumë më shpejt dhe me ndihmën vetëm të një administratori. Në të tjera fjalë, ekipet e zhvilluesve paraqesin kërkesa ashtu si më parë, por punët për realizimin e këtyre kërkesave tani realizohen sipas një skeme të re.

Në rrugën drejt organizatës DevOps

Duke nisur PaaS dhe duke kaluar specialistët e sistemit IT dhe zhvilluesit e aplikacioneve në të, organizata mund të vazhdojë zbatimin e metodologjisë DevOps, e cila përfshin midis të tjerash parimet kryesore:

• Të ndahen punët në etapa të vogla, për të marrë feedback në fazat e hershme, për të ulur rrezikun dhe për të shmangur 'paralizën analitike';
• Të automatizohen operacionet në mënyrë të mjaftueshme, për të mos krijuar pengesa ose pika të ngushta në procesin e shpërndarjes së aplikacioneve;
• Shkëmbimi i njohurive është çelësi për ndërtimin e besimit;
• Të paguhen rrethanat teknike me rregull, duke rezervuar kohë të caktuar në çdo cikël pune për përmirësime sistematike.

Në fazën e dytë të implementimit të teknologjive të kontejnerëve, ekipet e zhvillimit fillojnë natyrshëm të shohin mundësi për përmirësim dhe kompania priret drejt një modeli më kanonik DevOps. Mekanizmi tradicional i dorëzimit dhe ekzekutimit të kërkesave për shërbim tani perceptohet si një pikë e ngushtë, prandaj organizata synon të automatizojë veprimet e përsëritura dhe t'u ofrojë zhvilluesve mundësi vetë-shërbimi. Mundësitë e zhvilluesve në kuadër të çdo kërkese përcaktohen përmes përpjekjeve të përbashkëta të specialistëve të IT-së që operojnë platformat dhe atyre që përgjigjen për dorëzimin e aplikacioneve. Në thelb, në vend të administratorëve të sistemeve që kryejnë veprime sipas kërkesave të zhvilluesve, vijnë dy kategori të lartpërmendura të punonjësve që janë përgjegjës për përshkrimin dhe zbatimin e politikave që rregullojnë se çfarë është lejuar që zhvilluesit të bëjnë me forcat e tyre. Procedurat automatizuese ndihmojnë për të siguruar përputhshmërinë me këto kërkesa dhe për të koordinuar veprimet në raste kur situata del jashtë politikave në fuqi.

Kalimi në një skedë iteruese, ku mjedisi IT dhe modeli operacional përjetojnë ndryshime iteruese me kalimin e kohës, është një pikë kritike në planin e formimit të një sistemi të pjekur DevOps në kompani. Shkalla e pranim të metodologjisë DevOps varet nga toleranca e çdo organizate për ndryshimet dhe nga cilat ndryshime sjellin përfitimin më të madh. Për shembull, nëse nevoja për krijimin e mjediseve ose aplikacioneve të reja lind rrallë, atëherë optimizimi i veprimeve përkatëse do të jetë më pak i rëndësishëm se forca e kontrollit të zhvilluesve mbi ciklin e jetës së aplikacioneve.

Detyrat e reja që lindin në organizatat IT gjatë kalimit në OpenShift

Në këtë seksion do të shqyrtojmë rolet dhe detyrat që organizatat që kalojnë në OpenShift zakonisht i aplikojnë për të përshpejtuar automatizimin dhe vetë-shërbimin duke përdorur teknologji dhe PaaS.

Tabela më poshtë rendit 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 një skemë ndarjeje të punëve ose me strukturën organizative të grupeve, është thjesht një grup detyrash që duhet të përmbushen 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 kushte për formimin e një strategie më të përmirësuar DevOps në ndërmarrje, gjë që nga ana e saj rrit shkallën e ndërfunksionalitetit të ekipeve dhe ul rreziket e specializimit të ngushtë si në nivelin e individëve ashtu edhe të ekipeve.

Tabela 1. Përkufizimet e detyrave OpenShift

Detyrat
Aftësitë e nevojshme

Automatizimi dhe përgatitja (provisioning) e infrastrukturave IT

Punët:

• Projektimi dhe ndërtimi i zgjidhjeve harduerike
• Organizimi dhe mbështetja e automatizimit të konfigurimeve fillestare
• Projektimi dhe automatizimi i përgatitjes së VM-ve dhe hosteve

• Projektimi dhe realizimi i qendrave të të dhënave
• Administrimi i sistemit Linux
• Skematikët e automatizimit
• Dije për sistemet e ruajtjes
• Dije në projektimin dhe realizimin e rrjeteve
• Siguria

Instalimi dhe menaxhimi i platformës OpenShift

Punët:

• Kryerja e instalimit të klasit
• Menaxhimi i shërbimeve infrastrukturore
• Menaxhimi i shkallëzimit të platformës
• Verifikimi i identitetit dhe autorizimi në nivelin e platformës

• Administrimi i sistemit Linux
• Dije për teknologjitë rrjetësore
• Skematikët e automatizimit (Ansible)
• Dije për sistemet e ruajtjes
• Dije për teknologjitë dhe arkitekturat e kontejnerëve
• Dije për arkitekturat Kubernetes dhe OpenShift
• Siguria e platformave
• Integrimi i monitorimit

Menaxhimi i përgatitjes së mjediseve klientëve (tenant provisioning), izolimi me resurset IT

Punët:

• Krijimi i përdoruesve dhe grupeve brenda platformës
• Projektimi dhe menaxhimi i kuotave
• Projektimi dhe realizimi i RBAC

• Dije për arkitekturat Kubernetes dhe OpenShift
• Dije për teknologjitë dhe arkitekturat e kontejnerëve
• Skematikët e automatizimit
• Dije të mira në projektet, kuotat, lidhjet e roleve dhe punën me planifikuesit

Ndërtimi dhe menaxhimi i imazheve bazë

Punët:

• Zhvillimi i procesit të punës për ndryshimin e imazheve
• Zhvillimi i imazheve sipas standarteve

• Administrimi i sistemit Linux
• Skematikët e automatizimit
• Konfigurimi i komponentëve runtime të aplikacioneve dhe middleware
• Dije për arkitekturat e kontejnerëve
• Kornizat e ndërtimit të aplikacioneve (application build frameworks)
• Dije të mira në imazhet, imagestream dhe shabllonet

Projektimi dhe menaxhimi i kanaleve të shpërndarjes

Punët:

• Projektimi dhe dokumentimi i standarteve të kanaleve
• Zhvillimi i udhëzuesve të shkurtër dhe të template-ve
• Trajnimi i zhvilluesve

• Menaxhimi i kodit burimor
• Projektimi dhe implementimi i aplikacioneve
• Skematikët e automatizimit
• Testimi i automatizuar
• Testimi i cilësisë së kodit
• Dije për arkitekturat e kontejnerëve
• Dije për infrastrukturat immutable
• Siguria – menaxhimi i qasjes në fazat e kanalit, miratimi i proceseve të punës, etj.
• Njohuri e mirë mbi template-t e OpenShift, komponentët buildconfigs, deploymentconfigs, shërbimet, rrugët, configmaps

Zhvillimi i aplikacioneve dhe testeve

Punët:

• Kodimi i aplikacioneve
• Zhvillimi i testeve të automatizuara
• Reagimi ndaj dështimeve të testeve gjatë procesit të shpërndarjes
• Reagimi ndaj dështimeve të aplikacioneve
• Testimi i pranimit nga përdoruesi

• Projektimi dhe implementimi i aplikacioneve
• Testimi i automatizuar
• Menaxhimi i kodit burimor
• Monitorimi i aplikacioneve
• Dije për arkitekturat e aplikacioneve cloud-native

Monitorimi operativ dhe menaxhimi i aplikacioneve

Punët:

• Projektimi i aplikacioneve në kontekstin e performancës
• Monitorimi i aplikacioneve në fazën e ekzekutimit
• Skalimi i aplikacioneve (ose autoscaling)
• Menaxhimi i disponibilitetit të aplikacioneve
• Kuotat e kërkesave dhe kufijtë për menaxhimin e burimeve
• Testimi i performancës dhe kapaciteteve IT

• Projektimi dhe implementimi i performancës së aplikacioneve
• Monitorimi i performancës së aplikacioneve
• Testimi i performancës dhe testimi i ngarkesës

Testimi i pranimit nga përdoruesi

Punët:

• Testimi i UI (dizajni dhe ndërveprimi me përdoruesin)
• Zhvillimi i testeve të automatizuara

• Projektimi dhe verifikimi i ndërfaqeve të përdoruesit
• Template-t për testimin e automatizuar
• Kornizat e testimit
• Template-t për projektimin e aplikacioneve

Rolat e reja që shfaqen në organizatën IT gjatë kalimit në OpenShift

Me kalimin në një model organizativ të orientuar drejt DevOps, numri i specializimeve të rolit, zakonisht, zvogëlohet, dhe numri i ekipeve dhe rolëve ndër-funksionale rritet për të maksimizuar efikasitetin e bashkëpunimit. Këtu është siç mendojmë se duket lista e pozicioneve kryesore në organizatën IT që përdor OpenShift:

• Inxhinier i operacioneve të aplikacioneve (Application Operations Engineer) OSE Inxhinier i qëndrueshmërisë së faqes (Site Reliability Engineer). Më parë, ky post mund të ishte quajtur "Administrator i serverit të aplikacioneve."
• Zhvillues aplikacionesh / zhvillues softueri / inxhinier programimi.
• Administrator klasteri / platforme aplikacionesh. Më parë ky rol mund të quhej "Administrator sistemesh" ose "Administrator platformash Linux".
• Menaxher i lëshimit të softuerit (Release Manager) / Inxhinier i ndërtimit (Build Engineer).

Matrica e rolit dhe detyrave RACI

Së fundi, ne kalojmë në përputhjen e pozita dhe detyrave të shqyrtuara më sipër, për të dhënë një përmbledhje të përgjithshme se si duhet të duket struktura e organizatës që implementon DevOps në platformën OpenShift. Rolet e treguara më poshtë fillimisht mund të kryhen nga degë të vjetra të strukturës tradicionale organizative. Por me kalimin e kohës ndodh konsolidimi dhe krijohen ekipe të reja, të ndërtuara përreth aplikacioneve, që marrin përsipër shumicën ose madje të gjitha detyrat e treguara më poshtë.

Detyrat
Rolet

Inxhinier i operacioneve të aplikacioneve / Inxhinier i besueshmërisë së faqes
Zhvillues aplikacionesh / Zhvillues softueri / Inxhinier programimi
Administrator klasteri / platforme aplikacionesh
Menaxher i lëshimit të softuerit / Inxhinier i ndërtimit

Automatizimi dhe përgatitja (provisioning) e infrastrukturave 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ë mjediseve të klientëve (tenant provisioning), izolimit dhe kapaciteteve IT
C
I
R / A
I

Ndërtimi dhe menaxhimi i imazheve bazë
R
C
R / A
C

Zhvillimi i aplikacioneve dhe testeve
C
R / A
I
I

Monitorimi operativ dhe menaxhimi i aplikacioneve
R / A
C
C
I

Testimi i pranimit nga përdoruesi
C
R
I
I

Simbolet në matricën RACI
Burimi: Wikipedia

• Përgjegjës – Ekzekutuesi – ai që bën të nevojshmen për të përfunduar detyrën.
• Përgjegjës – Përgjegjës – punonjësi që është përfundimisht përgjegjës për përmbushjen e saktë dhe të kujdesshme të detyrës ose për arritjen e rezultatit; gjithashtu, ai është i vetmi që mund të delegojë punën te ekzekutuesit.
• Konsultuar – Konsulantët – zakonisht janë ekspertë në fushën përkatëse, këshillat e të cilëve kërkohen; ata mbajnë një komunikim dyanshëm.
• Të informuar – Të informuarit – njerëzit që mbahen në dijeni të ngjarjeve (dhe ndonjëherë vetëm pas përfundimit të detyrës ose arritjes së rezultatit); ata marrin informacion në mënyrë njëanshme.

Si është organizuar bashkëpunimi i ekipeve në një organizatë DevOps

Skema tradicionale e marrjes së burimeve zakonisht përbën një cikël kërkesash për alokimin e burimeve, të cilat më pas realizohen nga disa grupe. Në fund, të gjitha burimet e nevojshme alokohen dhe konfirmohen nga palë që po kërkon. Shpesh këto procese realizohen pjesërisht, madje edhe në tërësi, manualisht dhe kërkojnë ndërveprime të shpeshta dhe të shumta midis grupeve për një përpunim të suksesshëm të çdo kërkese.

Fig 1. Organizata tradicionale e IT-së

Diagrami më sipër ilustron marrëdhëniet tipike ndërmjet grupeve në një organizatë tradicionale IT. Në këtë skemë, disa grupe i drejtohen grupeve të tjera me kërkesën për të kryer punë të nevojshme, duke përdorur mjete komunikimi më shumë ose më pak të formizuara, si sistemi i tiketave ose emaili. Më pas, këto kërkesa shkojnë në radhë dhe presin momentin e tyre, ku pritja e gjatë shpesh çon në përkeqësim, madje edhe përshkallëzim të marrëdhënieve ndërmjet grupeve. Tensioni përkeqësohet edhe më shumë nga fakti se anëtarët e grupeve të ndryshme rrallë takohen fizikisht dhe, zakonisht, ndajnë vetëm informacionin e nevojshëm minimal.

Fig 2. Organizata IT DevOps

Kjo diagramë tregon se si funksionon bashkëpunimi në organizatën DevOps. Këtu, ekipet e njëjta nga diagrami i mëparshëm heqin dorë nga komunikimet joefektive që forcojnë ndarjen dhe i zëvendësojnë ato me kontakte personale, duke krijuar kështu kanale të vazhdueshëm ndërveprimi midis grupeve. Këto kanale ndihmojnë në formimin e një seti hibrid aftësish që ndihmon punonjësit të kuptojnë dhe paraqesin më mirë nevojat, problemet dhe mundësitë e atyre ekipeve që përfaqësojnë. Ekipet u japin njëra-tjetrës mundësinë për të kryer punët e nevojshme përmes portaleve të automatizuara të vetë-shërbimit në vend që të trajtojnë manualisht kërkesat për ndryshime si më parë. Dhe falë pranisë së kanaleve të ndërveprimit, këto sisteme të vetë-shërbimit janë në gjendje të adaptohen shpejt në nevojat e ekipeve për të cilët janë krijuar. Për të arritur edhe një nivel më të lartë mirëkuptimi dhe shkëmbimi informacioni brenda organizatës, anëtarët e ekipeve kryejnë periodike rotacione të rolit për të fituar përvojë në bashkëpunimin me grupe 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ë kros-funksionalitetit dhe përdorshmërisë.

Në përfundim

Në këtë postim, kemi treguar se si implementimi i zgjidhjeve PaaS mund të nxisë organizatën në adoptimin e metodologjisë DevOps, dhe në këtë proces, rolet dhe detyrat tradicionale pësojnë ndryshime. Prandaj, ne listuam detyrat kryesore IT që lindin në organizatë me kalimin në OpenShift, si dhe aftësitë e nevojshme për t'i përfunduar ato. Ne gjithashtu paraqitëm grupin kryesor të roleve organizative që lindin gjatë ndërtimit të ekipeve DevOps ndër-funksionale dhe matricën RACI që lidh rolet e reja me detyrat e reja. Dhe në fund, treguam se si platforma OpenShift dhe metodologjia e lidhur DevOps mund të ndryshojnë strukturën organizative të organizatës gjatë kalimit nga hierarkitë tradicionale dhe sistemet e përpunimit të kërkesave në ekipe ndër-funksionale me një nivel më të lartë të komunikimeve personale.

Burimi: habr.com