Aj keď samotné riešenia PaaS (platforma ako služba) nedokážu zmeniť spôsob interakcie jednotlivcov a tímov, často slúžia ako katalyzátor organizačných zmien v reakcii na zvýšenú agilitu IT.
V skutočnosti možno maximálnu návratnosť investícií PaaS často dosiahnuť len zmenou organizačných rolí, zodpovedností (úloh) a vzťahov. Našťastie riešenia PaaS, ako je OpenShift Container Platform, sú dostatočne flexibilné na to, aby umožnili každej IT organizácii určiť rýchlosť a rozsah zmien vzhľadom na zainteresovaných ľudí a procesy, ktoré sa vyskytujú.
V prvej fáze podnikovej kontajnerizácie je hlavnou prioritou implementácia kontajnerovej platformy ako nového systému nasadenia aplikácií. V tomto bode organizácie spájajú známe úlohy so známymi rolami, aby reagovali na štandardné požiadavky vývojových tímov týkajúce sa problémov, ako sú úložné systémy, prostredia nasadenia atď. V ďalších fázach kontajnerizácie už hovoríme o automatizácii alebo poskytovaní samoobslužných schopností vývojárom s cieľom znížiť záťaž systémových administrátorov a posunúť autonómiu a efektivitu vývojárov na vyššiu úroveň. Takto sa organizácia začína posúvať smerom k DevOps. V záverečnej fáze kontajnerizácie podnik prichádza k čistejšiemu, kanonickému modelu DevOps, v rámci ktorého mnohé z predchádzajúcich úloh a práce spadajú pod kontrolu medzifunkčných tímov, ktoré nie sú zoskupené podľa platforiem alebo technológií, ale z hľadiska pohľad na zabezpečenie prevádzky aplikácií alebo aplikačných služieb .
V tomto príspevku poskytneme návod, ako vykonať potrebné organizačné zmeny a ako sa menia tradičné IT roly s prijatím kontajnerových technológií v podniku.
Prepojenie nových pracovných miest so starými rolami
Vo svojej základnej, počiatočnej podobe je organizačný model PaaS navrhnutý tak, aby flexibilnejšie a rýchlejšie prideľoval IT zdroje aplikáciám ako runtime prostredie. Hoci to poskytuje určité výhody pre systémových administrátorov, vývojári zvyčajne nezískavajú žiadne významné výhody ani nové možnosti, pretože v tejto fáze sa podnik ľahko zaobíde bez automatizácie, samoobsluhy alebo radikálneho vylepšenia procesu nasadzovania. Hoci PaaS v tejto fáze minimálne ovplyvňuje vývojové procesy, zvyšuje agilitu IT systému, čo umožňuje administrátorom lepšie uspokojovať požiadavky vývojárov. Napríklad, zatiaľ čo predtým sa vývojové prostredie vytváralo z niekoľkých... virtuálne stroje Zatiaľ čo vytváranie a nasadzovanie úložných zväzkov môže trvať dni alebo dokonca týždne a vyžadovať si zapojenie viacerých rôznych administrátorov, v PaaS sa všetko robí oveľa rýchlejšie a stačí na to jeden administrátor. Inými slovami, vývojové tímy posielajú požiadavky ako predtým, ale práca na ich implementácii sa teraz vykonáva podľa nového modelu.
Smerom k organizácii DevOps
Spustením PaaS a prechodom IT operačných špecialistov a vývojárov aplikácií naň môže organizácia pokračovať v implementácii metodiky DevOps, ktorá okrem iného zahŕňa tieto základné princípy:
- Rozdeľte prácu na malé krokyzískať včasnú spätnú väzbu, znížiť riziká a vyhnúť sa paralýze analýzy;
- Dostatočne automatizujte operácievyhnúť sa vytváraniu prekážok alebo úzkych miest v procese nasadzovania aplikácie;
- Výmena znalostí – kľúč k budovaniu dôvery;
- Pravidelne splácajte technické dlhy, pričom sa v každom pracovnom cykle vyčleňuje určitý čas na systematické zlepšovanie.
V druhej fáze prijímania kontajnerovej technológie vývojové tímy prirodzene začínajú vidieť príležitosti na zlepšenie a podnik sa prikláňa k tradičnejšiemu modelu DevOps. Tradičný mechanizmus odosielania a plnenia servisných požiadaviek je teraz vnímaný ako prekážka, takže organizácia sa snaží automatizovať opakujúce sa akcie a poskytovať vývojárom samoobslužné funkcie. Navyše, tieto vývojárske schopnosti v rámci danej aplikácie sú určené spoločným úsilím IT špecialistov prevádzkujúcich platformy a tých, ktorí sú zodpovední za poskytovanie aplikácií. Inými slovami, správcovia systému, ktorí vykonávajú akcie na žiadosť vývojárov, sú nahradení dvoma vyššie uvedenými kategóriami zamestnancov, ktorí sú zodpovední za popis a uplatňovanie pravidiel upravujúcich, čo presne môžu vývojári robiť sami. Automatizované postupy pomáhajú zabezpečiť súlad so špecifikovanými požiadavkami a koordinovať akcie, keď situácia spadá mimo rozsah existujúcich politík.
Prechod na iteračný plán, v ktorom IT prostredie a prevádzkový model prechádzajú opakovanými zmenami v priebehu času, je kritickým míľnikom pri dosahovaní vyspelého podniku DevOps. Miera prijatia metodiky DevOps závisí od tolerancie každej organizácie voči zmenám a od toho, ktoré zmeny prinášajú najväčší úžitok. Ak sa napríklad potreba vytvárať nové prostredia alebo aplikácie vyskytuje zriedkavo, optimalizácia zodpovedajúcich činností bude menej dôležitá ako zvýšenie kontroly vývojára nad životným cyklom aplikácie.
Nové výzvy, ktoré vznikajú v IT organizáciách pri migrácii na OpenShift
V tejto časti sa pozrieme na roly a úlohy, ktoré organizácie, ktoré prijali OpenShift, zvyčajne používajú na urýchlenie automatizácie a samoobsluhy pomocou technológie a PaaS.
V tabuľke nižšie sú uvedené hlavné úlohy najvyššej úrovne, ktoré existujú v akejkoľvek organizácii, ktorá implementovala OpenShift, s príkladmi súvisiacich pracovných miest a zručností. Tento zoznam úloh by sa nemal zamieňať so štruktúrou rozpisu práce alebo štruktúrou tímu, ale skôr so súborom úloh, ktoré musia splniť tí, ktorí sú zodpovední za podporu IT prostredia (prostredí) pre úspešnú implementáciu kontajnerovej platformy. V skutočnosti ďalej ukážeme, že zavádzanie kontajnerových technológií vytvára predpoklady pre formovanie vyspelejšej stratégie DevOps v podniku, čo následne zvyšuje mieru krížovej funkčnosti tímov a znižuje riziká úzkej špecializácie na úrovni jednotlivcov aj tímov.
Tabuľka 1. Definície úloh OpenShift
úlohy
Požadované schopnosti
Automatizácia a poskytovanie IT infraštruktúr
Tvorba:
- Návrh a konštrukcia hardvérových riešení
- Organizácia a podpora automatizácie počiatočného nastavenia
- Návrh a automatizácia prípravy VM a hostiteľa
- Návrh a realizácia dátových centier
- Správa systému Linux
- Automatizačné scenáre
- Znalosť skladovacích systémov
- Znalosť návrhu a implementácie siete
- zabezpečenia
Inštalácia a správa platformy OpenShift
Tvorba:
- Vykonanie klastrovej inštalácie
- Manažment služieb infraštruktúry
- Správa škálovania platformy
- Autentifikácia a autorizácia na úrovni platformy
- Správa systému Linux
- Znalosť sieťových technológií
- Automatizačné skripty (Ansible)
- Znalosť skladovacích systémov
- Znalosť kontajnerových technológií a architektúr
- Znalosť architektúr Kubernetes a OpenShift
- Zabezpečenie platformy
- Monitorovanie integrácie
Riadenie prípravy klientskych prostredí (tenant provisioning), izolácia IT kapacít
Tvorba:
- Vytváranie používateľov a tímov v rámci platformy
- Návrh a správa kvót
- Návrh a implementácia RBAC
- Znalosť architektúr Kubernetes a OpenShift
- Znalosť kontajnerových technológií a architektúr
- Automatizačné scenáre
- Dobrá znalosť projektov, kvót, prideľovania rolí a práce s plánovačmi
Vytváranie a správa základných obrázkov
Tvorba:
- Vyvinutie pracovného postupu úpravy obrázkov
- Vývoj obrazu založený na štandardoch
- Správa systému Linux
- Automatizačné scenáre
- Konfigurácia komponentov runtime aplikácií a middlewaru
- Znalosť kontajnerových architektúr
- Rámce na vytváranie aplikácií
- Dobrá znalosť obrázkov, prúdu obrázkov a šablón
Navrhujte a spravujte kanály nasadenia
Tvorba:
- Návrh a dokumentácia noriem dopravníkov
- Vývoj rýchlych návodov a šablón
- Školenie vývojárov
- Správa zdrojového kódu
- Návrh a implementácia aplikácie
- Automatizačné scenáre
- Automatizované testovanie
- Testovanie kvality kódu
- Znalosť kontajnerových architektúr
- Znalosť nemenných infraštruktúr
- Bezpečnosť – riadenie prístupu k fázam potrubia, schvaľovanie pracovných postupov atď.
- Dobrá znalosť šablón OpenShift, konfigurácií zostavy komponentov, konfigurácií nasadenia, služieb, trás, konfiguračných máp
Vývoj aplikácií a testov
Tvorba:
- Kódovanie aplikácie
- Vývoj automatizovaných testov
- Reakcia na zlyhania testu počas procesu nasadenia
- Reakcia na zlyhania aplikácie
- Užívateľské akceptačné testovanie
- Návrh a implementácia aplikácie
- Automatizované testovanie
- Správa zdrojového kódu
- Monitorovanie aplikácií
- Znalosť cloudových natívnych aplikačných architektúr
Prevádzkový monitoring a správa aplikácií
Tvorba:
- Navrhovanie aplikácií v kontexte výkonu
- Monitorovanie aplikácií za behu
- Škálovanie aplikácie (alebo automatické škálovanie)
- Správa dostupnosti aplikácií
- Požiadajte o kvóty a limity správy zdrojov
- Testovanie výkonu a kapacity IT
- Navrhovanie a implementácia výkonnosti aplikácií
- Monitorovanie výkonu aplikácie
- Testovanie výkonu a záťaže
Užívateľské akceptačné testovanie
Tvorba:
- Testovanie používateľského rozhrania (dizajn a používateľská skúsenosť)
- Vývoj automatizovaných testov
- Navrhujte a testujte používateľské rozhrania
- Automatizované testovacie vzory
- Testovacie rámce
- Návrhové vzory aplikácií
Nové roly, ktoré vznikajú v IT organizácii pri migrácii na OpenShift
Keď prejdete na organizačný model zameraný na DevOps, miera špecializácie rolí má tendenciu klesať a počet medzifunkčných tímov a rolí sa naopak zvyšuje, aby sa maximalizovala efektivita spolupráce. Takto podľa nás vyzerá zoznam kľúčových pozícií v IT organizácii, ktorá používa OpenShift:
- Aplikačný prevádzkový inžinier ALEBO Inžinier spoľahlivosti lokality. Predtým sa táto pozícia mohla nazývať „Správca aplikačného servera“.
- Vývojár aplikácií / Vývojár softvéru / Softvérový inžinier.
- Správca klastra/aplikačnej platformy. Predtým sa táto rola mohla nazývať „Systémový správca“ alebo „Administrátor“. Linux-platformy“.
- Manažér vydania/stavebný inžinier.
Matica rolí a úloh RACI
Nakoniec prejdeme na porovnanie pozícií a úloh diskutovaných vyššie, aby sme získali všeobecnú predstavu o tom, ako by mala vyzerať štruktúra organizácie implementujúcej DevOps na platforme OpenShift. Na začiatku môžu byť nasledujúce úlohy obsadené rôznymi odvetviami starej, tradičnej organizačnej štruktúry. Postupom času však dochádza ku konsolidácii a nové tímy sa budujú okolo aplikácií, ktoré preberajú väčšinu alebo dokonca všetky úlohy uvedené nižšie.
úlohy
role
Aplikačný prevádzkový inžinier / Inžinier spoľahlivosti lokality
Vývojár aplikácií / Vývojár softvéru / Softvérový inžinier
Administrátor klastrovej/aplikačnej platformy
Manažér vydania softvéru/Inžinier montáže
Automatizácia a poskytovanie IT infraštruktúr
I
I
R / A
C
Inštalácia a správa platformy OpenShift
C
I
R / A
C
Navrhujte a spravujte kanály nasadenia
C
C
I
R / A
Spravujte poskytovanie nájomníkov, izoláciu a kapacitu IT
C
I
R / A
I
Vytváranie a správa základných obrázkov
R
C
R / A
C
Vývoj aplikácií a testov
C
R / A
I
I
Prevádzkový monitoring a správa aplikácií
R / A
C
C
I
Užívateľské akceptačné testovanie
C
R
I
I
Konvencie v matici RACI
Zdroj:
- Zodpovedný – Výkonný umelec je ten, kto robí to, čo je potrebné na splnenie úlohy.
- zodpovedný – Zodpovedný – zamestnanec, ktorý je v konečnom dôsledku zodpovedný za správne a dôkladné vykonanie úlohy alebo dosiahnutie výsledku; a tiež jediný, kto môže delegovať prácu na účinkujúcich.
- konzultovať – Konzultanti – zvyčajne ide o odborníkov na danú problematiku, ktorých rady sa žiadajú; Je s nimi udržiavaná obojsmerná komunikácia.
- informovaný – Informovaní – ľudia, ktorí sú informovaní o udalostiach (a niekedy až po dokončení úlohy alebo dosiahnutí výsledku); dostávajú informácie jednostranne.
Ako tímy spolupracujú v organizácii DevOps
Tradičné získavanie zdrojov zvyčajne zahŕňa cyklus požiadaviek na zdroje, ktoré potom vykonávajú viaceré tímy. Nakoniec sú všetky potrebné zdroje pridelené a potvrdené žiadajúcou stranou. Tieto procesy sú často čiastočne alebo úplne manuálne a vyžadujú časté a viacnásobné interakcie medzi tímami na úspešné spracovanie každej požiadavky.
Obrázok 1. Tradičná IT organizácia
Vyššie uvedený diagram znázorňuje typické vzťahy medzi tímami v tradičnej IT organizácii. V tejto schéme niektoré tímy kontaktujú iné tímy so žiadosťou o vykonanie potrebnej práce, pričom využívajú viac-menej formálne komunikačné prostriedky, ako je systém lístkov alebo e-mail. Tieto požiadavky potom idú do radu a čakajú v krídlach, pričom dlhé čakanie často vedie k zhoršeniu alebo dokonca zhoršeniu vzťahov medzi tímami. K napätiu prispieva aj fakt, že členovia rôznych tímov sa málokedy osobne stretávajú a majú tendenciu zdieľať len minimum potrebných informácií.
Obrázok 2: DevOps IT Organizácia
Tento diagram ukazuje, ako funguje spolupráca v organizácii DevOps. Tu rovnaké tímy z predchádzajúceho diagramu opustili neefektívnu komunikáciu, ktorá posilňovala silá, a nahradili ich osobnými kontaktmi, čím sa vytvorili neustále kanály interakcie medzi tímami. Tieto kanály podporujú hybridný súbor zručností, ktorý pomáha zamestnancom lepšie pochopiť a predstaviť si potreby, výzvy a príležitosti tímov, ktoré zastupujú. Tímy sa navzájom posilňujú pri dokončovaní práce prostredníctvom automatizovaných samoobslužných portálov namiesto manuálneho vybavovania žiadostí iných ľudí o zmenu, ako tomu bolo v minulosti. A vďaka prítomnosti interakčných kanálov sa tieto samoobslužné systémy dokážu rýchlo prispôsobiť potrebám tímov, pre ktoré sú určené. Aby sa dosiahlo ešte lepšie porozumenie a zdieľanie znalostí v rámci organizácie, členovia tímu pravidelne striedajú úlohy, aby získali skúsenosti s interakciou s rôznymi tímami a lepšie pochopili celkový obraz IT systémov, ktoré podporujú, čím sa zvyšuje ich úroveň vzájomnej funkčnosti a užitočnosti.
Sčítanie
V tomto príspevku sme diskutovali o tom, ako môže prijatie riešení PaaS posunúť organizáciu smerom k DevOps a zmeniť tradičné roly a úlohy ako súčasť procesu. Preto sme uviedli hlavné IT výzvy, ktorým organizácia čelí pri migrácii na OpenShift, ako aj zručnosti potrebné na ich dokončenie. Poskytli sme tiež základnú sadu organizačných rolí, ktoré vznikajú pri budovaní viacfunkčných tímov DevOps, a maticu RACI, ktorá spája nové roly s novými úlohami. Nakoniec sme diskutovali o tom, ako môže platforma OpenShift a jej pridružená metodika DevOps zmeniť organizačnú štruktúru organizácií, keď prechádzajú z tradičných hierarchií a lístkových systémov k viacfunkčným tímom s vyššou úrovňou osobnej komunikácie.
Zdroj: hab.com
