Nemrég részt vettem a DevOpsForum 2019-en, amelyet a Logrocon szervezett. Ezen a konferencián a résztvevők a vállalkozások és a fejlesztői, illetve IT-szolgáltatók közötti hatékony együttműködés új megoldásait és eszközeit keresték.
A konferencia jól sikerült: valóban sok hasznos előadás volt, érdekes előadási formátumokkal, és tonnányi beszélgetéssel a prezentálókkal. És ami különösen fontos, senki nem akart semmit eladni, ami az utóbbi időben jellemző a nagy konferenciák előadóira.
A Raiffeisen Bank, az Alfa Insurance és a Mango Telecom automatizálási tapasztalatairól és egyéb részletekről a kat alatt olvashat.
A nevem Jana, tesztelőként dolgozom, automatizálással és DevOps-szal foglalkozom, és imádok konferenciákra és meetupra járni. Az utolsó két évben részt vettem Oleg Bunin konferenciáin (HighLoad++, TeamLead Conf), a Jug rendezvényein (Heisenbug, JPoint), a TestCon Moscow, DevOps Pro Moscow, Big Data Moscow konferenciákon.
Első lépésként a konferencia programjára figyelek. Kevésbé érdekel, miről szól az előadás, sokkal inkább a prezentáló személyére. Még ha az előadás nagyon technológiai és érdekes is, nem biztos, hogy a bemutatott legjobb gyakorlatokat alkalmazni tudom a saját cégeimben. Erre van szükséged az előadóra.
Fény a pipeline végén a Raiffeisen Banknál
Általában érdekes előadókat keresek a konferenciák folyosóin. A DevOpsForum 2019-en az érdeklődési terület műhelyében a Raiffeisen Bank előadója, Mihail Bizhan került a látókörömbe. Az előadása során elmondta, hogyan segítik a csapataikat fokozatosan a DevOps-ra átállni, miért van szükségük erre, és hogyan lehet eladni az üzletnek a DevOps-transzformáció ötletét. Összességében arról is beszélt, hogyan lehet látni a fényt a pipeline végén.
Mihail Bizhan, a Raiffeisen Bank automatizálási igazgatója
Jelenleg a cégükben nem valós „igor DevOps” valósul meg. Tehát igazi, de nem minden csapatban. A DevOps bevezetésénél a csapatok felkészültségére építenek, mind az egyes mérnökök szempontjából, mind a termék igényének és a platform érettségének szempontjából, amelyre a termék épült. Misha elmondta, hogyan lehet elmagyarázni az üzletnek, miért van szükség DevOps-ra.
A bank segment has several growth drivers: service cost and the expansion of the customer base. Increasing service costs is not a very good driver, whereas growing the customer base is just the opposite. If competitors release a genuinely cool product, all the clients will flock there, and then over time the market stabilizes. Therefore, the introduction of new products and the speed of their market entry is the main focus for banks. This is exactly why DevOps is needed, and businesses understand this.
Another important point: DevOps does not always reduce time to market. DevOps cannot work alone; it is just one part of the process of creating and launching a product, from development to production (from code to customer). Everything before the code is not directly related to DevOps. This means that marketers can study the market for years and spend a lifetime catching up with competitors. It is essential to quickly understand what the customer needs and to plan the implementation of specific features — often, this is what is lacking for DevOps to work effectively and for the company to achieve its goals. Therefore, first and foremost, Raiffeisen Bank agreed with the business on the necessity to learn how to utilize DevOps. Automation for the sake of automation is not going to help much in the fight for new clients.
In general, Misha believes that DevOps needs to be implemented wisely. One must be prepared for the fact that at the beginning of the transformation, the team’s productivity will drop, earning less money at first, but eventually, this will pay off.
Test automation at 'Mango Telecom'
Egy új, számomra érdekes előadást tartott Egor Maszlov a «Mango Telekom» cégtől. Az előadás címe: „A tesztelés teljes ciklusának automatizálása SCRUM csapatban”. Egor szerint a DevOps kifejezetten a SCRUM számára készült, de a DevOps SCRUM csapatba való bevezetése meglehetősen problémás. Ennek oka, hogy a SCRUM csapat állandóan rohan valahova, nincs idő az újításokra és a folyamat átalakítására. A probléma továbbá abban rejlik, hogy a SCRUM nem feltételezi alagsorok kialakítását a csapaton belül (tesztelő csapat, fejlesztő csapat stb.). Ezen kívül az automatizált folyamatokhoz dokumentációra van szükség, de a SCRUM gyakran teljesen mentes a dokumentációtól — „a termék fontosabb, mint bármilyen írásos anyag”.
A SCRUM-ra való áttérés után a tesztelők elkezdtek tanácskozni a fejlesztőkkel arról, hogyan teszteljék a funkciókat. Fokozatosan a funkcionalitás mértéke növekedett, a dokumentáció viszont hiányzott, és sok hibát kezdtek el felfedezni azokban a funkciókban, amelyeket nem fedtek le tesztekkel, és már nem volt világos, ki és mikor tesztelte őket. Röviden — teljes káosz. Úgy döntöttek, áttérnek a tesztelés automatizálására. De akkor is teljes kudarc történt. Külső szakértőket vontak be az automatizálás érdekében, akik olyan technológiát használtak, amely ismeretlen volt a meglévő tesztelők számára. Az automata tesztelő keretrendszer persze működött, de miután a külsők elmentek, két hétig élt. Ezután megpróbálták második alkalommal bevezetni az automatizált tesztelést. Ez úgy kezdődött, hogy mindent belsőleg, saját erőforrásaikkal (helyes irány: növeljétek a tudást a cégen belül), SCRUM keretein belül kell felépíteni, és közben dokumentációt kell készíteni. Az automatizálás technológiai stack-nek egyeznie kell a termék stack-jével (itt biztosan egyetértek, ne teszteljétek a projektet JavaScript-tel valami mással). A sprint végén bemutatták, hogyan működik az automata teszt, a teljes csapat részvételével (hasznos). Így nőtt a csapat minden tagjának elkötelezettsége a tesztelés automatizálása iránt, valamint a tesztelők és az automata tesztek iránti bizalom, és nőtt az esélye annak, hogy az adott automata tesztet valóban használni fogják (és nem kommentálják ki egy hónap múlva a folyamatos hibák miatt).
Tudtad, hogy a DevOpsForum 2019-en volt nyílt mikrofon — egy régóta ismert és véleményem szerint hasznos előadásformátum. Csak úgy sétálsz, hallgatsz előadásokat, majd úgy döntesz, hogy a konferencia keretein belül érdemes megvitatni egy témát vagy problémát, megosztani egy releváns tapasztalatot a feladat megoldásáról.
Azt is észrevettem, hogy a szervezők rövid előadások sorozatát indították. Minden előadás legfeljebb 10 percig tart, amit kérdések követnek. Ily módon sok témát lehet felölelni, és kérdéseket lehet feltenni a megszólaltatott előadóknak, akik érdekesnek tűntek.
Az előadások között sétáltam a konferencia partnereinek standjai között, és rengeteg apróságot hoztam el/nyertem. Ó, mennyire szeretem a szóróanyagokat!
Kerekasztal és DevOps kérdések a fejlesztési igazgatóval az Альфастрахование cégtől
A DevOpsForum 2019 csúcspontja számomra a DevOps szakértők órás plenáris ülése volt. Négy résztvevőt hívtak meg, akik más szemszögből nézték a DevOps-t: Anton Isanin (Альфастрахование, fejlesztési igazgató), Nailya Zamashkina (Fintech Lab, operatív igazgató), Oleg Yegorkin (Ростелеком, Agile coach) és Anton Martyanov (független szakértő, aki a DevOps-t üzleti oldalról vizsgálta).
A szakértők közelebb ültek a közönséghez, és onnantól kezdődtek a dolgok: egy teljes órán át a terem résztvevői kérdéseket tettek fel, míg a szakértők igyekeztek válaszolni. Néha valódi viták zajlottak. A kérdések a legkülönfélébbek voltak, például: szükség van-e egyáltalán DevOps mérnökökre, miért nem lehet őket rendszergazdákból kinevelni, mindenkinek ajánlott-e a DevOps, mi a benne rejlő érték, és így tovább.
Ezután személyesen is beszéltem Anton Isaninnal. Megvitatottuk a DevOps kultúra minden házba való eljuttatásának szükségességét, és feltártuk a DevOps transzformáció sötét oldalát.
Képzeljük el, hogy mindenki összejött, és úgy döntött, hogy a DevOps szükséges mind a termék, mind az üzlet és a csapat számára. Elindult a bevezetés. Minden működött. Megkönnyebbültünk. A DevOps közelebb vitt minket az ügyfelekhez, most gyorsan teljesíthetjük minden kívánságukat. Végül egy nagy Ops részlegünk lett szigorú szabályokkal és követelményekkel, amely folyamatosan problémákat generál a terméken, sok bejelentést készítve. Ráadásul minden hiba „sürgős” státusszal érkezik, még akkor is, ha az ügyfél váratlanul azt szeretné, hogy a gomb sárga színű legyen a zöld helyett. Növekszik a projekt, nő a kiadások száma, és ezzel párhuzamosan a hibák és az új funkciók ügyfelek általi megértésének hiánya is. Az Ops még 10 embert felvesz, hogy el tudják mondani a hibákat, míg a fejlesztés 15 új kollégát alkalmaz, hogy zárni tudják azokat. És ahelyett, hogy új funkciókat vezetnének be, a csapat végtelen SD-kkel dolgozik, magyarázva a funkciót a felhasználónak és a támogatásnak is. Végül az Ops és a fejlesztés is dolgozik, de az ügyfél és az üzlet elégedetlen: az új funkciók megakadtak. Úgy tűnik, a DevOps van, de mintha mégsem lenne.
Anton határozottan kijelentette a DevOps implementációjának szükségességéről, hogy ez közvetlenül függ az üzlet méretétől. Ha évente egy ügyfél kiszolgálása milliárdokat hoz a cégnek – a DevOps nem szükséges (feltéve, hogy nem szükséges rendszeresen új változtatásokat bevezetni ennek az ügyfélnek). Minden rendben van. De ha az üzlet növekszik, és egyre több ügyfél arrives, akkor már meg kell felelni. Általában a cégben kezdetben nincs jól működő Ops. Először fejlesztjük a terméket, és csak később jövünk rá, hogy ahhoz, hogy a termék működjön, figyelni kell a szerverek, a szállításokra. Ekkor jön létre az Ops. Meg kell érteni, hogy az Ops, mint különálló részleg, sok akadályt állít a fejlesztés elé, és minden szállításar elakad. Tehát ebben az esetben a DevOps kultúrája már aktuális, csak ne feledkezzünk meg a sötét oldaláról sem.
Forrás: habr.com
