Cum OpenShift schimbă structura organizațională a unei organizații IT. Evoluția modelurilor organizaționale în tranziția către PaaS

Deși soluțiile PaaS („Platforma ca Serviciu”) în sine nu pot schimba modul în care interacționează indivizii și echipele, ele servesc adesea ca un catalizator pentru schimbări organizaționale ca răspuns la flexibilitatea crescută a tehnologiilor IT.

În practică, maximizarea rentabilității investițiilor în PaaS este adesea posibilă doar cu condiția schimbării rolurilor organizaționale, ariilor de responsabilitate și schemelor de relaționare. Din fericire, soluțiile PaaS, cum ar fi OpenShift Container Platform, oferă suficientă flexibilitate pentru ca fiecare organizație IT să poată stabili autonom viteza și amploarea schimbărilor în raport cu persoanele implicate și procesele în desfășurare.

În prima etapă a containerizării, prioritatea principală este implementarea platformei de containere ca nou sistem de desfășurare a aplicațiilor. În acest moment, organizațiile leagă activitățile familiare de rolurile cunoscute pentru a răspunde cererilor standard ale echipelor de dezvoltare în ceea ce privește sistemele de stocare, mediile de desfășurare etc. În etapele ulterioare ale containerizării, discuția se concentrează deja pe automatizare sau pe oferirea de oportunități de autoservire dezvoltatorilor pentru a reduce sarcina administratorilor de sistem și a îmbunătăți autonomia și operativitatea dezvoltatorilor. Așa se îndreaptă organizația către DevOps. În etapa finală a containerizării, organizațiile ajung la un model DevOps mai curat și canonic, în cadrul căruia multe dintre sarcinile și activitățile anterioare trec sub controlul echipelor interfunctionale, care sunt grupate nu pe baza platformelor sau tehnologiilor, ci din perspectiva asigurării funcționării aplicațiilor sau serviciilor aplicațiilor.

În această postare, vom prezenta un ghid pentru efectuarea schimbărilor organizaționale necesare și vom explica cum se schimbă rolurile tradiționale IT prin implementarea tehnologiilor de containere în cadrul organizațiilor.

Legarea de noi activități la vechile roluri

În forma sa de bază, modelul organizațional PaaS este creat pentru a aloca resursele IT aplicațiilor ca mediu de execuție într-un mod mai flexibil și rapid. Deși acest lucru aduce anumite avantaje administratorilor de sistem, dezvoltatorii, în general, nu beneficiază de câteva câteva oportunități substanțiale în această etapă, deoarece compania poate funcționa fără a începe automatizarea, a introduce auto-serviciul sau a îmbunătăți radical canalul de desfășurare. PaaS, minimizând impactul asupra proceselor de dezvoltare în această etapă, îmbunătățește totuși dinamica sistemului IT, permițând administratorilor să răspundă mai bine cerințelor dezvoltatorilor. De exemplu, dacă anterior crearea unui mediu de dezvoltare din mai multe mașini virtuale volume de stocare putea dura zile sau chiar săptămâni, necesitând implicarea mai multor administratori diferiți, în PaaS totul se desfășoară mult mai repede și cu ajutorul unui singur administrator. Cu alte cuvinte, echipele de dezvoltatori depun cereri ca și înainte, dar lucrările de implementare a acestor cereri sunt acum efectuate conform unui nou model.

Pe calea spre organizația DevOps

Prin lansarea PaaS și transferarea specialiștilor în exploatarea sistemelor IT și dezvoltatorilor de aplicații pe această platformă, organizația poate continua implementarea metodologiei DevOps, care include printre altele următoarele principii fundamentale:

• Împărțirea muncii în etape mai mici, pentru a obține feedback în stadii incipiente, reducând riscurile și evitând 'paralizia analitică';
• Automatizarea operațiunilor într-o măsură suficientă, pentru a nu crea obstacole sau blocaje în procesul de desfășurare a aplicației;
• Schimbul de cunoștințe – cheia construirii încrederii;
• Plata regulată a datoriilor tehnice, alocând în fiecare ciclu de lucru timp specific pentru îmbunătățiri sistematice.

