Osalesin hiljuti DevOpsForumil 2019, mille võõrustas Logrocon. Sellel konverentsil proovisid osalejad leida lahendusi ja uusi tööriistu tõhusaks suhtluseks äri- ja arendus- ning infotehnoloogiateenuste spetsialistide vahel.
Konverents oli edukas: seal oli tõesti palju kasulikke ettekandeid, huvitavaid esitlusvorminguid ja palju suhtlemist esinejatega. Ja eriti oluline on see, et keegi ei üritanud mulle midagi müüa, milles on suurtel konverentsidel esinejad viimasel ajal süüdi olnud.
Väljavõte Raiffeisenbanki, Alfastrakhovanie kõnedest, Mango Telecomi kogemusest automatiseerimise rakendamisel ja muudest kärbete alla kuuluvatest detailidest.
Minu nimi on Yana, töötan testijana, tegelen automatiseerimisega ja ka DevOpsiga ning mulle meeldib konverentsidel ja kohtumistel käia. Viimase kahe aasta jooksul olen käinud Oleg Bunini konverentsidel (HighLoad++, TeamLead Conf), Jug üritustel (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Kõigepealt juhin tähelepanu konverentsi programmile. Ma vaatan vähem seda, millest raport räägib, ja rohkem kõnelejat. Isegi kui aruanne osutub väga tehnoloogiliseks ja huvitavaks, pole tõsiasi, et saate mõnda aruande parimat praktikat oma ettevõttes rakendada. Ja siis on vaja kõlarit.
Valgus Raiffeisenbanki torujuhtme lõpus
Tavaliselt jahin ma kõrvalt kõnelejaid, mis mind huvitavad. 2019. aasta DevOpsForumil äratas mu huvi Raiffeisenbanki esineja Mikhail Bizhan. Oma kõne ajal rääkis ta sellest, kuidas nad hakkavad järk-järgult oma meeskondi DevOpsi külge tõmbama, miks neil seda vaja on ja kuidas DevOpsi ümberkujundamise ideed ärile müüa. No üldiselt ma rääkisin sellest, kuidas torujuhtme lõpus valgust näha.
Mihhail Bizhan, Raiffeisenbanki automatiseerimise direktor
Nüüd pole nende ettevõttes DevOpsi. See tähendab, et ta töötab, kuid mitte kõigis meeskondades. DevOpsi juurutamisel toetuvad nad meeskondade valmisolekule nii konkreetsete inseneride osas kui ka toote vajaduse ja platvormi küpsuse osas, millele see toode on ehitatud. Misha rääkis, kuidas selgitada ettevõttele, miks DevOpsi vaja on.
Pangandussegmendil on mitmeid kasvutegureid: teenuste hind ja kliendibaasi laienemine. Teenuste hinna tõstmine ei ole väga hea tõukejõud, kuid kliendibaasi kasvatamine on vastupidine. Kui konkurendid lasevad välja objektiivselt laheda toote, lähevad sinna kõik kliendid, siis aja jooksul turg ühtlustub. Seetõttu on uute toodete turule toomine ja nende kasutuselevõtu kiirus peamine, millele pangad keskenduvad. Just selleks DevOps on mõeldud ja ettevõtted mõistavad seda.
Järgmine oluline märkus: DevOps ei vähenda alati turule jõudmise aega. DevOps ei saa üksi töötada, see on vaid osa toote loomise ja turule toomise protsessist arendusest tootmiseni (koodist kliendini). Kuid kõik enne koodi ei ole DevOpsiga otseselt seotud. See tähendab, et turundajad saavad uurida turgu aastaid ja veeta kogu oma elu konkurentidele järele jõudes. On vaja kiiresti aru saada, mida klient vajab, ja planeerida selle või teise funktsiooni rakendamine - sageli ei piisa sellest, et DevOps töötaks ja ettevõte oma eesmärgi saavutaks. Seetõttu nõustus Raiffeisenbank esiteks äriga, et DevOpsi kasutamist on vaja õppida. Automatiseerimine automatiseerimise nimel ei aita võitluses uute klientide pärast kuigi palju.
Üldiselt usub Misha, et DevOps vajab juurutamist, kuid targalt. Ja me peame olema valmis selleks, et ümberkujundamise alguses meeskonna tootlikkus langeb, see teenib vähem raha, kuid siis on see õigustatud.
Mango Telecomi testimise automatiseerimine
Veel ühe huvitava raporti minu kui testija jaoks tegi Egor Maslov Mango Telecomist. Esitluse nimi oli "Täieliku testimistsükli automatiseerimine SCRUM-i meeskonnas". Egor usub, et DevOps loodi spetsiaalselt SCRUM-i jaoks, kuid samal ajal on DevOpsi tutvustamine SCRUM-i meeskonnas üsna problemaatiline. See juhtub seetõttu, et SCRUM-i meeskond jookseb alati kuskil, pole aega uuendustest segada ja protsessi uuesti üles ehitada. Probleem seisneb ka selles, et SCRUM ei hõlma alammeeskondade eraldamist meeskonnas (testimismeeskond, arendusmeeskond jne). Pealegi on olemasoleva protsessi automatiseerimiseks vaja dokumentatsiooni ja SCRUMis pole enamasti dokumentatsiooni täielikult olemas - "toode on olulisem kui mingisugune kirjutis."
Pärast SCRUM-ile üleminekut hakkasid testijad arendajatega konsulteerima, kuidas funktsioone testida. Tasapisi funktsionaalsuse maht kasvas, dokumentatsioon puudus ning funktsionaalsuses hakati tabama palju vigu, mida testid ei hõlmanud ning üldiselt polnud enam selge, kes ja millal testis. Lühidalt - segadus ja kõikumine. Otsustasime minna üle testimise automatiseerimisele. Kuid isegi siis oli täielik ebaõnnestumine. Nad palkasid sisseostetud automaatikaspetsialistid, kes kirjutasid ettevõttesiseste testijate jaoks tundmatule virnale. Autotestide raamistik muidugi töötas, kuid pärast allhankefirmade lahkumist kestis see kaks nädalat. Järgmine oli katse võtta kasutusele automaattestimine number kaks. See sai alguse sellest, et kõik tuleb üles ehitada ettevõtte sees, omal käel (õige vektor: sisemiselt ekspertteadmiste kogumine), SCRUM-i raames ja selle käigus dokumentatsiooni koostamine. Automatiseerimise virn peaks olema võrdne toote virnaga (siia lisan selle, ärge testige oma JavaScripti projekti millegi muuga). Sprindi lõpus tegid nad autotesti toimimise demo kogu meeskonnaga (abiks). Nii kasvas kõigi meeskonnaliikmete kaasatus automatiseerimisprotsessi, samuti usaldus autotestide vastu ning võimalus, et see autotest leiab kindlasti kasutust (ja seda ei kommenteerita kuu aja pärast pidevate rikete tõttu).
Muide, DevOpsForumil 2019 oli avatud mikrofon - ammu tuntud ja minu arvates kasulik kõnevorming. Käid niisama ringi, kuulad ettekandeid ja siis otsustad, et konverentsil tasub mingi teema või probleemi üle arutleda, jagada asjakohast kogemust probleemi lahendamisel.
Samuti märkasin, et korraldajad tegid vooga lühireportaate. Iga aruanne ei kesta üle 10 minuti, millele järgnevad küsimused. Nii saate korraga käsitleda paljusid teemasid ja esitada küsimusi teid huvitavatele esinejatele.
Ettekannete vahel käisin mööda konverentsipartnerite bokse ringi ja varastasin/võitsin palju kraami. Eh, mulle meeldib jaotusmaterjal!
Ümarlaua ja DevOpsi probleemid Alfastrakhovanie arendusdirektoriga
Minu jaoks oli kirsiks DevOpsForum 2019 tordil tunniajaline plenaaristung DevOpsi ekspertidega. Neli istungil osalejat kutsuti DevOpsi vaatama erinevate nurkade alt: Anton Isanin (Alfastrahhovanie, arendusdirektor), Nailya Zamashkina (Fintech Lab, tegevusdirektor), Oleg Egorkin (Rostelecom, Agile coach) ja Anton Martyanov (sõltumatu ekspert, vaatas DevOpsi ärilisest vaatenurgast).
Eksperdid istusid rahvale lähemale ja siis hakkasid asjad juhtuma: terve tunni esitasid osalejad publikust oma küsimusi ja eksperdid võtsid räpi. Mõnikord tekkisid tõelised vaidlused. Küsimused olid väga erinevad, näiteks: kas DevOpsi insenere on üldse vaja, miks ei võiks neid koolitada süsteemiadministraatoriteks, kas DevOpsi peaks pakkuma kõigile, mis on selle väärtus jne.
Seejärel rääkisin Anton Isaniniga isiklikult. Arutasime vajadust tuua DevOpsi kultuur igasse koju ja paljastasime DevOpsi ümberkujundamise varjukülje.
Kujutagem ette, et kõik tulid kokku ja otsustasid, et DevOpsi on vaja nii tootele kui ka ettevõttele ja meeskonnale. Hakkame seda ellu viima. Kõik õnnestus. Me hingasime välja. DevOps on toonud meid kliendile lähemale, nüüd saame kõik tema soovid kiiresti täita. Tänu sellele on meil suur rangete regulatsioonide ja nõuetega operatiivosakond, mis leiab pidevalt tootel vigu ja loob hunniku päringuid. Pealegi omistatakse kõikidele defektidele staatus “kiireloomuline”, isegi kui klient soovis ootamatult nupu rohelise asemel kollaseks värvida. Projekt kasvab, väljalasete arv kasvab ja sellest tulenevalt ka defektide ja uute funktsionaalsuste arusaamatuste arv klientide poolt. Ops palkab veel 10 inimest, et olla kursis defektidest teatamisega, ja arendus palkab veel 15 inimest, et olla kursis nende sulgemisega. Ja selle asemel, et tutvustada uusi funktsioone, töötab meeskond lõputute SD-dega, selgitades kasutajale funktsionaalsust ja samal ajal tuge. Selle tulemusena on nii Ops kui ka arendus äris, kuid klient ja äri pole rahul: uued funktsioonid takerduvad. Selgub, et DevOps näib olevat olemas, kuid tundub, et seda ei eksisteeri.
Seoses DevOpsi juurutamise vajadusega ütles Anton selgelt, et see sõltub otseselt ettevõtte mastaabist. Kui ühe kliendi teenindamine aastas toob ettevõttele miljardi, pole DevOpsi vaja (eeldusel, et te ei pea sellele kliendile regulaarselt uusi muudatusi juurutama). Kõik on kaetud šokolaadiga. Aga kui äri kasvab ja kliente tuleb juurde, siis tuleb järgida. Reeglina pole ettevõttes esialgu ühtegi lahedat Opsi. Kõigepealt lõikame toote ära ja alles siis saame aru, et toote toimimiseks on vaja serveritel silm peal hoida ja tarneid jälgida. Siis tekib Ops. Tuleb mõista, et Ops hakkab eraldiseisva divisjonina seadma arengule hunniku tõkkeid ja kõik tarned hakkavad takerduma. See tähendab, et antud juhul on DevOpsi kultuur juba asjakohane, kuid me ei tohi unustada selle varjukülgi.
Allikas: www.habr.com