Mellékleteink: HUP | Gamekapocs
Keres

Devops: hasznos játék a tűzzel

HWSW, 2017. június 22. 18:10
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

hirdetés

Könnyen megégeti magát, aki túl gyorsan vág bele. Tanulságok és tippek egy igazán nagy szervezetből.

A Magyar Telekom saját belső informatikájában az elmúlt években fokozatosan vezette be a devops módszertant a saját rendszerek üzemeltetésében és fejlesztésében. Az átállás kimondottan sikeresnek bizonyult, de nem tanulságok nélkül. Hogy mekkora átállásról van szó, azt jól illusztrálja, hogy a cég rendszerében mintegy 6300 VLAN, 4000 szerver és 800 hálózati eszköz található - egy ügyfél-tranzakció pedig átlagosan 114 különböző alkalmazást, 73 adatbázist, 190 tűzfalat, 145 middleware-t, 595 szoftvert és 23 tárolót érint.

Devops? Egyszerűbb és jobb döntések.

Az egyik legfontosabb érv a devops módszertan bevezetés mellett egy vállalatnál, hogy az összegyúrt csapat komoly (és nagyon hasznos) autonómiát nyer. Míg a fejlesztést és üzemeltetést is érintő kérdésekben korábban az a vezetői szinteken (neadjisten egy egész bizottságban) dőlt el, aki alatt mindkét csapat dolgozott, az összevont csapatok esetében ezek a döntések sokkal alacsonyabb szinten (a csapat vagy annak vezetője szintjén) létre tudnak jönni. Ez lényegesen gyorsabb döntéshozást jelent, nem kell a kérdéseket nehézkesen eszkalálni, majd megvárni, amíg az a megfelelő csatornákon visszacsorog.

Ez a legtöbb esetben egyszerűen jobb döntéseket is jelent, ahogy a fejlesztők és üzemeltetők megismerik egymás szempontjait - és ami sokkal fontosabb, egymás korlátait. Erre rá kell erősíteni a közös felelősség tudatosításával: ha a munkatársak csapatként felelnek a fejlesztési határidők betartásáért és a rendszer stabilitásáért is, akkor hirtelen megváltozik a döntéshozatal dinamikája, bevonják egymást a döntésekbe a fejlesztők és üzemeltetők, kialakul a szokás, hogy megkérdezik egymást a lehetőségekről és az egyes döntések potenciális következményeiről.

Az elvárások átalakítása döntő ebben a kérdésben: korábban a fejlesztőtől kizárólag a gyorsaságot és az új funkciók szállítását, az üzemeltetőtől pedig kizárólag a megbízhatóságot, a szolgáltatás minőségét kértük számon, ami azonnal ütköző pályára is állította a két oldalt. A közös felelősségi körrel ez feloldható és kialakulhat az egészséges kooperáció a csapaton belül.

Az ideális csapatméret meghatározása kemény dió, az ilyen félinformális, nagyon hatékony döntéshozás és kooperáció ugyanis nem skálázódik jól, így bizonyos méret fölött már romlik a csapatok teljesítménye. Az ideális méretet rengeteg faktor befolyásolja, de valahol 5 és 30 fő között érdemes tartani a létszámot.

Vigyázat, buktatók!

A fentiek alapján úgy tűnhet, hogy a devops-ot csak fel kellett találni, ettől a ponttól fogva meg is oldja a szervezet legfontosabb problémáit. Ez sajnos nincs így, az új munkavégzési forma maga is egyedi menedzsment kihívásokat hoz. Az egyik a már említett egyszerűbb döntéshozáshoz kapcsolódik: a sokszáz oldalas fix belső szabyálzatok kidobása ugyan nagyot dob a hatékonyságon, de egyúttal kiiktatja a belső "ellenőrzési pontokat" is, a belső folyamatokkal egyetemben. Az ideális a formalizált folyamatokat valamilyen lazított formában megtartani, mérföldköveket, lépcsőket meghatározni, hogy a devops ne vezessen menedzselhetetlen káoszhoz.

