Nemrég részt vettem a DevOpsForum 2019-en, amelynek a Logrocon házigazdája. A konferencián a résztvevők megoldásokat és új eszközöket próbáltak találni az üzleti, fejlesztési és informatikai szolgáltató szakemberek közötti hatékony interakcióhoz.
A konferencia jól sikerült: valóban sok hasznos beszámoló, érdekes előadási formátumok hangzottak el, és sok kommunikáció zajlott az előadókkal. És különösen fontos, hogy senki nem próbált nekem eladni semmit, amiben mostanában nagy konferenciák előadói vétkeztek.
Részlet a Raiffeisenbank, az Alfastrakhovanie, a Mango Telecom automatizálás megvalósításában szerzett tapasztalataiból és egyéb részletekből a vágás alatt.
A nevem Yana, tesztelőként dolgozom, automatizálással, valamint DevOps-szal foglalkozom, és imádok konferenciákra és találkozókra járni. Az elmúlt két évben Oleg Bunin konferenciáin (HighLoad++, TeamLead Conf), Jug rendezvényeken (Heisenbug, JPoint), TestCon Moszkvában, DevOps Pro Moszkvában, Big Data Moszkvában voltam.
Mindenekelőtt a konferencia programjára hívom fel a figyelmet. Kevésbé nézem, hogy miről fog szólni a jelentés, inkább a felszólalóra. Még ha a jelentés nagyon technológiainak és érdekesnek bizonyul is, nem tény, hogy a jelentésből származó bevált gyakorlatok közül néhányat alkalmazni fog a cégében. És akkor kell egy hangszóró.
Fény a csővezeték végén a Raiffeisenbanknál
Általában a pálya szélén keresek olyan hangszórókat, amelyek érdekelnek. A DevOpsForum 2019-en a Raiffeisenbank egyik előadója, Mikhail Bizhan felkeltette az érdeklődésemet. Beszéde során arról beszélt, hogyan kezdik fokozatosan rávenni a csapataikat a DevOpsra, miért van szükségük rá, és hogyan adhatják el a DevOps átalakítás ötletét az üzleti életnek. Nos, általában arról beszéltem, hogyan lehet látni a fényt a csővezeték végén.
Mikhail Bizhan, a Raiffeisenbank automatizálási igazgatója
Most már nincs „DevOps” a cégükben. Vagyis dolgozik, de nem minden csapatban. A DevOps bevezetésekor a csapatok felkészültségére támaszkodnak, mind a konkrét mérnökök, mind a termék igénye és a platform érettsége tekintetében, amelyre ez a termék épül. Misha elmondta, hogyan magyarázza el egy vállalkozásnak, miért van szükség a DevOps-ra.
A banki szegmensnek számos növekedési hajtóereje van: a szolgáltatások költségei és az ügyfélkör bővülése. A szolgáltatások költségének növelése nem túl jó hajtóerő, de az ügyfélkör növelése ennek az ellenkezője. Ha a versenytársak kiadnak egy objektíven menő terméket, minden vásárló odamegy, akkor idővel a piac kiegyenlítődik. Ezért a bankok elsősorban az új termékek piaci bevezetésére és bevezetésének gyorsaságára helyezik a hangsúlyt. A DevOps pontosan erre való, és a vállalkozások megértik ezt.
A következő fontos megjegyzés: A DevOps nem mindig csökkenti a piacra kerülés idejét. A DevOps nem tud egyedül működni, csak része a termék létrehozásának és piacra vitelének a fejlesztéstől a gyártásig (a kódtól a vásárlóig). De minden a kód előtt nem kapcsolódik közvetlenül a DevOpshoz. Vagyis a marketingesek évekig tanulmányozhatják a piacot, és egész életükben a versenytársak felzárkóztatásával tölthetik. Gyorsan meg kell érteni, mire van szüksége az ügyfélnek, és meg kell tervezni ennek vagy annak a funkciónak a megvalósítását - gyakran ez az, ami nem elég ahhoz, hogy a DevOps működjön, és a vállalat elérje célját. Ezért mindenekelőtt a Raiffeisenbank egyetértett az üzlettel abban, hogy meg kell tanulni a DevOps használatát. Az automatizálás az automatizálás érdekében nem sokat segít az új ügyfelekért folytatott küzdelemben.
Általában Misha úgy véli, hogy a DevOps-t végre kell hajtani, de bölcsen. Arra pedig fel kell készülni, hogy az átalakulás kezdetén csökken a csapat produktivitása, kevesebbet fog keresni, de akkor ez indokolt lesz.
A tesztelés automatizálása a Mango Telecomnál
Egy másik érdekes beszámolót, mint tesztelőt, Egor Maslov a Mango Telecomtól tartott. Az előadás címe „A teljes tesztelési ciklus automatizálása egy SCRUM csapatban”. Egor úgy véli, hogy a DevOps kifejezetten a SCRUM számára készült, ugyanakkor a DevOps bevezetése egy SCRUM csapatba meglehetősen problematikus. Ez azért van így, mert a SCRUM csapat mindig fut valahol, nincs idő arra, hogy az innovációk eltereljék a figyelmet és újraépítsék a folyamatot. A probléma abban is rejlik, hogy a SCRUM nem jár együtt az alcsapatok szétválasztásával a csapatban (tesztcsapat, fejlesztőcsapat stb.). Nos, emellett egy meglévő folyamat automatizálásához dokumentációra van szükség, és a SCRUM-ban legtöbbször nincs teljes dokumentáció - „a termék fontosabb, mint valamiféle írás”.
A SCRUM-ra való váltás után a tesztelők konzultálni kezdtek a fejlesztőkkel a funkciók tesztelésének módjáról. Fokozatosan nőtt a funkcionalitás mennyisége, nem volt dokumentáció, és rengeteg olyan hibát kezdtek elkapni a funkcionalitásban, amelyekre nem terjedtek ki a tesztek, és általában már nem volt egyértelmű, hogy ki és mikor tesztelte. Dióhéjban - zűrzavar és ingadozás. Úgy döntöttünk, hogy a tesztelési automatizálásra váltunk. De akkor is teljes kudarc következett. Kihelyezett automatizálási szakembereket alkalmaztak, akik a belső tesztelők számára ismeretlen veremre írtak. Az autotesztek kerete természetesen működött, de a kihelyezők távozása után ez két hétig tartott. A következő kísérlet volt a második számú automatikus tesztelés bevezetése. Azzal kezdődött, hogy mindent a cégen belül, önerőből kell felépíteni (a megfelelő vektor: belső szakértelem felépítése), a SCRUM keretein belül, és közben dokumentációt kell készíteni. Az automatizáláshoz használt veremnek meg kell egyeznie a termék veremével (itt adom hozzá, ne tesztelje mással a JavaScript-projektet). A sprint végén az egész csapattal készítettek egy bemutatót az automatikus teszt működéséről (hasznos). Így nőtt a csapat összes tagjának bevonása az automatizálási folyamatba, valamint az autotesztekbe vetett bizalom és annak esélye, hogy ezt az autotesztet biztosan használni fogják (és az állandó meghibásodások miatt egy hónap múlva sem kommentálják).
Mellesleg, a 2019-es DevOpsForumban volt egy nyitott mikrofon - ez egy régóta ismert és véleményem szerint hasznos beszédformátum. Így járkálsz, riportokat hallgatsz, majd úgy döntesz, hogy a konferencián érdemes egy-egy témát, problémát megvitatni, megosztani a probléma megoldásában releváns tapasztalatokat.
Azt is észrevettem, hogy a szervezők sorra készítettek rövid beszámolókat. Egy-egy jelentés legfeljebb 10 percig tart, majd kérdések következnek. Így egyszerre több témával foglalkozhat, és kérdéseket tehet fel az Önt érdeklő előadóknak.
Az előadások között körbejártam a konferenciapartnerek standjait és rengeteg cuccot loptam/nyertem. Eh, imádom a tájékoztatót!
Kerekasztal- és DevOps-problémák az Alfastrakhovanie fejlesztési igazgatójával
A hab a DevOpsForum 2019 tortán számomra egy órás plenáris ülés volt a DevOps szakértőivel. Négy résztvevőt hívtak meg, hogy különböző szemszögből nézzék meg a DevOps-ot: Anton Isanin (Alfastrakhovanie, fejlesztési igazgató), Nailya Zamashkina (Fintech Lab, üzemeltetési igazgató), Oleg Egorkin (Rostelecom, Agile coach) és Anton Martyanov (független szakértő, a DevOps-t vizsgálta) üzleti szempontból).
A szakértők közelebb ültek az emberekhez, majd elkezdtek történni a dolgok: egy egész órán keresztül a közönségből kérdezősködtek a résztvevők, a szakértők pedig elvitték a rapet. Néha valódi viták voltak. A kérdések nagyon különbözőek voltak, például: szükség van-e egyáltalán DevOps mérnökökre, miért nem lehet őket rendszergazdának képezni, mindenkinek fel kell-e kínálni a DevOps-ot, mi az értéke, stb.
Aztán személyesen beszéltem Anton Isaninnal. Megbeszéltük, hogy a DevOps kultúrát minden otthonba el kell vinni, és felfedtük a DevOps átalakulásának árnyoldalát.
Képzeljük el, hogy mindenki összefogott és úgy döntött, hogy a DevOps-ra mind a terméknek, mind az üzletnek és a csapatnak szüksége van. Menjünk a megvalósításba. Minden sikerült. Kifújtuk a levegőt. A DevOps közelebb hozott minket az ügyfélhez, most gyorsan teljesíthetjük minden kívánságát. Ennek eredményeként nagy, szigorú előírásokkal és követelményekkel rendelkező operatív részlegünk van, amely folyamatosan hibát talál a termékben, és egy csomó kérést hoz létre. Sőt, minden hiba "sürgős" állapotot kap, még akkor is, ha az ügyfél váratlanul sárgára akarta színezni a gombot zöld helyett. A projekt növekszik, a kiadások száma növekszik, és ennek megfelelően az új funkciókkal kapcsolatos hibák és az ügyfelek általi félreértések száma. Az Ops további 10 embert vesz fel, hogy lépést tartson a hibák bejelentésével, a fejlesztés pedig további 15 embert vesz fel, hogy lépést tartson a hibák bezárásával. És ahelyett, hogy új funkciókat vezetnének be, a csapat végtelen számú SD-vel dolgozik, elmagyarázva a funkcionalitást a felhasználónak és a támogatást egyszerre. Ennek eredményeként a műveletek és a fejlesztés is működik, de az ügyfél és a vállalkozás elégedetlen: az új funkciók elakadnak. Kiderült, hogy a DevOps létezik, de úgy tűnik, hogy nem.
A DevOps bevezetésének szükségességével kapcsolatban Anton egyértelműen kijelentette, hogy ez közvetlenül az üzlet méretétől függ. Ha évente egy ügyfél kiszolgálása milliárdot hoz a vállalatnak, akkor nincs szükség DevOps-ra (feltéve, hogy nem kell rendszeresen új változtatásokat bevezetnie ezen az ügyfélen). Mindent csokoládé borít. De ha az üzlet növekszik és több ügyfél jelenik meg, akkor meg kell felelnie. Általános szabály, hogy kezdetben nincs menő Ops a cégben. Először megvágjuk a terméket, és csak utána értjük meg, hogy a termék működéséhez figyelnünk kell a szervereket, és figyelni kell a kellékeket. Ekkor jön létre az Ops. Meg kell érteni, hogy az Ops, mint külön divízió, egy csomó akadályt állít a fejlesztés elé, és minden szállítás leáll. Vagyis ebben az esetben a DevOps kultúra már aktuális, de nem szabad megfeledkezni a sötét oldaláról sem.
Forrás: will.com