În a doua etapă de implementare a tehnologiilor containerizate, echipele de dezvoltare încep, desigur, să observe oportunități de îmbunătățire, iar organizația se îndreaptă către un model DevOps mai canonical. Mecanismul tradițional de trimitere și executare a cererilor de întreținere este acum perceput ca un punct slab, așa că organizația își propune să automatizeze acțiunile repetitive și să ofere dezvoltatorilor opțiuni de autogestionare. Aceste capacități ale dezvoltatorilor în cadrul unei cereri sunt determinate prin eforturile comune ale specialiștilor IT în exploatarea platformelor și a celor responsabili de livrarea aplicațiilor. Cu alte cuvinte, în locul administratorilor de sistem care efectuează acțiuni pe cererile dezvoltatorilor, apar cele două categorii menționate mai sus, care sunt responsabile pentru descrierea și aplicarea politicilor care reglementează ce anume li se permite dezvoltatorilor să facă singuri. Procedurile automatizate ajută la asigurarea respectării acestor cerințe și a coordonării acțiunilor în cazurile în care situația depășește politicile în vigoare.

Trecerea la un program iterativ, în care mediu IT și modelul operațional suferă modificări iterative în timp, este un punct de cotitură critic în formarea unei sisteme DevOps mature în cadrul organizației. Gradul de adoptare a metodologiei DevOps depinde de toleranța fiecărei organizații la schimbări și de tipul de schimbări care aduc cele mai mari beneficii. De exemplu, dacă nevoia de a crea medii sau aplicații noi apare rar, atunci optimizarea acțiunilor corespunzătoare va fi mai puțin importantă decât consolidarea controlului dezvoltatorilor asupra ciclului de viață al aplicațiilor.

Noi provocări care apar în organizațiile IT în timpul tranziției către OpenShift

În această secțiune, vom explora rolurile și sarcinile pe care organizațiile care au trecut la OpenShift le aplică de obicei pentru a accelera automatizarea și autogestionarea utilizând tehnologii și PaaS.

În tabelul de mai jos sunt enumerate principalele sarcini de nivel superior care există în orice organizație care a implementat OpenShift, cu exemple de lucrări și abilități corespunzătoare. Această listă de sarcini nu trebuie confundată cu schema de defalcare a activităților sau cu structura organizațională a echipelor, ci este doar un set de sarcini care trebuie îndeplinite de persoanele responsabile pentru suportul mediului IT, pentru o implementare de succes a platformei containerizate. În realitate, mai târziu vom arăta că implementarea tehnologiilor containerizate creează condițiile pentru formarea unei strategii DevOps mai mature în cadrul organizației, ceea ce, la rândul său, crește gradul de cross-funcționalitate al echipelor și reduce riscurile de specializare restrânsă la nivelul atât al angajaților individuali, cât și al echipelor.

Tabelul 1. Definiții ale sarcinilor OpenShift

Sarcini
Abilități necesare

Automatizarea și pregătirea (provisioning) infrastructurilor IT

Lucrări:

• Proiectarea și construirea soluțiilor hardware
• Organizarea și susținerea automatizării configurării inițiale
• Proiectarea și automatizarea pregătirii VM-urilor și gazdelor

• Proiectarea și implementarea centrelor de date
• Administrarea sistemelor Linux
• Scripte de automatizare
• Cunoștințe despre sistemele de stocare
• Cunoștințe în domeniul proiectării și implementării rețelelor
• Securitate

Instalarea și gestionarea platformei OpenShift

Lucrări:

• Executarea instalării cluster-ului
• Managementul serviciilor de infrastructură
• Managementul scalării platformei
• Verificarea autenticității și autorizarea la nivelul platformei

• Administrarea sistemelor Linux
• Cunoștințe despre tehnologiile de rețea
• Scripte de automatizare (Ansible)
• Cunoștințe despre sistemele de stocare
• Cunoștințe despre tehnologiile și arhitecturile containerizate
• Cunoștințe despre arhitecturile Kubernetes și OpenShift
• Securitatea platformelor
• Integrarea monitorizării

Managementul pregătirii mediilor client (tenant provisioning), izolarea capacităților IT

Lucrări:

• Crearea utilizatorilor și echipelor în cadrul platformei
• Proiectarea și gestionarea cotelor
• Proiectarea și implementarea RBAC

• Cunoștințe despre arhitecturile Kubernetes și OpenShift
• Cunoștințe despre tehnologiile și arhitecturile containerizate
• Scripte de automatizare
• Cunoștințe bune în domeniul proiectelor, cotelor, legării rolurilor și muncii cu planificatorii

Construirea și gestionarea imaginilor de bază

Lucrări:

• Dezvoltarea fluxului de lucru pentru modificarea imaginilor
• Dezvoltarea imaginilor pe baza standardelor

