Mi ĵus ĉeestis DevOpsForum 2019, gastigita de Logrocon. En ĉi tiu konferenco, partoprenantoj provis trovi solvojn kaj novajn ilojn por efika interago inter komercaj kaj disvolvaj kaj informteknologiaj servaj specialistoj.
La konferenco estis sukcesa: estis vere multaj utilaj raportoj, interesaj prezentformatoj kaj multe da komunikado kun la prelegantoj. Kaj precipe gravas, ke neniu provis vendi al mi ion, ion pri kio lastatempe kulpas prelegantoj en grandaj konferencoj.
Eltiraĵo de la paroladoj de Raiffeisenbank, Alfastrakhovanie, la sperto de Mango Telecom en efektivigado de aŭtomatigo kaj aliaj detaloj sub la tranĉo.
Mi nomiĝas Yana, mi laboras kiel testisto, mi faras aŭtomatigon, same kiel DevOps, kaj mi amas iri al konferencoj kaj renkontiĝoj. Dum la lastaj du jaroj, mi estis al la konferencoj de Oleg Bunin (HighLoad++, TeamLead Conf), Jug-eventoj (Heisenbug, JPoint), TestCon Moskvo, DevOps Pro Moskvo, Big Data Moskvo.
Antaŭ ĉio, mi atentigas pri la konferenca programo. Mi rigardas malpli pri kio temas la raporto, kaj pli pri la parolanto. Eĉ se la raporto montriĝas tre teknologia kaj interesa, ne estas fakto, ke vi povos apliki kelkajn el la plej bonaj praktikoj de la raporto en via kompanio. Kaj tiam vi bezonas parolanton.
Lumo ĉe la fino de la dukto ĉe Raiffeisenbank
Kutime, mi ĉasas parolantojn ĉe la rando, kiuj interesas min. Ĉe DevOpsForum 2019, parolanto de Raiffeisenbank, Mikhail Bizhan, kaptis mian intereson. Dum sia parolado, li parolis pri kiel ili iom post iom aliĝas al siaj teamoj al DevOps, kial ili bezonas ĝin kaj kiel vendi la ideon pri transformo de DevOps al komerco. Nu, ĝenerale, mi parolis pri kiel vidi la lumon ĉe la fino de la dukto.
Mikhail Bizhan, direktoro de aŭtomatigo ĉe Raiffeisenbank
Nun ili ne havas "DevOps" en sia kompanio. Tio estas, li laboras, sed ne en ĉiuj teamoj. Kiam ili efektivigas DevOps, ili dependas de la preteco de la teamoj, kaj laŭ specifaj inĝenieroj, kaj laŭ la bezono de la produkto kaj la matureco de la platformo sur kiu ĉi tiu produkto estas konstruita. Misha rakontis kiel klarigi al komerco kial DevOps estas necesa.
La banka segmento havas plurajn kreskajn ŝoforojn: kosto de servoj kaj vastiĝo de la klientbazo. Pliigi la koston de servoj ne estas tre bona ŝoforo, sed kreskigi la klientbazon estas la malo. Se konkurantoj liberigas objektive malvarmetan produkton, ĉiuj klientoj iras tien, tiam kun la tempo la merkato ebeniĝas. Tial, enkonduko de novaj produktoj al la merkato kaj la rapideco de ilia enkonduko estas la ĉefa afero, pri kiu bankoj fokusiĝas. Ĝuste por tio estas DevOps, kaj entreprenoj komprenas ĉi tion.
La sekva grava noto: DevOps ne ĉiam reduktas la tempon por surmerkatigi. DevOps ne povas funkcii sole, ĝi estas nur parto de la procezo de kreado kaj alportado de produkto al merkato de evoluo ĝis produktado (de kodo ĝis kliento). Sed ĉio antaŭ la kodo ne rekte rilatas al DevOps. Tio estas, merkatistoj povas studi la merkaton dum jaroj kaj pasigi sian tutan vivon renkontante konkurantojn. Necesas rapide kompreni, kion la kliento bezonas kaj plani la efektivigon de tiu aŭ alia funkcio - ofte tio ne sufiĉas por ke DevOps funkciu kaj la kompanio atingu sian celon. Tial, antaŭ ĉio, Raiffeisenbank konsentis kun komerco, ke necesas lerni kiel uzi DevOps. Aŭtomatigo pro aŭtomatigo ne multe helpos en la batalo por novaj klientoj.
Ĝenerale, Misha kredas, ke DevOps devas esti efektivigita, sed saĝe. Kaj ni devas esti pretaj por la fakto, ke komence de la transformo la produktiveco de la teamo falos, ĝi gajnos malpli da mono, sed tiam ĝi estos pravigita.
Aŭtomatigo de testado ĉe Mango Telecom
Alian interesan raporton por mi kiel testisto donis Egor Maslov el Mango Telecom. La prezento estis nomita "Aŭtomatigo de la plena testa ciklo en SCRUM-teamo." Egor kredas, ke DevOps estis kreita specife por SCRUM, sed samtempe, enkonduki DevOps en SCRUM-teamo estas sufiĉe problema. Ĉi tio okazas ĉar la SCRUM-teamo ĉiam kuras ie, ne estas tempo por esti distrita de novigoj kaj rekonstrui la procezon. La problemo ankaŭ kuŝas en la fakto, ke SCRUM ne implikas la apartigon de sub-teamoj en la teamo (testa teamo, evolua teamo, ktp). Nu, krome, por aŭtomatigi ekzistantan procezon, dokumentado necesas, kaj en SCRUM, plej ofte ne estas tute dokumentado - "la produkto estas pli grava ol ia skribo."
Post ŝanĝi al SCRUM, testistoj komencis konsulti kun programistoj pri kiel testi funkciojn. Iom post iom, la volumeno de funkcieco pliiĝis, ne estis dokumentado, kaj ili komencis kapti multajn cimojn en la funkcieco, kiuj ne estis kovritaj de testoj kaj ĝenerale ne plu estis klare, kiu testis ĝin kaj kiam. Resume - konfuzo kaj ŝanceliĝo. Ni decidis ŝanĝi al testa aŭtomatigo. Sed eĉ tiam estis kompleta fiasko. Ili dungis eksterkontraktitajn aŭtomatigajn specialistojn, kiuj skribis sur stako nekonata al endomaj testistoj. La kadro por aŭtotestoj funkciis, kompreneble, sed post kiam la subkontraktantoj foriris, ĝi daŭris du semajnojn. Venonta estis provo enkonduki aŭtotestadon numeron du. Ĝi komenciĝis per tio, ke ĉio devas esti konstruita ene de la kompanio, memstare (la ĝusta vektoro: konstruu kompetentecon interne), kadre de SCRUM, kaj kreu dokumentadon en la procezo. La stako por aŭtomatigo devus esti egala al la stako de la produkto (ĉi tie mi aldonas ĝin, ne provu vian JavaScript-projekton per io alia). Ĉe la fino de la spurto, ili faris demonstron pri kiel la aŭtotesto funkcias kun la tuta teamo (helpema). Tiel, la implikiĝo de ĉiuj teamanoj en la aŭtomatigprocezo pliiĝis, same kiel fido je aŭtotestoj kaj la ŝanco ke ĉi tiu aŭtotesto certe estos uzata (kaj ne estos komentita post monato pro konstantaj fiaskoj).
Cetere, ĉe DevOpsForum 2019 estis malfermita mikrofono - delonge konata kaj, laŭ mi, utila formato de paroladoj. Vi promenas tiel, aŭskultas raportojn, kaj poste decidas, ke en la konferenco indas diskuti certan temon aŭ problemon, kunhavigi koncernan sperton pri solvado de la problemo.
Mi ankaŭ rimarkis, ke la organizantoj faris fluon da mallongaj raportoj. Ĉiu raporto daŭras ne pli ol 10 minutojn, sekvataj de demandoj. Tiel vi povas trakti multajn temojn samtempe kaj demandi demandojn al parolantoj, kiuj interesas vin.
Inter prezentoj, mi promenis ĉirkaŭ la budoj de la konferencaj partneroj kaj ŝtelis/gajnis multajn aĵojn. Ho, mi amas la folion!
Ronda tablo kaj DevOps-problemoj kun la disvolva direktoro ĉe Alfastrakhovanie
La guisaĵo sur la kuko DevOpsForum 2019 por mi estis la unuhora plena kunsido kun spertuloj de DevOps. Kvar sesiaj partoprenantoj estis invititaj rigardi DevOps el malsamaj anguloj: Anton Isanin (Alfastrakhovanie, disvolva direktoro), Nailya Zamashkina (Fintech Lab, operacianta direktoro), Oleg Egorkin (Rostelecom, Agile-trejnisto) kaj Anton Martyanov (sendependa fakulo, rigardis DevOps). el komerca vidpunkto).
La fakuloj sidiĝis pli proksime al la homoj kaj tiam la aferoj komencis okazi: dum tuta horo, partoprenantoj el la publiko demandis siajn demandojn, kaj la fakuloj prenis la repon. Foje estis veraj debatoj. La demandoj estis tre malsamaj, ekzemple: ĉu DevOps-inĝenieroj entute bezonas, kial ili ne povas esti trejnitaj kiel sistemaj administrantoj, ĉu DevOps estu ofertita al ĉiuj, kio estas ĝia valoro, ktp.
Poste, mi persone parolis kun Anton Isanin. Ni diskutis la bezonon alporti la DevOps-kulturon al ĉiu hejmo kaj malkaŝis la malluman flankon de DevOps-transformo.
Ni imagu, ke ĉiuj kuniĝis kaj decidis, ke DevOps estas bezonata kaj de la produkto kaj de la komerco kaj la teamo. Ni iru efektivigi ĝin. Ĉio funkciis. Ni elspiris. DevOps alproksimigis nin al la kliento, nun ni povas rapide plenumi ĉiujn liajn dezirojn. Kiel rezulto, ni havas grandan Ops-sekcion kun striktaj regularoj kaj postuloj, kaj ĝi konstante trovas difektojn en la produkto kaj kreas amason da petoj. Krome, ĉiuj difektoj ricevas la "urĝan" statuson, eĉ se la kliento neatendite volis kolorigi la butonon flava anstataŭ verda. La projekto kreskas, la nombro da eldonoj kreskas kaj, sekve, la nombro da difektoj kaj miskomprenoj de novaj funkcioj de klientoj. Ops dungas 10 pliajn homojn por daŭrigi kun raportado de difektoj, kaj evoluo dungas 15 pliajn por daŭrigi kun fermo de ili. Kaj anstataŭ enkonduki novajn funkciojn, la teamo laboras kun senfinaj SD-oj, klarigante la funkciojn al la uzanto kaj subtenon samtempe. Kiel rezulto, kaj Ops kaj evoluo funkcias, sed la kliento kaj komerco estas malfeliĉaj: novaj funkcioj blokiĝas. Rezultas, ke DevOps ŝajnas ekzisti, sed ĝi ne ŝajnas ekzisti.
Koncerne la bezonon efektivigi DevOps, Anton klare deklaris, ke ĉi tio rekte dependas de la skalo de la komerco. Se servado de unu kliento jare alportas al la kompanio miliardon, DevOps ne estas bezonata (kondiĉe ke vi ne bezonas regule fari novajn ŝanĝojn al ĉi tiu kliento). Ĉio estas kovrita per ĉokolado. Sed se la komerco kreskas kaj pli da klientoj aperas, tiam vi devas plenumi. Kiel regulo, ne estas bonegaj Ops en la kompanio komence. Unue ni tranĉas la produkton, kaj nur tiam ni komprenas, ke por ke la produkto funkciu, ni devas observi la servilojn kaj monitori provizojn. Tio estas kiam Ops ekestas. Restas kompreni, ke Ops, kiel aparta divido, komencos starigi amason da baroj al disvolviĝo kaj ĉiuj liveroj komencos halti. Tio estas, en ĉi tiu kazo, la kulturo DevOps jam estas grava, sed ni ne devas forgesi pri ĝia malluma flanko.
fonto: www.habr.com