Nedavno sam prisustvovao DevOpsForumu 2019, čiji je domaćin Logrocon. Na ovoj konferenciji sudionici su pokušali pronaći rješenja i nove alate za učinkovitu interakciju između poslovanja i stručnjaka za razvoj i informatičke usluge.
Konferencija je bila uspješna: bilo je zaista puno korisnih izvješća, zanimljivih formata prezentacija i puno komunikacije s govornicima. A posebno je važno da mi nitko ništa nije pokušao prodati, za što su u zadnje vrijeme krivi govornici na velikim konferencijama.
Izvadak iz govora Raiffeisenbank, Alfastrakhovanie, iskustva Mango Telecoma u implementaciji automatizacije i drugih detalja ispod rezanja.
Moje ime je Yana, radim kao tester, bavim se automatizacijom, kao i DevOpsom, i volim ići na konferencije i sastanke. Tijekom protekle dvije godine bio sam na konferencijama Olega Bunina (HighLoad++, TeamLead Conf), Jug događajima (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Prije svega, skrećem pozornost na program konferencije. Manje gledam o čemu će biti izvještaj, a više govornika. Čak i ako se izvješće pokaže vrlo tehnološkim i zanimljivim, nije činjenica da ćete neke od najboljih praksi iz izvješća moći primijeniti u svojoj tvrtki. A onda vam treba zvučnik.
Svjetlo na kraju cjevovoda kod Raiffeisenbank
Obično tražim govornike sa strane koji me zanimaju. Na DevOpsForumu 2019, govornik iz Raiffeisenbanke, Mikhail Bizhan, privukao je moj interes. Tijekom svog govora govorio je o tome kako postupno uvode svoje timove u DevOps, zašto im je to potrebno i kako prodati ideju DevOps transformacije poslovanju. Pa, općenito, govorio sam o tome kako vidjeti svjetlo na kraju cjevovoda.
Mikhail Bizhan, direktor automatizacije u Raiffeisenbank
Sada nemaju "DevOps" u svojoj tvrtki. Odnosno, radi, ali ne u svim timovima. Prilikom implementacije DevOps-a oslanjaju se na spremnost timova, kako u pogledu konkretnih inženjera, tako i u smislu potreba proizvoda i zrelosti platforme na kojoj je taj proizvod izgrađen. Misha je rekao kako objasniti tvrtki zašto je DevOps potreban.
Bankarski segment ima nekoliko pokretača rasta: trošak usluga i širenje baze klijenata. Povećanje cijene usluga nije baš dobar pokretač, ali povećanje baze klijenata je suprotno. Ako konkurenti izbace objektivno cool proizvod, svi kupci idu tamo, a onda se s vremenom tržište izravna. Stoga je uvođenje novih proizvoda na tržište i brzina njihovog uvođenja glavna stvar na koju se banke fokusiraju. Upravo tome služi DevOps i tvrtke to razumiju.
Sljedeća važna napomena: DevOps ne skraćuje uvijek vrijeme izlaska na tržište. DevOps ne može raditi sam, on je samo dio procesa stvaranja i iznošenja proizvoda na tržište od razvoja do proizvodnje (od koda do kupca). Ali sve prije koda nije izravno povezano s DevOpsom. Odnosno, trgovci mogu proučavati tržište godinama i provesti cijeli život sustižući konkurente. Potrebno je brzo razumjeti što klijent treba i planirati implementaciju ove ili one značajke - često je to ono što nije dovoljno da DevOps radi i da tvrtka postigne svoj cilj. Stoga se prije svega Raiffeisenbank složila s gospodarstvom da je potrebno naučiti koristiti DevOps. Automatizacija radi automatizacije neće puno pomoći u borbi za nove kupce.
Općenito, Misha smatra da DevOps treba implementirati, ali mudro. I moramo biti spremni na činjenicu da će na početku transformacije produktivnost tima pasti, zarađivati će manje novca, ali onda će to biti opravdano.
Automatizacija testiranja u Mango Telecomu
Još jedno zanimljivo izvješće za mene kao testera dao je Egor Maslov iz Mango Telecoma. Prezentacija se zvala “Automatizacija punog ciklusa testiranja u SCRUM timu.” Egor vjeruje da je DevOps kreiran posebno za SCRUM, ali u isto vrijeme, uvođenje DevOps-a u SCRUM tim prilično je problematično. To se događa zato što SCRUM tim uvijek negdje trči, nema vremena za ometanje inovacijama i ponovnom izgradnjom procesa. Problem je i u tome što SCRUM ne uključuje odvajanje podtimova u timu (tim za testiranje, tim za razvoj i tako dalje). Pa, osim toga, za automatizaciju postojećeg procesa potrebna je dokumentacija, a u SCRUM-u najčešće nema potpune dokumentacije - "proizvod je važniji od nekakvog pisma."
Nakon prelaska na SCRUM, testeri su se počeli savjetovati s programerima o tome kako testirati značajke. Postupno se povećavao obujam funkcionalnosti, nije bilo dokumentacije, počeli su hvatati hrpu grešaka u funkcionalnosti koja nije bila obuhvaćena testovima i općenito se više nije znalo tko ju je i kada testirao. Ukratko - zbunjenost i kolebanje. Odlučili smo prijeći na automatizaciju testiranja. Ali i tada je došlo do potpunog promašaja. Angažirali su vanjske stručnjake za automatizaciju koji su pisali na hrpi nepoznatoj domaćim testerima. Framework za autotestove je, naravno, radio, ali nakon odlaska vanjskih suradnika to je trajalo dva tjedna. Sljedeći je bio pokušaj uvođenja autotestiranja broj dva. Počelo je s činjenicom da sve treba graditi unutar tvrtke, sami (pravi vektor: interno graditi ekspertizu), u okviru SCRUM-a i pritom stvarati dokumentaciju. Stog za automatizaciju trebao bi biti jednak stogu proizvoda (ovdje ga dodajem, nemojte testirati svoj JavaScript projekt ničim drugim). Na kraju sprinta napravili su demo kako autotest funkcionira s 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 sigurno koristiti (i neće se komentirati za mjesec dana zbog konstantnih kvarova).
Usput, na DevOpsForumu 2019 bio je otvoreni mikrofon - odavno poznati i, po mom mišljenju, koristan format govora. Hodate tako okolo, slušate izvješća, a onda odlučite da se na konferenciji isplati raspravljati o određenoj temi ili problemu, razmijeniti relevantna iskustva u rješavanju problema.
Također sam primijetio da su organizatori napravili stream kratkih izvještaja. Svako izvješće traje najviše 10 minuta, nakon čega slijede pitanja. Na taj način možete pokriti više tema odjednom i postavljati pitanja govornicima koji vas zanimaju.
Između prezentacija šetao sam po štandovima partnera konferencije i krao/osvojio svašta. Oh, sviđa mi se brošura!
Okrugli stol i DevOps problemi s direktorom razvoja u Alfastrakhovanie
Šlag na torti DevOpsForuma 2019. za mene je bila jednosatna plenarna sesija s DevOps stručnjacima. Četiri sudionika sesije pozvani su da pogledaju DevOps iz različitih kutova: Anton Isanin (Alfastrakhovanie, direktor razvoja), Nailya Zamashkina (Fintech Lab, operativni direktor), Oleg Egorkin (Rostelecom, Agile coach) i Anton Martyanov (nezavisni stručnjak, pogledao je DevOps s poslovnog gledišta).
Stručnjaci su sjeli bliže ljudima i tada su se stvari počele događati: cijeli sat su sudionici iz publike postavljali svoja pitanja, a stručnjaci su odgovarali. Ponekad je bilo pravih rasprava. Pitanja su bila vrlo različita, primjerice: jesu li DevOps inženjeri uopće potrebni, zašto se ne mogu školovati za sistemske administratore, treba li DevOps ponuditi svima, koja je njegova vrijednost i slično.
Tada sam osobno razgovarao s Antonom Išaninom. Razgovarali smo o potrebi prenošenja DevOps kulture 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 tvrtki i timu. Idemo to implementirati. 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 u proizvodu i stvara hrpu zahtjeva. Štoviše, svim kvarovima se dodjeljuje status "hitno", čak i ako je klijent neočekivano želio obojiti gumb žuto umjesto zeleno. Projekt raste, broj izdanja raste, a time i broj nedostataka i nerazumijevanja novih funkcionalnosti od strane klijenata. Ops zapošljava još 10 ljudi da drže korak s prijavljivanjem nedostataka, a razvoj zapošljava još 15 ljudi da drže korak s njihovim zatvaranjem. I umjesto uvođenja novih značajki, 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 tvrtka su nezadovoljni: nove značajke zapinju. Ispada da se čini da DevOps postoji, ali izgleda da ne postoji.
Što se tiče potrebe implementacije DevOps-a, Anton je jasno rekao da to izravno ovisi o opsegu poslovanja. Ako servisiranje jednog klijenta godišnje tvrtki donosi milijardu, DevOps nije potreban (pod uvjetom da ne morate redovito uvoditi nove promjene na ovog klijenta). Sve je preliveno čokoladom. Ali ako posao raste i pojavljuje se više klijenata, tada se trebate pridržavati. U pravilu, u početku nema cool Opsa u tvrtki. Prvo izrežemo proizvod, a tek onda shvatimo da, da bi proizvod radio, moramo paziti na servere i pratiti zalihe. Tada nastaje Ops. Ostaje za razumjeti da će Ops, kao zasebna divizija, početi postavljati hrpu prepreka razvoju i sve će isporuke početi stati. To jest, u ovom slučaju, DevOps kultura je već relevantna, ali ne smijemo zaboraviti na njezinu mračnu stranu.
Izvor: www.habr.com