Nedavno sam bila na DevOpsForum 2019, kojeg je organizirao Logrocon. Na ovoj konferenciji sudionici su pokušavali pronaći rješenja i nova sredstva za učinkovitu suradnju između poslovanja i stručnjaka za razvoj i IT usluge.
Konferencija je bila uspješna: bilo je stvarno mnogo korisnih izlaganja, zanimljivi formati nastupa i puno razgovora s predavačima. I posebno je važno što mi nitko nije pokušao prodati ništa, što su posljednjih godina greške govornika na velikim konferencijama.
Sažetak izlaganja Raiffeisenbanke, Alfa osiguranja, iskustvo Mango Telekoma u implementaciji automatizacije i drugi detalji pod katom.
Zovem se Jana, radim kao tester, bavim se automatizacijom, kao i DevOps-om i obožavam ići na konferencije i meetupe. U posljednje dvije godine bila sam na konferencijama Olega Bunina (HighLoad++, TeamLead Conf), na događanjima Jug (Heisenbug, JPoint), na TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Prvo na što obraćam pozornost je program konferencije. Manje gledam o čemu će se govoriti, više na predavača. Čak i ako se izlaganje pokaže vrlo tehnološkim i zanimljivim, nije garantirano da ćeš moći primijeniti neka najbolja rješenja iz izlaganja u svojoj tvrtki. I tada ti treba dobar predavač.
Svjetlo na kraju cijevi u Raiffeisen banci
Obično, organiziram lov na zanimljive predavače u hodnicima. Na DevOpsForum 2019 u mom interesnom polju našao se predavač iz Raiffeisen banke – Mihail Bižan. Tijekom izlaganja pričao je kako postepeno uvode svoje timove u DevOps, zašto im to treba i kako prodati ideju DevOps transformacije biznisu. Općenito, govorio je o tome kako vidjeti svjetlo na kraju cijevi.
Mihail Bižan, direktor za automatizaciju u Raiffeisen banci
Trenutno u njihovoj tvrtki ne postoji "pravi DevOps". To jest, on postoji, ali ne u svim timovima. Prilikom implementacije DevOps-a oslanjaju se na spremnost timova kako s gledišta konkretnih inženjera, tako i s gledišta potrebe proizvoda i zrelosti platforme na kojoj je taj proizvod izgrađen. Miša je objasnio kako objasniti biznisu zašto je DevOps potreban.
Bankovni sektor ima nekoliko pokretača rasta: cijena usluga i proširenje klijentelle. Povećanje cijene usluga nije baš dobar pokretač, dok je rast klijentelle suprotno. Ako konkurenti lansiraju objektivno odličan proizvod, svi klijenti odlaze tamo, a zatim se s vremenom tržište izjednačava. Zbog toga su lansiranje novih proizvoda i brzina njihova izlaska na tržište glavne stvari na koje se banke fokusiraju. Za to je upravo potrebno DevOps, a biznis to razumije.
Sljedeća važna napomena: DevOps ne uvijek smanjuje vrijeme do izlaska na tržište. DevOps ne može raditi sam, on je samo dio procesa stvaranja i izlaska proizvoda na tržište od razvoja do produkcije (od koda do klijenta). Sve što je prije koda nema izravne veze s DevOps-om. To znači da marketinški timovi mogu godinama istraživati tržište i cijeli život sustizati konkurenciju. Potrebno je brzo shvatiti što klijentu treba i planirati implementaciju određene funkcionalnosti — često upravo to nedostaje da bi DevOps funkcionirao i kompanija ostvarila svoje ciljeve. Stoga su se prije svega u Raiffeisen banci dogovorili s biznisom o tome da je potrebno naučiti koristiti DevOps. Automatizacija radi automatizacije ne pomaže mnogo u borbi za nove klijente.
Uglavnom, Miša smatra da DevOps treba implementirati, ali s razboritošću. Također, treba biti spreman na to da će u početnoj fazi transformacije tim imati smanjenu produktivnost, zarađivat će manje novca, ali će se to kasnije isplatiti.
Automatizacija testiranja u 'Mango Telekomu'
Još jedno zanimljivo predavanje kao tester održao je Egor Maslov iz „Mango Telekoma“. Prezentacija se zvala „Automatizacija pune ciklusa testiranja u SCRUM timu“. Egor smatra da je DevOps stvoren upravo za SCRUM, ali u isto vreme, uvođenje DevOps-a u SCRUM tim je prilično problematično. To se događa zato što SCRUM tim stalno juri negde, nemaju vremena da se odvlače na novine i prestrukturiraju procese. Problem je takođe u tome što SCRUM ne predviđa formiranje sub-timova u timu (tim tester) ili (tim programera) i tako dalje. Osim toga, za automatizaciju postojećeg procesa potrebna je dokumentacija, a u SCRUM-u najčešće dokumentacija potpuno nedostaje — „proizvod je važniji od nekakvog pisanja“.
Nakon prelaska na SCRUM, testeri su počeli da se savetuju s programerima o tome kako testirati funkcionalnosti. Postepeno se obim funkcionalnosti povećavao, dokumentacija je nedostajala i počeli su da nalaze mnogo grešaka u onoj funkcionalnosti koja nije imala testove, a i dalje nije bilo jasno ko i kada je to testirao. Ukratko — haos. Odlukli su da pređu na automatizaciju testiranja. Međutim, tada je došlo do potpunog neuspjeha. Angažovali su spoljne stručnjake za automatizaciju koji su pisali na nepoznatom jeziku za interne testere. Okvir za automatske testove naravno je funkcionisao, ali nakon što su spoljni saradnici otišli, postojala su još samo dva tjedna. Zatim je usledila druga pokušaja uvođenja automatskog testiranja. Počela je sa idejom da sve mora biti izgrađeno unutra kompanije, vlastitim snagama (ispravan pravac: povećavajte ekspertizu unutra), u okviru SCRUM-a, i tokom procesa stvaranja dokumentacije. Tehnologija za automatizaciju treba biti jedinstvena s tehnologijom proizvoda (tu apsolutno podržavam, nemojte testirati projekat na JavaScript-u nečim drugim). Na kraju sprinta organizovali su demonstraciju kako automatski test funkcioniše, uz prisustvo celog tima (korisno). Tako su povećali uključivanje svih članova tima u proces automatizacije, kao i poverenje u automatske testove i šansu da će ovaj automatski test zaista biti korišćen (a ne biti zakomentarisan nakon mesec dana zbog stalnih grešaka).
Usput, na DevOpsForum 2019. godine održao se otvoreni mikrofon – poznati format prezentacija koji je, po mom mišljenju, vrlo koristan. Šetaš, slušaš predavanja, a onda odlučuješ da u okviru konferencije raspravite neku temu ili problem, podijelit ćete relevantno iskustvo u rješavanju zadataka.
Također sam primijetila da su organizatori napravili niz kratkih predavanja. Svako predavanje traje ne više od 10 minuta, a zatim slijedi pitanje. Tako se može obuhvatiti mnogo tema i postaviti pitanja govornicima koji su vas zanimali.
Između predavanja prošetala sam po štandovima partnera konferencije i uzela/pobjedila mnogo raznih stvari. Ah, volim ja promotivne materijale!
Okrugli stol i pitanja o DevOps-u s direktorom razvoja u Alfastrojenu
Šlag na tortu DevOpsForum 2019. za mene je bila sat vremena plenarne sesije s DevOps stručnjacima. Pozvane su četiri osobe koje su trebale sagledati DevOps iz različitih perspektiva: Anton Isanin (Alfastrojenje, direktor razvoja), Nailja Zamashkina (Fintech Lab, operativna direktorica), Oleg Egorkin (Rostelecom, Agile kouč) i Anton Martyanov (neovisni stručnjak koji je sagledavao DevOps iz poslovne perspektive).
Stručnjaci su sjeli bliže publici i tu je počela rasprava: cijeli sat sudionici iz publike postavljali su svoja pitanja, a stručnjaci su odgovarali. Ponekad su se vodile prave debate. Pitanja su bila raznolika, na primjer: jesu li DevOps inženjeri uopće potrebni, zašto ih ne možemo obrazovati iz sistemskih administratora, treba li svima ponuditi DevOps, koja je njegova vrijednost i slično.
Nakon toga, razgovarala sam osobno s Antonom Isaninom. Raspravili smo potrebu da se kultura DevOps-a donese u svaku kuću i otkrili tamnu stranu DevOps transformacije.
Zamislite da su se svi okupili i odlučili da je DevOps potreban kako proizvodu, tako i biznisu i timu. Počelo se s implementacijom. Sve je prošlo kako treba. Odahnuli smo. DevOps nas je približio klijentima, sada možemo brzo ispuniti sve njihove želje. Na kraju imamo veliko Ops odeljenje sa strogim pravilnicima i zahtevima, i stalno proizvodi mane u proizvodu, stvara gomilu prijava. Pritom sve mane dolaze sa statusom "hitno", čak i kada klijent iznenada poželi da oboji dugme u žutu umesto zelenu. Projekat raste, raste broj izdanja i samim tim broj mana i nerazumevanja nove funkcionalnosti od strane klijenata. Ops zapošljava još 10 ljudi kako bi mogli da prijavljuju mane, a razvoj zapošljava još 15, kako bi ih mogli zatvoriti. I umesto da uvode nove funkcije, tim se bavi beskrajnim SD-ovima, objašnjavajući funkcionalnost korisnicima, a i podršci u isto vreme. Na kraju su i Ops i razvoj zaposleni, ali klijent i biznis su nezadovoljni: nove funkcije zapinju. Ispostavlja se da DevOps kao da postoji, a kao da i ne.
Što se tiče potrebe za implementacijom DevOps-a, Anton je jasno izjavio da to direktno zavisi od veličine biznisa. Ako usluga jednog klijenta godišnje donosi kompaniji milijardu — DevOps nije potreban (pod uslovom da ne treba redovno isporučivati nove izmene ovom klijentu). Svi su ionako u cvetu. Ali ako biznis raste, pojavljuje se više klijenata, onda treba i prilagoditi se. Generalno, u kompaniji u početku nema sjajnog Ops-a. Prvo pravimo proizvod, a tek kasnije shvatamo da da bi proizvod radio, treba paziti na poslužiteljima, pratiti isporuke. Tada se i pojavljuje Ops. Ostaje samo razumeti da će Ops, kao posebno odeljenje, početi postavljati gomilu prepreka za razvoj, i sve isporuke će početi zastajati. Dakle, u ovom slučaju DevOps kultura je već aktuelna, samo treba ne zaboraviti na njenu tamnu stranu.
Izvor: habr.com
