Hiljuti osalesin DevOpsForum 2019-l, mille korraldas Logrocon. Konverentsil püüdsid osalejad leida lahendusi ja uusi tööriistu tõhusaks koostööks äri ja arenduse ning IT-teeninduse spetsialistide vahel.
Konverents oli suur edu: oli palju kasulikke ettekandeid, huvitavaid esitusvorminguid ja rohkelt suhtlemist esinejatega. Eriti oluline oli, et keegi ei üritanud mulle midagi müüa, mis on suurte konverentside esinejate seas sageli probleemiks.
Rahaliste andmete esitlused Raiffeisen Bank'ilt, Alfa Insurance'ilt, Mango Telekome automatiseerimise kogemus ja muud üksikasjad allpool.
Minu nimi on Jana, töötan testijana, tegelen automatiseerimisega, samuti DevOps'iga ja armastan osaleda konverentsidel ja kohtumistel. Viimase kahe aasta jooksul olen käinud Oleg Bunini konverentsidel (HighLoad++, TeamLead Conf), Jug'i üritustel (Heisenbug, JPoint), TestCon Moskvases, DevOps Pro Moskvases, Big Data Moskvases.
Esimene asi, millele ma tähelepanu pööran, on konverentsi kava. Vähemal määral vaatan, millest ettekande teema on, kuid rohkem spikeri peale. Isegi kui ettekande sisu on väga tehniline ja huvitav, ei ole sugugi kindel, et suudate ettekandes jagatud parimaid praktikaid oma ettevõttes rakendada. Ja sel juhul on teil vajalik hea esineja.
Valgus toru lõpus Raiyffaisenbankis
Tavaliselt korraldan ma koridorides huvitavate esinejate jahtimist. DevOpsForum 2019 ajal jäi minu huvi alla ettekandja Raiyffaisenbankist - Mihhail Bijan. Oma esitluses rääkis ta, kuidas nad järk-järgult viivad oma meeskonnad DevOpsile, miks see neile vajalik on ja kuidas müüa ettevõttele DevOps-transformatsiooni ideed. Üldiselt rääkis ta ka sellest, kuidas näha valgust toru lõpus.
Mihhail Bijan, automatiseerimise direktor Raiyffaisenbankis
Praegu nende ettevõttes ei ole tõeliselt DevOps'i. See on tõeline, kuid mitte kõigis meeskondades. DevOps'i juurutamisel toetuvad nad meeskondade valmidusele nii spetsialistide tasandil kui ka toote vajaduste ja selle platvormi küpsuse osas, millele toode rajatud on. Misha rääkis, kuidas selgitada äri jaoks, miks DevOps on vajalik.
Panga sektoril on mitmeid kasvu tegureid: teenuste hind ja kliendibaasi laienemine. Teenuste hinna tõstmine ei ole just kõige parem kasvutegur, kuid kliendibaasi kasv on vastupidine. Kui konkurendid toovad turule objektiivselt kõrgelt hinnatud toote, lähevad kõik kliendid sinna, kuid aja jooksul turg stabiliseerub. Seetõttu on uute toodete turuleviimine ja nende toomise kiirus peamine asi, millele pangad keskenduvad. Just selleks ongi vajalik DevOps, ja äri mõistab seda.
Järgmine oluline märkus: DevOps ei vähenda alati turule mineku aega. DevOps ei saa töötada üksi; see on vaid osa tootearenduse ja turule viimise protsessist, alates koodist kuni kliendini. Kuid kõik, mis ei ole seotud koodiga, ei kuulu DevOps-i valdkonda. Ehkki turundajad võivad aastaid turgu uurida ja konkurentidest jääda maha, on oluline kiiresti mõista, mida klient vajab, ja planeerida selle funktsiooni elluviimist — tihti on just see, mida vajatakse, et DevOps tõhusalt tööle hakkaks ja ettevõte oma eesmärgid saavutaks. Seetõttu leppis Raiffeisenbankis esmalt kokku, et tuleb õppida DevOps-i tõhusat kasutamist. Automaatika automaatika nimel ei aita oluliselt uute klientide omandamisel.
Üldiselt on Misha arvamus, et DevOps-i tuleks rakendada, kuid targalt. Tuleb olla valmis selleks, et transformatsiooni alguses võib meeskonna tootlikkus väheneda ja nad teenivad vähem raha, kuid hiljem see tasub end ära.
Testimise automatiseerimine ettevõttes «Mango Telecom»
Teise huvitava ettekande tegi Egor Maslov "Mango Telecom"-ist. Esitluse pealkiri oli "Testimise täisläbimise automatiseerimine SCRUM meeskonnas". Egori arvates on DevOps loodud just SCRUM-i jaoks, kuid DevOps-i rakendamine SCRUM meeskonnas osutub üsna problemaatiliseks. Selle põhjuseks on see, et SCRUM meeskond on pidevas liikumises, pole aega uuteks algatusteks ega protsesside ümberkorraldamiseks. Probleem on ka selles, et SCRUM ei eelda alameeskondade loomist (nt testijate meeskond, arendajate meeskond jne). Lisaks on olemasoleva protsessi automatiseerimiseks vajalik dokumentatsioon, aga SCRUMis on dokumentatsioon sageli täielikult puudulik — "toode on olulisem kui mingisugune kirjutamine".
SCRUM-ile üleminekuga hakkasid testijad arendajatega nõu pidama, kuidas funktsioone testida. Aja jooksul suurenes funktsionaalsuse maht, dokumentatsioon puudus ja nad hakkasid avastama palju vigu funktsioonides, mille puhul testimist polnud ja polnud selge, kes ja millal neid testis. Ühesõnaga — segadus ja kaos. Otsustati liikuda testimise automatiseerimise suunas. Kuid ka siis toimus täielik ebaõnnestumine. Nad kaasasid automatiseerimiseks alltöövõtjaid, kes kasutasid teadmata tehnoloogiat. Autotestimise raamistiku töö küll, kuid pärast alltöövõtjate lahkumist kestis see vaid kaks nädalat. Järgnes teine katse automatiseerimise sisseviimiseks. See algas sellega, et kõik peab toimuma ettevõtte sees, oma jõududega (õige suund: kasvatage oma pädevust), SCRUM-i raames ning dokumentatsiooni loomise protsessis. Automatiseerimise tehnoloogia peab olema sama, mis toote tehnoloogia (siin olen täielikult nõus, ärge testige projekti JavaScriptis millegi muuga). Sprinti lõpuks korraldasid nad demoesituse, kuidas autotest töötab, kogu meeskonna osavõtul (kasulik). Nii suurenes kogu meeskonna kaasatus automatiseerimisprotsessis, samuti usaldus autotestide ja võimalus, et see autotest tõenäoliselt kasutatakse (mitte ei jää kommentaaridesse kuuks ajaks pidevate ebaõnnestumiste tõttu).
Muide, DevOpsForum 2019-l oli avatud mikrofon — juba ammu tuntud ja minu arvates kasulik esitluste formaat. Kõnnid ringi, kuulad ettekandeid ja siis otsustad, et konverentsi raames tasub arutada mõnda teemat või probleemi, jagada asjakohaseid kogemusi ülesande lahendamisel.
Olen ka tähele pannud, et korraldajad viisid sisse lühiettekannete vooru. Iga ettekande kestus ei ületa 10 minutit, pärast millele järgneb küsimustevoor. Nii saab katta kohe palju teemasid ja esinejatelt, kes on huvitatud, küsimusi esitada.
Ettekannete vahel jalutasin konverentsi partnerite stendidelt ja haarasin/ võitsin palju erinevaid asju. Ah, ma armastan üritustel jagatavat!
Ümarlaud ja DevOpsi küsimused riskijuhtimise direktoriga Alfastrahovannist
DevOpsForum 2019 oli tõeline tipphetk, milleks oli tunni pikkune paneeldiskussioon DevOpsi ekspertidega. Osales neli paneeli liiget, kes vaatasid DevOpsi erinevatest vaatenurkadest: Anton Isanin (AlfaStrahovanie, arendusdirektor), Nailia Zamashkina (Fintech Lab, operatiivdirektor), Oleg Egorkin (Rostelecom, Agile-treener) ja Anton Martyanov (iseseisev ekspert, vaatas DevOpsi ärinurgast).
Eksperdid istusid rahvale lähemale ja seejärel algas tõeline show: terve tunni jagu küsisid osalejad saalist oma küsimusi, ja eksperdid vastasid. Vahel tulid välja tõelised debatid. Küsimused olid väga mitmekesised, näiteks: kas DevOps-inseneride olemasolu on üldse vajalik, miks ei saa neid kasvatada süsteemiadministraatoritest, kas peaks kõigile pakkuma DevOpsi, milline on selle väärtus jne.
Seejärel suheldes Anton Isaniniga isiklikult, arutasime vajadust tuua DevOpsi kultuur igasse koju ning paljastasime DevOpsi ümberkujundamise tumedamaid külgi.
Kujutame ette, et kõik kokku said ja otsustasid, et DevOps on vajalik nii tootmisele, äri kui ka meeskonnale. Hakkasime rakendama. Kõik läks korda. Võtsime hinge. DevOps tõi meid klientidele lähemale, nüüd suudame kiiresti täita kõik nende soovid. Tulemusena on meil suur Ops-osakond, millel on ranged regulatsioonid ja nõudmised, ja see genereerib pidevalt defekte tootesse, luues hulga piletite jaoks. Kõik defektid on tähistatud staatusega „kiire”, isegi kui klient tahab üllatusena muuta nupuvärvi rohelisest kollaseks. Projekt kasvab, kasvab väljaandmiste arv ja vastavalt ka defektide ja koostööprobleemide arv klientide seas. Ops palkab juurde 10 inimest, et jõuda defekte raporteerida, samas kui arendus palkab veel 15, et neid sulgeda. Ja selle asemel, et rakendada uusi funktsioone, töötab meeskond lõputute SD‘dega, selgitades funktsionaalsust kasutajatele ja samas ka toele. Lõppkokkuvõttes on nii Ops kui arendus tegevuses, kuid klient ja äri on rahulolematud: uued funktsioonid jäävad kinni. Tundub, et DevOps on olemas, aga samas nagu ei olegi.
Anton rõhutas, et DevOpsi rakendamine sõltub otseselt ettevõtte suurusest. Kui ühe kliendi teenindamine aastas toob ettevõttele miljardit — DevOps ei ole vajalik (olemasolu eeldusel, et sul ei ole tarvis kliendile regulaarselt uusi muudatusi rakendada). Kõik on nii-öelda korras. Kuid kui äri kasvab ja kliente tuleb juurde, siis tuleb sellele vastata. Tavaliselt ei ole ettevõttes algselt tugevat opsimeeskonda. Esiteks arendame toodet ja alles seejärel mõistame, et toote sujuvaks toimimiseks tuleb jälgida serveritega, toimetamist. Siis tekibki vajadus opsi järele. Tuleb mõista, et ops, kui eraldi osakond, hakkab kehtestama hulga takistusi arendusele ning kõik toimetamised hakkavad venima. See tähendab, et antud olukorras on DevOpsi kultuur juba relevantne, kuid ei tohi unustada ka selle tumedat poolt.
Allikas: habr.com
