Ég sótti nýlega DevOpsForum 2019, hýst af Logrocon. Á þessari ráðstefnu reyndu þátttakendur að finna lausnir og ný verkfæri fyrir árangursríkt samspil viðskipta- og þróunar- og upplýsingatækniþjónustusérfræðinga.
Ráðstefnan heppnaðist vel: það voru virkilega margar gagnlegar skýrslur, áhugavert kynningarform og mikil samskipti við fyrirlesarana. Og það er sérstaklega mikilvægt að enginn hafi reynt að selja mér neitt, eitthvað sem fyrirlesarar á stórum ráðstefnum hafa gerst sekir um undanfarið.
Útdráttur úr ræðum Raiffeisenbank, Alfastrakhovanie, reynslu Mango Telecom í að innleiða sjálfvirkni og aðrar upplýsingar undir niðurskurðinum.
Ég heiti Yana, ég vinn sem prófari, stunda sjálfvirkni, sem og DevOps, og ég elska að fara á ráðstefnur og fundi. Undanfarin tvö ár hef ég verið á ráðstefnum Oleg Bunin (HighLoad++, TeamLead Conf), Jug-viðburði (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Fyrst og fremst vek ég athygli á dagskrá ráðstefnunnar. Ég horfi minna á það sem skýrslan mun fjalla um og meira á ræðumanninn. Jafnvel þótt skýrslan reynist mjög tæknivædd og áhugaverð, þá er það ekki staðreynd að þú munt geta beitt sumum af bestu starfsvenjum skýrslunnar í þínu fyrirtæki. Og þá þarftu hátalara.
Ljós við enda leiðslunnar hjá Raiffeisenbanka
Venjulega leita ég að hátölurum á hliðarlínunni sem vekja áhuga minn. Á DevOpsForum 2019 vakti ræðumaður frá Raiffeisenbank, Mikhail Bizhan, áhuga minn. Í ræðu sinni talaði hann um hvernig þeir eru smám saman að fá teymi sín að krækja í DevOps, hvers vegna þeir þurfa það og hvernig á að selja hugmyndina um DevOps umbreytingu til fyrirtækja. Jæja, almennt talaði ég um hvernig á að sjá ljósið í lok leiðslunnar.
Mikhail Bizhan, forstöðumaður sjálfvirkni hjá Raiffeisenbank
Nú eru þeir ekki með „DevOps“ í fyrirtækinu sínu. Það er að segja, hann vinnur, en ekki í öllum liðum. Þegar þeir innleiða DevOps treysta þeir á viðbúnað teymanna, bæði hvað varðar sérstaka verkfræðinga, og hvað varðar þörf vörunnar og þroska vettvangsins sem þessi vara er byggð á. Misha sagði hvernig á að útskýra fyrir fyrirtæki hvers vegna DevOps er þörf.
Bankasviðið hefur nokkra vaxtarhvata: þjónustukostnað og stækkun viðskiptavinahópsins. Að auka kostnað við þjónustu er ekki mjög góður drifkraftur, en að stækka viðskiptavinahópinn er hið gagnstæða. Ef samkeppnisaðilar gefa út hlutlæga flotta vöru fara allir viðskiptavinir þangað, þá jafnast markaðurinn með tímanum. Þess vegna er það helsta sem bankar leggja áherslu á að koma nýjum vörum á markaðinn og hraðinn á innleiðingu þeirra. Þetta er nákvæmlega það sem DevOps er fyrir og fyrirtæki skilja þetta.
Næsta mikilvæga athugasemd: DevOps styttir ekki alltaf tíma á markað. DevOps getur ekki virkað eitt og sér, það er bara hluti af því ferli að búa til og koma vöru á markað frá þróun til framleiðslu (frá kóða til viðskiptavina). En allt fyrir kóðann er ekki beint tengt DevOps. Það er að segja að markaðsmenn geta rannsakað markaðinn í mörg ár og eytt öllu lífi sínu í að ná keppinautum. Nauðsynlegt er að skilja fljótt hvað viðskiptavinurinn þarf og skipuleggja innleiðingu þessa eða hinna eiginleikans - oft er þetta það sem er ekki nóg til að DevOps virki og fyrirtækið nái markmiði sínu. Þess vegna, fyrst og fremst, var Raiffeisenbank sammála viðskiptalífinu um að nauðsynlegt væri að læra hvernig á að nota DevOps. Sjálfvirkni í þágu sjálfvirkni mun ekki hjálpa mikið í baráttunni um nýja viðskiptavini.
Almennt séð telur Misha að útfæra DevOps, en skynsamlega. Og við verðum að vera tilbúin fyrir þá staðreynd að í upphafi umbreytingarinnar mun framleiðni liðsins minnka, það mun þéna minna, en þá verður það réttlætanlegt.
Sjálfvirkni prófana hjá Mango Telecom
Önnur áhugaverð skýrsla fyrir mig sem prófunaraðila gaf Egor Maslov frá Mango Telecom. Kynningin var kölluð „Sjálfvirkni alls prófunarferilsins í SCRUM teymi. Egor telur að DevOps hafi verið búið til sérstaklega fyrir SCRUM, en á sama tíma er nokkuð erfitt að koma DevOps inn í SCRUM teymi. Þetta gerist vegna þess að SCRUM teymið er alltaf að keyra einhvers staðar, það er enginn tími til að vera annars hugar af nýjungum og endurbyggja ferlið. Vandamálið liggur líka í því að SCRUM felur ekki í sér aðskilnað undirteyma í teyminu (prófateymi, þróunarteymi og svo framvegis). Jæja, að auki, til að gera sjálfvirkt ferli sem fyrir er, þarf skjöl og í SCRUM er oftast engin skjöl til að fullu - „varan er mikilvægari en einhvers konar skrif.
Eftir að hafa skipt yfir í SCRUM fóru prófunaraðilar að ráðfæra sig við forritara um hvernig ætti að prófa eiginleika. Smám saman jókst magn virkni, engin skjöl voru til og þeir fóru að grípa mikið af villum í virkninni sem ekki var fjallað um í prófunum og almennt var ekki lengur ljóst hver prófaði það og hvenær. Í hnotskurn - rugl og væl. Við ákváðum að skipta yfir í að prófa sjálfvirkni. En jafnvel þá var algjörlega misbrestur. Þeir réðu útvistaða sjálfvirknisérfræðinga sem skrifuðu á stafla sem ekki var þekkt fyrir innanhússprófendur. Ramminn fyrir sjálfvirkar prófanir virkaði vissulega, en eftir að útvistaraðilar fóru, stóð hann yfir í tvær vikur. Næst var tilraun til að kynna sjálfvirka prófun númer tvö. Það byrjaði á því að allt þarf að byggja upp innan fyrirtækisins, á eigin spýtur (réttur vektor: byggja upp sérfræðiþekkingu innbyrðis), innan ramma SCRUM, og búa til skjöl í ferlinu. Staflan fyrir sjálfvirkni ætti að vera jafn og stafla vörunnar (hér er ég að bæta honum við, ekki prófa JavaScript verkefnið þitt með neinu öðru). Í lok sprettsins gerðu þeir kynningu á því hvernig sjálfvirka prófið virkar með öllu liðinu (gagnlegt). Þannig jókst þátttaka allra liðsmanna í sjálfvirkniferlinu, sem og traust á sjálfvirkum prófunum og líkurnar á því að þetta sjálfvirka próf verði örugglega notað (og verður ekki tjáð eftir mánuð vegna stöðugra bilana).
Við the vegur, á DevOpsForum 2019 var opinn hljóðnemi - löngu þekkt og að mínu mati gagnlegt ræðusnið. Maður gengur svona um, hlustar á skýrslur og ákveður svo að á ráðstefnunni sé þess virði að ræða ákveðið efni eða vandamál, deila viðeigandi reynslu af lausn vandans.
Ég tók líka eftir því að skipuleggjendur gerðu straum af stuttum skýrslum. Hver skýrsla tekur ekki lengri tíma en 10 mínútur og síðan fylgja spurningar. Þannig geturðu fjallað um mörg efni í einu og spurt spurninga til fyrirlesara sem hafa áhuga á þér.
Á milli kynninga gekk ég um bása ráðstefnufélaga og stal/vann fullt af dóti. Æ, ég elska útsendinguna!
Round table og DevOps mál með þróunarstjóra hjá Alfastrakhovanie
Rúsínan í DevOpsForum 2019 kökuna fyrir mig var klukkutíma langur þingfundur með DevOps sérfræðingum. Fjórum þátttakendum var boðið að skoða DevOps frá mismunandi sjónarhornum: Anton Isanin (Alfastrakhovanie, þróunarstjóri), Nailya Zamashkina (Fintech Lab, rekstrarstjóri), Oleg Egorkin (Rostelecom, Agile þjálfari) og Anton Martyanov (óháður sérfræðingur, skoðaði DevOps frá viðskiptalegu sjónarmiði).
Sérfræðingarnir settust nær fólkinu og þá fóru hlutirnir að gerast: í heila klukkustund spurðu þátttakendur úr salnum spurninga sinna og sérfræðingarnir tóku rappið. Stundum voru alvöru rökræður. Spurningarnar voru mjög mismunandi, til dæmis: vantar DevOps verkfræðinga yfirhöfuð, hvers vegna er ekki hægt að þjálfa þá sem kerfisstjóra, ætti DevOps að vera boðið öllum, hvers virði er það, og svo framvegis.
Síðan talaði ég persónulega við Anton Isanin. Við ræddum nauðsyn þess að koma DevOps menningu á hvert heimili og afhjúpuðum myrku hliðina á DevOps umbreytingu.
Við skulum ímynda okkur að allir hafi tekið sig saman og ákveðið að DevOps sé þörf bæði fyrir vöruna og fyrirtækið og teymið. Við skulum fara að framkvæma það. Allt gekk upp. Við önduðum frá okkur. DevOps hefur fært okkur nær viðskiptavininum, nú getum við fljótt uppfyllt allar óskir hans. Fyrir vikið erum við með stóra Ops deild með ströngum reglugerðum og kröfum og hún finnur stöðugt galla í vörunni og býr til fullt af beiðnum. Þar að auki er öllum göllum úthlutað „aðkallandi“ stöðu, jafnvel þótt viðskiptavinurinn vildi óvænt lita hnappinn gulan í stað græns. Verkefnið er að stækka, útgáfum fjölgar og í samræmi við það, fjöldi galla og misskilnings viðskiptavina á nýjum virkni. Ops ræður 10 manns í viðbót til að halda í við að tilkynna galla og þróun ræður 15 í viðbót til að halda í við að loka þeim. Og í stað þess að kynna nýja eiginleika vinnur teymið með endalausum SD-um, útskýrir virknina fyrir notandanum og stuðninginn á sama tíma. Fyrir vikið eru bæði Ops og þróun að virka, en viðskiptavinurinn og fyrirtækið eru óánægðir: nýir eiginleikar festast. Það kemur í ljós að DevOps virðist vera til, en það virðist ekki vera til.
Varðandi nauðsyn þess að innleiða DevOps sagði Anton skýrt frá því að þetta færi beint eftir umfangi fyrirtækisins. Ef að þjónusta einn viðskiptavin á ári færir fyrirtækinu milljarð, er DevOps ekki þörf (að því gefnu að þú þurfir ekki að setja nýjar breytingar á þessum viðskiptavini reglulega). Allt er þakið súkkulaði. En ef fyrirtækið stækkar og fleiri viðskiptavinir birtast, þá þarftu að fara eftir því. Að jafnaði er engin flott Ops í fyrirtækinu í upphafi. Fyrst skerum við vöruna og þá fyrst skiljum við að til þess að varan virki þurfum við að sjá um netþjóna og fylgjast með birgðum. Það er þegar Ops verður til. Það á eftir að skilja að Ops, sem sérstök deild, mun byrja að setja upp fullt af hindrunum fyrir þróun og allar sendingar munu byrja að stoppa. Það er að segja, í þessu tilfelli er DevOps menningin þegar viðeigandi, en við megum ekki gleyma myrku hliðinni.
Heimild: www.habr.com