Nedávno jsem se zúčastnil DevOpsForum 2019, které pořádá Logrocon. Na této konferenci se účastníci snažili najít řešení a nové nástroje pro efektivní interakci mezi businessem a specialisty na vývoj a služby informačních technologií.
Konference byla úspěšná: bylo opravdu mnoho užitečných zpráv, zajímavých formátů prezentací a hodně komunikace s přednášejícími. A obzvláště důležité je, že se mi nikdo nepokusil nic prodat, což se v poslední době provinili řečníci na velkých konferencích.
Výňatek z projevů Raiffeisenbank, Alfastrakhovanie, zkušenosti Mango Telecom se zaváděním automatizace a další podrobnosti pod řezem.
Jmenuji se Yana, pracuji jako tester, dělám automatizaci a také DevOps a ráda chodím na konference a setkání. Během posledních dvou let jsem byl na konferencích Olega Bunina (HighLoad++, TeamLead Conf), Jug event (Heisenbug, JPoint), TestCon Moskva, DevOps Pro Moskva, Big Data Moskva.
Nejprve upozorňuji na program konference. Méně se dívám na to, o čem zpráva bude, a více na řečníka. I když se zpráva ukáže jako velmi technologická a zajímavá, není pravda, že některé osvědčené postupy ze zprávy budete moci aplikovat ve vaší společnosti. A pak potřebujete reproduktor.
Světlo na konci potrubí u Raiffeisenbank
Obvykle sháním reproduktory na okraj, které mě zajímají. Na DevOpsForum 2019 mě zaujal řečník z Raiffeisenbank, Michail Bizhan. Během svého projevu mluvil o tom, jak své týmy postupně zapojují do DevOps, proč to potřebují a jak prodat myšlenku transformace DevOps byznysu. Obecně jsem mluvil o tom, jak vidět světlo na konci potrubí.
Michail Bizhan, ředitel automatizace v Raiffeisenbank
Nyní ve své společnosti nemají „DevOps“. To znamená, že pracuje, ale ne ve všech týmech. Při implementaci DevOps spoléhají na připravenost týmů jak z hlediska konkrétních inženýrů, tak z hlediska potřeby produktu a vyspělosti platformy, na které je tento produkt postaven. Misha řekla, jak vysvětlit firmě, proč je DevOps potřeba.
Bankovní segment má několik faktorů růstu: náklady na služby a rozšíření klientské základny. Zvyšování nákladů na služby není příliš dobrým hnacím motorem, ale růst klientské základny je opakem. Pokud konkurenti uvolní objektivně skvělý produkt, všichni zákazníci tam půjdou a trh se časem vyrovná. Proto je uvádění nových produktů na trh a rychlost jejich zavedení tím hlavním, na co se banky zaměřují. Přesně k tomu slouží DevOps a podniky to chápou.
Další důležitá poznámka: DevOps ne vždy zkracuje dobu uvedení na trh. DevOps nemůže fungovat samostatně, je to jen součást procesu tvorby a uvedení produktu na trh od vývoje po výrobu (od kódu k zákazníkovi). Ale vše před kódem přímo nesouvisí s DevOps. To znamená, že marketéři mohou studovat trh roky a celý život strávit doháněním konkurentů. Je potřeba rychle pochopit, co klient potřebuje a naplánovat implementaci té či oné funkce – často právě to nestačí k tomu, aby DevOps fungoval a firma dosáhla svého. Raiffeisenbank se proto v první řadě shodla s byznysem, že je potřeba naučit se používat DevOps. Automatizace kvůli automatizaci v boji o nové zákazníky příliš nepomůže.
Obecně se Misha domnívá, že DevOps je třeba implementovat, ale moudře. A musíme být připraveni na to, že na začátku transformace produktivita týmu klesne, bude vydělávat méně peněz, ale pak se to ospravedlní.
Automatizace testování ve společnosti Mango Telecom
Další zajímavou zprávu pro mě jako testera podal Egor Maslov z Mango Telecom. Prezentace se jmenovala „Automatizace celého testovacího cyklu v týmu SCRUM“. Egor se domnívá, že DevOps byl vytvořen speciálně pro SCRUM, ale zároveň je zavedení DevOps do týmu SCRUM poměrně problematické. To se děje proto, že tým SCRUM stále někde běží, není čas se rozptylovat inovacemi a přestavovat proces. Problém je také v tom, že SCRUM nezahrnuje oddělení podtýmů v týmu (testovací tým, vývojový tým atd.). Kromě toho, k automatizaci existujícího procesu je potřeba dokumentace a ve SCRUMu nejčastěji neexistuje úplná dokumentace – „produkt je důležitější než nějaký druh psaní“.
Po přechodu na SCRUM začali testeři konzultovat s vývojáři, jak funkce testovat. Postupně se zvětšoval objem funkčnosti, chyběla dokumentace a začali chytat spoustu chyb ve funkčnosti, která nebyla pokryta testy a celkově už nebylo jasné, kdo a kdy to testoval. Stručně řečeno - zmatek a kolísání. Rozhodli jsme se přejít na automatizaci testování. Ale i tehdy došlo k naprostému selhání. Najali outsourcované specialisty na automatizaci, kteří psali na zásobník neznámý interním testerům. Framework pro autotesty samozřejmě fungoval, ale po odchodu outsourcerů vydržel dva týdny. Další byl pokus o zavedení autotestu číslo dvě. Začalo to tím, že vše je potřeba vybudovat ve firmě, vlastními silami (správný vektor: vybudovat si odbornost interně), v rámci SCRUMu a v procesu vytvořit dokumentaci. Zásobník pro automatizaci by se měl rovnat zásobníku produktu (zde ho přidávám, netestujte svůj JavaScript projekt s ničím jiným). Na konci sprintu udělali demo, jak autotest funguje s celým týmem (užitečné). Zvýšilo se tak zapojení všech členů týmu do procesu automatizace, důvěra v autotesty a šance, že tento autotest bude určitě využit (a nebude za měsíc kvůli neustálým výpadkům komentován).
Mimochodem, na DevOpsForum 2019 byl otevřený mikrofon - dlouho známý a podle mého názoru užitečný formát projevů. Chodíte takto, posloucháte zprávy a pak se rozhodnete, že na konferenci stojí za to diskutovat o určitém tématu nebo problému a sdílet relevantní zkušenosti s řešením problému.
Také jsem si všiml, že organizátoři udělali proud krátkých reportáží. Každá zpráva netrvá déle než 10 minut, po které následují otázky. Tímto způsobem můžete pokrýt mnoho témat najednou a klást otázky řečníkům, kteří vás zajímají.
Mezi prezentacemi jsem chodil po stáncích partnerů konference a ukradl/vyhrál spoustu věcí. Oh, miluji leták!
Kulatý stůl a problémy DevOps s ředitelem vývoje ve společnosti Alfastrakhovanie
Třešničkou na dortu DevOpsForum 2019 pro mě bylo hodinové plenární zasedání s odborníky z DevOps. Čtyři účastníci zasedání byli pozváni, aby se podívali na DevOps z různých úhlů: Anton Isanin (Alfastrakhovanie, vývojový ředitel), Nailya Zamashkina (Fintech Lab, provozní ředitel), Oleg Egorkin (Rostelecom, Agile coach) a Anton Martyanov (nezávislý odborník, podíval se na DevOps z obchodního hlediska).
Experti se posadili blíž k lidem a pak se začaly dít věci: celou hodinu se účastníci z publika ptali a experti se chopili rapu. Občas tam byly opravdové debaty. Otázky byly velmi odlišné, například: jsou inženýři DevOps vůbec potřeba, proč nemohou být vyškoleni jako správci systému, zda by měl být DevOps nabízen všem, jaká je jeho hodnota a tak dále.
Potom jsem mluvil s Antonem Isaninem osobně. Diskutovali jsme o potřebě přinést kulturu DevOps do každého domova a odhalili jsme temnou stránku transformace DevOps.
Představme si, že se všichni sešli a rozhodli, že DevOps potřebuje jak produkt, tak firma a tým. Pojďme to implementovat. Všechno se povedlo. Vydechli jsme. DevOps nás přiblížil klientovi, nyní můžeme rychle splnit všechna jeho přání. Díky tomu máme velké oddělení Ops s přísnými předpisy a požadavky, které neustále nachází závady na produktu a vytváří hromadu požadavků. Všem závadám je navíc přiřazen stav „naléhavé“, a to i v případě, že si klient nečekaně přál obarvit tlačítko žlutě místo zeleně. Projekt roste, roste počet releasů a tím pádem i počet defektů a nepochopení nové funkcionality ze strany klientů. Ops najímá dalších 10 lidí, aby drželi krok s hlášením závad, a vývoj najímá dalších 15, aby udrželi krok s jejich uzavíráním. A místo zavádění nových funkcí tým pracuje s nekonečnými SD, které uživateli vysvětlují funkčnost a zároveň podporu. Výsledkem je, že jak operace, tak vývoj fungují, ale klient a firma jsou nešťastní: nové funkce se zasekávají. Ukazuje se, že DevOps zdánlivě existuje, ale zdá se, že neexistuje.
Pokud jde o potřebu implementace DevOps, Anton jasně uvedl, že to přímo závisí na rozsahu podnikání. Pokud služba jednoho klienta ročně přináší společnosti miliardu, DevOps není potřeba (za předpokladu, že u tohoto klienta nepotřebujete pravidelně zavádět nové změny). Vše je pokryto čokoládou. Pokud ale obchod roste a objevují se další klienti, pak je potřeba vyhovět. Zpočátku ve společnosti zpravidla nejsou žádné cool Ops. Nejprve produkt odřízneme a teprve potom pochopíme, že aby produkt fungoval, musíme mít na očích servery a monitorovat zásoby. Tehdy vzniká Ops. Zbývá pochopit, že Ops jako samostatná divize začne klást spoustu překážek vývoji a všechny dodávky se začnou brzdit. To znamená, že v tomto případě je kultura DevOps již relevantní, ale nesmíme zapomínat na její temnou stránku.
Zdroj: www.habr.com