Nedavno sem se udeležil foruma DevOpsForum 2019, ki ga je gostil Logrocon. Na tokratni konferenci so udeleženci skušali poiskati rešitve in nova orodja za učinkovito interakcijo med podjetji in strokovnjaki za razvojne in informacijske storitve.
Konferenca je bila uspešna: bilo je res veliko koristnih poročil, zanimivih oblik predstavitve in veliko komunikacije z govorci. In še posebej pomembno je, da mi nihče ni poskušal ničesar prodati, kar zadnje čase zagrešijo govorci na velikih konferencah.
Odlomek iz govorov Raiffeisenbank, Alfastrakhovanie, izkušenj Mango Telecoma pri izvajanju avtomatizacije in drugih podrobnosti pod rezom.
Moje ime je Yana, delam kot preizkuševalec, ukvarjam se z avtomatizacijo in DevOpsom ter rada hodim na konference in srečanja. V zadnjih dveh letih sem bil na konferencah Olega Bunina (HighLoad++, TeamLead Conf), dogodkih Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Najprej opozarjam na program konference. Manj gledam na to, o čem bo poročilo, bolj na govornika. Tudi če se poročilo izkaže za zelo tehnološko in zanimivo, ni dejstvo, da boste nekatere dobre prakse iz poročila lahko uporabili v svojem podjetju. In potem potrebujete zvočnik.
Luč na koncu cevovoda pri Raiffeisenbank
Običajno ob strani iščem govorce, ki me zanimajo. Na forumu DevOpsForum 2019 me je zanimal govornik iz Raiffeisenbank, Mikhail Bizhan. Med svojim govorom je govoril o tem, kako postopoma navajajo svoje ekipe na DevOps, zakaj ga potrebujejo in kako idejo o preobrazbi DevOps prodati podjetjem. No, na splošno sem govoril o tem, kako videti luč na koncu cevovoda.
Mikhail Bizhan, direktor avtomatizacije pri Raiffeisenbank
Zdaj v svojem podjetju nimajo "DevOps". Se pravi, dela, vendar ne v vseh ekipah. Pri implementaciji DevOps se zanašajo na pripravljenost ekip, tako v smislu konkretnih inženirjev, kot v smislu potrebe izdelka in zrelosti platforme, na kateri je ta izdelek zgrajen. Misha je povedal, kako podjetju razložiti, zakaj je DevOps potreben.
Bančni segment ima več dejavnikov rasti: stroške storitev in širitev baze strank. Povečevanje stroškov storitev ni ravno dobro gonilo, povečanje števila strank pa nasprotno. Če konkurenti izdajo objektivno kul izdelek, gredo vsi kupci tja, nato pa se čez čas trg izravna. Zato je uvajanje novih produktov na trg in hitrost njihovega uvajanja glavna stvar, na katero se banke osredotočajo. Točno temu je DevOps namenjen in podjetja to razumejo.
Naslednja pomembna opomba: DevOps ne skrajša vedno časa do trga. DevOps ne more delovati sam, je le del procesa ustvarjanja in uvajanja izdelka na trg od razvoja do proizvodnje (od kode do stranke). Toda vse pred kodo ni neposredno povezano z DevOps. To pomeni, da lahko tržniki leta preučujejo trg in vse življenje preživijo v dohitevanju konkurentov. Treba je hitro razumeti, kaj stranka potrebuje, in načrtovati implementacijo te ali one funkcije - pogosto je to tisto, kar ni dovolj, da DevOps deluje in podjetje doseže svoj cilj. Zato so se v Raiffeisenbank najprej strinjali z gospodarstvom, da se je treba naučiti uporabljati DevOps. Avtomatizacija zaradi avtomatizacije ne bo veliko pomagala v boju za nove stranke.
Na splošno Misha meni, da je treba DevOps izvajati, vendar pametno. In moramo biti pripravljeni na dejstvo, da bo na začetku preobrazbe produktivnost ekipe padla, zaslužila bo manj denarja, a potem bo to upravičeno.
Avtomatizacija testiranja pri Mango Telecomu
Še eno zanimivo poročilo zame kot preizkuševalca je podal Egor Maslov iz Mango Telecoma. Predstavitev se je imenovala "Avtomatizacija celotnega cikla testiranja v ekipi SCRUM." Egor verjame, da je bil DevOps ustvarjen posebej za SCRUM, hkrati pa je uvedba DevOps v ekipo SCRUM precej problematična. To se zgodi, ker ekipa SCRUM vedno nekam teče, ni časa, da bi se motili z inovacijami in obnovili proces. Problem je tudi v tem, da SCRUM ne vključuje ločevanja podekip v ekipi (testna ekipa, razvojna ekipa itd.). No, poleg tega je za avtomatizacijo obstoječega procesa potrebna dokumentacija, v SCRUM-u pa najpogosteje ni popolne dokumentacije - "izdelek je pomembnejši od neke vrste pisanja."
Po prehodu na SCRUM so se preizkuševalci začeli posvetovati z razvijalci o tem, kako preizkusiti funkcije. Postopoma se je obseg funkcionalnosti povečeval, dokumentacije ni bilo, v funkcionalnosti so začeli loviti veliko hroščev, ki niso bili zajeti s testi in nasploh ni bilo več jasno, kdo in kdaj jo je testiral. Na kratko – zmeda in nihanje. Odločili smo se za prehod na avtomatizacijo testiranja. Toda tudi takrat je prišlo do popolnega poloma. Najeli so zunanje strokovnjake za avtomatizacijo, ki so pisali na sklad, ki ni bil znan notranjim preizkuševalcem. Ogrodje za avtoteste je seveda delovalo, a po odhodu zunanjih izvajalcev je trajalo dva tedna. Sledil je poskus uvedbe samodejnega testiranja številka dve. Začelo se je s tem, da je treba vse graditi znotraj podjetja, sami (pravi vektor: strokovnost gradite interno), v okviru SCRUM-a in ob tem ustvarjati dokumentacijo. Sklad za avtomatizacijo mora biti enak skladu izdelka (tukaj ga dodajam, ne preizkušajte svojega JavaScript projekta z ničemer drugim). Na koncu sprinta so s celotno ekipo naredili demo, kako deluje avtotest (koristno). Tako se je povečala vključenost vseh članov ekipe v proces avtomatizacije, povečalo pa se je tudi zaupanje v avtoteste in možnost, da bo ta avtotest zagotovo uporabljen (in ne bo komentiran čez en mesec zaradi stalnih napak).
Mimogrede, na DevOpsForum 2019 je bil odprt mikrofon - že dolgo znana in po mojem mnenju uporabna oblika govorov. Takole hodiš naokoli, poslušaš poročila, nato pa se odločiš, da je na konferenci vredno razpravljati o določeni temi ali problemu, deliti ustrezne izkušnje pri reševanju problema.
Opazil sem tudi, da so organizatorji naredili tok kratkih poročil. Posamezno poročilo ne traja več kot 10 minut, sledijo pa mu vprašanja. Tako lahko pokrivate več tem hkrati in postavljate vprašanja govorcem, ki vas zanimajo.
Med predstavitvami sem hodil po kabinah partnerjev konference in ukradel/zadel marsikaj. Oh, všeč mi je izroček!
Okrogla miza in vprašanja DevOps z direktorjem razvoja pri Alfastrakhovanie
Češnja na torti DevOpsForum 2019 je bila zame enourna plenarna seja s strokovnjaki DevOps. Štirje udeleženci seje so bili povabljeni, da si ogledajo DevOps z različnih zornih kotov: Anton Isanin (Alfastrakhovanie, direktor razvoja), Nailya Zamashkina (Fintech Lab, operativni direktor), Oleg Egorkin (Rostelecom, Agile coach) in Anton Martyanov (neodvisni strokovnjak, si je ogledal DevOps). s poslovnega vidika).
Strokovnjaki so se usedli bližje ljudem in potem se je začelo dogajati: celo uro so udeleženci iz občinstva postavljali vprašanja, strokovnjaki pa so zagovarjali. Včasih so bile prave debate. Vprašanja so bila zelo različna, na primer: ali so DevOps inženirji sploh potrebni, zakaj se ne morejo izšolati za sistemske skrbnike, naj se DevOps ponudi vsem, kakšna je njegova vrednost ipd.
Nato sem se osebno pogovarjal z Antonom Isaninom. Razpravljali smo o potrebi po prenosu kulture DevOps v vsak dom in razkrili temno stran preobrazbe DevOps.
Predstavljajmo si, da so se vsi zbrali in odločili, da DevOps potrebujejo tako izdelek kot podjetje in ekipa. Pojdimo to izvajati. Vse se je izšlo. Izdihnili smo. DevOps nas je približal naročniku, sedaj lahko hitro uresničimo vse njegove želje. Posledično imamo velik Ops oddelek s strogimi predpisi in zahtevami, ki nenehno najde napake v izdelku in ustvari kup zahtev. Poleg tega se vsem okvaram dodeli status »nujno«, tudi če je stranka nepričakovano želela gumb obarvati rumeno namesto zeleno. Projekt raste, število izdaj raste in s tem tudi število napak in nerazumevanja novih funkcionalnosti s strani naročnikov. Ops zaposli še 10 ljudi, da sledijo poročanju o napakah, razvoj pa zaposli še 15 ljudi, da sledijo njihovemu zapiranju. In namesto da bi predstavili nove funkcije, ekipa dela z neskončnimi SD-ji, ki uporabniku razlagajo funkcionalnost in hkrati podpirajo. Posledično tako operacije kot razvoj delujejo, vendar sta stranka in podjetje nezadovoljna: nove funkcije se zataknejo. Izkazalo se je, da se zdi, da DevOps obstaja, vendar se zdi, da ne obstaja.
Glede potrebe po implementaciji DevOps je Anton jasno povedal, da je to neposredno odvisno od obsega posla. Če servisiranje ene stranke na leto prinese podjetju milijardo, DevOps ni potreben (pod pogojem, da vam ni treba redno uvajati novih sprememb za to stranko). Vse je oblito s čokolado. Toda če posel raste in se pojavi več strank, potem morate upoštevati. Praviloma v podjetju na začetku ni kul Ops. Najprej produkt razrežemo, šele nato razumemo, da moramo za delovanje produkta paziti na strežnike in spremljati dobave. Takrat nastane Ops. Še vedno je treba razumeti, da bo Ops kot ločen oddelek začel postavljati kup ovir za razvoj in vse dobave bodo začele zastajati. To pomeni, da je v tem primeru kultura DevOps že pomembna, vendar ne smemo pozabiti na njeno temno stran.
Vir: www.habr.com