Es nesen apmeklÄju DevOpsForum 2019, ko vadÄ«ja Logrocon. Å ajÄ konferencÄ dalÄ«bnieki mÄÄ£inÄja rast risinÄjumus un jaunus instrumentus efektÄ«vai biznesa un attÄ«stÄ«bas un informÄcijas tehnoloÄ£iju servisa speciÄlistu mijiedarbÄ«bai.
Konference bija veiksmÄ«ga: bija patieÅ”Äm daudz noderÄ«gu referÄtu, interesanti prezentÄciju formÄti un daudz komunikÄcijas ar runÄtÄjiem. Un Ä«paÅ”i svarÄ«gi ir tas, ka man neviens neko nemÄÄ£inÄja pÄrdot, pie kÄ pÄdÄjÄ laikÄ ir vainÄ«gi runÄtÄji lielÄs konferencÄs.
Izvilkums no Raiffeisenbank, Alfastrakhovanie, Mango Telecom pieredzes automatizÄcijas ievieÅ”anÄ un citÄm detaļÄm zem samazinÄjuma.
Mani sauc Yana, es strÄdÄju par testeri, veicu automatizÄciju, kÄ arÄ« DevOps, un man patÄ«k apmeklÄt konferences un tikÅ”anÄs. PÄdÄjo divu gadu laikÄ esmu bijis Oļega BuÅina konferencÄs (HighLoad++, TeamLead Conf), Jug pasÄkumos (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Vispirms vÄrÅ”u uzmanÄ«bu uz konferences programmu. Es mazÄk skatos uz to, par ko bÅ«s ziÅojums, bet vairÄk uz runÄtÄju. Pat ja pÄrskats izrÄdÄ«sies ļoti tehnoloÄ£isks un interesants, tas nav fakts, ka jÅ«s varÄsiet savÄ uzÅÄmumÄ pielietot kÄdu no ziÅojuma labÄkajÄm praksÄm. Un tad jums ir nepiecieÅ”ams skaļrunis.
Gaisma cauruļvada galÄ Raiffeisenbank
Parasti es meklÄju runÄtÄjus malÄ, kas mani interesÄ. DevOpsForum 2019 mani ieinteresÄja Raiffeisenbank runÄtÄjs Mihails BÄ«Å”ans. Savas runas laikÄ viÅÅ” stÄstÄ«ja par to, kÄ viÅi pamazÄm piesaista savas komandas DevOps, kÄpÄc viÅiem tas ir vajadzÄ«gs un kÄ pÄrdot DevOps pÄrveides ideju biznesam. Nu vispÄr es runÄju par to, kÄ redzÄt gaismu cauruļvada galÄ.
Mihails Bizans, Raiffeisenbank automatizÄcijas direktors
Tagad viÅu uzÅÄmumÄ nav āDevOpsā. Tas ir, viÅÅ” strÄdÄ, bet ne visÄs komandÄs. IevieÅ”ot DevOps, viÅi paļaujas uz komandu gatavÄ«bu gan attiecÄ«bÄ uz konkrÄtiem inženieriem, gan attiecÄ«bÄ uz produkta nepiecieÅ”amÄ«bu un platformas briedumu, uz kuras Å”is produkts ir bÅ«vÄts. MiÅ”a pastÄstÄ«ja, kÄ biznesam izskaidrot, kÄpÄc ir nepiecieÅ”ams DevOps.
Banku segmentam ir vairÄki izaugsmes virzÄ«tÄji: pakalpojumu izmaksas un klientu bÄzes paplaÅ”inÄÅ”anÄs. Pakalpojumu izmaksu palielinÄÅ”ana nav ļoti labs virzÄ«tÄjspÄks, bet klientu bÄzes palielinÄÅ”ana ir pretÄja. Ja konkurenti izlaiž objektÄ«vi forÅ”u produktu, turp dodas visi klienti, tad laika gaitÄ tirgus izlÄ«dzinÄs. TÄpÄc jaunu produktu ievieÅ”ana tirgÅ« un to ievieÅ”anas Ätrums ir galvenais, uz ko bankas koncentrÄjas. Tas ir tieÅ”i tas, kam DevOps ir paredzÄts, un uzÅÄmumi to saprot.
NÄkamÄ svarÄ«gÄ piezÄ«me: DevOps ne vienmÄr samazina laiku, lai nonÄktu tirgÅ«. DevOps nevar strÄdÄt vienatnÄ, tÄ ir tikai daļa no produkta izveides un ievieÅ”anas tirgÅ« no izstrÄdes lÄ«dz ražoÅ”anai (no koda lÄ«dz klientam). Bet viss pirms koda nav tieÅ”i saistÄ«ts ar DevOps. Tas nozÄ«mÄ, ka tirgotÄji var pÄtÄ«t tirgu gadiem ilgi un visu savu dzÄ«vi pavadÄ«t, lai panÄktu konkurentus. Ir Ätri jÄsaprot, kas klientam nepiecieÅ”ams, un jÄplÄno Ŕīs vai citas funkcijas ievieÅ”ana - bieži vien ar to nepietiek, lai DevOps darbotos un uzÅÄmums sasniegtu savu mÄrÄ·i. TÄpÄc, pirmkÄrt, Raiffeisenbank vienojÄs ar biznesu, ka ir jÄiemÄcÄs lietot DevOps. AutomatizÄcija automatizÄcijas dÄļ daudz nepalÄ«dzÄs cÄ«ÅÄ par jauniem klientiem.
KopumÄ MiÅ”a uzskata, ka DevOps ir jÄievieÅ”, bet saprÄtÄ«gi. Un jÄbÅ«t gataviem tam, ka transformÄcijas sÄkumÄ komandas produktivitÄte kritÄ«sies, nopelnÄ«s mazÄk, bet pÄc tam tas attaisnosies.
Mango Telecom testÄÅ”anas automatizÄcija
VÄl vienu interesantu ziÅojumu man kÄ testÄtÄjam sniedza Egors Maslovs no Mango Telecom. PrezentÄcija saucÄs āPilna testÄÅ”anas cikla automatizÄcija SCRUM komandÄā. Egors uzskata, ka DevOps tika radÄ«ts tieÅ”i SCRUM, taÄu tajÄ paÅ”Ä laikÄ DevOps ievieÅ”ana SCRUM komandÄ ir diezgan problemÄtiska. Tas notiek tÄpÄc, ka SCRUM komanda vienmÄr kaut kur skrien, nav laika novÄrsties no jauninÄjumiem un atjaunot procesu. ProblÄma ir arÄ« tajÄ, ka SCRUM neietver apakÅ”komandu nodalÄ«Å”anu komandÄ (testÄÅ”anas komanda, izstrÄdes komanda utt.). TurklÄt, lai automatizÄtu esoÅ”u procesu, ir nepiecieÅ”ama dokumentÄcija, un SCRUM visbiežÄk dokumentÄcijas nav pilnÄ«bÄ - āprodukts ir svarÄ«gÄks par kaut kÄdu rakstÄ«Å”anuā.
PÄc pÄrejas uz SCRUM testÄtÄji sÄka konsultÄties ar izstrÄdÄtÄjiem par to, kÄ pÄrbaudÄ«t funkcijas. PamazÄm palielinÄjÄs funkcionalitÄtes apjoms, nebija dokumentÄcijas, un sÄka Ä·ert daudz kļūdu funkcionalitÄtÄ, uz kurÄm netika veikti testi un vispÄr vairs nebija skaidrs, kurÅ” un kad to testÄjis. ÄŖsumÄ - apjukums un svÄrstÄ«bas. MÄs nolÄmÄm pÄriet uz testÄÅ”anas automatizÄciju. Bet pat tad bija pilnÄ«ga neveiksme. ViÅi nolÄ«ga Ärpakalpojumu automatizÄcijas speciÄlistus, kuri rakstÄ«ja uz skursteÅa, kas nav zinÄma iekÅ”Äjiem testÄtÄjiem. Autotestu ietvars, protams, darbojÄs, taÄu pÄc Ärpakalpojumu sniedzÄju aizieÅ”anas tas ilga divas nedÄļas. NÄkamais bija mÄÄ£inÄjums ieviest automÄtisko testÄÅ”anu numur divi. Tas sÄkÄs ar faktu, ka viss ir jÄveido uzÅÄmuma iekÅ”ienÄ, paÅ”iem (pareizais vektors: jÄveido zinÄÅ”anas iekÅ”Äji), SCRUM ietvaros un jÄveido dokumentÄcija Å”ajÄ procesÄ. AutomatizÄcijas kaudzei jÄbÅ«t vienÄdai ar produkta kaudzÄ«ti (Å”eit es to pievienoju, nepÄrbaudiet savu JavaScript projektu ar neko citu). Sprinta beigÄs viÅi kopÄ ar visu komandu veica demonstrÄciju par to, kÄ automÄtiskais tests darbojas (noderÄ«gi). LÄ«dz ar to pieauga visu komandas dalÄ«bnieku iesaiste automatizÄcijas procesÄ, kÄ arÄ« uzticÄÅ”anÄs autotestiem un iespÄja, ka Å”is autotests noteikti tiks izmantots (un pÄc mÄneÅ”a nemitÄ«go kļūmju dÄļ netiks komentÄts).
Starp citu, DevOpsForum 2019 bija atvÄrts mikrofons - sen zinÄms un, manuprÄt, noderÄ«gs runu formÄts. Tu Å”Ädi staigÄ apkÄrt, noklausies referÄtus un tad nolem, ka konferencÄ ir vÄrts apspriest kÄdu konkrÄtu tÄmu vai problÄmu, daloties attiecÄ«gÄ pieredzÄ problÄmas risinÄÅ”anÄ.
TÄpat pamanÄ«ju, ka organizatori veidoja Ä«su reportÄžu straumi. Katrs ziÅojums ilgst ne vairÄk kÄ 10 minÅ«tes, kam seko jautÄjumi. TÄdÄ veidÄ varat vienlaikus aptvert daudzas tÄmas un uzdot jautÄjumus runÄtÄjiem, kuri jÅ«s interesÄ.
Starp prezentÄcijÄm es staigÄju pa konferences partneru kabÄ«nÄm un nozagu/uzvarÄju daudz lietu. Ak, man patÄ«k izdales materiÄls!
ApaÄ¼Ä galda un DevOps problÄmas ar Alfastrakhovanie attÄ«stÄ«bas direktoru
GlazÅ«ra uz DevOpsForum 2019 kÅ«kas man bija stundu garÄ plenÄrsÄde ar DevOps ekspertiem. Äetri sesijas dalÄ«bnieki tika aicinÄti apskatÄ«t DevOps no dažÄdiem leÅÄ·iem: Antons IsaÅins (Alfastrakhovanie, attÄ«stÄ«bas direktors), Nailja ZamaÅ”kina (Fintech Lab, darbÄ«bas direktors), Oļegs Egorkins (Rostelecom, Agile treneris) un Antons Martjanovs (neatkarÄ«gs eksperts, apskatÄ«ja DevOps). no biznesa viedokļa).
Eksperti apsÄdÄs tuvÄk cilvÄkiem, un tad sÄkÄs lietas: veselu stundu dalÄ«bnieki no skatÄ«tÄjiem uzdeva savus jautÄjumus, un eksperti uzÅÄma repu. Dažreiz notika patiesas debates. JautÄjumi bija ļoti dažÄdi, piemÄram: vai DevOps inženieri vispÄr ir vajadzÄ«gi, kÄpÄc viÅus nevar apmÄcÄ«t par sistÄmu administratoriem, vai DevOps ir jÄpiedÄvÄ visiem, kÄda ir tÄ vÄrtÄ«ba utt.
Tad es personÄ«gi runÄju ar Antonu IsaÅinu. MÄs apspriedÄm nepiecieÅ”amÄ«bu ieviest DevOps kultÅ«ru katrÄ mÄjÄ un atklÄjÄm DevOps transformÄcijas Änas puses.
IedomÄsimies, ka visi sanÄca kopÄ un nolÄma, ka DevOps ir vajadzÄ«gs gan produktam, gan uzÅÄmumam un komandai. Iesim to Ä«stenot. Viss izdevÄs. MÄs izelpojÄm. DevOps mÅ«s ir pietuvinÄjis klientam, tagad varam Ätri izpildÄ«t visas viÅa vÄlmes. RezultÄtÄ mums ir liela Ops nodaļa ar stingriem noteikumiem un prasÄ«bÄm, un tÄ nepÄrtraukti konstatÄ produkta defektus un veido virkni pieprasÄ«jumu. TurklÄt visiem defektiem tiek pieŔķirts statuss āsteidzamsā, pat ja klients negaidÄ«ti vÄlÄjÄs pogu nokrÄsot dzeltenÄ, nevis zaÄ¼Ä krÄsÄ. Projekts aug, pieaug izlaidumu skaits un attiecÄ«gi arÄ« defektu un klientu pÄrpratumu skaits par jauno funkcionalitÄti. Ops pieÅem darbÄ vÄl 10 cilvÄkus, lai ziÅotu par defektiem, un izstrÄde algo vÄl 15 cilvÄkus, lai neatpaliktu no to slÄgÅ”anas. Un tÄ vietÄ, lai ieviestu jaunas funkcijas, komanda strÄdÄ ar bezgalÄ«giem SD, vienlaikus izskaidrojot lietotÄjam funkcionalitÄti un atbalstu. RezultÄtÄ gan operÄtÄjsistÄmas, gan izstrÄde darbojas, bet klients un uzÅÄmums ir neapmierinÄti: jaunas funkcijas iestrÄgst. IzrÄdÄs, ka DevOps, Ŕķiet, pastÄv, bet Ŕķiet, ka tas neeksistÄ.
RunÄjot par nepiecieÅ”amÄ«bu ieviest DevOps, Antons skaidri norÄdÄ«ja, ka tas ir tieÅ”i atkarÄ«gs no biznesa mÄroga. Ja viena klienta apkalpoÅ”ana gadÄ ienes uzÅÄmumam miljardu, DevOps nav nepiecieÅ”ams (ar nosacÄ«jumu, ka Å”im klientam nav regulÄri jÄievieÅ” jaunas izmaiÅas). Viss ir pÄrklÄts ar Å”okolÄdi. Bet, ja bizness attÄ«stÄs un parÄdÄs vairÄk klientu, tad jums ir jÄievÄro. Parasti uzÅÄmumÄ sÄkotnÄji nav neviena forÅ”a Ops. Vispirms mÄs sagriežam produktu, un tikai tad saprotam, ka, lai produkts darbotos, ir jÄseko lÄ«dzi serveriem un jÄuzrauga piegÄdes. TieÅ”i tad parÄdÄs Ops. Atliek saprast, ka Ops kÄ atseviŔķa nodaļa sÄks uzlikt virkni ŔķÄrŔļu attÄ«stÄ«bai un visas piegÄdes sÄks apstÄties. Tas ir, Å”ajÄ gadÄ«jumÄ DevOps kultÅ«ra jau ir aktuÄla, taÄu mÄs nedrÄ«kstam aizmirst par tÄs tumÅ”o pusi.
Avots: www.habr.com