Nesen es apmeklēju DevOpsForum 2019, ko organizēja Logrocon. Šajā konferencē dalībnieki centās atrast risinājumus un jaunus rīkus efektīvai biznesa un izstrādātāju un IT speciālistu sadarbībai.
Konference izdevās: bija tiešām daudz noderīgu ziņojumu, interesanti uzstāšanās formāti un daudz sarunu ar runātājiem. Un, kas īpaši svarīgi, neviens man neko nepārdod, kā to bieži dara runātāji lielās konferencēs.
Izcili mirkļi no Raiffeisenbank, Alfa Insurance uzstāšanām, Mango Telecom automatizācijas ieviešanas pieredze un citas detaļas zem katra.
Mani sauc Jana, es strādāju par testētāju, nodarbojos ar automatizāciju, kā arī DevOps un esmu kaislīga par konferencēm un meet-upiem. Pēdējo divu gadu laikā esmu apmeklējusi Oļega Bunina konferencēs (HighLoad++, TeamLead Conf), Jug pasākumos (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Pirmais, ko es ievēroju, ir konferences programma. Mazāk uzmanības pievēršu tam, par ko būs ziņojums, vairāk - runātājam. Pat ja ziņojums izrādīsies ļoti tehnisks un interesants, nav garantijas, ka spēsi pielietot kādas labākās prakses savā uzņēmumā. Un tad tev ir nepieciešams runātājs.
Gaisma tunelī Raiffeisenbankā
Parasti es rīkoju medības pēc interesējošiem runātājiem kuluāros. DevOpsForum 2019 laikā mans interesi piesaistīja runātājs no Raiffeisenbank, Mihails Bižans. Uzstāšanās laikā viņš stāstīja, kā viņi pakāpeniski ievieš DevOps savos komandas, kāpēc viņiem tas ir nepieciešams un kā pārdot biznesam DevOps transformācijas ideju. Un kopumā viņš runāja par to, kā saredzēt gaismu tunelī.
Mihails Bižans, automatizācijas direktors Raiffeisenbankā
Pašlaik viņiem uzņēmumā nav "īstā DevOps". Tas ir īsts, bet ne visās komandās. Ieviešot DevOps, viņi paļaujas uz komandu gatavību, gan konkrēto inženieru ziņā, gan produkta vajadzību un platformas, uz kuras šis produkts ir būvēts, nobriešanas ziņā. Miša stāstīja, kā izskaidrot biznesam, kāpēc nepieciešams DevOps.
Banku segmentam ir vairāki izaugsmes dzinēji: pakalpojumu izmaksas un klientu bāzes paplašināšana. Pakalpojumu izmaksu paaugstināšana nav pārāk labs dzinējs, bet klientu bāzes izaugsme ir tieši pretēji. Ja konkurenti izlaiž objektīvi lielisku produktu, visi klienti pāriet pie viņiem, un laika gaitā tirgus izlīdzinās. Tādēļ jaunu produktu izlaišana un to izlaišanas ātrums ir galvenās lietas, uz kurām koncentrējas bankas. Tieši tāpēc ir nepieciešams DevOps, un biznesa vide to saprot.
Nākamais svarīgais novērojums: DevOps ne vienmēr samazina time to market. DevOps nevar darboties viens, tas ir tikai daļa no produkta izstrādes un tirgū virzīšanas procesa no izstrādes līdz ražošanai (no koda līdz klientam). Bet viss, kas notiek pirms koda, tieši neskar DevOps. Tas nozīmē, ka mārketinga speciālisti var gadiem ilgi pētīt tirgu un visu mūžu sekot konkurentiem. Ir svarīgi ātri saprast, kas nepieciešams klientiem un plānot konkrētu funkciju ieviešanu — bieži tieši šis trūkst, lai DevOps darbotos un uzņēmums sasniegtu savus mērķus. Tāpēc, pirmkārt, Raiffeisenbankā tika panākta vienošanās ar biznesu par to, ka ir jāmācās izmantot DevOps. Automatizācija tikai automatizācijas nolūkā būtiski nepalīdzēs cīņā par jauniem klientiem.
Kopumā Miša uzskata, ka DevOps ir jāievieš, bet saprātīgi. Jābūt gatavam tam, ka transformācijas sākumā komandai var samazināties produktivitāte, tā nopelnīs mazāk naudas, bet vēlāk tas attaisnosies.
Testēšanas automatizācija uzņēmumā "Mango Telekom"
Aizraujošs ziņojums kā testētājam sniedza Egors Maslovs no "Mango Telecom". Prezentācija bija nosaukta "Testēšanas pilna cikla automatizācija SCRUM komandā". Egors uzskata, ka DevOps ir radīts tieši SCRUM, taču ieviešana SCRUM komandā ir diezgan problemātiska. Tas notiek, jo SCRUM komanda vienmēr steidzas, nav laika novirzīties uz jauninājumiem un pārstrukturēt procesus. Problēma ir arī tāda, ka SCRUM neparedz ķert subkomandas (testētāju komanda, izstrādātāju komanda un tā tālāk). Turklāt esošā procesa automatizācijai nepieciešama dokumentācija, bet SCRUM visbiežāk dokumentācijas nav vispār – "produkts ir svarīgāks par kādu rakstīšanu".
Pēc pārejas uz SCRUM testētāji sāka konsultēties ar izstrādātājiem, kā testēt funkcionalitāti. Pakāpeniski funkcionalitātes apjoms pieauga, dokumentācija netika sagatavota, un viņi sāka pamanīt daudz kļūdu tajā funkcionalitātē, kurā nebija testu pārklājuma un vispār vairs nebija skaidrs, kurš un kad to testēja. Divos vārdos – haoss un neskaidrība. Viņi nolēma pāriet uz testēšanas automatizāciju. Bet pat tad notika pilnīgs fiasko. Viņi piesaistīja ārējus speciālistus automatizācijai, kuri rakstīja uz nezināma testētājiem tehnoloģiju kaudzes. Autotestu unģens darbojās, bet pēc tam, kad ārējie darbinieki aizgāja, tā ilga tikai divas nedēļas. Pēc tam bija otrā automatizācijas mēģinājuma uzsākšana. Tas sākās ar to, ka viss jāveido iekšēji, ar saviem spēkiem (pareizais virziens: palieliniet iekšējo ekspertīzi), SCRUM ietvaros, un procesā jāizveido dokumentācija. Automatizācijas tehnoloģiju kaudzei jāsakrīt ar produkta tehnoloģiju kaudzi (šajā ziņā es piekrītu, nu nemēģiniet testēt projektu JavaScript ar kaut ko citu). Sprinta beigās viņi rīkoja demonstrāciju par to, kā darbojas autotests, ar visu komandu dalību (noderīgi). Tādējādi tika palielināta visu komandas dalībnieku iesaistīšanās automatizācijā, kā arī uzticība autotestiem un iespēja, ka šis autotests noteikti tiks izmantots (nevis tiks izslēgts pēc mēneša pastāvīgu izgāšanos dēļ).
Starp citu, DevOpsForum 2019 bija atvērto mikrofonu formāts – jau sen pazīstams un, manuprāt, noderīgs pasākums, kurā cilvēki var piecelties un dalīties ar savām pieredzēm. Tu ej apkārt, klausies ziņojumus, un tad izlem, ka konferences ietvaros ir vērts aplūkot kādu tēmu vai problēmu, daloties ar atbilstošu pieredzi risinājuma meklējumos.
Es arī ievēroju, ka organizatori rīkoja īso ziņojumu plūsmu. Katrs ziņojums ilgst ne vairāk kā 10 minūtes, pēc tam seko jautājumu sesija. Tādējādi var aptvert vairāk tēmu un uzdot jautājumus runātājiem, kuri piesaistīja uzmanību.
Starplaikos es izstaigāju partneru stendus un dabūju daudz dažādu laipnu pārsteigumu. Ak, kā man patīk saņemt dāvanas!
Apaļais galds un jautājumi par DevOps ar attīstības vadītāju no Alfa Group.
DevOpsForum 2019 ķirsis uz kūkas bija stundu gara plēnārsessija ar DevOps ekspertiem. Tika uzaicināti četri sesijas dalībnieki, kuri aplūkoja DevOps no dažādiem aspektiem: Antons Isanins (Alfa Group, attīstības vadītājs), Nailija Zamashkina (Fintech Lab, operatīvā direktore), Oļegs Egorkins (Rosteļekoms, Agile treneris) un Antons Martjānovs (neatkarīgs eksperts, kurš aplūkoja DevOps no biznesa skatupunkta).
Eksperti sēdēja tuvāk publikai, un te nu sākās: veselu stundu dalībnieki no zāles uzdeva savus jautājumus, un eksperti centās atbildēt. Dažreiz norisinājās īstas debates. Jautājumi bija visdažādākie, piemēram: vai vispār ir nepieciešami DevOps inženieri, kāpēc viņus nevar izaudzināt no sistēmu administratoriem, vai visiem ir jāiepazīst DevOps, kāda ir tā vērtība un tā tālāk.
Pēc tam es personīgi parunāju ar Antonu Isaninu. Apspriedām nepieciešamību ieviest DevOps kultūru katrā mājā un atklājām DevOps transformācijas tumšo pusi.
Iedomājieties, ka visi ir apsēdušies un izlēmuši, ka DevOps ir nepieciešams gan produktam, gan biznesam un komandai. Sāka to ieviest. Viss izdevās. Izsita elpu. DevOps mūs padarīja tuvāk klientam, tagad mēs ātri varam izpildīt visas viņa prasības. Rezultātā mums ir liels Ops apakšnodaļa ar stingrām prasībām un noteikumiem, un tā nepārtraukti nosūta defektus uz produktu, radot kaudzi pieprasījumu. Turklāt visi defekti saņem statusu "steidzami", pat ja klientam pēkšņi iegribējās izkrāsot pogu dzeltenā krāsā, nevis zaļā. Projekts aug, pieaug izlaidumu skaits un attiecīgi defektu un klientu nesapratņu skaits par jauno funkcionalitāti. Ops pieņem vēl 10 cilvēkus, lai paspētu ziņot par defektiem, bet izstrāde pieņem vēl 15, lai paspētu tos novērst. Un vietā, lai ieviestu jaunās funkcijas, komanda strādā ar bezgalīgām SD lietām, skaidrojot funkcionalitāti lietotājam, nodrošinot atbalstu arī tam. Rezultāts ir tas, ka gan Ops, gan izstrāde ir aizņemti, bet klients un bizness ir neapmierināti: jaunas funkcijas iestrēgst. Izrādās, DevOps ir, bet tā kā nav.
Par to, kāpēc ir nepieciešams ieviest DevOps, Antons bez šaubām apgalvoja, ka tas tieši atkarīgs no biznesa apmēriem. Ja viena klienta apkalpošana gadā uzņēmumam ienāk miljardu — DevOps nav nepieciešams (ja vien tev nav jāizlaiž šim klientam jaunas izmaiņas regulāri). Viss jau ir kārtībā. Bet, ja bizness aug, un tiek pievienoti jauni klienti, tad ir jāatbilst. Parasti, sākotnēji uzņēmumā nav lieliska Ops. Sākotnēji mēs attīstām produktu, un tikai pēc tam saprotam, ka, lai produkts darbotos, ir jāseko līdzi piegādēm. Tad arī rodas Ops. Ir jāizprot, ka Ops kā atsevišķa nodaļa sāks izvirzīt daudz barjeru izstrādei un visas piegādes sāks apstāties. Tas nozīmē, ka šajā gadījumā DevOps kultūra jau ir aktuāla, tikai nevajag aizmirst par tās tumšo pusi. serveriem, sekot piegādēm. Tad arī rodas Ops. Iznāk, ka Ops kā atsevišķa nodaļa sāks izvirzīt daudz barjeru izstrādei un visas piegādes sāks apstāties. Tas nozīmē, ka šajā gadījumā DevOps kultūra jau ir aktuāla, tikai nevajag aizmirst par tās tumšo pusi.
Avots: habr.com
