Nedavno sam prisustvovao DevOpsForum 2019, čiji je domaćin bio Logrocon. Na ovoj konferenciji učesnici su pokušali da pronađu rješenja i nove alate za efikasnu interakciju između poslovnog i razvojnog i stručnjaka za usluge informacionih tehnologija.
Konferencija je uspjela: bilo je zaista puno korisnih izvještaja, zanimljivih formata prezentacije i dosta komunikacije sa govornicima. A posebno je važno da mi niko ništa nije pokušao prodati, za šta su u posljednje vrijeme krivi govornici na velikim konferencijama.
Odlomak iz govora Raiffeisenbanke, Alfastrakhovanie, iskustva Mango Telecoma u implementaciji automatizacije i drugih detalja ispod reza.
Zovem se Yana, radim kao tester, bavim se automatizacijom, kao i DevOps-om, i volim ići na konferencije i sastanke. U protekle dvije godine bio sam na konferencijama Olega Bunina (HighLoad++, TeamLead Conf), Jug događajima (Heisenbug, JPoint), TestCon Moskva, DevOps Pro Moskva, Big Data Moskva.
Prije svega skrećem pažnju na program konferencije. Manje gledam o čemu će izvještaj biti, a više na govornika. Čak i ako se izvještaj pokaže kao vrlo tehnološki i zanimljiv, nije činjenica da ćete neke od najboljih praksi iz izvještaja moći primijeniti u svojoj kompaniji. A onda vam treba zvučnik.
Svjetlo na kraju cjevovoda kod Raiffeisenbanke
Obično po strani tražim zvučnike koji me zanimaju. Na DevOpsForumu 2019, zainteresovao me je govornik iz Raiffeisenbanke, Mikhail Bizhan. Tokom svog govora, govorio je o tome kako postepeno navlače svoje timove na DevOps, zašto im je to potrebno i kako da ideju transformacije DevOpsa prodaju biznisu. Pa, općenito, pričao sam o tome kako vidjeti svjetlo na kraju cjevovoda.
Mikhail Bizhan, direktor automatizacije u Raiffeisenbank
Sada nemaju "DevOps" u svojoj kompaniji. Odnosno, on radi, ali ne u svim timovima. Prilikom implementacije DevOps-a oslanjaju se na spremnost timova, kako u pogledu konkretnih inženjera, tako i u pogledu potrebe proizvoda i zrelosti platforme na kojoj je ovaj proizvod izgrađen. Misha je rekao kako da objasni biznisu zašto je DevOps potreban.
Bankarski segment ima nekoliko pokretača rasta: cijene usluga i širenje baze klijenata. Povećanje cijene usluga nije baš dobar pokretač, ali povećanje baze klijenata je suprotno. Ako konkurenti izdaju objektivno kul proizvod, svi kupci odu tamo, a onda se s vremenom tržište izjednači. Stoga je uvođenje novih proizvoda na tržište i brzina njihovog uvođenja glavna stvar na koju se banke fokusiraju. To je upravo ono čemu služi DevOps, i kompanije to razumiju.
Sljedeća važna napomena: DevOps ne smanjuje uvijek vrijeme izlaska na tržište. DevOps ne može raditi sam, to je samo dio procesa kreiranja i dovođenja proizvoda na tržište od razvoja do proizvodnje (od koda do kupca). Ali sve prije koda nije direktno povezano s DevOps-om. To jest, trgovci mogu godinama proučavati tržište i cijeli život sustizati konkurente. Potrebno je brzo shvatiti šta klijentu treba i planirati implementaciju ove ili one funkcije – često je to ono što nije dovoljno da DevOps radi i da kompanija postigne svoj cilj. Stoga se, prije svega, Raiffeisenbank složila sa biznisom da je potrebno naučiti kako koristiti DevOps. Automatizacija radi automatizacije neće puno pomoći u borbi za nove kupce.
Općenito, Misha vjeruje da DevOps treba implementirati, ali mudro. I moramo biti spremni na činjenicu da će na početku transformacije produktivnost tima pasti, zarađivati manje novca, ali će onda biti opravdano.
Automatizacija testiranja u Mango Telecomu
Još jedan zanimljiv izvještaj za mene kao testera dao je Egor Maslov iz Mango Telecoma. Prezentacija se zvala „Automatizacija punog ciklusa testiranja u SCRUM timu“. Egor smatra da je DevOps kreiran posebno za SCRUM, ali je u isto vrijeme uvođenje DevOps-a u SCRUM tim prilično problematično. To se događa jer SCRUM tim uvijek negdje trči, nema vremena da se ometate inovacijama i obnovite proces. Problem je i u tome što SCRUM ne uključuje razdvajanje podtimova u timu (testirajući tim, razvojni tim i tako dalje). Pa, osim toga, za automatizaciju postojećeg procesa potrebna je dokumentacija, a u SCRUM-u najčešće nema kompletne dokumentacije – „proizvod je važniji od neke vrste pisanja“.
Nakon prelaska na SCRUM, testeri su počeli da se konsultuju sa programerima o tome kako da testiraju funkcije. Postepeno se povećavao obim funkcionalnosti, nije bilo dokumentacije, a počeli su da hvataju mnogo grešaka u funkcionalnosti koja nije bila pokrivena testovima i generalno više nije bilo jasno ko ju je i kada testirao. Ukratko - zbunjenost i kolebanje. Odlučili smo se prebaciti na automatizaciju testiranja. Ali čak i tada je došlo do potpunog neuspjeha. Angažirali su vanjske stručnjake za automatizaciju koji su pisali na hrpu nepoznatoj domaćim testerima. Okvir za autotestove je svakako funkcionisao, ali nakon što su autsorseri otišli, trajalo je dve nedelje. Sljedeći je bio pokušaj uvođenja autotestiranja broj dva. Počelo je činjenicom da sve treba izgraditi unutar kompanije, samostalno (pravi vektor: interno izgraditi ekspertizu), u okviru SCRUM-a, i kreirati dokumentaciju u procesu. Stack za automatizaciju bi trebao biti jednak stogu proizvoda (ovdje ga dodajem, nemojte testirati svoj JavaScript projekat ni sa čim drugim). Na kraju sprinta, napravili su demo kako autotest radi sa cijelim timom (korisno). Time je povećana uključenost svih članova tima u proces automatizacije, povjerenje u autotestove i šansa da će se ovaj autotest definitivno koristiti (i neće biti komentarisan za mjesec dana zbog stalnih kvarova).
Inače, na DevOpsForumu 2019 bio je otvoreni mikrofon - odavno poznat i, po mom mišljenju, koristan format govora. Ovako hodate, slušate izvještaje, a zatim odlučujete da na konferenciji vrijedi razgovarati o određenoj temi ili problemu, podijeliti relevantno iskustvo u rješavanju problema.
Također sam primijetio da su organizatori napravili niz kratkih izvještaja. Svaki izvještaj ne traje duže od 10 minuta, nakon čega slijede pitanja. Na ovaj način možete obraditi više tema odjednom i postavljati pitanja govornicima koji vas zanimaju.
Između prezentacija, šetao sam po štandovima partnera na konferenciji i krao/osvojio mnogo stvari. Eh, sviđa mi se materijal!
Okrugli sto i DevOps pitanja sa direktorom razvoja u Alfastrakhovanie
Šlag na torti DevOpsForum 2019 za mene je bila jednosatna plenarna sesija sa DevOps stručnjacima. Četiri učesnika sesije pozvana su da pogledaju DevOps iz različitih uglova: Anton Isanin (Alfastrakhovanie, direktor razvoja), Nailya Zamashkina (Fintech Lab, operativni direktor), Oleg Egorkin (Rostelecom, Agile trener) i Anton Martyanov (nezavisni stručnjak, pogledao je DevOps). sa poslovnog stanovišta).
Stručnjaci su sjeli bliže ljudima i onda su se stvari počele događati: cijeli sat su učesnici iz publike postavljali svoja pitanja, a stručnjaci su se držali. Ponekad je bilo pravih debata. Pitanja su bila veoma različita, na primer: da li su DevOps inženjeri uopšte potrebni, zašto se ne mogu školovati za sistem administratore, treba li DevOps biti ponuđen svima, koja je njegova vrednost i tako dalje.
Zatim sam lično razgovarao sa Antonom Isaninom. Razgovarali smo o potrebi da se DevOps kultura donese u svaki dom i otkrili mračnu stranu DevOps transformacije.
Zamislimo da su se svi okupili i odlučili da je DevOps potreban i proizvodu i poslu i timu. Hajde da ga implementiramo. Sve je uspjelo. Izdahnuli smo. DevOps nas je približio klijentu, sada možemo brzo ispuniti sve njegove želje. Kao rezultat toga, imamo veliki Ops odjel sa strogim propisima i zahtjevima, koji stalno pronalazi nedostatke na proizvodu i stvara gomilu zahtjeva. Štaviše, svim nedostacima se dodeljuje status „hitno“, čak i ako je klijent neočekivano želeo da dugme oboji žutom umesto zelenom. Projekat raste, broj izdanja raste, a samim tim i broj nedostataka i nerazumijevanja nove funkcionalnosti od strane klijenata. Ops zapošljava još 10 ljudi kako bi bio u toku s prijavljivanjem nedostataka, a razvoj zapošljava još 15 ljudi kako bi ih zatvorio. I umjesto uvođenja novih funkcija, tim radi s beskrajnim SD-ovima, objašnjavajući funkcionalnost korisniku i podršku u isto vrijeme. Kao rezultat toga, i operacije i razvoj rade, ali klijent i posao su nezadovoljni: nove funkcije zaglavljuju. Ispostavilo se da DevOps izgleda postoji, ali izgleda da ne postoji.
Što se tiče potrebe implementacije DevOps-a, Anton je jasno naveo da to direktno zavisi od obima poslovanja. Ako servisiranje jednog klijenta godišnje kompaniji donese milijardu, DevOps nije potreban (pod uslovom da ne morate redovno uvoditi nove izmjene na ovog klijenta). Sve je preliveno čokoladom. Ali ako posao raste i pojavi se više klijenata, onda se morate pridržavati. Po pravilu, u kompaniji u početku nema cool Ops. Prvo isječemo proizvod, a tek onda shvatimo da, da bi proizvod funkcionirao, moramo paziti na servere i pratiti zalihe. Tada nastaje Ops. Ostaje da se shvati da će Ops, kao posebna divizija, početi da postavlja gomilu prepreka razvoju i da će sve isporuke početi da zastoje. Odnosno, u ovom slučaju, DevOps kultura je već relevantna, ali ne smijemo zaboraviti na njenu tamnu stranu.
izvor: www.habr.com