DevOpsForum 2019. DevOps-i rakendamiseks ei saa oodata

Hiljuti osalesin DevOpsForum 2019, mille korraldas Logrocon. Selles konverentsis pidasid osalejad tõsiselt probleemidest lahendusi ja uusi tööriistu, et tõhusalt suhelda äri- ja arendusteadlaste ning infotehnoloogia spetsialistidega.

Konverents õnnestus: oli palju kasulikke ettekandeid, huvitavaid esitlusformaate ja palju suhtlemist ettekandjatega. Eriti oluline on, et keegi ei üritanud mulle midagi müüa, mis on viimasel ajal suurte konverentside esinejatele omane.

Raiifainbanki, Alfa Insurance'i ettekande kokkuvõte, Mango Telekome kogemus automatiseerimise rakendamisel ja muud üksikasjad pärast katet.

Minu nimi on Jana, töötan testijana, tegelen automatiseerimisega ning DevOps'iga ja armastan konverentsidel ja kohtumistel osaleda. Viimase kahe aasta jooksul olen käinud Oleg Bunini konverentsidel (HighLoad++, TeamLead Conf), Jug'i üritustel (Heisenbug, JPoint), TestCon Moskvast, DevOps Pro Moskvast, Big Data Moskvast.

Esimese asjana pööran tähelepanu konverentsi programmile. Vähem vaatan, millest ettekandeks on, rohkem aga esinejale. Isegi kui ettekande teema on väga tehniline ja huvitav, ei tähenda see, et sa saaksid ettekandest mõningaid parimaid praktikaid oma ettevõttes rakendada. Ja siis on sul vajalik esineja.

Valgus toru lõpus Raiifainbankis

Tavaliselt korraldan ma huvitavate esinejate otsimise kulisse. DevOpsForum 2019 raames juhtus mu huvi alla esineja Raiifainbankist - Mihhail Bijan. Tema ettekande ajal rääkis ta, kuidas nad järk-järgult koti oma meeskonnad DevOps'i peale, milleks see neile vajalik on ja kuidas müüa äriile DevOps'i transformatsiooni ideed. Kokkuvõttes rääkis ta, kuidas näha valgust toru lõpus.

Mihhail Bijan, automatiseerimise direktor Raiifainbankis

Praegu ei ole nende ettevõttes "tõelist DevOps'i". See tähendab, et see on tõeline, kuid mitte kõigis meeskondades. DevOps'i rakendamisel toetuvad nad meeskondade valmisolekule, nii konkreetsete inseneride kui ka toote vajaduste ja platvormi küpsuse seisukohalt, millele see toode põhineb. Miša rääkis, kuidas äritegevusele selgitada, miks DevOps vajalik on.

Panga segmendil on mitmeid kasvumootoreid: teenuste hind ja kliendibaasi laienemine. Teenuste hinna tõstmine ei ole just väga hea kasvumootor, samas kui kliendibaasi kasv on vastupidine. Kui konkurendid toovad turule objektiivselt hea toote, lahkuvad kõik kliendid sinna ja aja jooksul turg stabiliseerub. Seetõttu on uute toodete turule toomine ja nende toomise kiirus peamine asi, millele pangad keskenduvad. Just selleks on vajalik DevOps, ja äri teeb seda selgelt teadlikuks.

Järgmine oluline märkus: DevOps ei vähenda alati turule jõudmise aega. DevOps ei saa töötada iseseisvalt, see on vaid osa tootmisprotsessist arendusest kuni tootmiseni (koodist kliendini). Kuid kõik, mis on seotud koodiga, pole otseselt seotud DevOpsiga. See tähendab, et turundajad võivad aastaid turgu uurida ja kogu elu konkurentidele järgi jõuda. On vajalik kiiresti mõista, mida klient vajab, ja plaanida teatud funktsioonide rakendamine — sageli just seda vajatakse, et DevOps töötaks ja ettevõte oma eesmärki saavutaks. Seega, esmajoones kokkulepe Raiffeisen Bankis ärihindadega, et õppida DevOpsit kasutama. Automatiseerimine pelgalt automatiseerimise nimel ei aita oluliselt uute klientide pärast võitlemisel.

Kokkuvõttes arvab Misha, et DevOps tuleb rakendada, kuid arukalt. Ja tuleb olla valmis sellele, et muutuva alguses langeb meeskonna tootlikkus, ta teenib vähem raha, kuid see tasub end hiljem ära.

Testimise automatiseerimine „Mango Telekomis“

Teise huvitav ettekande tegi testijana mulle E.gor Maslov ettevõttest 'Mango Telecom'. Ettekanne kandis pealkirja 'Testimise täisläbiviimise automatiseerimine SCRUM meeskonnas'. E.gor usub, et DevOps on loodud just SCRUM'i jaoks, kuid samas on DevOps'i rakendamine SCRUM meeskonnas piisavalt problemaatiline. See juhtub, kuna SCRUM meeskond jookseb pidevalt kuskil, pole aega uute rakenduste ja protsesside ümberkorraldamiseks. Probleem seisneb ka selles, et SCRUM ei eelda meeskonna jagamist alameeskondadeks (nt testijate meeskond, arendajate meeskond jne). Samuti, et olemasoleva protsessi automatiseerimiseks on vajalik dokumentatsioon, mida SCRUM'is enamasti ei ole — 'toode on olulisem kui mingi kirjatükk'.