Ennek közvetlen folyománya a biztonság kérdése is. Éles rendszerhez tradicionális üzemeltetés esetén csak néhány kiválasztott fér hozzá, a fejlesztők pedig saját környezetben dolgoznak. A devops ezt felrúgja, hirtelen sokkal többen férnek hozzá az összes környezethez és rendszerekhez, amit szerepkörök meghatározásával, oktatással, tudatosítással kell kezelni.

Tipikus példa a desktop környezetek kérdése: az üzemeltetők erősen korlátozott, magas biztonságú munkaállomásaihoz képest a fejlesztők jóval gazdagabb szoftverkörnyezetet használnak, az IDE, a frameworkök, a hatékony munkavégzéshez elengedhetetlen tucatnyi alkalmazás biztonsági minősítése sokkal nehezebb, ezt a kérdést a devops bevezetésekor szintén kezelni kell.

További tapasztalat, hogy az egy-egy szolgáltatásra beállított devops-csapatok hajlamosak szem elől téveszteni az összképet és csak a rájuk bízott rendszerekkel foglalkozni, saját kis kertjüket ápolgatni. Márpedig az üzlet egész folyamatokban gondolkodik, amelyek sok, egymással integrált, egymást kiegészítő szolgáltatásból állnak, így az egyes csapatok között is meg kell tartani a kommunikációt és az end-to-end szemléletmódot, erre meg kell találni a helyet a szervezetben.

A devops bevezetése hajlamos megbontani a meglévő csoportdinamikát is. A különböző területeket összefogó és kontextusában látó vezető fejlesztő lesz automatikusan a munka középpontja, ahogy a "legokosabb embert" kezdik keresni a problémákkal a kollégák. Ez gyorsan a vezető fejlesztő túlterheléséhez vezet, miközben a munkafolyamatok megállnak. Ezt a helyzetet mindenképp kezelni kell és a feladatokat visszadelegálni a megfelelő szintre, másképp ez szűk keresztmetszete lesz a munkának.

A prioritások okos kezelése is komoly kihívás lehet. A devops üzemmódban ugyanis a sürgős és kritikus hibák elhárítása válik az egyetlen prioritássá, egy folyamatos tűzoltássá válik a munkavégzés, az összes környezetben egyszerre. Ez azzal jár, hogy a hatását hosszabb távon éreztető karbantartásokat a csapat elhanyagolja, erőforrás hiányában nem végzi el. Ez pedig idővel a rendszerek stabilitását ássa alá, megnő az alacsony prioritású backlog és a technical debt, elkezd a szolgáltatás minősége romlani. A megoldás: dedikálni kell néhány főt arra, hogy rendszeresen ezzel, csak a backlog takarításával foglalkozzon. Ehhez azonban nagy fegyelem kell, hogy egy komolyabb krízis esetén is hagyjuk őket végezni a saját dolgukat.

Végső soron be kell látni, hogy a szállítási gyorsaság, az új funkciók és a minőség között alapvető ellentét feszül: a stabil, megbízható rendszerek legnagyobb ellensége a változás (különösen a gyors változás), amely a stabilizált, összecsiszolt informatikát kikezdi. A legjobb fejlesztők és üzemeltetők is hibáznak néha, ezért érdemes a lehető legtöbb tevékenységet automatizálni. Ha a csapat összeül, megérti egymás szempontjait és elkészíti ezeket az eszköztárakat, akkor a legfontosabb hibaforrásokat ki tudja küszöbölni a változtatások során. Ebben rengeteget segít, hogy a devops csapatokban az üzemeltetési készségek mellett megjelennek a fejlesztők is, akik képesek ezeket az eszközöket csapatszinten létrehozni - ez korábban szinte teljesen hiányzott.

[A Magyar Telekom megbízásából készített anyag]

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.