Devops: hasznos játék a tűzzel (x)

 ( hup | 2017. június 26., hétfő - 10:57 )

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.)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Tetszett. Köszi.

Kiváló összefoglalás.

Köszi. Ez egy aranybánya volt a házi bullshit generátoromba, az összetett mondatok nagy részét sikerült is átimplementálnom. ;]

Remek előadás volt a HWSW meetupon.

Üdv,
Marci

+1

+1

Most akkor a devops az egy munkakor, egy csapatszervezesi forma, modern management szemlelet, vagy mi?

Igen. :)

Üdv,
Marci

Nekem csak az a fura, hogy eddig ugy hittem, hogy a devops az egy fejleszto, aki uzemeltet is (vagy egy uzemelteto, aki feljeszt is). Ennek igy sok ertelme nincs, mert a szakteruletek egyenkent is eleg nagyok ahhoz, hogy az egyszeri feljeszto ne ertsen mindkettohoz kello melysegben. Viszont ha a devops azt jelenti, hogy a csapat ugy van szervezve, hogy van benne uzemelteto is, fejleszto is, teszter, UX designer, stb, annak mar van ertelme, igy viszont megkaptuk a Product Team-eket.

Viszont meg mindig ott vannak a devops allashirdetesek. Meg mindig nem teljesen tiszta nekem ez az egesz. Kicsit olyan mint a "startup", arra huzzuk ra amire akarjuk, mert nincs egy jol korulirt meghatarozasa, hogy mi tartozik bele.

Szerk: ha viszont az uzemeltetes reszbe nem tartozik bele a szerverek tutujgatasa, csak grafikonok nezegetese, meg logok elemzese fejlesztoi oldalrol, akkor nincs problemam.

Jól látod. Ebben az olvasatban a devops olyan, mint az informatikus: Mindenhez is nem ért semmit. ;)

Amikor devops _mérnököt_ keres egy startup az az igazi... :) Bár még akár velem is előfordulhat ilyen, de hát azért a buzzwordnégyzet remek.

Tudom, hogy nem korrekt, de akkor kerdesre kerdesekkel felelnek :)
HR-esek kedvenc kerdese: "Hogy kepzeli el a jovojet 5 ev mulva?"

Kello rutin utan az ember gonosz modon megkerdezne:
* hogy milyen elorelepesi lehetosgeket ajanl/biztosit a ceg nem menedzser tipusu, uzemeltetoi munkakorben?
* milyen karrier eletut van az Onok cegenel, mint uzemelteto?

Legtobbszor itt dol a sajat dugajaba a kerdezo, mert nincs valasz, vagy nem tudja.

Szoval visszaterve a kerdesedhez, en azt kerdeznem hogy:
* hogy nez ki a rendszergazdai/uzemeltetoi eletpalya?
* hova lehet eljutni szimplan csak szakmai vonalon, illetve mi a kriteriuma, hogy megfelelj az adott pozicionak?

De hogy valaszoljak is a kerdesre, nem egyertelmu a megitelese/feladatkore a DevOps mernokoknek. Mindent az hataroz meg hogy mi a vallalat uzleti celja, milyen uzleti szempontoknak kell megfelelni, mi teremt erteket a ceg szamara es ezeket probalja a DevOpsos eszkoztar elemeivel (konfiguracio menedzsment, CI/CD, stb) megvalostani adott platformon (cloud, on-premises). Az en ertelmezesemben nem csak szoftverfejleszto cegeknel van/lenne igeny DevOps mernokre, illetve nem feltetlen szukseges hogy az uzemeltetett kornyezetek felhoben legyenek.

DevOps is a collaboration framework and approach that allows development, quality assurance and operations to meet today’s rapidly changing business demand and customer needs.
Ez az én definícióm. De ha a lényegét akarjuk megérteni, akkor arról szól, hogy a teljes értékláncban (fejlesztéstől üzemeltetésig, de akár üzleti elemzők, platform szakemberek is ide tartozhatnak) a döntéseket alacsonyabb szinten és a szolgáltatásra optimalizálva hozzuk meg.

> 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.

