Čeprav sama PaaS (Platform as a Service) rešitev ne more spremeniti načinov individualne in skupinske interakcije, pogosto deluje kot katalizator organizacijskih sprememb kot odgovor na povečano prilagodljivost IT-tehnologij.
V praksi je največji izkoristek naložb v PaaS pogosto možen le ob pogojih spremembe organizacijskih vlog, področij odgovornosti in shem odnosov. Na srečo PaaS rešitve, kot je OpenShift Container Platform, zagotavljajo dovolj prilagodljivosti, da si lahko vsaka IT-organizacija sama določi hitrost in obseg sprememb glede na vključene ljudi in potekajoče procese.
V prvi fazi kontejnerizacije podjetja je glavni prioriteta uvedba kontejnerske platforme kot novega sistema za uvajanje aplikacij. V tem trenutku organizacije povezujejo običajne naloge z ustaljenimi vlogami, da se odzovejo na standardne zahteve razvojnih ekip, kot so sistemi shranjevanja, okolja uvajanja itd. V kasnejših fazah kontejnerizacije pa je že govora o avtomatizaciji ali zagotavljanju možnosti samopostrežbe za razvijalce, da bi zmanjšali obremenitev sistemskih skrbnikov in izboljšali avtonomijo in učinkovitost razvijalcev. Tako organizacija začne napredovati proti DevOpsu. V zaključni fazi kontejnerizacije podjetje doseže bolj čisto, kanonično DevOps model, v okviru katerega številne prejšnje naloge in delo preidejo pod nadzor čezfunkcionalnih ekip, ki so razdeljene ne glede na platforme ali tehnologije, temveč z vidika zagotavljanja delovanja aplikacij ali aplikativnih storitev.
V tem članku bomo predstavili vodnik za potrebne organizacijske spremembe in opisali, kako se tradicionalne IT-vloge spreminjajo z uvajanjem kontejnerskih tehnologij v podjetju.
Povezovanje novih nalog s starimi vlogami
V svoji osnovni, začetni obliki se organizacijski model PaaS oblikuje, da bi bolj fleksibilno in hitro dodeljeval IT-virе aplikacijam kot izvajalno okolje. In čeprav to prinaša določene prednosti sistemskim administratorjem, razvijalci tu običajno ne pridobijo nobenih pomembnejših koristi in novih priložnosti, saj podjetje v tej fazi lahko popolnoma obvladuje področje brez začetka avtomatizacije, uvajanja samozadostnosti ali radikalnega izboljšanja procesu uvajanja. Z minimalnim posegom v razvojne procese na tej stopnji PaaS vseeno povečuje dinamičnost IT-sistema, kar omogoča administratorjem, da bolje zadovoljijo zahteve razvijalcev. Na primer, če se je prej izdelava razvojnega okolja iz več virtualnih naprav in shrambnih enot lahko vlekla dni ali celo tedne, pri čemer je bilo potrebno sodelovanje več različnih administratorjev, je zdaj v PaaS vse to opravljeno veliko hitreje in z delom samo enega administratorja. Z drugimi besedami, razvijalci oddajo zahteve kot prej, toda izvedba teh zahtev se zdaj izvaja po novem načrtu.
Na poti k DevOps-organizaciji
Z zagon PaaS in prenosom strojnim strokovnjakom za IT-sisteme in razvijalcem aplikacij lahko organizacija nadaljuje z uvajanjem metodologije DevOps, ki med drugim vključuje naslednje osnovne načela:
- Razdeliti delo na manjše faze, da bi pridobili povratne informacije v zgodnjih fazah, zmanjšali tveganja in se izognili 'analitičnemu paralizisu';
- Avtomatizirati operacije v zadostni meri, da ne bi ustvarili ovir ali ozkih grl v procesu uvajanja aplikacij;
- Izmenjava znanja je ključ do gradnje zaupanja;
- Redno plačevati tehnične dolgove, pri čemer v vsakem delovnem ciklu namenite določen čas za sistematična izboljšanja.
V drugem koraku uvajanja kontejnerskih tehnologij ekipe za razvoj se seveda začnejo zavedati možnosti za izboljšave, podjetje pa se nagiba k bolj kanoničnemu modelu DevOps. Tradicionalni mehanizem za oddajo in izvajanje zahtevkov za storitve se zdaj doživlja kot ožja grla, zato organizacija stremi k avtomatizaciji ponavljajočih se nalog in zagotavljanju možnosti samopostrežbe za razvijalce. Te možnosti razvijalcev v okviru določenega zahtevka določajo skupni napori IKT strokovnjakov za obratovanje platform in tistih, ki so odgovorni za dostavo aplikacij. Z drugimi besedami, na mesto sistemskih administratorjev, ki izvajajo ukaze razvijalcev, prihajata dve zgoraj omenjeni kategoriji zaposlenih, ki odgovarjata za opis in uporabo politik, ki urejajo, kaj razvijalcem dovoljujejo, da počnejo sami. Avtomatizirani postopki pomagajo zagotoviti skladnost s temi zahtevami in uskladiti delovanja v primerih, ko situacija preseže obstoječe politike.
Prehod na iterativni urnik, v katerem IT okolje in operativni model doživljata iterativne spremembe s časom, je kritična mejna točka v oblikovanju zrele DevOps sistema v podjetju. Stopnja sprejemanja metodologije DevOps je odvisna od tolerance vsake organizacije do sprememb in od tega, katere spremembe prinašajo največjo korist. Na primer, če potreba po ustvarjanju novih okolij ali aplikacij nastane redko, je optimizacija ustreznih dejanj manj pomembna od okrepitve nadzora razvijalcev nad življenjskim ciklom aplikacij.
Nove naloge, ki nastanejo v IT organizacijah ob prehodu na OpenShift
V tem razdelku bomo raziskali vloge in naloge, ki jih organizacije, ki so prešle na OpenShift, običajno uporabljajo za pospeševanje avtomatizacije in samopostrežbe z uporabo tehnologij in PaaS.
V spodnji tabeli so navedene glavne naloge na višji ravni, ki obstajajo v vsaki organizaciji, ki je implementirala OpenShift, skupaj z primeri ustreznih del in veščin. Ta seznam nalog ne gre zamenjati z načrtom delitve nalog ali z organizacijsko strukturo ekip; to je le nabor nalog, ki jih morajo opravljati osebe odgovorne za podporo IT okolju, za uspešno uvedbo platforme s kontejnerji. V resnici bomo pokazali, da uvedba kontejnerskih tehnologij ustvarja predpogoje za oblikovanje bolj zrele strategije DevOps v podjetju, kar posledično povečuje stopnjo čezfunkcionalnosti ekip in zmanjšuje tveganja za preozko specializacijo na ravni posameznikov in ekip.
Tabela 1. Opredelitve nalog OpenShift
Zadaci
Zahtevane veščine
Avtomatizacija in priprava (provisioning) IT infrastrukture
Naloge:
- Oblikovanje in gradnja strojnih rešitev
- Organizacija in podpora avtomatizaciji začetne nastavitve
- Oblikovanje in avtomatizacija priprave VM in gostiteljev
- Oblikovanje in realizacija podatkovnih centrov
- Sistemsko administriranje Linuxa
- Skripte za avtomatizacijo
- Poznavanje sistemov shranjevanja
- Poznavanje na področju oblikovanja in izvedbe omrežij
- Sigurnost
Namestitev in upravljanje platforme OpenShift
Naloge:
- Izvedba namestitve klasterja
- Upravljanje infrastrukturnih storitev
- Upravljanje širjenja platforme
- Preverjanje pristnosti in avtorizacija na ravni platforme
- Sistemsko administriranje Linuxa
- Poznavanje omrežnih tehnologij
- Skripte za avtomatizacijo (Ansible)
- Poznavanje sistemov shranjevanja
- Poznavanje kontejnerskih tehnologij in arhitektur
- Poznavanje arhitektur Kubernetes in OpenShift
- Varnost platform
- Integracija nadzorovanja
Upravljanje s pripravljenostjo klientskih okolij (tenant provisioning) ter izolacija IT zmožnosti
Naloge:
- Ustvarjanje uporabnikov in ekip v okviru platforme
- Oblikovanje in upravljanje kvot
- Oblikovanje in realizacija RBAC
- Poznavanje arhitektur Kubernetes in OpenShift
- Poznavanje kontejnerskih tehnologij in arhitektur
- Skripte za avtomatizacijo
- Dobre veščine na področju projektov, kvot, vezave vlog in dela s planiralniki
Sestavljanje in upravljanje osnovnih slik
Naloge:
- Razvoj delovnega toka spremembe slik
- Razvoj slik na podlagi standardov
- Sistemsko administriranje Linuxa
- Skripte za avtomatizacijo
- Konfiguracija runtime komponent aplikacij in middleware
- Poznavanje kontejnerskih arhitektur
- Okviri za gradnjo aplikacij (application build frameworks)
- Dobre veščine na področju slik, imagestream in predlog
Načrtovanje in upravljanje z uvajalnimi napravami
Naloge:
- Načrtovanje in dokumentiranje standardov uvajalnih naprav
- Razvijanje kratkih navodil in predlog
- Usposabljanje razvijalcev
- Upravljanje izvorne kode
- Načrtovanje in implementacija aplikacij
- Skripte za avtomatizacijo
- Avtomatizirano testiranje
- Testiranje kakovosti kode
- Poznavanje kontejnerskih arhitektur
- Poznavanje ne-spremenljive infrastrukture
- Varnost – upravljanje dostopa do stopenj cevi, odobritev delovnih tokov itd.
- Dobre poznavanje vzorcev OpenShift, komponent buildconfigs, deploymentconfigs, storitev, poti, configmaps
Razvoj aplikacij in testov
Naloge:
- Kodiranje aplikacij
- Razvoj avtomatiziranih testov
- Reagiranja na napake testov med uvajalnim postopkom
- Reagiranja na napake aplikacij
- Uporabniško sprejemno testiranje
- Načrtovanje in implementacija aplikacij
- Avtomatizirano testiranje
- Upravljanje izvorne kode
- Nadzor aplikacij
- Poznavanje arhitektur oblačnih (cloud native) aplikacij
Operativni nadzor in upravljanje aplikacij
Naloge:
- Načrtovanje aplikacij v kontekstu zmogljivosti
- Nadzor aplikacij med izvajanjem
- Širitev aplikacij (ali samodejna širitev)
- Upravljanje razpoložljivosti aplikacij
- Kvote in omejitve upravljanja virov
- Testiranje zmogljivosti in IT zmogljivosti
- Načrtovanje in implementacija zmogljivosti aplikacij
- Nadzor zmogljivosti aplikacij
- Testiranje zmogljivosti in obremenitveno testiranje
Uporabniško sprejemno testiranje
Naloge:
- Testiranje uporabniškega vmesnika (oblikovanje in interakcije z uporabnikom)
- Razvoj avtomatiziranih testov
- Načrtovanje in preverjanje uporabniških vmesnikov
- Predloge za avtomatizirano testiranje
- Okviri za testiranje
- Predloge za načrtovanje aplikacij
Nove vloge, ki se pojavijo v IT organizaciji ob prehodu na OpenShift
Ob prehodu na organizacijski model usmerjen v DevOps se običajno zmanjša število specializacijskih vlog in poveča število medfunkcionalnih ekip ter vlog za optimizacijo sodelovanja. Tukaj je, po našem mnenju, seznam osnovnih mest v IT organizaciji, ki uporablja OpenShift:
- Inženir za delovanje aplikacij (Application Operations Engineer) ALI Inženir za zanesljivost spletnega mesta (Site Reliability Engineer). To mesto je bilo prej znano kot "Administrator strežnika aplikacij".
- Razvijalec aplikacij/razvijalec programske opreme/inženir-programer.
- Skrbnik gruče/aplikacijske platforme. Ova uloga se ranije mogla nazivati "Sistem administrator" ili "Administrator Linux platformi".
- Menadžer za izradu softvera (Release Manager)/Inženjer za izgradnju (Build Engineer).
RACI matrica uloga i zadataka
Na kraju, prelazimo na usklađivanje gore navedenih pozicija i zadataka, kako bismo pružili opšti pregled kako bi struktura organizacije koja implementira DevOps na OpenShift platformi trebala izgledati. Inicijalno, uloge navedene u nastavku mogu vršiti različite grane stare, tradicionalne organizacione strukture. Međutim, vremenom se događa konsolidacija i formiraju se novi timovi oko aplikacija koji preuzimaju većinu ili čak sve navedene zadatke.
Zadaci
Vloge
Inženjer za podršku aplikacijama / Inženjer za pouzdanost sajta
Razvijač aplikacija / Razvijač softvera / Inženjer-programer
Administrator gruče/aplikacijske platforme
Menadžer za izradu softvera / Inženjer za izgradnju
Avtomatizacija in priprava (provisioning) IT infrastrukture
I
I
R/A
C
Namestitev in upravljanje platforme OpenShift
C
I
R/A
C
Načrtovanje in upravljanje z uvajalnimi napravami
C
C
I
R/A
Upravljanje pripremom klijentskih okruženja (tenant provisioning), izolacijom i IT resursima
C
I
R/A
I
Sestavljanje in upravljanje osnovnih slik
R
C
R/A
C
Razvoj aplikacij in testov
C
R/A
I
I
Operativni nadzor in upravljanje aplikacij
R/A
C
C
I
Uporabniško sprejemno testiranje
C
R
I
I
Oznake u RACI matrici
Izvor:
- Odgovoran – Izvršilac – onaj ko obavlja potrebne radnje za završavanje zadatka.
- Odgovoran – Odgovorna osoba – zaposleni koji je na kraju odgovoran za pravilno i temeljito izvršavanje zadatka ili postizanje rezultata; takođe, jedini koji može delegirati rad izvršiocima.
- Konsultovani – Konsultanti – obično su to stručnjaci u određenoj oblasti čiji se saveti traže; održava se dvosmerna komunikacija sa njima.
- Obavešteni – Osobe koje se drže u toku sa događanjima (a često samo na kraju zadatka ili postizanju rezultata); one primaju informacije u jednosmernoj komunikaciji.
Kako funkcioniše saradnja timova u DevOps organizaciji
Tradicionalna shema dobijanja resursa obično predstavlja ciklus zahteva za dodelu resursa koji se zatim izvršavaju od strane više timova. Na kraju, svi potrebni resursi se dodeljuju i potvrđuju od strane tražeće strane. Često se ovi procesi delimično, a čak i potpuno, obavljaju ručno i zahtevaju česte i brojne interakcije među timovima za uspešno rukovanje svakim zahtevom.
Slika 1. Tradicionalna IT organizacija
Diagram zgoraj prikazuje tipične odnose med ekipami v tradicionalni IT-organizaciji. V okviru te sheme se ene ekipe obračajo na druge ekipe s prošnjami za opravljanje potrebnih del, pri čemer uporabljajo bolj ali manj formalizirane komunikacijske sredstva, kot so sistemov za naloge ali e-pošta. Te prošnje nato pristanejo v vrsti in čakajo na svoj čas, pri čemer dolgotrajno čakanje pogosto pripelje do poslabšanja ali celo zaostrovanja odnosov med ekipami. Napetost dodatno zaostruje dejstvo, da člani različnih ekip redko srečujejo drug drugega osebno in običajno delijo le minimalno potrebno informacijo.
Slika 2. IT-organizacija DevOps
Na tej diagrami je prikazano, kako poteka sodelovanje v organizaciji DevOps. Tukaj so iste ekipe iz prejšnje diagrama opustile neučinkovite komunikacije, ki so povečale razdrobljenost, in jih nadomestile s osebnimi stiki, kar je ustvarilo stalne kanale za interakcijo med ekipami. Ti kanali pomagajo pri oblikovanju hibridnega sklopa znanj, ki omogoča zaposlenim boljše razumevanje in predstavljanje potreb, težav in priložnosti tistih ekip, ki jih zastopajo. Ekipe si omogočajo izvajanje potrebnih del prek avtomatiziranih portalov za samopostrežbo namesto da bi ročno obravnavale tuje prošnje za spremembe, kot je bilo prej. In zahvaljujoč obstoju interakcijskih kanalov so ti sistemi samopostrežbe sposobni hitro prilagajati se potrebam ekip, za katere so ustvarjeni. Za dosego še večjega medsebojnega razumevanja in izmenjave znanja znotraj organizacije člani ekip občasno opravljajo rotacijo vlog, da pridobijo izkušnje pri sodelovanju z različnimi ekipami in bolje razumejo celotno sliko IT-sistemov, ki jih upravljajo, s čimer povečujejo svoj nivo medfunkcionalnosti in uporabnosti.
Na koncu
V tem prispevku smo opisali, kako lahko uvajanje rešitev PaaS spodbudi organizacijo k sprejetju metodologije DevOps, pri čemer se v okviru tega procesa spreminjajo tradicionalne vloge in naloge. Zato smo navedli glavne IT-naloge, ki nastanejo v organizaciji ob prehodu na OpenShift, ter veščine, potrebne za njihovo izvajanje. Prav tako smo predstavili osnovni niz organizacijskih vlog, ki se pojavijo pri oblikovanju križnofunkcionalnih ekip DevOps, in RACI matrično, ki povezuje nove vloge z novimi nalogami. Na koncu pa smo opisali, kako lahko platforma OpenShift in z njo povezana metodologija DevOps spremenita organizacijsko strukturo organizacije pri prehodu z tradicionalne hierarhije in sistemov obdelave zahtevkov na križnofunkcionalne ekipe z višjo stopnjo osebne komunikacije.
Izvor: habr.com