• Administrarea sistemelor Linux
• Scripte de automatizare
• Configurarea componentelor runtime ale aplicațiilor și middleware-ului
• Cunoștințe despre arhitecturile containerizate
• Cadre de construcție a aplicațiilor (application build frameworks)
• Cunoștințe bune în domeniul imaginilor, imagestream-urilor și șabloanelor

Proiectarea și gestionarea fluxurilor de livrare

Lucrări:

• Proiectarea și documentarea standardelor fluxurilor
• Dezvoltarea ghidurilor și șabloanelor concise
• Formarea dezvoltatorilor

• Gestionarea codului sursă
• Proiectarea și implementarea aplicațiilor
• Scripte de automatizare
• Testare automatizată
• Testarea calității codului
• Cunoștințe despre arhitecturile containerizate
• Cunoștințe despre infrastructuri immutable
• Securitate - gestionarea accesului la etapele fluxului, aprobarea proceselor de lucru etc.
• Cunoștințe solide despre șabloanele OpenShift, componentele buildconfigs, deploymentconfigs, servicii, rute, configmaps

Dezvoltarea aplicațiilor și testelor

Lucrări:

• Programarea aplicațiilor
• Dezvoltarea testelor automatizate
• Reacția la eșecurile testelor în desfășurarea fluxului
• Reacția la defecțiunile aplicațiilor
• Testarea de acceptare a utilizatorului

• Proiectarea și implementarea aplicațiilor
• Testare automatizată
• Gestionarea codului sursă
• Monitorizarea aplicațiilor
• Cunoștințe despre arhitecturile aplicațiilor cloud-native

Monitorizarea operațională și gestionarea aplicațiilor

Lucrări:

• Proiectarea aplicațiilor în contextul performanței
• Monitorizarea aplicațiilor în timpul execuției
• Scalarea aplicațiilor (sau scalarea automată)
• Gestionarea disponibilității aplicațiilor
• Cotele de cereri și limitele pentru gestionarea resurselor
• Testarea performanței și a capacităților IT

• Proiectarea și implementarea performanței aplicațiilor
• Monitorizarea performanței aplicațiilor
• Testarea performanței și teste de adaos

Testarea de acceptare a utilizatorului

Lucrări:

• Testarea UI (design și interacțiuni utilizator)
• Dezvoltarea testelor automatizate

• Proiectarea și verificarea interfețelor utilizator
• Șabloane pentru testarea automatizată
• Cadre de testare
• Șabloane pentru proiectarea aplicațiilor

Noi roluri care apar în organizația IT atunci când se trece la OpenShift

Pe măsură ce se trece la un model organizațional orientat spre DevOps, numărul specializărilor rolurilor de obicei scade, iar numărul echipelor și rolurilor interfuncționale crește pentru a maximiza eficiența colaborării. Iată cum, în opinia noastră, arată lista principalelor poziții dintr-o organizație IT care utilizează OpenShift:

• Inginer de operațiuni aplicații (Application Operations Engineer) sau Inginer de fiabilitate site (Site Reliability Engineer). Anterior, această poziție putea fi numită „Administrator server aplicații”.
• Dezvoltator aplicații/dezvoltator software/inginer de programare.
• Administrator de cluster / platformă de aplicații. Anterior, acest rol ar putea fi numit „Administrator de sistem” sau „Administrator de platforme Linux”.
• Manager de lansare software (Release Manager) / Inginer de construcție (Build Engineer).

Matrița rolurilor și sarcinilor RACI

În cele din urmă, ajungem la corelarea pozițiilor și sarcinilor discutate mai sus, pentru a oferi o imagine generală despre cum ar trebui să arate structura organizațională care implementează DevOps pe platforma OpenShift. Rolurile specificate mai jos pot fi inițial realizate de ramurile vechii structuri organizaționale tradiționale. Dar, în timp, se realizează consolidări și apar noi echipe, structurate în jurul aplicațiilor, care își asumă majoritatea sau chiar toate sarcinile enumerate mai jos.

Sarcini
Roluri

Inginer de operațiuni aplicații / Inginer de fiabilitate site.
Dezvoltator de aplicații / Dezvoltator software / Inginer programator.
Administrator de cluster / platformă de aplicații.
Manager de lansare software / Inginer de construcție.

Automatizarea și pregătirea (provisioning) infrastructurilor IT
I
I
R / A
C

Instalarea și gestionarea platformei OpenShift
C
I
R / A
C

Proiectarea și gestionarea fluxurilor de livrare
C
C
I
R / A