Miota mondom, hogy kell egy kis letszamu csapat, aki karban tartja a kodot, mig a tobbiek gozerovel fejesztenek, de eddig mindig csak azt a valaszt kaptam, hogy "hat de akkor a tobbiek szar munkat csinalnanak, mert majd mas eltakaritja a mocskot utanuk". Ebben is van valami, meg a rendes code review-ban is.

... 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.
Ez a rendszer biztosan jól el van ... ööö ... meg van szervezve.
Bár nem tudjuk mi az az ügyfél tranzakció, és ezzel többen is lehetünk így.

Az a baj, hogy az "agilitassal" sokan azt hiszik, hogy tervezni nem kell, aztan megy mindenki a kisebb ellenallas fele. Businessnek jo, mert dol a le, a dolgozok meg megszakadnak, hogy egyben tartsak valahogy a kartyavarat.

üt!

Üdv,
Marci

Viccnek jo, de azert ne mondd mar nekem, hogy az "evolutionary" design jo kodot eredmenyez, ertheto, es jol felepitett adatszerkezetekkel, pattern hasznalattal, rendes elnevezesekkel.

Altalaban a kovetkezo tortenik: a business novekedni szeretne, ezert hajtja a fejlesztot, hogy "kodolj, kodolj, KODOLJ! A karbantartas le van szarva". A fejleszto kodol, mint a guzu, nincs 2 perce elgondolkozni azon, hogy hova is lenne jo tenni azt az uj valtozot, ugyhogy csak beszorja valahova, ahonnan nem nagyon log ki logikailag. Ugyanigy tesznek a tobbiek is, kozben meg sirnak a managementnek, hogy ez igy szar, ossze fog omlani. Egy ido utan annyi spagettit fozunk, hogy tobbet kell majd bugfixelni, meg corner-case-ket lefedni, mint aktualisan feature-t fejleszteni. Business ezt leszarja, mert a primadonnak csak hadd picsogjanak, dol a le, van bonusz meg nyaralas Balin. Aztan amikor egyszercsak raeszmelnek, hogy "hat igazabol hisztiznek itt a fiuk/lanyok mar miota, es hat tenyleg belassult a fejlesztes, pedig mar ezt a legujabb buzzwordot is, meg azt a legujabb coolsagot is kiprobaltuk", akkor rajonnek, hogy a normalis kodbazis megse csak mese habbal, hogy a developer kiralykisasszonyok jol erezzek maguk, de eddigre mar keso, refaktoralni nem lehet, szoval el lehet kezdeni ketszeres efforttal kiszervezni valahova a meglevo funkcionalitast, ezzel kicsontozva az oreg es gany kodbazist.

En ertem, hogy ez igy "mukodik", de hogy ez igy szuboptimalis es igy senkinek se jo, az is tutifix.

a szub-optimális egy eufémizmus a "szar"-ra?
--

Meg anno Telekomnal dolgozva travianoztunk es minden egyes falunak tudtunk adni a cegnel uzemelo alkalmazas (100+) nevet...

Ami tortenik:

Letesitesi rendszerek lekerdezese
Legacy rendszerek basztatasa letezo ugyfel eseten
Szamlazasi rendszerek basztatasa (igen ez egy ilyen meno ceg abbol is van tobb :D )
Rendeles eseten kulonbozo WF-k inditasa
Ajanlatok betoltese etc

Azert ugye megvan, hogy egy sima mobil hivasfelepites is atmegy 10+ nodeon, es akkor meg policy control vagy szamlazas meg sehol sincs?

Ok, a 190 tűzfalat (átlagosan) értem. ;)

Kicsit komolyabbra fordítva a szót, a mobil technológiához tényleg nem értek. Viszont láttam már 10:1 arányú költséggel és kiépítéssel megvalósított azonos funkciójú rendszereket. Ez a számok alapján a legbonyolultabbak közé tartozhat. Kérdés, hogy a rendszer túlbonyolítása, majd ehhez a sok-sok szakember biztosítása és bonyolult hierarchiába szervezése hatékony-e? Szerintem nem.

Pont azert koltott el a Telekom egy szabad szemmel tavolrol is lathato mennyisegu penzt ,hogy probalja kicsit megregulazni a dolgokat. Az hogy ez az indiaiakkal karoltve mennyire volt sikeres az mas teszta. Lenyeg hogy "mukodik".

