Bár a PaaS (Platform as a Service) megoldások önmagukban nem képesek megváltoztatni az egyéni és csapatinterakciókat, gyakran katalizátorként szolgálnak a szervezeti változásokhoz, válaszul az IT-technológiák fokozott rugalmasságára.
A valóságban a PaaS-ba történő befektetések maximális megtérülése gyakran csak a szervezeti szerepek, felelősségi körök (feladatok) és kapcsolati modellek megváltoztatásának feltétele mellett lehetséges. Szerencsére a PaaS megoldások, mint az OpenShift Container Platform, elegendő rugalmassággal bírnak ahhoz, hogy minden IT-szervezet önállóan meghatározhassa a változások sebességét és mértékét az érintett emberek és folyamatok tekintetében.
A vállalatok konténerizálásának első szakaszában a legfontosabb prioritás az új alkalmazástelepítési rendszer, a konténerplatform bevezetése. Ekkor a szervezetek a megszokott munkafolyamataikat a szokásos szerepeikhez kötik, hogy reagáljanak a fejlesztőcsapatok standard igényeire, például tárolórendszerek, telepítési környezetek stb. terén. A konténerizálás későbbi szakaszaiban már az automatizálásról vagy a fejlesztők önsegítő lehetőségeinek biztosításáról van szó, hogy csökkentsék a rendszergazdák terheit, és a fejlesztők önállóságát és hatékonyságát magasabb szintre emeljék. Így kezdi el a szervezet a DevOps irányába való elmozdulást. A konténerizálás végső szakaszában a vállalat egy tisztább, kanonikus DevOps modellhez jut, amely keretében számos korábbi feladat és munka átkerül a keresztfunkcionális csapatok irányítása alá, amelyek nem platformok vagy technológiák alapján csoportosulnak, hanem az alkalmazások vagy alkalmazási szolgáltatások működésének biztosítása szempontjából.
Ebben a bejegyzésben bemutatjuk a szükséges szervezeti változások végrehajtásának útmutatóját, és elmondjuk, hogyan változnak a hagyományos IT-szerepek a konténertechnológiák bevezetésekor a vállalatnál.
Az új feladatok régi szerepekhez való társítása
A PaaS alapvető szervezeti modellje a számítástechnikai erőforrások rugalmas és gyors biztosítására jött létre az alkalmazások futtatási környezeteként. Bár ez bizonyos előnyöket biztosít a rendszergazdák számára, a fejlesztők általában nem élveznek lényeges előnyöket és új lehetőségeket, mivel ezen a ponton a vállalatok általában elkerülhetik az automatizálás, az önkiszolgálás bevezetését vagy a telepítési folyamat radikális javítását. A fejlesztési folyamatok minimális érintésével a PaaS mégis növeli az IT-rendszerek dinamizmusát, lehetővé téve ezzel a rendszergazdák számára, hogy jobban kiszolgálják a fejlesztők igényeit. Például, míg korábban a fejlesztői környezet létrehozása több napot vagy akár heteket is igénybe vehetett, és több különböző rendszergazda részvételét igényelte, a PaaS segítségével mindezek a feladatok sokkal gyorsabban, csak egy rendszergazda által elvégezhetők. virtuális gépekhez Más szavakkal, a fejlesztőcsapatok továbbra is kérdéseket nyújtanak be, de a kérdések megvalósítására vonatkozó munkát már egy új rendszer szerint végzik el.
Az utat a DevOps-hoz
A PaaS elindításával és az IT-rendszerek üzemeltetőinek, valamint az alkalmazásfejlesztőknek a migrálásával az organizáció folytathatja a DevOps módszertan bevezetését, amely mások mellett az alábbi alapelveket tartalmazza:
- A munkát kisebb lépésekre bontani, hogy korai visszajelzéseket kaphassunk, csökkenthessük a kockázatokat, és elkerüljük az «analitikai bénultságot»;
- A műveletek automatizálása megfelelő mértékig, hogy ne keletkezzenek akadályok vagy szűk keresztmetszetek az alkalmazás telepítési folyamatában;
- A tudásmegosztás – a bizalom építésének kulcsa;
- A műszaki adósságok rendszeres törlesztése, külön időt biztosítva a rendszeres fejlesztésekre minden munkaciklus során.
A konténertechnológiák bevezetésének második szakaszában a fejlesztőcsapatok természetesen észreveszik a fejlesztési lehetőségeket, és a vállalat hajlik a hagyományosabb DevOps modell felé. A karbantartási kérelmek benyújtásának és végrehajtásának hagyományos mechanizmusa most szűk keresztmetszetként van elkönyvelve, ezért a szervezet arra törekszik, hogy automatizálja az ismétlődő feladatokat, és önkiszolgáló lehetőségeket biztosítson a fejlesztők számára. Ezen fejlesztők lehetőségeit a különféle kérelmek keretében az IT-platformok üzemeltető szakembereinek és az alkalmazáshoz kapcsolódó szállítók közös erőfeszítései határozzák meg. Más szavakkal, a fejlesztők kérelmeinek teljesítéséért felelős rendszergazdák helyébe a fenti két csoport, a politikák megfogalmazásáért és alkalmazásáért felelős munkatársak lépnek, akik meghatározzák, hogy a fejlesztők mit végezhetnek el önállóan. Az automatizált eljárások segítenek a megadott követelmények betartásának biztosításában, és összhangba hozzák a műveleteket, amikor a helyzet túllép a fennálló politikák keretein.
Az iteratív ütemtervhez való átmenet, amelyben az IT-örök és az operatív modell idővel iteratív változásokon megy keresztül, kritikus mérföldkő a vállalat fejlett DevOps rendszerének kialakításában. A DevOps módszertan elfogadásának mértéke minden egyes szervezet toleranciájától függ a változásokkal szemben és attól, hogy mely változások hozzák a legnagyobb előnyöket. Például, ha az új környezetek vagy alkalmazások létrehozásának szükséglete ritkán merül fel, akkor a kapcsolódó tevékenységek optimalizálása kevésbé fontos, mint a fejlesztők ellenőrzésének fokozása az alkalmazások életciklusának kezelésében.
Új feladatok, amelyek az IT-szervezetekben felmerülnek az OpenShift-re való átmenet során
Ebben a szakaszban megvizsgáljuk azokat a szerepeket és feladatokat, amelyeket az OpenShift-re való áttérés során a szervezetek általában alkalmaznak az automatizálás és az önkiszolgálás felgyorsítása érdekében a technológia és a PaaS segítségével.
Az alábbi táblázatban az OpenShift-et bevezető szervezetek alapvető, magas szintű feladatait soroljuk fel, a megfelelő munkák és készségek példáival. Ez a feladatsor nem összetévesztendő a munkamegosztási sémával vagy a csapatok szervezeti struktúrájával, csupán azoknak a feladatoknak a halmaza, amelyeket az IT-környezetek fenntartásáért felelős személyeknek el kell végezniük a konténer platform sikeres bevezetése érdekében. Valójában később bemutatjuk, hogy a konténertechnológiák bevezetése elősegíti a vállalati szintű érettebb DevOps stratégia kialakulását, ami viszont növeli a csapatok közötti keresztteljesítményt, és csökkenti az egyes alkalmazottak és csapatok szakképzettségének szűkítéséből adódó kockázatokat.
1. táblázat: Az OpenShift feladatainak meghatározása
Feladatok
Szükséges készségek
IT-infrastruktúrák automatizálása és előkészítése (provisioning)
Feladatok:
- Hardvermegoldások tervezése és építése
- Az alapvető konfigurációs automatizálás megszervezése és támogatása
- Virtuális gépek és hosztok előkészítésének tervezése és automatizálása
- Adatközpontok tervezése és megvalósítása
- Linux rendszeradminisztráció
- Automatizálási forgatókönyvek
- Tárhely rendszerek ismerete
- Hálózatok tervezésének és megvalósításának ismerete
- Biztonság
Az OpenShift platform telepítése és kezelése
Feladatok:
- A klaszter telepítésének végrehajtása
- Infrastruktúra-szolgáltatások kezelése
- A platform skálázásának kezelése
- Hitelesítés és engedélyezés a platform szintjén
- Linux rendszeradminisztráció
- Hálózati technológiák ismerete
- Automatizálási forgatókönyvek (Ansible)
- Tárhely rendszerek ismerete
- Konténertechnológiák és architektúrák ismerete
- A Kubernetes és OpenShift architektúrák ismerete
- Platformok biztonsága
- Monitorozási integráció
Bérlői környezetek előkészítése, az IT-kapacitások izolálása
Feladatok:
- Felhasználók és csoportok létrehozása a platform keretein belül
- Kvóták tervezése és kezelése
- RBAC tervezése és megvalósítása
- A Kubernetes és OpenShift architektúrák ismerete
- Konténertechnológiák és architektúrák ismerete
- Automatizálási forgatókönyvek
- Jó ismeretek a projektek, kvóták, szerepkötések és a tervezők munkája terén
Alapképek készítése és kezelése
Feladatok:
- Képkészítési munkafolyamat kidolgozása
- Szabványoknak megfelelő képek fejlesztése
- Linux rendszeradminisztráció
- Automatizálási forgatókönyvek
- Az alkalmazások és middleware runtime-komponenseinek konfigurálása
- Konténerarchitektúrák ismerete
- Alkalmazásépítési keretrendszerek
- Jó ismeretek a képek, imagestream-ek és sablonok terén
Telepítési és üzemeltetési folyamatok tervezése és kezelése
Feladatok:
- Telepítési szabványok tervezése és dokumentálása
- Rövid útmutatók és sablonok kidolgozása
- Fejlesztők képzése
- Forráskód kezelése
- Alkalmazások tervezése és megvalósítása
- Automatizálási forgatókönyvek
- Automatizált tesztelés
- Kódminőségi tesztelés
- Konténerarchitektúrák ismerete
- Immutable infrastruktúrák ismerete
- Biztonság – a csőfázisokhoz való hozzáférés kezelése, munkafolyamatok jóváhagyása stb.
- Jó ismeretek az OpenShift sablonokról, buildconfig, deploymentconfig, szolgáltatások, útvonalak, configmap-ek tekintetében
Alkalmazások és tesztek fejlesztése
Feladatok:
- Alkalmazások kódolása
- Automatizált tesztek kidolgozása
- Tesztleállásokra való reagálás a telepítési cső során
- Alkalmazásmeghibásodásokra való reagálás
- Felhasználói elfogadó tesztelés
- Alkalmazások tervezése és megvalósítása
- Automatizált tesztelés
- Forráskód kezelése
- Alkalmazások figyelése
- Felhőalapú (cloud native) alkalmazások architektúráinak ismerete
Működési figyelés és alkalmazáskezelés
Feladatok:
- Alkalmazások tervezése teljesítmény szempontjából
- Folyamatban lévő alkalmazások figyelése
- Alkalmazások skálázása (vagy automatikus skálázás)
- Alkalmazások elérhetőségének kezelése
- Kérési kvóták és erőforráskezelési limitációk
- Teljesítmény- és IT-kapacitás tesztelése
- Alkalmazások teljesítményének tervezése és megvalósítása
- Alkalmazások teljesítményének figyelése
- Teljesítményt és terhelést tesztelni
Felhasználói elfogadó tesztelés
Feladatok:
- UI tesztelés (tervezés és felhasználói interakciók)
- Automatizált tesztek kidolgozása
- Felhasználói felületek tervezése és ellenőrzése
- Automatizált tesztelési sablonok
- Tesztelési keretrendszerek
- Alkalmazás tervezési sablonok
Új szerepkörök, amelyek az IT-szervezetekben merülnek fel az OpenShiftre való áttérés során
A DevOps-orientált szervezeti modellre való áttérés során a szerepkörök specializációjának száma általában csökken, míg a keresztfunkcionális csapatok és szerepkörök száma nő a hatékony együttműködés maximalizálása érdekében. Íme, hogyan nézhet ki a fő pozíciók listája az OpenShiftet használó IT-szervezetekben:
- Alkalmazások üzemeltetési mérnöke (Application Operations Engineer) VAGY Helyi megbízhatósági mérnök (Site Reliability Engineer). Ezt a pozíciót korábban "Alkalmazásszerver-adminisztrátornak" is nevezték.
- Alkalmazásfejlesztő / szoftverfejlesztő / programozó mérnök.
- Cluster- vagy alkalmazásplatform-adminisztrátor. Régebben ezt a szerepet "Rendszergazdának" vagy "Linux-platform adminisztrátornak" is nevezték.
- Szoftverkiadás-menedzser (Release Manager)/Építési mérnök (Build Engineer).
RACI szerepkörök és feladatok mátrixa
Végül áttérünk a fent tárgyalt pozíciók és feladatok összepárosítására, hogy általános képet kapjunk arról, hogyan kell kinéznie egy DevOps-t végrehajtó szervezet struktúrájának az OpenShift platformon. A kezdetben megadott szerepeket a régi, hagyományos szerkezeti ágak különböző részei tölthetik be. Idővel azonban konszolidáció történik, és új csapatok alakulnak az alkalmazások köré, amelyek a legtöbb vagy akár az összes alább megadott feladatot magukhoz vonják.
Feladatok
Szerepek
Alkalmazásmérnök / Webhelymegbízhatósági mérnök
Alkalmazásfejlesztő / Szoftverfejlesztő / Programozó mérnök
Cluster- vagy alkalmazásplatform-adminisztrátor
Szoftverkiadás-menedzser / Építési mérnök
IT-infrastruktúrák automatizálása és előkészítése (provisioning)
I
I
R/A
C
Az OpenShift platform telepítése és kezelése
C
I
R/A
C
Telepítési és üzemeltetési folyamatok tervezése és kezelése
C
C
I
R/A
Ügyféltájékoztató környezetek (tenant provisioning), izoláció és IT-erőforrások kezelése
C
I
R/A
I
Alapképek készítése és kezelése
R
C
R/A
C
Alkalmazások és tesztek fejlesztése
C
R/A
I
I
Működési figyelés és alkalmazáskezelés
R/A
C
C
I
Felhasználói elfogadó tesztelés
C
R
I
I
Jelölések a RACI mátrixban
Forrás:
- Felelős – A végrehajtó – az a személy, aki szükséges lépéseket tesz a feladat elvégzésére.
- Elszámoltatható – Felelős – az a munkavállaló, aki végső soron felelős a feladat helyes és gondos elvégzéséért vagy az eredmény eléréséért; és egyedül ő jogosult a végrehajtókkal való munka delegálására.
- Konzultált – Tanácsadók – általában az adott szakterület szakértői, akinek a véleményét kérik; velük kétirányú kommunikációt tartanak fenn.
- Informált – Az informáltak – olyan emberek, akiket a fejleményekről tájékoztatnak (és néha csak a feladat befejezése vagy az eredmény elérése után); ők egyirányú tájékoztatást kapnak.
Hogyan működik a csapatok együttműködése a DevOps szervezetekben
A hagyományos erőforrás-beszerzési séma általában az erőforrás-igénylések ciklusa, amelyeket több csapat teljesít. Végül minden szükséges erőforrás a kérvényező fél által megerősítve kerül megadásra. Gyakran ezek a folyamatok részben vagy akár teljesen manuálisan zajlanak, és gyakori, számos interakciót igényelnek a csapatok között minden egyes kérés sikeres feldolgozásához.
1. ábra. Hagyományos IT-szervezet
A fenti diagram bemutatja a tipikus kapcsolatokat a csapatok között a hagyományos IT-szervezetben. Ebben a séma keretein belül az egyes csapatok a szükséges feladatok elvégzésére kérik más csapatokat, többé-kevésbé formalizált kommunikációs eszközöket használva, mint például a jegyrendszer vagy az e-mail. Ezt követően ezek a kérelmek sorba kerülnek, és várakoznak a sorukra, amelynek hosszas várakozása gyakran a kapcsolatok romlásához, vagy akár kiéleződéséhez is vezet a csapatok között. A feszültséget tovább fokozza, hogy a különböző csapatok tagjai ritkán találkoznak személyesen, és általában csak a legszükségesebb információkat osztják meg.
2. ábra. DevOps IT-szervezet
Ez a diagram bemutatja, hogyan működik az együttműködés a DevOps szervezetben. Itt ugyanazok a csapatok az előző diagramról lemondtak a hatékonytalan kommunikációkról, amelyek fokozzák az elkülönültséget, és helyettük személyes kapcsolatokra váltottak, így folyamatos interakciós csatornákat hoztak létre a csapatok között. Ezek a csatornák segítik a hibrid készségek kialakulását, amely segít a munkavállalóknak jobban megérteni és képviselni a képviselt csapatok szükségleteit, problémáit és lehetőségeit. A csapatok lehetőséget adnak egymásnak a szükséges feladatok végrehajtására automatizált önkiszolgáló portálokon keresztül, ahelyett, hogy manuálisan dolgoznának fel a másik csapat által kért változtatásokat, ahogyan azt korábban tették. És a kapcsolatoknak köszönhetően ezek az önkiszolgáló rendszerek gyorsan alkalmazkodni tudnak a létrehozott csapatok igényeihez. A még nagyobb kölcsönös megértés és tudásmegosztás érdekében a csapatok tagjai időnként szerepcseréket végeznek, hogy tapasztalatot szerezzenek különböző csapatokkal való együttműködésben, jobban átláthassák az általuk kezelt IT-rendszerek összképét, ezzel növelve a keresztfunkcionalitásukat és hasznosságukat.
Összefoglalva
Ebben a bejegyzésben arról írtunk, hogy a PaaS megoldások bevezetése hogyan ösztönözheti a szervezeteket a DevOps módszertan alkalmazására. Ennek folyamatában a hagyományos szerepek és feladatok átalakuláson mennek keresztül. Ezért felsoroltuk a fő IT-feladatokat, amelyek a szervezetekben felmerülnek az OpenShift bevezetésével, valamint a végrehajtásukhoz szükséges készségeket. Bemutattuk a főbb szervezeti szerepeket is, amelyek a cross-funkcionális DevOps csapatok kiépítésekor merülnek fel, valamint a RACI mátrixot, amely összekapcsolja az új szerepeket az új feladatokkal. Végül pedig arról írtunk, hogy az OpenShift platform és a hozzá kapcsolódó DevOps módszertan hogyan alakíthatja át a szervezet struktúráját a hagyományos hierarchiákról és ügykezelő rendszerekről a cross-funkcionális csapatokra, ahol magasabb szintű személyes kommunikáció zajlik.
Forrás: habr.com
