Hivi majuzi nilihudhuria DevOpsForum 2019, iliyoandaliwa na Logrocon. Katika mkutano huu, washiriki walijaribu kutafuta suluhu na zana mpya za mwingiliano mzuri kati ya biashara na maendeleo na wataalamu wa huduma ya teknolojia ya habari.
Mkutano huo ulikuwa wa mafanikio: kulikuwa na ripoti nyingi muhimu, miundo ya kuvutia ya uwasilishaji na mawasiliano mengi na wasemaji. Na ni muhimu sana kwamba hakuna mtu aliyejaribu kuniuzia chochote, jambo ambalo wasemaji kwenye mikutano mikubwa wamekuwa na hatia hivi karibuni.
Sehemu kutoka kwa hotuba za Raiffeisenbank, Alfastrakhovanie, uzoefu wa Mango Telecom katika kutekeleza otomatiki na maelezo mengine chini ya kukata.
Jina langu ni Yana, ninafanya kazi ya majaribio, nafanya mitambo otomatiki, na vile vile DevOps, na ninapenda kwenda kwenye mikutano na mikutano. Katika kipindi cha miaka miwili iliyopita, nimekuwa kwenye mikutano ya Oleg Bunin (HighLoad++, TeamLead Conf), matukio ya Jug (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Kwanza kabisa, ninaelekeza uangalifu kwenye programu ya mkutano. Siangalii zaidi ripoti itahusu nini, na zaidi kwa mzungumzaji. Hata kama ripoti itageuka kuwa ya kiteknolojia na ya kuvutia sana, si ukweli kwamba utaweza kutumia baadhi ya mbinu bora kutoka kwa ripoti katika kampuni yako. Na kisha unahitaji msemaji.
Mwanga mwishoni mwa bomba la Raiffeisenbank
Kawaida, mimi hutafuta wasemaji kando ambayo inanipendeza. Katika DevOpsForum 2019, mzungumzaji kutoka Raiffeisenbank, Mikhail Bizhan, alivutiwa nami. Wakati wa hotuba yake, alizungumza juu ya jinsi wanavyofanya timu zao kuunganishwa kwenye DevOps, kwa nini wanaihitaji, na jinsi ya kuuza wazo la mabadiliko ya DevOps kwa biashara. Kweli, kwa ujumla, nilizungumza juu ya jinsi ya kuona taa mwishoni mwa bomba.
Mikhail Bizhan, mkurugenzi wa automatisering katika Raiffeisenbank
Sasa hawana "DevOps" katika kampuni yao. Hiyo ni, anafanya kazi, lakini sio katika timu zote. Wakati wa kutekeleza DevOps, hutegemea utayari wa timu, kwa suala la wahandisi maalum, na kwa suala la hitaji la bidhaa na ukomavu wa jukwaa ambalo bidhaa hii imejengwa. Misha aliiambia jinsi ya kuelezea biashara kwa nini DevOps inahitajika.
Sehemu ya benki ina vichocheo kadhaa vya ukuaji: gharama ya huduma na upanuzi wa msingi wa mteja. Kuongezeka kwa gharama ya huduma sio dereva mzuri sana, lakini kukua msingi wa mteja ni kinyume chake. Ikiwa washindani watatoa bidhaa nzuri kabisa, wateja wote huenda huko, kisha baada ya muda soko huongezeka. Kwa hiyo, kuanzisha bidhaa mpya kwenye soko na kasi ya kuanzishwa kwao ni jambo kuu ambalo mabenki huzingatia. Hivi ndivyo DevOps inavyotumika, na wafanyabiashara wanaelewa hili.
Ujumbe muhimu unaofuata: DevOps haipunguzi muda wa soko kila wakati. DevOps haiwezi kufanya kazi peke yake, ni sehemu tu ya mchakato wa kuunda na kuleta bidhaa sokoni kutoka kwa maendeleo hadi uzalishaji (kutoka kwa msimbo hadi mteja). Lakini kila kitu kabla ya msimbo haihusiani moja kwa moja na DevOps. Hiyo ni, wauzaji wanaweza kusoma soko kwa miaka na kutumia maisha yao yote kupatana na washindani. Inahitajika kuelewa haraka kile mteja anahitaji na kupanga utekelezaji wa hii au kipengele hicho - mara nyingi hii ndiyo haitoshi kwa DevOps kufanya kazi na kampuni kufikia lengo lake. Kwa hiyo, kwanza kabisa, Raiffeisenbank ilikubaliana na biashara kwamba ilikuwa ni lazima kujifunza jinsi ya kutumia DevOps. Automation kwa ajili ya automatisering haitasaidia sana katika kupigania wateja wapya.
Kwa ujumla, Misha anaamini kwamba DevOps inahitaji kutekelezwa, lakini kwa busara. Na tunapaswa kuwa tayari kwa ukweli kwamba mwanzoni mwa mabadiliko tija ya timu itashuka, itapata pesa kidogo, lakini basi itahesabiwa haki.
Uendeshaji wa majaribio katika Mango Telecom
Ripoti nyingine ya kufurahisha kwangu kama mjaribu ilitolewa na Egor Maslov kutoka Mango Telecom. Wasilisho liliitwa "Otomatiki ya mzunguko kamili wa majaribio katika timu ya SCRUM." Egor anaamini kuwa DevOps iliundwa mahsusi kwa SCRUM, lakini wakati huo huo, kuanzisha DevOps kwenye timu ya SCRUM ni shida sana. Hii hutokea kwa sababu timu ya SCRUM inafanya kazi mahali fulani kila wakati, hakuna wakati wa kukengeushwa na ubunifu na kuunda upya mchakato. Tatizo pia liko katika ukweli kwamba SCRUM haihusishi mgawanyiko wa timu ndogo katika timu (timu ya kupima, timu ya maendeleo, na kadhalika). Kweli, zaidi ya hayo, kuhariri mchakato uliopo, nyaraka zinahitajika, na katika SCRUM, mara nyingi hakuna hati kabisa - "bidhaa ni muhimu zaidi kuliko aina fulani ya uandishi."
Baada ya kubadili SCRUM, wanaojaribu walianza kushauriana na wasanidi programu kuhusu jinsi ya kujaribu vipengele. Hatua kwa hatua, kiasi cha utendaji kiliongezeka, hakukuwa na nyaraka, na walianza kupata mende nyingi katika utendaji ambao haukufunikwa na vipimo na kwa ujumla haikuwa wazi tena ni nani aliyeijaribu na lini. Kwa kifupi - kuchanganyikiwa na vacillation. Tuliamua kubadili kwa kupima otomatiki. Lakini hata hivyo kulikuwa na kushindwa kabisa. Waliajiri wataalamu wa mitambo ya kiotomatiki ambao waliandika kwenye safu isiyojulikana kwa wajaribu wa ndani. Mfumo wa majaribio ya kiotomatiki ulifanya kazi, kwa kweli, lakini baada ya watoa huduma wa nje kuondoka, ilidumu kwa wiki mbili. Ifuatayo ilikuwa jaribio la kutambulisha nambari ya pili ya majaribio. Ilianza na ukweli kwamba kila kitu kinahitaji kujengwa ndani ya kampuni, peke yako (vector sahihi: kujenga utaalamu ndani), ndani ya mfumo wa SCRUM, na kuunda nyaraka katika mchakato. Rafu ya otomatiki inapaswa kuwa sawa na mrundikano wa bidhaa (hapa ninaiongeza, usijaribu mradi wako wa JavaScript na kitu kingine chochote). Mwishoni mwa sprint, walifanya onyesho la jinsi autotest inavyofanya kazi na timu nzima (inayosaidia). Kwa hivyo, ushiriki wa washiriki wote wa timu katika mchakato wa otomatiki uliongezeka, na pia imani katika majaribio ya kiotomatiki na nafasi ya kuwa jaribio hili la kiotomatiki litatumika (na halitatolewa maoni kwa mwezi kwa sababu ya kutofaulu mara kwa mara).
Kwa njia, kwenye DevOpsForum 2019 kulikuwa na kipaza sauti wazi - inayojulikana kwa muda mrefu na, kwa maoni yangu, muundo muhimu wa hotuba. Unazunguka kama hii, sikiliza ripoti, na kisha uamue kwamba kwenye mkutano inafaa kujadili mada au shida fulani, kushiriki uzoefu unaofaa katika kutatua shida.
Pia niliona kwamba waandaaji walifanya mtiririko wa ripoti fupi. Kila ripoti huchukua si zaidi ya dakika 10, ikifuatiwa na maswali. Kwa njia hii unaweza kushughulikia mada nyingi kwa wakati mmoja na kuuliza maswali kwa wazungumzaji wanaokuvutia.
Kati ya mawasilisho, nilizunguka vibanda vya washirika wa mkutano na kuiba/kushinda vitu vingi. Lo, napenda kitini!
Jedwali la pande zote na masuala ya DevOps na mkurugenzi wa maendeleo katika Alfastrakhovanie
Mchujo kwenye keki ya DevOpsForum 2019 kwangu ulikuwa kikao cha jumla cha saa moja na wataalam wa DevOps. Washiriki wanne wa kikao walialikwa kuangalia DevOps kutoka pembe tofauti: Anton Isanin (Alfastrakhovanie, mkurugenzi wa maendeleo), Nailya Zamashkina (Fintech Lab, mkurugenzi wa uendeshaji), Oleg Egorkin (Rostelecom, kocha wa Agile) na Anton Martyanov (mtaalam wa kujitegemea, aliangalia DevOps kutoka kwa mtazamo wa biashara).
Wataalam waliketi karibu na watu na kisha mambo yakaanza kutokea: kwa saa nzima, washiriki kutoka kwa watazamaji waliuliza maswali yao, na wataalam walichukua rap. Wakati fulani kulikuwa na mijadala ya kweli. Maswali yalikuwa tofauti sana, kwa mfano: je wahandisi wa DevOps wanahitajika kabisa, kwa nini hawawezi kufunzwa kama wasimamizi wa mfumo, lazima DevOps itolewe kwa kila mtu, thamani yake ni nini, na kadhalika.
Kisha, nilizungumza na Anton Isanin kibinafsi. Tulijadili hitaji la kuleta utamaduni wa DevOps kwa kila nyumba na tukafichua upande mbaya wa mabadiliko ya DevOps.
Hebu tufikirie kwamba kila mtu alikusanyika na kuamua kuwa DevOps inahitajika na bidhaa na biashara na timu. Twende kuitekeleza. Kila kitu kilifanyika. Tulishusha pumzi. DevOps imetuleta karibu na mteja, sasa tunaweza kutimiza matakwa yake yote haraka. Matokeo yake, tuna idara kubwa ya Ops yenye kanuni kali na mahitaji, na mara kwa mara hupata kasoro katika bidhaa na kuunda rundo la maombi. Zaidi ya hayo, kasoro zote hupewa hali ya "haraka", hata kama mteja bila kutarajia alitaka kupaka kifungo rangi ya njano badala ya kijani. Mradi unakua, idadi ya matoleo inakua na, ipasavyo, idadi ya kasoro na kutokuelewana kwa utendaji mpya na wateja. Ops huajiri watu 10 zaidi ili kuendelea na kasoro za kuripoti, na maendeleo huajiri 15 zaidi ili kuendelea na kuzifunga. Na badala ya kutambulisha vipengele vipya, timu hufanya kazi na SD zisizo na mwisho, kuelezea utendakazi kwa mtumiaji na usaidizi kwa wakati mmoja. Kwa hivyo, Ops na maendeleo vinafanya kazi, lakini mteja na biashara hawana furaha: vipengele vipya vinakwama. Inatokea kwamba DevOps inaonekana kuwepo, lakini haionekani kuwepo.
Kuhusu hitaji la kutekeleza DevOps, Anton alisema wazi kwamba hii inategemea moja kwa moja ukubwa wa biashara. Ikiwa kuhudumia mteja mmoja kwa mwaka huleta kampuni bilioni, DevOps haihitajiki (mradi huhitaji kusambaza mabadiliko mapya kwa mteja huyu mara kwa mara). Kila kitu kimefunikwa na chokoleti. Lakini ikiwa biashara inakua na wateja wengi wanaonekana, basi unahitaji kuzingatia. Kama sheria, hakuna Ops nzuri katika kampuni hapo awali. Kwanza tunapunguza bidhaa, na kisha tu tunaelewa kuwa ili bidhaa ifanye kazi, tunahitaji kuweka macho kwenye seva na kufuatilia vifaa. Hapo ndipo Ops inapotokea. Inabakia kueleweka kuwa Ops, kama mgawanyiko tofauti, itaanza kuweka rundo la vikwazo kwa maendeleo na utoaji wote utaanza kukwama. Hiyo ni, katika kesi hii, utamaduni wa DevOps tayari unafaa, lakini hatupaswi kusahau kuhusu upande wake wa giza.
Chanzo: mapenzi.com