A telekom eleve egy cegcsoport ami korabban kisebb nagyobb cegekbol allt. Szoval nem direkt basztak ki magukkal es kezdtek el fejleszteni mondjuk 4 szamlazasi rendszert hanem mert az adott volt es mindegyikbe bele voltak/vannak drotozva olyan dolgok amiket nem lehet csak ugy hiphopp kiszedni beloluk.

Az azokhoz egyedileg drotozott legacy rendszerekrol nem is beszelve. Nagyon nehez ezeket kigyomlalni ugy hogy mindennek mukodnie kell kozben es lehetoleg ne basszal el semmit mert kulonben bedontod az ugyfelszolgalatot 3 perc alatt...

Szoval karosszekbol a legtobben itt nagyon okosan megmondjak a tutit de egyszer szivesen megneznem oket, ahogyan megvaltjak a vilagot egy ilyen cegnel :D
Ilyen bonyolultsagu rendszereknel nagyon sok a nem lehet illetve sok ember tyukszemere tapos ra az aki esetleg valami jo dolgot probal csinalni. Ami neked jo (mondjuk ugyfelszolgalat) azt a szamlazas vetozza mert feje tetejere allitja oket. Ami nekik jo azt az uzemeltetes kaszalja el. Ami nekik jo azt meg a security vagy barmelyik random igazgatosag.

Tudom miről beszélsz. Véletlenül 20 évet ott/nekik dolgoztam. ;)
Nyugodtan mondhatnám, mint devops. Csak akkor még nem így hívták. :)

Akkor miert tetted fel az eredeti kerdest?

En ugyan "csak" 7 evet dolgoztam ott de kb az elso evben leesett mennyire bonyolult a rendszer. Hogy mennyire hatekony? Mihez kepest? Nehez osszehasonlitani mas cegekkel mert senkinel nincs ennyifele technologia es termek amit ossze kene fogni mint naluk.

Az csak egy költői kérdés volt.
Ilyen bonyolult rendszerek sokszor úgy alakulnak ki, hogy meggondoatlanul összepakolnak egy csomó "szabványos" rendszert. Az, hogy mi a cél többnyire elsikkad. Az így kialakult rendszert sem devops, sem az atyaúristen nem bogozza ki soha. Ezzel szemben sok-sok hozzánemértő embernek ad munkát.
Ennek semmi köze a sokféle technológiához meg termékhez. Pl. a számlázás - ha már megértetted miről van szó - faék bonyolultságú. Amikor először írtam ezzel kapcsolatos szoftvert, akkor volt doksi, meg egy guru, aki fél óra alatt elmagyarázta mi is történik. (Kiragadott, hiányos példa következik.) Jó 10 évvel később kaptam egy megbízást egy bizonyos funkció bővítésre. Megszereztem a megbízó számát és elmagyaráztam neki (mivel a megrendelt feladatnak nem sok értelme volt, le kellett volna butítani azt ami már jól működött):
- mik a szabályok
- jelenleg hogyan működik a CDR gyűjtés/feldolgozás
- üzemzavar esetén mi történik (Nehezen megértette, majd örült.)
- ezért nem azt, nem úgy, nem ott és nem akkor kell csinálni
Lényegében a rendszer többet és jobban tudott, mint a megrendelő hozzáértése. Maga a megrendelés is csak azért született, mert a komplex rendszer struktúráját nem tudta képbe helyezni. A végén 20 sor programért markoltam fel a lóvét.
Ha eredetileg rosszul oldom meg a feladatot, akkor már rég kibukott volna a számlázáson.

Nem azt akarom mesélni, hogy én találtam fel a világot! Viszont egy feladatot érdemes néhány komplex tudással rendekező szakemberrel megoldani. Akkor nem keletkezik ilyen topic, és a felszabaduló itpalánták kitöltik a nagy IT szakemberhiányban az űrt. ;) (Bocs ez csúnya volt.)

Igen csak ugy nehez rendszert reformalni es egyszerusiteni ha 25 masik log rajta (ez mar leteztek a nagy reform elkezdese elott) amikre mondjuk eppen nincsen penz de eltorsz feature-oket bennuk.