Gestionarea pregătirii mediilor clientului (tenant provisioning), izolării și capacităților IT.
C
I
R / A
I

Construirea și gestionarea imaginilor de bază
R
C
R / A
C

Dezvoltarea aplicațiilor și testelor
C
R / A
I
I

Monitorizarea operațională și gestionarea aplicațiilor
R / A
C
C
I

Testarea de acceptare a utilizatorului
C
R
I
I

Semne convenționale în matricea RACI.
Sursa: Wikipedia

• Responsabil – Cel care efectuează – persoana care face tot ceea ce este necesar pentru a îndeplini sarcina.
• Responsabil – Cel responsabil – angajatul care, în cele din urmă, răspunde pentru îndeplinirea corectă și atentă a sarcinii sau pentru atingerea rezultatului; de asemenea, este singurul care poate delega munca executanților.
• Consultați – Consultanți – de obicei, sunt experți în domeniu, a căror opinie este solicitată; se menține o comunicare bidirecțională cu aceștia.
• Informați – Cei informați – persoanele care sunt ținute la curent cu evenimentele (de multe ori, doar la finalizarea sarcinii sau obținerea rezultatului); primesc informații într-o manieră unidirecțională.

Cum funcționează colaborarea echipelor în organizația DevOps.

Schema tradițională de obținere a resurselor, în general, reprezintă un ciclu de solicitări de alocare a resurselor, care sunt apoi procesate de mai multe echipe. La final, toate resursele necesare sunt alocate și confirmate de partea solicitantă. Adesea, aceste procese sunt parțial, dacă nu chiar complet, realizate manual și necesită interacțiuni frecvente și numeroase între echipe pentru a gestiona cu succes fiecare cerere.

Figura 1. Organizația IT tradițională

Diagrama de mai sus ilustrează relațiile tipice dintre echipele dintr-o organizație IT tradițională. În cadrul acestei scheme, unele echipe se adresează altor echipe cu cereri de efectuare a lucrărilor necesare, folosind mijloace de comunicare mai mult sau mai puțin formalizate, precum sistemele de tichete sau e-mailul. Aceste cereri ajung apoi în coadă și așteaptă rândul, iar așteptarea îndelungată duce adesea la deteriorarea sau chiar intensificarea relațiilor dintre echipe. Tensiunile sunt accentuate și de faptul că membrii diferitelor echipe se întâlnesc rar personal și, în general, împărtășesc doar informațiile minim necesare.

Figura 2. Organizația IT DevOps

Această diagramă arată cum funcționează colaborarea în organizația DevOps. Aici, aceleași echipe din diagrama anterioară au renunțat la comunicările ineficiente care accentuau fragmentarea și le-au înlocuit cu contacte personale, creând astfel canale permanente de interacțiune între echipe. Aceste canale contribuie la formarea unui set hibrid de competențe, care ajută angajații să înțeleagă și să prezinte mai bine nevoile, problemele și oportunitățile echipelor pe care le reprezintă. Echipele permit una alteia să realizeze lucrările necesare prin intermediul portalurilor de autoservire automatizate în loc să răspundă manual la solicitările de modificare ale altora, ca în trecut. Și, datorită prezenței canalelor de interacțiune, aceste sisteme de autoservire se pot adapta rapid nevoilor echipelor pentru care sunt create. Pentru a realiza o mai bună înțelegere și schimb de cunoștințe în cadrul organizației, membrii echipelor efectuează periodic rotații de roluri pentru a acumula experiență în interacțiunea cu diferite echipe și a înțelege mai bine imaginea de ansamblu a sistemelor IT pe care le deservesc, crescând astfel nivelul lor de funcționalitate transversale și utilitate.

În concluzie

În acest post, am discutat despre cum implementarea soluțiilor PaaS poate determina organizația să adopte metodologia DevOps, iar în cadrul acestui proces, rolurile și sarcinile tradiționale suferă modificări. De aceea, am enumerat principalele sarcini IT care apar într-o organizație în urma tranziției la OpenShift, precum și abilitățile necesare pentru a le îndeplini. De asemenea, am prezentat setul principal de roluri organizaționale care apar în construirea echipelor DevOps multifuncționale și matricea RACI, care corelează noile roluri cu noile sarcini. Și în final, am arătat cum platforma OpenShift și metodologia DevOps asociată pot schimba structura organizațională a unei organizații prin tranziția de la ierarhiile tradiționale și sistemele de gestionare a cererilor la echipe multifuncționale cu un nivel mai ridicat de comunicare personală.

Sursa: habr.com