Hi!
Jina langu ni Mikhail, mimi ni Naibu Mkurugenzi wa IT katika kampuni ya Sportmaster. Nataka kushiriki hadithi ya jinsi tulivyokabiliana na changamoto zilizotokea wakati wa janga.
Katika siku za kwanza za hali halisi mpya, muundo wa kawaida wa biashara ya nje ya mtandao wa Sportmaster ulisitishwa, na mzigo kwenye chaneli yetu ya mtandaoni, hasa katika suala la uwasilishaji kwa anwani ya mteja, uliongezeka mara 10. Katika wiki chache tu, tulibadilisha biashara kubwa ya nje ya mtandao kuwa ya mtandaoni na kurekebisha huduma kulingana na mahitaji ya wateja wetu.
Kimsingi, kile ambacho kilikuwa operesheni yetu ya upande ikawa biashara yetu kuu. Umuhimu wa kila agizo la mtandaoni umeongezeka sana. Ilikuwa ni lazima kuokoa kila ruble ambayo mteja alileta kwa kampuni.
Ili kujibu maombi ya wateja haraka, tulifungua kituo cha ziada cha mawasiliano katika ofisi kuu ya kampuni, na sasa tunaweza kupokea simu zipatazo 285 kwa wiki. Wakati huo huo, tulihamisha maduka 270 hadi kwa muundo mpya wa uendeshaji usio na kiwasiliani na salama, ambao uliwaruhusu wateja kupokea maagizo na wafanyakazi kudumisha kazi zao.
Wakati wa mchakato wa mabadiliko, tulikutana na shida kuu mbili. Kwanza, mzigo kwenye rasilimali zetu za mtandaoni umeongezeka kwa kiasi kikubwa (Sergey atakuambia jinsi tulivyoshughulikia hili). Pili, mtiririko wa shughuli adimu (kabla ya COVID) umeongezeka mara nyingi zaidi, ambayo kwa upande wake ilihitaji kiasi kikubwa cha otomatiki ya haraka. Ili kutatua tatizo hili, tulilazimika kuhamisha rasilimali haraka kutoka kwa maeneo ambayo hapo awali yalikuwa ndio kuu. Elena atakuambia jinsi tulivyoshughulikia hili.
Uendeshaji wa huduma za mtandaoni
Kolesnikov Sergey, anayehusika na uendeshaji wa duka la mtandaoni na microservices
Kuanzia wakati maduka yetu ya rejareja yalipoanza kukaribia wageni, tulianza kurekodi ongezeko la vipimo kama vile idadi ya watumiaji, idadi ya maagizo yaliyowekwa kwenye programu yetu, na idadi ya maombi kwa programu.
Idadi ya maagizo kutoka Machi 18 hadi Machi 31Idadi ya maombi kwa huduma ndogo za malipo mtandaoniIdadi ya maagizo yaliyowekwa kwenye tovuti
Katika grafu ya kwanza tunaona kwamba ongezeko lilikuwa takriban mara 14, kwa pili - mara 4. Tunazingatia kipimo cha muda wa majibu cha programu zetu kuwa kiashiria zaidi.
Katika grafu hii tunaona majibu ya pande na maombi, na sisi wenyewe tuliamua kwamba hatukugundua ukuaji wowote kama huo.
Hii ni kwa sababu ya ukweli kwamba tulianza kazi ya maandalizi mwishoni mwa 2019. Sasa huduma zetu zimehifadhiwa, uvumilivu wa makosa unahakikishwa katika kiwango cha seva za kimwili, mifumo ya virtualization, dockers, na huduma ndani yao. Wakati huo huo, uwezo wa rasilimali zetu za seva hutuwezesha kuhimili mizigo mingi.
Chombo kikuu kilichotusaidia katika hadithi hii yote ilikuwa mfumo wetu wa ufuatiliaji. Kweli, hadi hivi majuzi hatukuwa na mfumo mmoja ambao ungeturuhusu kukusanya metrics katika tabaka zote, kutoka kwa kiwango cha vifaa vya kimwili na vifaa hadi kiwango cha metrics ya biashara.
Hapo awali, kulikuwa na ufuatiliaji katika kampuni, lakini kama sheria ilitawanywa na ilikuwa katika eneo la uwajibikaji wa idara maalum. Kwa kweli, tukio lilipotokea, karibu hatukuwahi kuwa na uelewa wa kawaida wa kile kilichotokea, hakukuwa na mawasiliano, na mara nyingi hii ilisababisha kukimbia kwenye miduara kutafuta na kutenganisha tatizo ili liweze kurekebishwa.
Wakati fulani, tulifikiri na kuamua kwamba tulikuwa na kutosha kwa kuvumilia hili - tulihitaji mfumo wa umoja ili kuona picha nzima kwa ukamilifu. Teknolojia kuu ambazo zimejumuishwa kwenye mrundikano wetu ni Zabbix kama kituo cha arifa na uhifadhi wa vipimo, Prometheus ya kukusanya na kuhifadhi vipimo vya programu, Stack ELK ya kukata na kuhifadhi data kutoka kwa mfumo mzima wa ufuatiliaji, pamoja na Grafana kwa taswira, Swagger, Docker. na vitu vingine muhimu na ambavyo unavifahamu.
Wakati huo huo, hatutumii tu teknolojia zinazopatikana kwenye soko, lakini pia kuendeleza baadhi yetu wenyewe. Kwa mfano, tunatengeneza huduma za kuunganisha mifumo baina ya nyingine, yaani, aina fulani ya API ya kukusanya vipimo. Pia tunafanyia kazi mifumo yetu ya ufuatiliaji - katika kiwango cha vipimo vya biashara tunatumia majaribio ya UI. Na pia roboti katika Telegraph ili kuziarifu timu.
Pia tunajaribu kufanya mfumo wa ufuatiliaji ufikiwe na timu ili ziweze kuhifadhi na kufanya kazi kwa kujitegemea na vipimo vyao, ikiwa ni pamoja na kuweka arifa za baadhi ya vipimo finyu ambavyo havitumiwi sana.
Katika mfumo mzima, tunajitahidi kufanya shughuli na ujanibishaji wa matukio haraka iwezekanavyo. Kwa kuongezea, idadi ya huduma ndogo na mifumo yetu imeongezeka sana hivi karibuni, na idadi ya miunganisho imeongezeka ipasavyo. Na kama sehemu ya kuboresha mchakato wa kugundua matukio katika kiwango cha ujumuishaji, tunatengeneza mfumo unaokuruhusu kufanya ukaguzi wa mfumo wa msalaba na kuonyesha matokeo, ambayo hukuruhusu kupata shida kuu zinazohusiana na uagizaji na mwingiliano wa mifumo na. kila mmoja.
Bila shaka, bado tuna nafasi ya kukua na kuendeleza katika suala la mifumo ya uendeshaji, na tunashughulikia hili kikamilifu. Unaweza kusoma zaidi kuhusu mfumo wetu wa ufuatiliaji .
Vipimo vya kiufundi
Orlov Sergey, anaongoza kituo cha umahiri kwa maendeleo ya wavuti na rununu
Tangu kufungwa kwa duka halisi kuanza, tumekabiliana na changamoto mbalimbali kutoka kwa mtazamo wa maendeleo. Kwanza kabisa, mzigo unaongezeka kama hivyo. Ni wazi kwamba ikiwa hatua zinazofaa hazitachukuliwa, basi wakati mzigo mkubwa unatumiwa kwenye mfumo, unaweza kugeuka kuwa malenge na bang huzuni, au kuharibu kabisa utendaji, au hata kupoteza utendaji wake.
Kipengele cha pili, kidogo kidogo, ni kwamba mfumo chini ya mzigo mkubwa ulipaswa kubadilishwa haraka sana, kukabiliana na mabadiliko katika michakato ya biashara. Wakati mwingine mara kadhaa kwa siku. Makampuni mengi yana sheria kwamba ikiwa kuna shughuli nyingi za uuzaji, hakuna haja ya kufanya mabadiliko yoyote kwenye mfumo. Hakuna hata kidogo, wacha ifanye kazi mradi tu inafanya kazi.
Na kimsingi tulikuwa na Ijumaa Nyeusi isiyo na mwisho, ambayo ilikuwa muhimu kubadili mfumo. Na hitilafu yoyote, tatizo, au kushindwa katika mfumo itakuwa ghali sana kwa biashara.
Kuangalia mbele, nitasema kwamba tuliweza kukabiliana na majaribio haya, mifumo yote ilihimili mzigo, ilipunguzwa kwa urahisi, na hatukupata mapungufu yoyote ya kiufundi ya kimataifa.
Kuna nguzo nne ambazo uwezo wa mfumo wa kuhimili mizigo ya juu ya kuongezeka hutegemea. Wa kwanza wao ni ufuatiliaji, ambao umesoma juu yake hapo juu. Bila mfumo wa ufuatiliaji uliojengwa, karibu haiwezekani kupata vikwazo vya mfumo. Mfumo mzuri wa ufuatiliaji ni kama nguo za nyumbani; unapaswa kuwa wa kustarehesha na kukufaa.
Kipengele cha pili ni kupima. Tunachukua hatua hii kwa uzito sana: tunaandika vitengo vya kawaida, vipimo vya ujumuishaji, vipimo vya mzigo na vingine vingi kwa kila mfumo. Pia tunaandika mkakati wa majaribio, na wakati huo huo tunajaribu kuongeza kiwango cha majaribio hadi hatuhitaji tena ukaguzi wa mikono.
Nguzo ya tatu ni CI/CD Pipeline. Michakato ya kujenga, kupima, na kupeleka maombi inapaswa kuwa ya kiotomatiki iwezekanavyo; kusiwe na uingiliaji kati wa mikono. Mada ya Bomba la CI/CD ni ya kina kabisa, na nitaigusia kwa ufupi tu. Inafaa kutaja tu kwamba tuna orodha ya ukaguzi ya CI/CD Bomba, ambayo kila timu ya bidhaa hupitia kwa usaidizi wa vituo vya umahiri.
Na hapa kuna orodha
Kwa njia hii, malengo mengi yanafikiwa. Hili ni toleo la API na ugeuzaji wa vipengele ili kuepuka treni ya kutolewa, na kufikia uwasilishaji wa majaribio mbalimbali kwa kiwango ambacho majaribio yanajiendesha kiotomatiki kikamilifu, utumaji haujafumwa, na kadhalika.
Nguzo ya nne ni kanuni za usanifu na ufumbuzi wa kiufundi. Tunaweza kuzungumza mengi juu ya usanifu kwa muda mrefu, lakini nataka kusisitiza kanuni kadhaa ambazo ningependa kuzingatia.
Kwanza, unahitaji kuchagua zana maalum kwa kazi maalum. Ndiyo, inaonekana wazi, na ni wazi kwamba misumari inapaswa kupigwa kwa nyundo, na saa za mikono zinapaswa kuunganishwa na screwdrivers maalum. Lakini katika enzi yetu, zana nyingi hujitahidi kwa ulimwengu wote ili kufunika sehemu ya juu ya watumiaji: hifadhidata, kache, mifumo na zingine. Kwa mfano, ukichukua hifadhidata ya MongoDB, inafanya kazi na shughuli za hati nyingi, na hifadhidata ya Oracle inafanya kazi na json. Na inaweza kuonekana kuwa kila kitu kinaweza kutumika kwa kila kitu. Lakini ikiwa tunasimama kwa tija, basi tunahitaji kuelewa kwa uwazi nguvu na udhaifu wa kila chombo na kutumia zile tunazohitaji kwa darasa letu la kazi.
Pili, wakati wa kubuni mifumo, kila ongezeko la ugumu lazima liwe na haki. Lazima tukumbuke hili kila wakati; kanuni ya uunganishaji mdogo inajulikana kwa kila mtu. Ninaamini kwamba inapaswa kutumika kwa kiwango cha huduma maalum, na kwa kiwango cha mfumo mzima, na kwa kiwango cha mazingira ya usanifu. Uwezo wa kupima kwa usawa kila sehemu ya mfumo kwenye njia ya mzigo pia ni muhimu. Ikiwa una uwezo huu, kuongeza haitakuwa vigumu.
Akizungumza juu ya ufumbuzi wa kiufundi, tuliuliza timu za bidhaa kuandaa seti mpya ya mapendekezo, mawazo na ufumbuzi, ambayo walitekeleza katika maandalizi ya wimbi linalofuata la mzigo wa kazi.
Keshi
Ni muhimu kukaribia kwa uangalifu uchaguzi wa cache za ndani na zilizosambazwa. Wakati mwingine inaleta maana kutumia zote mbili ndani ya mfumo mmoja. Kwa mfano, tuna mifumo ambayo baadhi ya data kimsingi ni akiba ya onyesho, yaani, chanzo cha masasisho kiko nyuma ya mfumo wenyewe, na mifumo haibadiliki. data hii. Kwa njia hii tunatumia Cache ya Caffeine ya ndani.
Na kuna data ambayo mfumo hubadilika kikamilifu wakati wa operesheni, na hapa tayari tunatumia cache iliyosambazwa na Hazelcast. Mbinu hii huturuhusu kutumia manufaa ya akiba iliyosambazwa ambapo zinahitajika, na kupunguza gharama za huduma za kusambaza data ya nguzo ya Hazelcast ambapo tunaweza kufanya bila hiyo. Tumeandika mengi kuhusu kache. ΠΈ .
Kwa kuongezea, kubadilisha serializer hadi Kryo huko Hazelcast kulitupa nguvu nzuri. Na mabadiliko kutoka ReplicatedMap hadi IMap + Near Cache katika Hazelcast ilituruhusu kupunguza uhamishaji wa data kwenye nguzo.
Ushauri mdogo: katika kesi ya kubatilishwa kwa cache ya wingi, mbinu ya kuongeza joto kwenye cache ya pili na kisha kuibadilisha wakati mwingine inatumika. Inaweza kuonekana kuwa kwa njia hii tunapaswa kupata matumizi ya kumbukumbu mara mbili, lakini kwa mazoezi, katika mifumo hiyo ambapo hii ilifanyika, matumizi ya kumbukumbu yalipungua.
Rafu tendaji
Tunatumia rafu tendaji katika idadi kubwa ya mifumo. Kwa upande wetu, hii ni Webflux au Kotlin na coroutines. Rafu tendaji ni nzuri haswa ambapo tunatarajia utendakazi wa polepole wa pato. Kwa mfano, wito kwa huduma za polepole, kufanya kazi na mfumo wa faili au mifumo ya kuhifadhi.
Kanuni muhimu zaidi ni kuepuka kuzuia simu. Mifumo tendaji ina idadi ndogo ya nyuzi za huduma za moja kwa moja zinazoendesha chini ya kofia. Ikiwa tutajiruhusu bila uangalifu kupiga simu ya moja kwa moja ya kuzuia, kama vile simu ya kiendeshaji ya JDBC, mfumo utasimama tu.
Jaribu kugeuza makosa kuwa ubaguzi wako wa wakati wa kukimbia. Mtiririko halisi wa utekelezaji wa programu hubadilika hadi mifumo tendaji, na utekelezaji wa msimbo unakuwa usio na mstari. Matokeo yake, ni vigumu sana kutambua matatizo kwa kutumia ufuatiliaji wa stack. Na suluhisho hapa litakuwa kuunda vighairi wazi vya wakati wa kukimbia kwa kila kosa.
Elasticsearch
Unapotumia Elasticsearch, usichague data ambayo haijatumiwa. Hii, kwa kanuni, pia ni ushauri rahisi sana, lakini mara nyingi hii ndio imesahaulika. Iwapo unahitaji kuchagua zaidi ya rekodi elfu 10 kwa wakati mmoja, unahitaji kutumia Tembeza. Ili kutumia mlinganisho, ni kidogo kama kishale katika hifadhidata ya uhusiano.
Usitumie kichujio cha posta isipokuwa lazima. Na data kubwa katika sampuli kuu, operesheni hii hupakia hifadhidata sana.
Tumia shughuli nyingi inapohitajika.
API
Wakati wa kuunda API, jumuisha mahitaji ya kupunguza data inayotumwa. Hii ni kweli hasa kuhusiana na mbele: ni katika makutano haya tunapita zaidi ya njia za vituo vyetu vya data na tayari tunafanya kazi kwenye kituo kinachotuunganisha na mteja. Ikiwa ina shida kidogo, trafiki nyingi husababisha uzoefu mbaya wa mtumiaji.
Na hatimaye, usitupe kundi zima la data, kuwa wazi kuhusu mkataba kati ya watumiaji na wauzaji.
Mabadiliko ya shirika
Eroshkina Elena, Naibu Mkurugenzi wa IT
Wakati uwekaji karantini ulipotokea, na hitaji likatokea la kuongeza kasi ya ukuzaji mtandaoni na kuanzisha huduma za vituo vyote, tayari tulikuwa katika mchakato wa mabadiliko ya shirika.
Sehemu ya muundo wetu ilihamishwa kufanya kazi kulingana na kanuni na mazoea ya mbinu ya bidhaa. Timu zimeundwa ambazo sasa zinawajibika kwa uendeshaji na ukuzaji wa kila bidhaa. Wafanyikazi katika timu kama hizi wanahusika kwa 100% na kuunda kazi zao kwa kutumia Scrum au Kanban, kulingana na kile kinachofaa kwao, kuweka bomba la kusambaza, kutekeleza mazoea ya kiufundi, mazoea ya uhakikisho wa ubora, na mengi zaidi.
Kwa bahati nzuri, idadi kubwa ya timu za bidhaa zetu zilikuwa katika eneo la huduma za mtandaoni na vituo vyote. Hii ilituruhusu kubadili hali ya kazi ya mbali kwa muda mfupi iwezekanavyo (umakini, halisi katika siku mbili) bila kupoteza ufanisi. Mchakato uliobinafsishwa ulituruhusu kuzoea haraka hali mpya za kufanya kazi na kudumisha kasi ya juu ya utoaji wa utendakazi mpya.
Kwa kuongeza, tuna haja ya kuimarisha timu hizo ambazo ziko kwenye mipaka ya biashara ya mtandaoni. Wakati huo ikawa wazi kwamba tunaweza tu kufanya hivyo kwa kutumia rasilimali za ndani. Na takriban watu 50 katika wiki mbili walibadilisha eneo ambalo walifanya kazi hapo awali na kujihusisha katika kutengeneza bidhaa ambayo ilikuwa mpya kwao.
Hili halikuhitaji juhudi zozote maalum za usimamizi, kwa sababu pamoja na kuandaa mchakato wetu wenyewe, uboreshaji wa kiufundi wa bidhaa, na mbinu za uhakikisho wa ubora, tunafundisha timu zetu kujipanga - kusimamia mchakato wao wa uzalishaji bila kuhusisha rasilimali za usimamizi.
Tuliweza kulenga rasilimali zetu za usimamizi haswa mahali zilipohitajika wakati huo - katika kuratibu pamoja na biashara: Ni nini muhimu kwa mteja wetu kwa sasa, ni utendakazi gani unapaswa kutekelezwa kwanza, nini kifanyike ili kuongeza uwezo wetu wa kusambaza. kutoa na kushughulikia maagizo. Yote haya na mfano wa kuigwa ulio wazi ulifanya iwezekane katika kipindi hiki kupakia mitiririko yetu ya thamani ya uzalishaji na kile ambacho ni muhimu na muhimu sana.
Ni wazi kwamba kwa kazi ya mbali na kasi ya juu ya mabadiliko, wakati viashiria vya biashara hutegemea ushiriki wa kila mtu, huwezi kutegemea tu hisia za ndani kutoka kwa mfululizo "Je, kila kitu kinaendelea vizuri na sisi? Ndiyo, inaonekana ni nzuri." Vipimo vya lengo la mchakato wa uzalishaji vinahitajika. Tunayo haya, yanapatikana kwa mtu yeyote anayevutiwa na vipimo vya timu za bidhaa. Kwanza kabisa, timu yenyewe, biashara, wakandarasi na usimamizi.
Mara moja kila baada ya wiki mbili, hali hufanyika na kila timu, ambapo metrics huchambuliwa kwa dakika 10, vikwazo katika mchakato wa uzalishaji hutambuliwa, na suluhisho la pamoja linatengenezwa: nini kifanyike ili kuondokana na vikwazo hivi. Hapa unaweza kuomba usaidizi mara moja kutoka kwa wasimamizi ikiwa tatizo lolote lililotambuliwa liko nje ya eneo la ushawishi wa timu, au utaalamu wa wenzako ambao huenda tayari wamekumbana na tatizo kama hilo.
Hata hivyo, tunaelewa kwamba ili kuharakisha mara nyingi (na hili ndilo lengo hasa tunalojiwekea), bado tunahitaji kujifunza mengi na kutekeleza katika kazi yetu ya kila siku. Hivi sasa tunaendelea kuongeza mbinu ya bidhaa zetu kwa timu nyingine na bidhaa mpya. Ili kufanya hivyo, ilitubidi tujue muundo mpya - shule ya mtandaoni ya wataalamu wa mbinu.
Wataalamu wa mbinu, watu wanaosaidia timu kujenga mchakato, kuanzisha mawasiliano, na kuboresha ufanisi wa kazi, kimsingi ni mawakala wa mabadiliko. Kwa sasa, wahitimu wa kundi letu la kwanza wanafanya kazi na timu na kuzisaidia kufanikiwa.
Nadhani hali ya sasa inatufungulia fursa na matarajio ambayo labda sisi wenyewe bado hatuyafahamu kikamilifu. Lakini uzoefu na mazoezi tunayopata hivi sasa yanathibitisha kuwa tumechagua njia sahihi ya maendeleo, hatutakosa fursa hizi mpya katika siku zijazo na tutaweza kujibu kwa ufanisi changamoto ambazo Sportmaster itakabiliana nazo.
Matokeo
Wakati huu mgumu, tumeunda kanuni kuu ambazo maendeleo ya programu hutegemea, ambayo, nadhani, itakuwa muhimu kwa kila kampuni inayohusika na hili.
Watu. Hivi ndivyo kila kitu kinategemea. Wafanyikazi lazima wafurahie kazi zao na kuelewa malengo ya kampuni na malengo ya bidhaa wanazofanyia kazi. Na, bila shaka, wanaweza kuendeleza kitaaluma.
Π’Π΅Ρ Π½ΠΎΠ»ΠΎΠ³ΠΈΡ. Ni muhimu kwa kampuni kuchukua mbinu ya ukomavu kufanya kazi na mkusanyiko wake wa teknolojia na kujenga ujuzi ambapo inahitajika. Inaonekana rahisi sana na dhahiri. Na mara nyingi hupuuzwa.
Mchakato. Ni muhimu kupanga vizuri kazi ya timu za bidhaa na vituo vya uwezo, kuanzisha mwingiliano na biashara ili kufanya kazi nayo kama mshirika.
Kwa ujumla, ndivyo tulivyonusurika. Thesis kuu ya wakati wetu ilithibitishwa mara nyingine tena, kwa kubofya kwa sauti kwenye paji la uso
Hata kama wewe ni biashara kubwa ya nje ya mtandao yenye maduka mengi na rundo la miji ambapo unafanya kazi, tengeneza biashara yako ya mtandaoni. Hii sio tu chaneli ya ziada ya mauzo au programu nzuri ambayo unaweza pia kununua kitu (na pia kwa sababu washindani pia wana nzuri). Hili si tairi la ziada la kukusaidia kukabiliana na dhoruba.
Hili ni jambo la lazima kabisa. Ambayo sio tu uwezo wako wa kiufundi na miundombinu lazima iwe tayari, lakini pia watu wako na michakato. Baada ya yote, unaweza haraka kununua kumbukumbu ya ziada, nafasi, kupeleka matukio mapya, nk katika masaa kadhaa. Lakini watu na michakato inahitaji kuwa tayari kwa hili mapema.
Chanzo: mapenzi.com