Nedávno som sa zúčastnil DevOpsForum 2019, ktoré organizuje Logrocon. Na tejto konferencii sa účastníci snažili nájsť riešenia a nové nástroje pre efektívnu interakciu medzi biznisom a špecialistami na vývoj a služby informačných technológií.
Konferencia bola úspešná: bolo naozaj veľa užitočných správ, zaujímavých formátov prezentácií a veľa komunikácie s prednášajúcimi. A je obzvlášť dôležité, aby sa mi nikto nič nesnažil predať, čoho sa v poslednej dobe previnili rečníci na veľkých konferenciách.
Výňatok z prejavov Raiffeisenbank, Alfastrakhovanie, skúsenosti Mango Telecom s implementáciou automatizácie a ďalšie detaily pod rezom.
Volám sa Yana, pracujem ako tester, robím automatizáciu a tiež DevOps a rada chodím na konferencie a stretnutia. Za posledné dva roky som bol na konferenciách Olega Bunina (HighLoad++, TeamLead Conf), Jug eventoch (Heisenbug, JPoint), TestCon Moskva, DevOps Pro Moskva, Big Data Moskva.
V prvom rade dávam do pozornosti program konferencie. Menej sa pozerám na to, o čom bude správa, a viac na rečníka. Aj keď sa správa ukáže ako veľmi technologická a zaujímavá, nie je pravda, že niektoré osvedčené postupy zo správy budete môcť aplikovať vo vašej spoločnosti. A potom potrebujete reproduktor.
Svetlo na konci potrubia v Raiffeisenbank
Reproduktory väčšinou poľujem na okraj, ktorý ma zaujíma. Na DevOpsForum 2019 ma zaujal rečník z Raiffeisenbank, Michail Bizhan. Počas svojho prejavu hovoril o tom, ako svoje tímy postupne zapájajú do DevOps, prečo to potrebujú a ako predať myšlienku transformácie DevOps biznisu. Vo všeobecnosti som hovoril o tom, ako vidieť svetlo na konci potrubia.
Michail Bizhan, riaditeľ pre automatizáciu v Raiffeisenbank
Teraz vo svojej spoločnosti nemajú „DevOps“. To znamená, že pracuje, ale nie vo všetkých tímoch. Pri implementácii DevOps sa spoliehajú na pripravenosť tímov ako z hľadiska konkrétnych inžinierov, tak aj z hľadiska potreby produktu a vyspelosti platformy, na ktorej je tento produkt postavený. Misha povedala, ako vysvetliť podniku, prečo je potrebný DevOps.
Bankový segment má niekoľko faktorov rastu: náklady na služby a rozšírenie klientskej základne. Zvyšovanie nákladov na služby nie je veľmi dobrým hnacím motorom, no rast klientskej základne je pravý opak. Ak konkurenti vydajú objektívne skvelý produkt, všetci zákazníci tam idú, potom sa časom trh vyrovná. Preto je uvádzanie noviniek na trh a rýchlosť ich uvedenia to hlavné, na čo sa banky zameriavajú. Presne na to slúži DevOps a podniky tomu rozumejú.
Ďalšia dôležitá poznámka: DevOps nie vždy skracuje čas uvedenia na trh. DevOps nemôže fungovať samostatne, je to len časť procesu tvorby a uvedenia produktu na trh od vývoja až po výrobu (od kódu k zákazníkovi). Všetko pred kódom však priamo nesúvisí s DevOps. To znamená, že marketéri môžu roky študovať trh a celý život stráviť dobiehaním konkurentov. Je potrebné rýchlo pochopiť, čo klient potrebuje a naplánovať implementáciu tej či onej funkcie – často to nestačí na to, aby DevOps fungoval a firma dosiahla svoj cieľ. Preto sa Raiffeisenbank v prvom rade zhodla s biznisom, že je potrebné naučiť sa používať DevOps. Automatizácia kvôli automatizácii v boji o nových zákazníkov veľmi nepomôže.
Vo všeobecnosti Misha verí, že DevOps je potrebné implementovať, ale múdro. A musíme byť pripravení na to, že na začiatku transformácie produktivita tímu klesne, bude zarábať menej peňazí, ale potom sa to ospravedlní.
Automatizácia testovania v Mango Telecom
Ďalší zaujímavý report pre mňa ako testera podal Egor Maslov z Mango Telecom. Prezentácia sa volala „Automatizácia celého testovacieho cyklu v tíme SCRUM“. Egor sa domnieva, že DevOps bol vytvorený špeciálne pre SCRUM, no zároveň je zavedenie DevOps do tímu SCRUM dosť problematické. Stáva sa to preto, že tím SCRUM stále niekde beží, nie je čas nechať sa rozptyľovať inováciami a prestavovať proces. Problém je aj v tom, že SCRUM nezahŕňa oddelenie podtímov v tíme (testovací tím, vývojový tím a pod.). Okrem toho, na automatizáciu existujúceho procesu je potrebná dokumentácia a v SCRUMe najčastejšie neexistuje úplná dokumentácia – „produkt je dôležitejší ako nejaký druh písania“.
Po prechode na SCRUM začali testeri konzultovať s vývojármi, ako testovať funkcie. Postupne narastal objem funkcionality, chýbala dokumentácia a začali chytať množstvo chýb vo funkcionalite, ktorá nebola pokrytá testami a celkovo už nebolo jasné, kto a kedy ju testoval. V skratke – zmätok a kolísanie. Rozhodli sme sa prejsť na automatizáciu testovania. Ale aj vtedy došlo k úplnému zlyhaniu. Najali externých špecialistov na automatizáciu, ktorí písali na zásobník neznámy interným testerom. Framework pre autotesty samozrejme fungoval, ale po odchode outsourcingov vydržal dva týždne. Ďalším bol pokus zaviesť autotesting číslo dva. Začalo to tým, že všetko je potrebné vybudovať vo firme, svojpomocne (správny vektor: vybudovať si odbornosť interne), v rámci SCRUM-u a v procese vytvárať dokumentáciu. Zásobník pre automatizáciu by sa mal rovnať zásobníku produktu (tu ho pridávam, netestujte svoj JavaScript projekt s ničím iným). Na konci sprintu urobili demo, ako funguje autotest s celým tímom (užitočné). Zvýšilo sa tak zapojenie všetkých členov tímu do procesu automatizácie, dôvera v autotesty a šanca, že tento autotest bude určite použitý (a nebude o mesiac komentovaný kvôli neustálym poruchám).
Mimochodom, na DevOpsForum 2019 bol otvorený mikrofón - dlho známy a podľa môjho názoru užitočný formát prejavov. Takto sa prechádzate, počúvate správy a potom sa rozhodnete, že na konferencii stojí za to diskutovať o určitej téme alebo probléme a podeliť sa o relevantné skúsenosti s riešením problému.
Tiež som si všimol, že organizátori spravili prúd krátkych reportáží. Každá správa netrvá dlhšie ako 10 minút, po ktorých nasledujú otázky. Týmto spôsobom môžete pokryť veľa tém naraz a klásť otázky rečníkom, ktorí vás zaujímajú.
Medzi prezentáciami som chodil po stánkoch partnerov konferencie a ukradol/vyhral som veľa vecí. Och, milujem leták!
Okrúhly stôl a problémy DevOps s riaditeľom vývoja v Alfastrakhovanie
Čerešničkou na torte DevOpsForum 2019 bolo pre mňa hodinové plenárne zasadnutie s odborníkmi z DevOps. Štyria účastníci stretnutia boli pozvaní, aby sa pozreli na DevOps z rôznych uhlov: Anton Isanin (Alfastrakhovanie, vývojový riaditeľ), Nailya Zamashkina (Fintech Lab, prevádzkový riaditeľ), Oleg Egorkin (Rostelecom, Agile coach) a Anton Martyanov (nezávislý expert, pozreli sa na DevOps z obchodného hľadiska).
Experti si sadli bližšie k ľuďom a potom sa začali diať veci: celú hodinu sa účastníci z publika pýtali svoje otázky a experti sa chopili rapu. Občas tam boli poriadne debaty. Otázky boli veľmi odlišné, napríklad: sú vôbec inžinieri DevOps potrební, prečo ich nemožno vyškoliť ako systémových administrátorov, či by mal byť DevOps ponúkaný každému, aká je jeho hodnota atď.
Potom som sa osobne rozprával s Antonom Isaninom. Diskutovali sme o potrebe priniesť kultúru DevOps do každého domova a odhalili sme temnú stránku transformácie DevOps.
Predstavme si, že sa všetci spojili a rozhodli, že DevOps potrebuje produkt aj firma a tím. Poďme to implementovať. Všetko vyšlo. Vydýchli sme si. DevOps nás zblížil s klientom, teraz vieme rýchlo splniť všetky jeho priania. Výsledkom je, že máme veľké oddelenie Ops s prísnymi predpismi a požiadavkami, ktoré neustále nachádza chyby v produkte a vytvára množstvo požiadaviek. Okrem toho sú všetky chyby priradené do stavu „naliehavé“, aj keď klient neočakávane chcel zafarbiť tlačidlo na žlto namiesto zelenej. Projekt rastie, rastie počet vydaní a tým aj počet defektov a nepochopenia novej funkcionality zo strany klientov. Ops najíma ďalších 10 ľudí, aby držali krok s hlásením chýb, a vývoj najíma 15 ďalších, aby držali krok s ich zatváraním. A namiesto zavádzania nových funkcií tím pracuje s nekonečnými SD, pričom používateľovi vysvetľuje funkčnosť a podporu. Výsledkom je, že operácie aj vývoj fungujú, ale klient a podnik sú nespokojní: nové funkcie uviaznu. Zdá sa, že DevOps existuje, ale zdá sa, že neexistuje.
Čo sa týka potreby implementácie DevOps, Anton jasne uviedol, že to priamo závisí od rozsahu podnikania. Ak obsluhovanie jedného klienta ročne prináša spoločnosti miliardu, DevOps nie je potrebný (za predpokladu, že nepotrebujete u tohto klienta pravidelne zavádzať nové zmeny). Všetko je pokryté čokoládou. Ale ak obchod rastie a objavuje sa viac klientov, potom sa musíte podriadiť. Spravidla v spoločnosti spočiatku nie sú žiadne cool Ops. Najprv produkt rozrežeme a až potom pochopíme, že na to, aby produkt fungoval, musíme dohliadať na servery a monitorovať zásoby. Vtedy vzniká Ops. Zostáva pochopiť, že Ops ako samostatná divízia začne klásť veľa prekážok vo vývoji a všetky dodávky sa začnú brzdiť. To znamená, že v tomto prípade je kultúra DevOps už relevantná, ale nesmieme zabudnúť na jej temnú stránku.
Zdroj: hab.com