Pärast üleminekut SCRUM'ile hakkasid testijad arendajatega nõu pidama, kuidas funktsioone testida. Aja jooksul funktsionaalsus suurenes, dokumentatsioon puudus ja nad hakkasid leidma palju vigu funktsionaalsuses, millel ei olnud katte teste, ja ei olnud selge, kes ja millal seda testis. Kahe sõnaga — hajusus ja segadus. Otsustati minna testimise automatiseerimise teed. Kuid ka siis toimus täielik ebaõnnestumine. Nad kaasasid automatiseerimise jaoks väljaüüritud spetsialiste, kes kirjutasid neile tundmatus keeles. Automaatsete testide raamistik töötas siiski, kuid peale väljaüürijate lahkumist elas see ainult kaks nädalat. Järgnes teine katse automatiseerimise rakendamiseks. See algas sellest, et kõik tuli ehitada ettevõtte sees, oma jõududega (õige suund: suurendage sisemist ekspertiisi), SCRUM'i raamistikus, ja protsessi käigus luua dokumentatsiooni. Automatiseerimise tehnoloogiaalane leht peab olema võrdne tootmise tehnoloogiaplaaniga (siin olen täiesti nõus, ärge testige projekti JavaScriptis millegi muuga). Sprindi lõpus korraldasid nad kogu meeskonna osalusel automaatsete testide toimivuse demo (kasulik). Nii suurenes kõigi meeskonnaliikmete kaasatus automatiseerimisprotsessi, usaldus automaatsete testide vastu ja võimalus, et seda automaatset testi määratletakse kindlasti kasutatavaks (mitte ei panda kuue kuu pärast kommenteerimise alla pidevate ebaõnnestumiste tõttu).

Muide, DevOpsForum 2019 raames oli avatud mikrofon - hästi tuntud ja minu arvates kasulik vorm esitluste jaoks. Sa käid ringi, kuulad ettekandeid ja siis otsustad, et konverentsi käigus tasub arutada mõnd teemat või probleemi ning jagada asjakohast kogemust lahenduste leidmisel.

Samuti märkisin, et korraldajad viisid sisse lühikeste ettekannete seansi. Iga ettekande kestus on kuni 10 minutit, millele järgnevad küsimused. Nii saab katab palju teemasid ja küsida esinejatelt, kes sind huvitavad.

Ettekannete vahel jalutasin konverentsi koostööpartnerite stendidel ja sain endaga kaasa palju erinevat kraami. Ahh, ma armastan tasuta asju!

Ümmargune laud ja DevOps küsimused Alfastrahovanii arendusdirektoriga

DevOpsForum 2019 ehet tõi minu jaoks tunnine paneeldiskussioon DevOps eksperdiga. Kutsuti neli seansi osalist, kes pidasid DevOpsi vaatama erinevatelt poolt: Anton Isanin (Alfastrahovanie, arendusdirektor), Nailya Zamashkina (Fintech Lab, tegevusdirektor), Oleg Egorkin (Rostelecom, Agile-treener) ja Anton Martjanov (iseseisev ekspert, kes vaatas DevOpsi äri perspektiivist).

Eksperdid istusid lähemale inimestele ja siis läks lahti: terve tunni jooksul esitasid saalist osalejad oma küsimusi, samas kui eksperdid vastasid. Mõnikord käidi tõelisi arutelusid. Küsimused olid väga erinevad, näiteks: kas DevOps insenere on üldse vaja, miks ei saa neid süsteemiadministraatoritest kasvatada, kas kõigile tuleks pakkuda DevOpsi, milline on selle väärtus jne.

Seejärel rääkisin isiklikult Anton Isanini poole. Rääkisime DevOpsi kultuuri edasiviimise olulisusest igasse koju ning avasime DevOpsi transformatsiooni tumedat poolt.

Kujutage ette, et kõik on kogunenud ja otsustanud, et DevOps on vajalik nii tootearendusele kui ka ärile ja meeskonnale. Hakkasime rakendama. Kõik õnnestus. Sügasime kukalt. DevOps viis meid kliendile lähemale, nüüd saame kiiresti täita kõik tema soovid. Lõpuks on meil suur Ops-osakond rangete eeskirjade ja nõudmistega, mis pidevalt viskab tootele defekte ja loob hulk taotlusi. Kõik defektid lähevad kauba juurde

Anton kuulutas kindlalt, et DevOpsi rakendamine sõltub otseselt äri mastaabist. Kui ühe kliendi teenindamine aastas toob ettevõttele miljard, siis DevOps'i pole vaja (olemasolul, et ei ole vajadust kliendile pidevalt uusi muudatusi viia). Kõik on nii hästi. Kuid kui äri kasvab ja kliente tuleb rohkem, siis tuleb ka vastata. Reeglina ei ole ettevõttes algselt kvaliteetset Ops'i. Esmalt arendame toodet ja alles seejärel mõistame, et toote toimimiseks tuleb jälgida serveritega, jälgida tarnimisi. Siis tekibki Ops. Jääb arusaadavaks, et Ops, kui eraldiseisev osakond, hakkab seadma rohkelt takistusi arendusele ja kõik tarned hakkavad takerduma. See tähendab, et antud juhul on DevOpsi kultuur juba asjakohane, vaid tuleb meeles pidada selle tumedat külge.

Allikas: habr.com