A sok technologia meg azert macera mert kulonbozo rendszerekben laknak/laktak (leven mas cegek birtokoltak T-kabel,ADSL, Tcom ADSL, VOIP, berelt vonal, Hosting, Webhosting, Optika, Mobil, PSTN) Szoval annyira nem egyszeru hozzajuk nyulni. De hat ezt is tudod jol ha nekik dolgoztal :)

A meggondolatlanul osszepakolnak rendszert meg nemszeretem de kell kategoria. Marketing es sales dontesek vezettek. Akciokat upgradeket ki kell ajanlani. Es ha nincsenek a rendszerek osszekotve, nehez ezt megcsinalni.

Hát most nagyon rosszat szóltál! (Marketing es sales dontesek vezettek.)
Képzeld el, egyszer magkaptam a telefonszámlám, ahol tájékoztattak, hogy jövő hónapban milyen szolgáltatás fog elindulni. Mentem is a főnökömhöz, aki csak valami húb. utánanézek-et emlegetett. :-) A marketing odaírta, csak szoftver meg adat nem volt hozzá. :)))) Persze mi üzemeltettük volna, ha lett volna mit.

Régen ifjú voltam, meg naív. Úgy hittem, hogy megfogalmaznak az okosok valamilyen célt, másik okosok megtervezik (gazdaságilag is)/megrendelik/kifejlesztik, üzembe helyezik, tesztelik - igy ebben a sorrendben. Majd ezek után jön a marketing. No, most olvasd el ugyanezt visszafelé. Erre sok mindent lehet mondani: elmebetegek, másik cégnél dolgoznak, stb. És mégis működik. Ez csoda!

Egyrészt köszönöm az előadást a meetupon, tényleg tanulságosnak tűnt. Leginkább ez:

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.

Nagyon érdekelne, hogy ezt a klasszikusan (és hatékonyan) sokcsapatos cégek hogyan oldják fel ezt a problémát. Nekem az a tapasztalatom, hogy akármilyen fejlesztőt is nehéz találni, nem hogy olyat, akinek van üzemeltetési tapasztalata is, azaz képes a szoftvert az üzemeltetési szempontoknak megfelelően specifikálni és megírni. Tudom, hogy a klasszikus szoftverfejlesztésben a specifikáció és a kódolás a személyek szintjén is elválik egymástól, de a devopsnál ez nincs így. (Javítsatok ki, ha tévedek!) Ez viszont kulcsfontosságúvá teszi azt a csapatonként 1-2 embert, akik képesek szélesebb spektrumban gondolkozni. Mindezt súlyosbítja az, hogy ezek az emberek a legritkább esetben rendelkeznek a szükséges management skillekkel pl. a feladat delegálásának képességével.

Egyszóval a felvetett problémát én is megéltem már, de nagyon kíváncsi lennék a megoldásra.

+1

subs

Ebben több kérdés van egyszerre:
1.,A vezető fejlesztő akkor tudja jól figyelembe venni az üzemeltetési szempontokat, ha van megfelelő információja, mire van szükség. Ez kétféle lehet:
-Statikus, azaz szabályzatokban és kötelezően használandó fejlesztési keretrendszerekben gyűjtjük a nem funkcionális követelmények kezelésének a megkövetelt módját. Ezt neki ismernie kell.
-Dinamikus, azaz a vezető fejlesztő megkap minden olyan működési statisztikát, riasztást (jobb esetben feldolgozott módon és valós időben, de nem tőle várjuk az operatív beavatkozást) ami az általa fejlesztett szolgáltatással kapcsolatos. Illetve részt vesz azokon a szolgáltatás menedzsment megbeszéléseken ahol a szolgáltatás SLA-t célokat kell meghatározni és riportolni.
Így rendelkezni fog azokkal az eszközökkel és információkkal ami ahhoz szükséges, hogy jól tudja végezni a munkáját.

2., A vezető fejlesztő nem feltétlenül rendelkezik management képességekkel. Ebben az esetben tandem-ben dolgozik valakivel, aki az operatív csoport vezetési feladatokat látja el. Tapasztalatom szerint ez nagyon hatékony tud lenni és nagyobb csapatok irányítására is alkalmas.