Neseniai dalyvavau „DevOpsForum 2019“, kurį rengė Logrocon. Šioje konferencijoje dalyviai bandė ieškoti sprendimų ir naujų priemonių efektyviai verslo ir plėtros bei informacinių technologijų paslaugų specialistų sąveikai.
Konferencija pavyko: buvo tikrai daug naudingų pranešimų, įdomių pranešimų formatų ir daug bendrauta su pranešėjais. Ir ypač svarbu, kad man niekas nieko nebandė parduoti, dėl ko pastaruoju metu kalti pranešėjai didelėse konferencijose.
Ištrauka iš „Raiffeisenbank“, „Alfastrakhovanie“, „Mango Telecom“ patirties diegiant automatizavimą ir kitų smulkmenų.
Mano vardas Yana, dirbu testuotoja, užsiimu automatizavimu, taip pat „DevOps“ ir mėgstu lankytis konferencijose ir susitikimuose. Per pastaruosius dvejus metus buvau Olego Bunino konferencijose (HighLoad++, TeamLead Conf), Jug renginiuose (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Pirmiausia atkreipiu dėmesį į konferencijos programą. Mažiau žiūriu į tai, apie ką bus pranešta, o į kalbėtoją. Net jei ataskaita pasirodys labai technologiška ir įdomi, tai nėra faktas, kad galėsite pritaikyti kai kurias iš ataskaitos geriausių praktikų savo įmonėje. Ir tada jums reikia garsiakalbio.
Šviesa dujotiekio gale Raiffeisenbank
Paprastai garsiakalbių, kurie mane domina, medžioju nuošalyje. „DevOpsForum 2019“ sudomino Raiffeisenbank pranešėjas Michailas Bizhanas. Savo kalboje jis kalbėjo apie tai, kaip jie pamažu pritraukia savo komandas prie „DevOps“, kodėl jiems to reikia ir kaip „DevOps“ transformacijos idėją parduoti verslui. Na, apskritai, aš kalbėjau apie tai, kaip pamatyti šviesą vamzdyno gale.
Michailas Bizhanas, „Raiffeisenbank“ automatizavimo direktorius
Dabar jų įmonėje nėra „DevOps“. Tai yra, jis dirba, bet ne visose komandose. Diegdami „DevOps“ jie pasikliauja komandų pasirengimu tiek kalbant apie konkrečius inžinierius, tiek apie produkto poreikį ir platformos, ant kurios yra sukurtas šis produktas, brandą. Misha papasakojo, kaip paaiškinti verslui, kodėl reikalingas „DevOps“.
Bankininkystės segmentas turi keletą augimo varomųjų jėgų: paslaugų kainos ir klientų bazės plėtimosi. Paslaugų kainų didinimas nėra labai geras veiksnys, tačiau klientų skaičiaus augimas yra priešingas. Jei konkurentai išleidžia objektyviai šaunų produktą, visi klientai ten eina, tada laikui bėgant rinka išsilygins. Todėl naujų produktų įvedimas į rinką ir jų įvedimo greitis yra pagrindinis dalykas, į kurį bankai orientuojasi. „DevOps“ yra būtent tai, ir įmonės tai supranta.
Kita svarbi pastaba: „DevOps“ ne visada sutrumpina pateikimo į rinką laiką. „DevOps“ negali dirbti vienas, tai tik dalis produkto kūrimo ir pateikimo rinkai proceso nuo kūrimo iki gamybos (nuo kodo iki kliento). Tačiau viskas prieš kodą neturi tiesioginio ryšio su „DevOps“. Tai yra, rinkodaros specialistai gali tyrinėti rinką metų metus ir visą savo gyvenimą pasivyti konkurentus. Būtina greitai suprasti, ko reikia klientui ir suplanuoti vienos ar kitos funkcijos įgyvendinimą – dažnai to neužtenka, kad „DevOps“ veiktų, o įmonė pasiektų savo tikslą. Todėl visų pirma „Raiffeisenbank“ sutiko su verslu, kad būtina išmokti naudotis „DevOps“. Automatika dėl automatizavimo nelabai padės kovojant dėl naujų klientų.
Apskritai Misha mano, kad „DevOps“ reikia įdiegti, tačiau išmintingai. Ir turime būti pasiruošę tam, kad pertvarkos pradžioje komandos produktyvumas kris, ji uždirbs mažiau pinigų, bet vėliau tai pasiteisins.
„Mango Telecom“ testavimo automatizavimas
Dar vieną įdomų pranešimą man, kaip testuotojui, pateikė Egor Maslov iš Mango Telecom. Pristatymas vadinosi „Viso testavimo ciklo automatizavimas SCRUM komandoje“. Egoras mano, kad „DevOps“ buvo sukurtas specialiai SCRUM, tačiau tuo pačiu metu „DevOps“ įvedimas į SCRUM komandą yra gana problemiškas. Taip nutinka todėl, kad SCRUM komanda nuolat kažkur bėga, nėra laiko blaškytis nuo naujovių ir perstatyti procesą. Problema slypi ir tame, kad SCRUM neapima pogrupių atskyrimo komandoje (testavimo komanda, kūrimo komanda ir pan.). Na, be to, norint automatizuoti esamą procesą, reikalinga dokumentacija, o SCRUM dažniausiai visiškai nėra dokumentacijos - „produktas yra svarbesnis už kažkokį raštą“.
Perėjus prie SCRUM, testuotojai pradėjo konsultuotis su kūrėjais, kaip išbandyti funkcijas. Palaipsniui didėjo funkcionalumo apimtys, nebeliko dokumentacijos, o funkcionalume pradėjo gaudyti daug klaidų, kurios nebuvo testuojamos ir apskritai nebeaišku, kas ir kada jį išbandė. Trumpai tariant – sumaištis ir svyravimas. Nusprendėme pereiti prie testavimo automatizavimo. Tačiau net ir tada įvyko visiška nesėkmė. Jie pasamdė užsakomuosius automatikos specialistus, kurie rašė ant kamino, kurio vidiniai bandytojai nežinojo. Žinoma, automatinių testų sistema veikė, tačiau užsakovams pasitraukus, tai truko dvi savaites. Kitas buvo bandymas įvesti antrąjį automatinį testavimą. Viskas prasidėjo nuo to, kad viskas turi būti sukurta įmonėje, savarankiškai (tinkamas vektorius: kaupti žinias viduje), SCRUM rėmuose ir proceso metu kurti dokumentus. Automatizavimo krūva turi būti lygi produkto krūvai (čia aš jį pridedu, nebandykite savo JavaScript projekto su niekuo kitu). Sprinto pabaigoje jie padarė demonstracinę versiją, kaip veikia automatinis testas su visa komanda (naudinga). Taip išaugo visų komandos narių įsitraukimas į automatizavimo procesą, pasitikėjimas autotestais bei tikimybė, kad šis autotestas tikrai bus panaudotas (ir po mėnesio dėl nuolatinių gedimų nebus komentuojamas).
Beje, „DevOpsForum 2019“ buvo atviras mikrofonas – seniai žinomas ir, mano nuomone, naudingas kalbų formatas. Taip vaikštinėji, klausai pranešimų, o tada nusprendi, kad konferencijoje verta aptarti tam tikrą temą ar problemą, pasidalinti aktualia problema sprendžiant patirtimi.
Taip pat pastebėjau, kad organizatoriai kūrė trumpų reportažų srautą. Kiekvienas pranešimas trunka ne ilgiau kaip 10 minučių, po to pateikiami klausimai. Tokiu būdu galite vienu metu aptarti daugybę temų ir užduoti klausimus jus dominantiems pranešėjams.
Tarp pristatymų vaikščiojau po konferencijos partnerių kabinas ir pavogiau/laimėjau daug dalykų. O, man patinka dalomoji medžiaga!
Apvalaus stalo ir „DevOps“ problemos su „Alfastrakhovanie“ plėtros direktoriumi
„DevOpsForum 2019“ torto vyšna man buvo valandą trukusi plenarinė sesija su „DevOps“ ekspertais. Keturi sesijos dalyviai buvo pakviesti pažvelgti į DevOps iš skirtingų pusių: Antonas Isaninas (Alfastrakhovanie, plėtros direktorius), Nailya Zamashkina (Fintech Lab, veiklos direktorius), Olegas Egorkinas (Rostelecom, Agile treneris) ir Antonas Martianovas (nepriklausomas ekspertas, pažvelgė į DevOps verslo požiūriu).
Ekspertai susėdo arčiau žmonių, o tada viskas ėmė dėtis: visą valandą klausytojai klausinėjo klausytojų, o ekspertai klausė repo. Kartais kildavo tikros diskusijos. Klausimai buvo labai įvairūs, pavyzdžiui: ar išvis reikalingi DevOps inžinieriai, kodėl jų negalima apmokyti sistemos administratorių, ar DevOps reikia siūlyti visiems, kokia jo vertė ir pan.
Tada aš asmeniškai kalbėjausi su Antonu Isaninu. Aptarėme būtinybę įtraukti DevOps kultūrą į kiekvienus namus ir atskleidėme tamsiąją DevOps transformacijos pusę.
Įsivaizduokime, kad visi susibūrė ir nusprendė, kad „DevOps“ reikalingas ir produktui, ir verslui, ir komandai. Eikime tai įgyvendinti. Viskas pavyko. Iškvėpėme. DevOps priartino mus prie kliento, dabar galime greitai išpildyti visus jo norus. Dėl to turime didelį operacijų skyrių su griežtais reglamentais ir reikalavimais, kuris nuolat randa gaminio defektus ir sukuria krūvą užklausų. Be to, visiems defektams priskiriamas statusas „skubus“, net jei klientas netikėtai norėjo nuspalvinti mygtuką geltonai, o ne žaliai. Projektas auga, daugėja leidimų ir atitinkamai daugėja defektų ir klientų nesusipratimų dėl naujo funkcionalumo. „Ops“ pasamdo dar 10 žmonių, kad nepraneštų apie defektus, o plėtra pasamdo dar 15, kad juos pašalintų. Užuot pristačiusi naujų funkcijų, komanda dirba su begale SD, tuo pačiu paaiškindama funkcionalumą vartotojui ir palaikymą. Dėl to ir operacijos, ir plėtra veikia, bet klientas ir verslas nepatenkinti: naujos funkcijos stringa. Pasirodo, kad DevOps egzistuoja, bet atrodo, kad jo nėra.
Kalbėdamas apie būtinybę įdiegti „DevOps“, Antonas aiškiai pareiškė, kad tai tiesiogiai priklauso nuo verslo masto. Jei vieno kliento aptarnavimas per metus atneša įmonei milijardą, DevOps nereikalingas (su sąlyga, kad jums nereikia reguliariai diegti naujų pakeitimų šiam klientui). Viskas padengta šokoladu. Bet jei verslas auga ir atsiranda daugiau klientų, tuomet reikia laikytis. Paprastai įmonėje iš pradžių nėra šaunių operacijų. Pirmiausia nupjauname gaminį, o tik tada suprantame, kad norint, kad produktas veiktų, reikia stebėti serverius ir stebėti atsargas. Tada atsiranda „Ops“. Belieka suprasti, kad „Ops“, kaip atskiras padalinys, pradės statyti daugybę kliūčių plėtrai ir visi pristatymai pradės strigti. Tai yra, šiuo atveju DevOps kultūra jau yra aktuali, tačiau nereikia pamiršti ir tamsiosios jos pusės.
Šaltinis: www.habr.com