Mnamo Aprili 25, sisi katika Mail.ru Group tulifanya mkutano kuhusu mawingu na karibu - . Vivutio vichache:
- Kuu - Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Kituo cha Data cha Rostelecom na Yandex.Cloud walizungumza kuhusu maalum ya soko letu la wingu na huduma zao;
- Wenzake kutoka Bitrix24 walielezea jinsi walivyo ;
- Leroy Merlin, Otkritie, Burger King na Schneider Electric walitoa kuvutia - ni kazi gani ambazo biashara zao huweka kwa IT na teknolojia gani, pamoja na zile za wingu, wanaona kuwa zenye kuahidi zaidi.
Unaweza kutazama video zote kutoka kwa mailto:CLOUD conference , na hapa unaweza kusoma jinsi mjadala kuhusu huduma ndogo ulivyoenda. Alexander Deulin, mkuu wa kituo cha utafiti na maendeleo cha mifumo ya biashara ya MegaFon, na Sergey Sergeev, mkurugenzi wa teknolojia ya habari wa kikundi cha M.Video-Eldorado, walishiriki kesi zao za mafanikio za kuondokana na monoliths. Pia tulijadili masuala yanayohusiana ya mkakati wa IT, michakato na hata HR.
Wanajopo
- Sergey Sergeev, Kikundi CIO "M.Video-Eldorado";
- Alexander Deulin, mkuu wa kituo cha utafiti na maendeleo ya mifumo ya biashara MegaFon;
- Msimamizi - Dmitry Lazarenko, Mkuu wa mwelekeo wa PaaS Mail.ru Cloud Solutions.
Baada ya hotuba ya Alexander Deulin ameunganishwa kwa majadiliano na Sergey Sergeev kutoka M.Video-Eldorado na msimamizi wa majadiliano Dmitry Lazarenko, Mail.ru Cloud Solutions.
Hapo chini tumekuandalia nakala ya majadiliano, lakini pia unaweza kutazama video:
Mpito kwa huduma ndogo ni jibu kwa mahitaji ya soko
Dmitry:
Je, umekuwa na uzoefu wowote uliofanikiwa wa kuhamia huduma ndogo? Na kwa ujumla: unaona wapi faida kubwa zaidi ya biashara kutoka kwa kutumia huduma ndogo au kuhama kutoka kwa monoliths hadi huduma ndogo?
Sergey:
Tayari tumekuja kwa njia fulani katika mabadiliko ya huduma ndogo na tumekuwa tukitumia njia hii kwa zaidi ya miaka mitatu. Hitaji la kwanza ambalo lilihalalisha hitaji la huduma ndogo ndogo lilikuwa ujumuishaji usio na mwisho wa bidhaa mbali mbali za mbele na ofisi ya nyuma. Na kila wakati tulilazimika kufanya ushirikiano wa ziada na maendeleo, kutekeleza sheria zetu wenyewe kwa uendeshaji wa hii au huduma hiyo.
Wakati fulani, tuligundua kwamba tulihitaji kuharakisha utendakazi wa mifumo yetu na matokeo ya utendakazi. Wakati huo, dhana kama vile huduma ndogo na mbinu ya huduma ndogo tayari zilikuwepo kwenye soko, na tuliamua kujaribu. Hii ilianza mnamo 2016. Kisha jukwaa liliwekwa na huduma 10 za kwanza zilitekelezwa na timu tofauti.
Moja ya huduma za kwanza, zilizojaa sana, ilikuwa huduma ya kuhesabu bei. Kila wakati unapokuja kwenye chaneli yoyote, kwa kikundi cha kampuni za M.Video-Eldorado, iwe tovuti au duka la rejareja, chagua bidhaa hapo, angalia bei kwenye wavuti au kwenye "Kikapu", gharama ni kiotomatiki. kuhesabiwa na huduma moja. Kwa nini hii ni muhimu: kabla ya hii, kila mfumo ulikuwa na kanuni zake za kufanya kazi na matangazo - na punguzo na kadhalika. Ofisi yetu ya nyuma inashughulikia bei; utendaji wa punguzo unatekelezwa katika mfumo mwingine. Hii ilihitaji kuwekwa kati na huduma ya kipekee, inayoweza kutenganishwa iliyoundwa katika mfumo wa mchakato wa biashara ambao ungeturuhusu kutekeleza hili. Ndivyo tulivyoanza.
Thamani ya matokeo ya kwanza ilikuwa kubwa sana. Kwanza, tuliweza kuunda huluki zinazoweza kutenganishwa ambazo huturuhusu kufanya kazi tofauti na kwa njia iliyojumlishwa. Pili, tumepunguza gharama ya umiliki katika suala la ushirikiano na mifumo zaidi.
Katika kipindi cha miaka mitatu iliyopita, tumeongeza mifumo mitatu ya mstari wa mbele. Ilikuwa vigumu kuzidumisha kwa kiasi sawa cha rasilimali ambazo kampuni inaweza kumudu. Kwa hiyo, kazi iliondoka kutafuta maduka mapya, kukabiliana na soko kwa kasi, kwa gharama za ndani na ufanisi.
Jinsi ya kupima mafanikio ya kuhamia microservices
Dmitry:
Je, mafanikio katika kuhamia huduma ndogo huamuliwaje? Ni nini kilikuwa "kabla" katika kila kampuni? Je, ulitumia kipimo gani kubainisha mafanikio ya mabadiliko, na ni nani aliyeamua hasa?
Sergey:
Kwanza kabisa, ilizaliwa ndani ya IT kama kuwezesha - "kufungua" uwezo mpya. Tulikuwa na haja ya kufanya kila kitu haraka kwa pesa sawa, kukabiliana na changamoto za soko. Sasa mafanikio yanaonyeshwa kwa idadi ya huduma zinazotumiwa tena na mifumo tofauti, umoja wa michakato kati yao wenyewe. Sasa ni, lakini wakati huo ilikuwa fursa ya kuunda jukwaa na kuthibitisha hypothesis kwamba tunaweza kufanya hivyo, itatoa athari na kuhesabu kesi ya biashara.
Alexander:
Mafanikio ni hisia ya ndani. Biashara daima inataka zaidi, na kina cha kumbukumbu yetu ni dhibitisho la mafanikio. Inaonekana kwangu hivyo.
Sergey:
Ndiyo, nakubali. Katika kipindi cha miaka mitatu, tayari tuna huduma zaidi ya mia mbili na mrundikano. Haja ya rasilimali ndani ya timu inakua tu - kwa 30% kila mwaka. Hii inatokea kwa sababu watu waliona: ni kasi, ni tofauti, kuna teknolojia tofauti, yote haya yanaendelea.
Microservices zitakuja, lakini msingi utabaki
Dmitry:
Ni kama mchakato usioisha ambapo unawekeza katika maendeleo. Je, mpito kwa huduma ndogo za biashara tayari umekwisha au la?
Sergey:
Ni rahisi sana kujibu. Unafikiria nini: kubadilisha simu ni mchakato usio na mwisho? Sisi wenyewe tunanunua simu kila mwaka. Na hapa ni: kwa muda mrefu kama kuna haja ya kasi, kwa kukabiliana na soko, mabadiliko fulani yatahitajika. Hii haimaanishi kwamba tunaacha mambo ya kawaida.
Lakini hatuwezi kufunika na kufanya kila kitu mara moja. Tuna urithi, huduma za ujumuishaji za kawaida ambazo zilikuwepo hapo awali: mabasi ya biashara na kadhalika. Lakini kuna mlundikano, na pia kuna haja. Idadi ya programu za rununu na utendakazi wao inakua. Wakati huo huo, hakuna mtu anasema kwamba utapewa pesa zaidi ya 30%. Hiyo ni, daima kuna mahitaji kwa upande mmoja, na utafutaji wa ufanisi kwa upande mwingine.
Dmitry:
Maisha ni katika hali nzuri. (Anacheka)
Alexander:
Kwa ujumla, ndiyo. Hatuna mbinu za kimapinduzi za kuondoa sehemu ya msingi kutoka kwa mandhari. Kazi ya kimfumo inaendelea kuoza mifumo ili iweze kuendana zaidi na usanifu wa huduma ndogo, ili kupunguza ushawishi wa mifumo kwa kila mmoja.
Lakini tunapanga kuweka sehemu ya msingi, kwa kuwa katika mazingira ya waendeshaji daima kutakuwa na majukwaa ambayo tunununua. Tena, tunahitaji usawa wa afya: hatupaswi kukimbilia kukata msingi. Tunaweka mifumo kando, na sasa inageuka kuwa tayari tuko juu ya sehemu nyingi za msingi. Zaidi ya hayo, kwa kuendeleza utendakazi, tunaunda uwakilishi unaohitajika kwa njia zote zinazofanya kazi na huduma zetu za mawasiliano.
Jinsi ya kuuza huduma ndogo kwa biashara
Dmitry:
Ninavutiwa pia - kwa wale ambao hawajabadilisha, lakini wanapanga: ilikuwa rahisi kiasi gani kuuza wazo hili kwa biashara na je, ilikuwa tukio, mradi wa uwekezaji? Au ilikuwa mkakati wa kufahamu: sasa tunaenda kwa huduma ndogo na ndivyo hivyo, hakuna kitu kitakachotuzuia. Ilikuwaje kwako?
Sergey:
Hatukuwa tunauza mbinu, lakini faida ya biashara. Kulikuwa na tatizo katika biashara, na tulijaribu kulitatua. Wakati huo, ilionyeshwa kwa ukweli kwamba njia tofauti zilitumia kanuni tofauti za kuhesabu bei - tofauti kwa matangazo, kwa matangazo, na kadhalika. Ilikuwa vigumu kudumisha, makosa yalitokea, na tulisikiliza malalamiko ya wateja. Yaani tulikuwa tunauza suluhu la tatizo, lakini tulikuja na ukweli kwamba tunahitaji pesa kuunda jukwaa. Na walionyesha kesi ya biashara kwa kutumia mfano wa hatua ya kwanza ya uwekezaji: jinsi tutaendelea kurejesha na nini hii itaturuhusu kufanya.
Dmitry:
Je, kwa namna fulani ulirekodi wakati wa hatua ya kwanza?
Sergey:
Ndiyo, hakika. Tulitenga miezi 6 ili kuunda msingi kama jukwaa na kujaribu majaribio. Wakati huu, tulijaribu kuunda jukwaa ambalo tutateleza kwenye rubani. Kisha hypothesis ilithibitishwa, na kwa kuwa inafanya kazi, inamaanisha tunaweza kuendelea. Walianza kuiga na kuimarisha timu - waliihamisha katika mgawanyiko tofauti ambao hufanya hivyo.
Inayofuata inakuja kazi ya kimfumo kulingana na mahitaji ya biashara, fursa, upatikanaji wa rasilimali na kila kitu ambacho kiko kwenye kazi kwa sasa.
Dmitry:
SAWA. Alexander, unasema nini?
Alexander:
Huduma zetu ndogo zilizaliwa kutoka kwa "povu la bahari" - kwa sababu ya kuokoa rasilimali, kwa sababu ya mabaki kadhaa katika mfumo wa uwezo wa seva na ugawaji upya wa vikosi ndani ya timu. Hapo awali, hatukuuza mradi huu kwa biashara. Huu ulikuwa mradi ambapo sote tulitafiti na kuendeleza ipasavyo. Tulianza mwanzoni mwa 2018 na tukaendeleza mwelekeo huu kwa shauku. Uuzaji ndio umeanza na tuko kwenye mchakato.
Dmitry:
Je, hutokea kwamba biashara inakuruhusu kufanya mambo kama vile Google - kwa siku moja bila malipo kwa wiki? Je! una mwelekeo kama huo?
Alexander:
Wakati huo huo kama utafiti, tulishughulikia pia shida za biashara, kwa hivyo huduma zetu zote ndogo ni suluhisho kwa shida za biashara. Mwanzoni tu tulitengeneza huduma ndogo ndogo ambazo zilifunika sehemu ndogo ya msingi wa wasajili, na sasa tupo katika takriban bidhaa zote maarufu.
Na athari ya nyenzo tayari iko wazi - tunaweza tayari kuhesabiwa, kasi ya uzinduzi wa bidhaa na mapato yaliyopotea yanaweza kukadiriwa ikiwa tungefuata njia ya zamani. Hii ndio tunajenga kesi.
Microservices: Hype au umuhimu?
Dmitry:
Nambari ni nambari. Na mapato au pesa zilizohifadhiwa ni muhimu sana. Je, ukiangalia upande wa pili? Inaonekana kwamba microservices ni mwenendo, hype na makampuni mengi yanatumia vibaya? Je, unatofautisha kwa uwazi kiasi gani kati ya kile unachofanya na usichotafsiri kwa huduma ndogo? Ikiwa urithi sasa, bado utakuwa na urithi ndani ya miaka 5? Je, ni umri gani wa mifumo ya taarifa inayofanya kazi katika M.Video-Eldorado na MegaFon katika miaka 5? Je, kutakuwa na mifumo ya habari ya miaka kumi, kumi na tano au itakuwa kizazi kipya? Je, unaonaje hili?
Sergey:
Inaonekana kwangu kuwa ni ngumu kufikiria mbali sana. Tukiangalia nyuma, ni nani aliyefikiria kuwa soko la teknolojia lingekua kwa njia hii, ikijumuisha kujifunza kwa mashine na utambuzi wa mtumiaji kwa uso? Lakini ukiangalia miaka ijayo, inaonekana kwangu kuwa mifumo ya msingi, mifumo ya darasa la ERP katika makampuni - wamekuwa wakifanya kazi kwa muda mrefu sana.
Kampuni zetu kwa pamoja zina umri wa miaka 25, na ERP ya kawaida ya kina sana katika mazingira ya mifumo. Ni wazi kwamba tunachukua vipande kadhaa kutoka hapo na kujaribu kuvikusanya katika huduma ndogo, lakini msingi utabaki. Ni vigumu kwangu sasa kufikiria kwamba tutachukua nafasi ya mifumo yote ya msingi huko na haraka kuhamia upande mwingine, mkali wa mifumo mpya.
Mimi ni mfuasi wa ukweli kwamba kila kitu ambacho kiko karibu zaidi na mteja na mtumiaji ndipo ambapo faida na thamani kubwa zaidi ya biashara iko, ambapo uwezo wa kubadilika na kuzingatia kasi, mabadiliko, "jaribu, ghairi, tumia tena, fanya kitu tofauti" inahitajika "-hapo ndipo mazingira yatabadilika. Na bidhaa za sanduku haziingii huko vizuri sana. Angalau hatuoni. Suluhisho rahisi na rahisi zaidi zinahitajika hapo.
Tunaona maendeleo haya:
- mifumo ya msingi ya habari (hasa ofisi ya nyuma);
- tabaka za kati kwa namna ya microservices huunganisha msingi, jumla, kuunda cache, na kadhalika;
- mifumo ya mstari wa mbele inalenga watumiaji;
- safu ya muunganisho ambayo kwa ujumla imeunganishwa katika soko, mifumo mingine na mifumo ikolojia. Safu hii ni nyepesi iwezekanavyo, rahisi, na ina kiwango cha chini cha mantiki ya biashara.
Lakini wakati huo huo, mimi ni mfuasi wa kuendelea kutumia kanuni za zamani ikiwa zitatumika ipasavyo.
Wacha tuseme una mfumo wa kawaida wa biashara. Iko katika mazingira ya muuzaji mmoja na ina moduli mbili zinazofanya kazi na kila mmoja. Pia kuna kiolesura cha ujumuishaji wa kawaida. Kwa nini uifanye upya na kuleta huduma ndogo huko?
Lakini wakati kuna moduli 5 katika ofisi ya nyuma, ambayo vipande vya habari hukusanywa katika mchakato wa biashara, ambayo hutumiwa na mifumo ya mstari wa mbele 8-10, faida inaonekana mara moja. Unachukua kutoka kwa mifumo mitano ya ofisi ya nyuma na kuunda huduma, iliyotengwa, ambayo inalenga mchakato wa biashara. Fanya huduma kuwa ya hali ya juu kiteknolojia - ili ihifadhi habari na istahimili makosa, na pia inafanya kazi na hati au vyombo vya biashara. Na unaiunganisha kulingana na kanuni moja na bidhaa zote za mstari wa mbele. Walighairi bidhaa ya mstari wa mbele - walizima tu ujumuishaji. Kesho unahitaji kuandika programu ya rununu au kutengeneza tovuti ndogo na kuweka sehemu moja tu katika utendaji - kila kitu ni rahisi: uliikusanya kama mjenzi. Ninaona maendeleo zaidi katika mwelekeo huu - angalau katika nchi yetu.
Alexander:
Sergey alielezea kabisa mbinu yetu, asante. Nitasema tu mahali ambapo hatutaenda - kwa sehemu ya msingi, kwa mada ya malipo ya mtandaoni. Hiyo ni, ukadiriaji na malipo utabaki, kwa kweli, "mkubwa" wa kupuria ambao utaandika pesa kwa uaminifu. Na mfumo huu utaendelea kuthibitishwa na mamlaka zetu za udhibiti. Kila kitu kingine kinachoangalia wateja, kwa kweli, ni huduma ndogo.
Dmitry:
Hapa uthibitisho ni hadithi moja. Pengine msaada zaidi. Ikiwa unatumia kidogo juu ya usaidizi au mfumo hauhitaji usaidizi na marekebisho, ni bora usiiguse. Maelewano ya busara.
Jinsi ya kuendeleza microservices za kuaminika
Dmitry:
Sawa. Lakini bado nina nia. Sasa unasema hadithi ya mafanikio: kila kitu kilikuwa sawa, tukabadilisha huduma ndogo, tukatetea wazo kwa biashara, na kila kitu kilifanyika. Lakini nimesikia hadithi nyingine.
Miaka michache iliyopita, kampuni ya Uswizi ambayo ilikuwa imewekeza miaka miwili katika kutengeneza jukwaa jipya la huduma ndogo kwa benki hatimaye ilifunga mradi huo. Imeanguka kabisa. Mamilioni mengi ya faranga za Uswizi yalitumika, na mwishowe timu ilitawanywa - haikufanya kazi.
Umekuwa na hadithi kama hizo? Kulikuwa na au kulikuwa na ugumu wowote? Kwa mfano, kudumisha microservices na ufuatiliaji pia ni maumivu ya kichwa katika shughuli za uendeshaji wa kampuni. Baada ya yote, idadi ya vipengele huongezeka mara kumi. Unaonaje, kumekuwa na mifano isiyofanikiwa ya uwekezaji hapa? Na unaweza kuwashauri nini watu ili wasipate shida kama hizi?
Alexander:
Mifano ambayo haikufaulu ni pamoja na biashara kubadilisha vipaumbele na kughairi miradi. Wakati katika hatua nzuri ya utayari (kwa kweli, MVP iko tayari), biashara ilisema: "Tuna vipaumbele vipya, tunaendelea na mradi mwingine, na tunafunga huu."
Hatukuwa na mapungufu yoyote ya kimataifa na huduma ndogo. Tunalala kwa amani, tuna zamu ya 24/7 ya wajibu ambayo inahudumia BSS nzima [mfumo wa usaidizi wa biashara].
Na jambo moja zaidi - tunakodisha microservices kulingana na sheria zinazotumika kwa bidhaa za sanduku. Ufunguo wa mafanikio ni kwamba unahitaji, kwanza, kukusanya timu ambayo itatayarisha kikamilifu huduma ndogo kwa uzalishaji. Maendeleo yenyewe ni, kwa masharti, 40%. Zilizosalia ni uchanganuzi, mbinu ya DevSecOps, miunganisho sahihi na usanifu sahihi. Tunalipa kipaumbele maalum kwa kanuni za kujenga maombi salama. Wawakilishi wa usalama wa habari hushiriki katika kila mradi katika hatua ya kupanga usanifu na wakati wa mchakato wa utekelezaji. Pia hudhibiti mifumo ya kuchanganua msimbo kwa udhaifu.
Wacha tuseme tunapeleka huduma zetu zisizo na utaifa - tunazo huko Kubernetes. Hii inaruhusu kila mtu kulala kwa amani kutokana na kuongeza kiotomatiki na kuongeza huduma kiotomatiki, na zamu ya wajibu huchukua matukio.
Katika uwepo mzima wa huduma zetu ndogo, kumekuwa na tukio moja au mbili tu ambazo zimefikia mstari wetu. Sasa hakuna matatizo na uendeshaji. Sisi, bila shaka, hatuna 200, lakini kuhusu microservices 50, lakini hutumiwa katika bidhaa za bendera. Ikiwa wameshindwa, tungekuwa wa kwanza kujua kuhusu hilo.
Microservices na HR
Sergey:
Ninakubaliana na mwenzangu kuhusu uhamisho wa kuunga mkono - kwamba kazi inahitaji kupangwa kwa usahihi. Lakini nitakuambia juu ya shida ambazo, kwa kweli, zipo.
Kwanza, teknolojia ni mpya. Hii ni hype kwa njia nzuri, na kupata mtaalamu ambaye ataelewa na anaweza kuunda hii ni changamoto kubwa. Ushindani wa rasilimali ni wazimu, kwa hivyo wataalam wanastahili uzito wao katika dhahabu.
Pili, pamoja na uundaji wa mandhari fulani na idadi inayoongezeka ya huduma, tatizo la utumiaji upya lazima litatuliwe kila mara. Kama watengenezaji wanapenda kufanya: "Hebu tuandike mambo mengi ya kuvutia hapa sasa ..." Kwa sababu ya hili, mfumo unakua na kupoteza ufanisi wake katika suala la fedha, gharama ya umiliki, na kadhalika. Hiyo ni, ni muhimu kujumuisha utumiaji tena katika usanifu wa mfumo, ujumuishe kwenye ramani ya barabara ya kuanzisha huduma na kuhamisha urithi kwa usanifu mpya.
Shida nyingine - ingawa hii ni nzuri kwa njia yake - ni ushindani wa ndani. "Ah, wavulana wapya wa mitindo wametokea hapa, wanazungumza lugha mpya." Watu, bila shaka, ni tofauti. Kuna wale ambao wamezoea kuandika katika Java, na wale wanaoandika na kutumia Docker na Kubernetes. Hawa ni watu tofauti kabisa, wanazungumza tofauti, hutumia maneno tofauti na wakati mwingine hawaelewani. Uwezo au kutokuwa na uwezo wa kushiriki mazoezi, kubadilishana maarifa, kwa maana hii pia ni shida.
Naam, kuongeza rasilimali. βMkuu, twende! Na sasa tunataka haraka, zaidi. Nini, huwezi? Je, haiwezekani kutoa mara mbili kwa mwaka? Na kwa nini?" Maumivu kama haya ya kukua labda ni ya kawaida kwa vitu vingi, njia nyingi, na unaweza kuhisi.
Kuhusu ufuatiliaji. Inaonekana kwangu kuwa huduma au zana za ufuatiliaji wa viwanda tayari zinajifunza au zinaweza kufanya kazi na Docker na Kubernetes katika hali tofauti, isiyo ya kawaida. Ili, kwa mfano, usiishie na mashine 500 za Java ambazo yote haya yanafanya kazi, ambayo ni, inajumlisha. Lakini bidhaa hizi bado hazina ukomavu, lazima zipitie hili. Mada ni mpya kweli, itaendelea kukuza.
Dmitry:
Ndiyo, inavutia sana. Na hii inatumika kwa HR. Labda mchakato wako wa HR na chapa ya HR umebadilika kidogo kwa miaka hii 3. Ulianza kuajiri watu wengine wenye uwezo tofauti. Na labda kuna faida na hasara zote mbili. Hapo awali, blockchain na sayansi ya data walikuwa hype, na wataalamu ndani yao walikuwa na thamani ya mamilioni. Sasa gharama inapungua, soko linajaa, na kuna hali kama hiyo katika huduma ndogo.
Sergey:
Ndiyo, kabisa.
Alexander:
HR anauliza swali: "Nyati yako ya waridi iko wapi kati ya sehemu ya nyuma na ya mbele?" HR haelewi huduma ndogo ni nini. Tuliwaambia siri na tukawaambia kwamba backend ilifanya kila kitu, na hakuna nyati. Lakini HR inabadilika, inajifunza haraka na kuajiri watu ambao wana maarifa ya kimsingi ya IT.
Maendeleo ya microservices
Dmitry:
Ukiangalia usanifu unaolengwa, huduma ndogo huonekana kama monster kama huyo. Safari yako ilichukua miaka kadhaa. Wengine wana mwaka, wengine miaka mitatu. Je, uliona matatizo yote, usanifu unaolengwa, hakuna kilichobadilika? Kwa mfano, katika kesi ya huduma ndogo, lango na meshes za huduma sasa zinaonekana tena. Ulizitumia hapo mwanzo au ulibadilisha usanifu wenyewe? Je, una changamoto kama hizo?
Sergey:
Tayari tumeandika upya itifaki kadhaa za mawasiliano. Mwanzoni kulikuwa na itifaki moja, sasa tulibadilisha hadi nyingine. Tunaongeza usalama na kuegemea. Tulianza na teknolojia za biashara - Oracle, Mantiki ya Wavuti. Sasa tunahama kutoka kwa bidhaa za kiteknolojia za biashara katika huduma ndogo na kuhamia chanzo wazi au teknolojia iliyo wazi kabisa. Tunaacha hifadhidata na kuhamia kwa kile kinachofanya kazi kwa ufanisi zaidi kwetu katika muundo huu. Hatuhitaji tena teknolojia za Oracle.
Tulianza kwa urahisi kama huduma, bila kufikiria ni kiasi gani tulihitaji kache, tungefanya nini wakati hakukuwa na muunganisho na huduma ndogo, lakini data ilihitajika, nk. Sasa tunatengeneza jukwaa ili usanifu uweze kuelezewa. sio kwa lugha ya huduma, na kwa lugha ya biashara, chukua mantiki ya biashara kwenye ngazi inayofuata tunapoanza kuzungumza kwa maneno. Sasa tumejifunza kuzungumza kwa barua, na ngazi inayofuata ni wakati huduma zitakusanywa katika aina fulani ya jumla, wakati hii tayari ni neno - kwa mfano, kadi ya bidhaa nzima. Imekusanywa kutoka kwa huduma ndogo, lakini ni API iliyojengwa juu ya hii.
Usalama ni muhimu sana. Mara tu unapoanza kupatikana na una huduma ambayo unaweza kupata mambo mengi ya kuvutia, na kwa haraka sana, kwa sekunde iliyogawanyika, basi kuna tamaa ya kuipata kwa njia isiyo salama zaidi. Ili kujiepusha na hili, ilitubidi kubadili mbinu za upimaji na ufuatiliaji. Ilibidi tubadilishe timu, muundo wa usimamizi wa utoaji, CI/CD.
Haya ni mageuzi - kama simu, haraka sana: kwanza kulikuwa na simu za kitufe cha kushinikiza, kisha simu mahiri zilionekana. Tuliandika upya na kuunda upya bidhaa kwa sababu soko lilikuwa na mahitaji tofauti. Hivi ndivyo tunavyobadilika: daraja la kwanza, daraja la kumi, kazi.
Mara kwa mara, kitu kinawekwa kwa mwaka kutoka kwa mtazamo wa teknolojia, kitu kingine kutoka kwa mtazamo wa backlog na mahitaji. Tunaunganisha kitu kimoja hadi kingine. Timu hutumia 20% kwa deni la kiufundi na msaada wa kiufundi kwa timu, 80% kwa shirika la biashara. Na tunasonga kwa kuelewa kwa nini tunafanya hivyo, kwa nini tunafanya maboresho haya ya kiteknolojia, yatasababisha nini. Kama hivyo.
Dmitry:
Baridi. Ni nini kwenye MegaFon?
Alexander:
Changamoto kuu tulipokuja kwa huduma ndogo ndogo haikuwa kuanguka kwenye machafuko. Ofisi ya usanifu wa MegaFon mara moja ilijiunga nasi, hata ikawa mwanzilishi na dereva - sasa tuna usanifu wenye nguvu sana. Kazi yake ilikuwa kuelewa ni mtindo gani tunaenda na ni teknolojia gani zinahitaji kufanyiwa majaribio. Kwa usanifu, tuliendesha marubani hawa wenyewe.
Swali lililofuata lilikuwa: "Basi jinsi ya kutumia haya yote?" Na moja zaidi: "Jinsi ya kuhakikisha mwingiliano wa uwazi kati ya huduma ndogo?" Mesh ya huduma ilitusaidia kujibu swali la mwisho. Tulijaribu Istio na tukapenda matokeo. Sasa tuko kwenye hatua ya kusambaa katika maeneo yenye tija. Tuna mtazamo chanya kuelekea changamoto zote - ukweli kwamba tunahitaji mara kwa mara kubadilisha stack, kujifunza kitu kipya. Tuna nia ya kuendeleza, si kutumia ufumbuzi wa zamani.
Dmitry:
Maneno ya dhahabu! Changamoto kama hizo huweka timu na biashara kwenye vidole vyao na kuunda siku zijazo. GDPR iliunda maafisa wakuu wa ulinzi wa data, na changamoto za sasa huunda huduma ndogo ndogo na maafisa wa usanifu. Na inapendeza.
Tulijadili sana. Jambo kuu ni kwamba kubuni nzuri ya microservices na usanifu yenyewe inakuwezesha kuepuka makosa mengi. Kwa kweli, mchakato huo ni wa kurudia na wa mageuzi, lakini ni siku zijazo.
Asante kwa washiriki wote, shukrani kwa Sergei na Alexander!
Maswali kutoka kwa hadhira
Swali kutoka kwa hadhira (1):
Sergey, usimamizi wa IT umebadilikaje katika kampuni yako? Ninaelewa kuwa kunapokuwa na rundo kubwa la mifumo kadhaa, jinsi inavyosimamiwa ni mchakato wazi na wenye mantiki. Ulijengaje upya usimamizi wa sehemu ya TEHAMA baada ya idadi kubwa sana ya huduma ndogo kuunganishwa kwa muda mfupi?
Sergey:
Nakubaliana na mwenzangu kuwa usanifu ni muhimu sana kama kichochezi cha mabadiliko. Tulianza kwa kuwa na kitengo cha usanifu. Wasanifu ni wakati huo huo wamiliki wa usambazaji wa utendaji na mahitaji ya jinsi itaonekana katika mazingira. Kwa hivyo pia hufanya kama waratibu wa mabadiliko haya. Kwa hivyo, kulikuwa na mabadiliko mahususi kwa mchakato mahususi wa uwasilishaji tulipounda jukwaa la CI/CD.
Lakini kiwango, kanuni za msingi za maendeleo, uchambuzi wa biashara, upimaji na maendeleo hazijafutwa. Tumeongeza kasi tu. Hapo awali, mzunguko ulichukua sana, ufungaji kwenye mazingira ya mtihani ulichukua mengi zaidi. Sasa biashara inaona manufaa na kusema: βKwa nini hatuwezi kufanya vivyo hivyo katika maeneo mengine?β
Ni kama, kwa njia nzuri, sindano kwa namna ya chanjo iliyoonyesha: unaweza kufanya hivyo kwa njia hii, lakini unaweza kufanya hivyo kwa njia nyingine. Bila shaka, kuna tatizo katika wafanyakazi, katika uwezo, katika ujuzi, katika upinzani.
Swali kutoka kwa hadhira (2):
Wakosoaji wa usanifu wa microservice wanasema kwamba kupima na maendeleo ni vigumu. Hii ni mantiki ambapo mambo yanakuwa magumu. Je, timu yako ilikumbana na changamoto gani na umezishinda vipi? Swali kwa kila mtu.
Alexander:
Kuna shida wakati wa kuhama kutoka kwa huduma ndogo hadi jukwaa, lakini zinaweza kutatuliwa.
Kwa mfano, tunatengeneza bidhaa ambayo inajumuisha huduma ndogo 5-7. Tunahitaji kutoa majaribio ya ujumuishaji kwenye rafu nzima ya huduma ndogo ili kutoa mwanga wa kijani kuhamia kwenye tawi kuu. Jukumu hili halikuwa geni kwetu: tulikuwa tukifanya hivi kwa muda mrefu katika BSS, wakati mchuuzi alipotupa suluhu zilizosafirishwa tayari.
Na shida yetu iko kwenye timu ndogo tu. Mhandisi mmoja wa QA anahitajika kwa bidhaa moja ya masharti. Na hivyo, tunasafirisha bidhaa ya microservices 5-7, ambayo 2-3 inaweza kuendelezwa na watu wa tatu. Kwa mfano, tuna bidhaa katika uundaji ambayo muuzaji wetu wa mfumo wa bili, Mail.ru Group na MegaFon R&D hushiriki. Tunahitaji kulishughulikia hili kwa majaribio kabla ya kuisafirisha hadi kwa toleo la umma. Mhandisi wa QA amekuwa akifanya kazi kwenye bidhaa hii kwa mwezi mmoja na nusu, na timu iliyobaki imesalia bila msaada wake.
Ugumu huu unasababishwa tu na kuongeza. Tunaelewa kuwa huduma ndogo haziwezi kuwepo katika ombwe; kutengwa kabisa hakuna. Tunapobadilisha huduma moja, tunajaribu kuhifadhi mkataba wa API kila wakati. Ikiwa kitu kinabadilika chini ya kofia, sehemu ya mbele ya huduma inabaki. Ikiwa mabadiliko ni mbaya, aina fulani ya mabadiliko ya usanifu hufanyika na tunahamia metamodel tofauti kabisa ya data, ambayo haikubaliani kabisa - basi tu tunazungumzia kuhusu vipimo vya API ya huduma ya v2 inayoonekana. Tunasaidia matoleo ya kwanza na ya pili wakati huo huo, na baada ya watumiaji wote kubadili toleo la pili, tunafunga tu la kwanza.
Sergey:
Nataka kuongeza. Ninakubali kabisa juu ya shida - zinatokea. Mazingira yanazidi kuwa magumu, na gharama za ziada zinaongezeka, haswa kwa majaribio. Jinsi ya kukabiliana na hili: badilisha kwa kupima otomatiki. Ndio, itabidi uwekeze zaidi katika kuandika majaribio ya kiotomatiki na majaribio ya kitengo. Ili watengenezaji wasingeweza kufanya bila kupita jaribio, hawakuweza kubadilisha nambari. Ili hata kifungo cha kushinikiza haifanyi kazi bila autotest, mtihani wa kitengo.
Ni muhimu kudumisha utendaji uliopita, na hii ni ziada ya ziada. Ukiandika tena teknolojia kwa itifaki nyingine, kisha uiandikie tena hadi ufunge kila kitu kabisa.
Wakati mwingine hatufanyi majaribio ya mwisho hadi mwisho kwa makusudi, kwa sababu hatutaki kukomesha maendeleo, ingawa pia tuna jambo moja baada ya jingine. Mazingira ni makubwa sana, magumu, kuna mifumo mingi. Wakati mwingine ni vijiti tu - ndio, unapunguza ukingo wa usalama, hatari zaidi huonekana. Lakini wakati huo huo unatoa usambazaji.
Alexander:
Ndiyo, majaribio ya kiotomatiki na vipimo vya kitengo hukuruhusu kuunda huduma ya ubora wa juu. Tuko kwa bomba ambalo haliwezi kupitishwa bila vipimo vya kitengo na ujumuishaji. Mara nyingi tunalazimika kuburuta viigizaji na mifumo ya kibiashara kwenye maeneo ya majaribio na mazingira ya usanidi, kwa sababu si mifumo yote inayoweza kuwekwa katika maeneo ya majaribio. Zaidi ya hayo, haziloweshi tu - tunatoa majibu kamili kutoka kwa mfumo. Hii ni sehemu kubwa ya kufanya kazi na huduma ndogo, na pia tunawekeza ndani yake. Bila hii, machafuko yatatokea.
Swali kutoka kwa hadhira (3):
Kwa kadiri ninavyoelewa, huduma ndogo ndogo hapo awali zilikua kutoka kwa timu tofauti na sasa zipo katika mfano huu. Je, faida na hasara zake ni zipi?
Tuna hadithi kama hiyo: aina ya kiwanda cha huduma ndogo iliibuka. Sasa tumefikia mahali kwamba tunapanua mbinu hii ya uzalishaji kwa mitiririko na mifumo. Kwa maneno mengine, tunaenda mbali na ukuzaji wa kati wa huduma ndogo, miundo ya huduma ndogo, na tunakaribia mifumo.
Ipasavyo, operesheni yetu pia huenda kwa mifumo, ambayo ni, tunagawa mada hii. Mtazamo wako ni upi na hadithi unayolenga ni ipi?
Alexander:
Umetupa jina la "kiwanda cha huduma ndogo" moja kwa moja kutoka kwa mdomo wako - pia tunataka kuongeza. Kwanza, tuna timu moja sasa. Tunataka kuzipa timu zote za maendeleo ambazo MegaFon inayo fursa ya kufanya kazi katika mfumo ikolojia wa pamoja. Hatutaki kuchukua kabisa utendakazi wote wa maendeleo ambao tunao sasa. Kazi ya ndani ni kuongeza, kazi ya kimataifa ni kuongoza maendeleo kwa timu zote kwenye safu ya huduma ndogo.
Sergey:
Nitakuambia njia ambayo tumepita. Kwa kweli tulianza kufanya kazi kama timu moja, lakini sasa hatuko peke yetu. Mimi ni mtetezi wa yafuatayo: lazima kuwe na mmiliki wa mchakato. Mtu anahitaji kuelewa, kudhibiti, kudhibiti na kujenga mchakato wa ukuzaji wa huduma ndogo. Lazima amiliki rasilimali na ashiriki katika usimamizi wa rasilimali.
Rasilimali hizi, wanaojua teknolojia, maalum na kuelewa jinsi ya kuunda huduma ndogo, zinaweza kupatikana katika timu za bidhaa. Tuna mchanganyiko ambapo watu kutoka kwa jukwaa la huduma ndogo wako kwenye timu ya bidhaa inayounda programu ya simu. Wapo, lakini wanafanya kazi kulingana na mchakato wa idara ya usimamizi wa jukwaa la huduma ndogo na msimamizi wao wa maendeleo. Ndani ya kitengo hiki kuna timu tofauti inayohusika na teknolojia. Hiyo ni, tunachanganya rasilimali ya kawaida kati yetu na kuigawanya, kuwapa timu.
Wakati huo huo, mchakato unabakia kwa ujumla, kudhibitiwa, unaendelea kulingana na kanuni za teknolojia ya jumla, na kupima kitengo na kadhalika - kila kitu kilichojengwa juu. Kunaweza kuwa na safu katika mfumo wa rasilimali zilizokusanywa kutoka kwa idara tofauti za mbinu ya bidhaa.
Alexander:
Sergey, wewe ndiye mmiliki wa mchakato huo, sivyo? Je, kumbukumbu ya kazi imeshirikiwa? Nani anawajibika kwa usambazaji wake?
Sergey:
Angalia: hapa kuna mchanganyiko tena. Kuna backlog ambayo inaundwa kulingana na maboresho ya teknolojia - hii ni hadithi moja. Kuna mrundikano, ambao umeundwa kutoka kwa miradi, na kuna mlundikano kutoka kwa bidhaa. Lakini mlolongo wa kuanzishwa kwa kila bidhaa za huduma au kuundwa kwa huduma hii hutengenezwa na mtaalamu wa bidhaa. Hayuko katika kurugenzi ya IT; aliondolewa haswa kutoka kwayo. Lakini watu wangu hakika hufanya kazi kulingana na mchakato huo huo.
Mmiliki wa backlog katika mwelekeo tofauti - backlog ya mabadiliko - watakuwa watu tofauti. Uunganisho wa huduma za teknolojia, kanuni yao ya kuandaa - yote haya yatakuwa katika IT. Ninamiliki jukwaa na rasilimali pia. Juu ni nini kinahusu mabadiliko ya nyuma na kazi, na usanifu kwa maana hii.
Wacha tuseme biashara inasema: "Tunataka kazi hii, tunataka kuunda bidhaa mpya - rejesha mkopo." Tunajibu: "Ndio, tutafanya upya." Wasanifu wa majengo wanasema: "Hebu tufikirie: ni wapi katika mkopo tutaandika huduma ndogo na tutafanyaje?" Kisha tunaigawanya katika miradi, bidhaa au mkusanyiko wa teknolojia, kuiweka katika timu na kuitekeleza. Je, umeunda bidhaa ndani na ukaamua kutumia huduma ndogo katika bidhaa hii? Tunasema: "Sasa mifumo ya urithi tuliyokuwa nayo, au mifumo ya mstari wa mbele, lazima ibadilishe hadi huduma hizi ndogo." Wasanifu wanasema: "Kwa hivyo: katika kumbukumbu ya kiteknolojia ndani ya bidhaa za mstari wa mbele - mpito kwa huduma ndogo. Nenda". Na wataalam wa bidhaa au wamiliki wa biashara wanaelewa ni kiasi gani cha uwezo kilichotengwa, wakati kitafanyika na kwa nini.
Mwisho wa mjadala, lakini sio wote
Kongamano la mailto:CLOUD liliandaliwa .
Pia tunafanya matukio mengine - k.m. @Kubernetes Meetup, ambapo huwa tunatafuta wasemaji bora:
- Fuata @Kubernetes na habari zingine za @Meetup katika chaneli yetu ya Telegraph
- Je, ungependa kuzungumza katika mojawapo ya @Meetups? Acha ombi
Chanzo: mapenzi.com