Kila mtu anazungumza juu ya michakato ya ukuzaji na upimaji, mafunzo ya wafanyikazi, motisha inayoongezeka, lakini michakato hii haitoshi wakati dakika ya kupunguzwa kwa huduma inagharimu pesa nyingi. Nini cha kufanya unapofanya shughuli za kifedha chini ya SLA kali? Jinsi ya kuongeza uaminifu na uvumilivu wa makosa ya mifumo yako, kuchukua maendeleo na kupima nje ya equation?
Kongamano lijalo la HighLoad++ litafanyika tarehe 6 na 7 Aprili 2020 huko St. Petersburg. Maelezo na tikiti za . Novemba 9, 18:00. HighLoad++ Moscow 2018, Delhi + ukumbi wa Kolkata. Hizi na .
Evgeniy Kuzovlev (baadaye - EC): - Marafiki, hello! Jina langu ni Kuzovlev Evgeniy. Mimi ni kutoka kampuni ya EcommPay, kitengo maalum ni EcommPay IT, kitengo cha IT cha kundi la makampuni. Na leo tutazungumzia kuhusu wakati wa chini - kuhusu jinsi ya kuepuka, kuhusu jinsi ya kupunguza matokeo yao ikiwa haiwezi kuepukwa. Mada hiyo inasemwa kama ifuatavyo: "Nini cha kufanya wakati dakika ya kupungua inagharimu $ 100"? Kuangalia mbele, idadi yetu ni kulinganishwa.
Je, EcommPay IT hufanya nini?
Sisi ni akina nani? Kwa nini nimesimama hapa mbele yako? Kwa nini nina haki ya kukuambia jambo hapa? Na tutazungumza nini hapa kwa undani zaidi?
Kundi la makampuni ya EcommPay ni mpokeaji wa kimataifa. Tunachakata malipo kote ulimwenguni - nchini Urusi, Ulaya, Asia ya Kusini-Mashariki (Kote Ulimwenguni). Tuna ofisi 9, wafanyakazi 500 kwa jumla, na takriban chini ya nusu yao ni wataalamu wa IT. Kila kitu tunachofanya, kila kitu tunachopata pesa, tulifanya wenyewe.
Tuliandika bidhaa zetu zote (na tunazo nyingi sana - katika mstari wetu wa bidhaa kubwa za IT tuna vipengele 16 tofauti) wenyewe; Tunaandika wenyewe, tunajiendeleza. Na kwa sasa tunafanya miamala takriban milioni moja kwa siku (mamilioni labda ndiyo njia sahihi ya kusema). Sisi ni kampuni changa - tuna umri wa miaka sita tu.
Miaka 6 iliyopita ilikuwa mwanzo kama huo wakati wavulana walikuja pamoja na biashara. Waliunganishwa na wazo (hakukuwa na kitu kingine isipokuwa wazo), na tukakimbia. Kama uanzishaji wowote, tulikimbia haraka... Kwetu sisi, kasi ilikuwa muhimu zaidi kuliko ubora.
Wakati fulani tulisimama: tuligundua kwamba hatuwezi tena kwa namna fulani kuishi kwa kasi hiyo na kwa ubora huo na tulihitaji kuzingatia ubora kwanza. Kwa wakati huu, tuliamua kuandika jukwaa jipya ambalo lingekuwa sahihi, linaloweza kupanuka na kutegemewa. Walianza kuandika jukwaa hili (walianza kuwekeza, kuendeleza maendeleo, kupima), lakini kwa wakati fulani waligundua kuwa maendeleo na upimaji haukuruhusu kufikia kiwango kipya cha ubora wa huduma.
Unatengeneza bidhaa mpya, unaiweka katika uzalishaji, lakini bado kuna kitu kitaenda vibaya mahali fulani. Na leo tutazungumzia jinsi ya kufikia kiwango kipya cha ubora (jinsi tulivyofanya, kuhusu uzoefu wetu), kuchukua maendeleo na kupima nje ya equation; tutazungumzia juu ya kile kinachopatikana kwa uendeshaji - ni operesheni gani inaweza kufanya yenyewe, inaweza kutoa nini kwa kupima ili kuathiri ubora.
Wakati wa kupumzika. Amri za uendeshaji.
Daima msingi kuu, kile tutazungumza juu ya leo ni wakati wa kupumzika. Neno la kutisha. Ikiwa tuna wakati wa kupumzika, kila kitu ni mbaya kwetu. Tunakimbia kuiinua, wasimamizi wameshikilia seva - Mungu apishe mbali isianguke, kama wanasema kwenye wimbo huo. Hii ndio tutazungumza juu ya leo.
Tulipoanza kubadili mbinu zetu, tuliunda amri 4. Nimeziwasilisha kwenye slaidi:
Amri hizi ni rahisi sana:
- Haraka kutambua tatizo.
- Ondoa kwa haraka zaidi.
- Saidia kuelewa sababu (baadaye, kwa watengenezaji).
- Na sanifu mbinu.
Ningependa kuteka mawazo yako kwa uhakika Nambari 2. Tunaondoa tatizo, si kutatua. Kuamua ni sekondari. Kwa sisi, jambo la msingi ni kwamba mtumiaji analindwa kutokana na tatizo hili. Itakuwepo katika mazingira fulani ya pekee, lakini mazingira haya hayatakuwa na mawasiliano nayo. Kwa kweli, tutapitia vikundi hivi vinne vya shida (baadhi kwa undani zaidi, zingine kwa undani kidogo), nitakuambia kile tunachotumia, ni uzoefu gani unaofaa tunao katika suluhisho.
Utatuzi wa shida: Zinatokea lini na nini cha kufanya juu yao?
Lakini tutaanza nje ya utaratibu, tutaanza na hatua ya 2 - jinsi ya kujiondoa haraka tatizo? Kuna tatizo - tunahitaji kurekebisha. "Tufanye nini kuhusu hili?" - swali kuu. Na tulipoanza kufikiria jinsi ya kurekebisha tatizo, tulijitengenezea mahitaji fulani ambayo utatuzi lazima ufuate.
Ili kuunda mahitaji haya, tuliamua kujiuliza swali: "Tuna matatizo wakati gani"? Na shida, kama ilivyotokea, hutokea katika kesi nne:
- Kushindwa kwa vifaa.
- Huduma za nje zimeshindwa.
- Kubadilisha toleo la programu (usambazaji sawa).
- Ukuaji wa mzigo unaolipuka.
Hatutazungumza juu ya mbili za kwanza. Hitilafu ya vifaa inaweza kutatuliwa kwa urahisi kabisa: lazima uwe na kila kitu kilichorudiwa. Ikiwa hizi ni diski, diski lazima zikusanyike katika RAID; ikiwa hii ni seva, seva lazima irudishwe; ikiwa una miundombinu ya mtandao, lazima upe nakala ya pili ya miundombinu ya mtandao, ambayo ni, unaichukua na nakala yake. Na ikiwa kitu kitashindwa, unabadilisha kuweka nguvu. Ni ngumu kusema chochote zaidi hapa.
Ya pili ni kushindwa kwa huduma za nje. Kwa wengi, mfumo sio shida hata kidogo, lakini sio kwetu. Kwa kuwa tunachakata malipo, sisi ni kijumlishi kinachosimama kati ya mtumiaji (anayeingiza data ya kadi yake) na benki, mifumo ya malipo (Visa, MasterCard, Mira, nk.). Huduma zetu za nje (mifumo ya malipo, benki) zinaelekea kushindwa. Sisi wala wewe (ikiwa una huduma kama hizi) hatuwezi kuathiri hili.
Nini cha kufanya basi? Kuna chaguzi mbili hapa. Kwanza, ikiwa unaweza, unapaswa kurudia huduma hii kwa njia fulani. Kwa mfano, ikiwa tunaweza, tunahamisha trafiki kutoka kwa huduma moja hadi nyingine: kwa mfano, kadi zilichakatwa kupitia Sberbank, Sberbank ina matatizo - tunahamisha trafiki [kwa masharti] kwa Raiffeisen. Jambo la pili tunaloweza kufanya ni kugundua kutofaulu kwa huduma za nje haraka sana, na kwa hivyo tutazungumza juu ya kasi ya majibu katika sehemu inayofuata ya ripoti.
Kwa kweli, kati ya hizi nne, tunaweza kushawishi hasa mabadiliko ya matoleo ya programu - kuchukua hatua ambazo zitasababisha uboreshaji wa hali katika mazingira ya kupelekwa na katika hali ya ukuaji wa kulipuka kwa mzigo. Kwa kweli, ndivyo tulivyofanya. Hapa, tena, noti ndogo ...
Kati ya shida hizi nne, kadhaa hutatuliwa mara moja ikiwa una wingu. Ikiwa uko katika Microsoft Azhur, mawingu ya Ozoni, au kutumia mawingu yetu, kutoka kwa Yandex au Mail, basi angalau malfunction ya vifaa inakuwa tatizo lao na kila kitu mara moja kinakuwa sawa kwako katika mazingira ya malfunction ya vifaa.
Sisi ni kampuni isiyo ya kawaida kidogo. Hapa kila mtu anazungumza juu ya "Kubernets", juu ya mawingu - hatuna "Kubernets" wala mawingu. Lakini tuna racks ya vifaa katika vituo vingi vya data, na tunalazimika kuishi kwenye vifaa hivi, tunalazimika kuwajibika kwa yote. Kwa hivyo, tutazungumza katika muktadha huu. Kwa hiyo, kuhusu matatizo. Wawili wa kwanza walitolewa nje ya mabano.
Kubadilisha toleo la programu. Misingi
Wasanidi programu wetu hawana ufikiaji wa uzalishaji. Kwanini hivyo? Ni kwamba tumeidhinishwa na PCI DSS, na wasanidi programu wetu hawana haki ya kuingia kwenye "bidhaa". Hiyo ni, kipindi. Hata kidogo. Kwa hivyo, jukumu la ukuzaji huisha haswa wakati usanidi unawasilisha muundo ili kutolewa.
Msingi wetu wa pili tulionao, ambao pia unatusaidia sana, ni kutokuwepo kwa maarifa ya kipekee yasiyo na kumbukumbu. Natumai ni vivyo hivyo kwako. Kwa sababu ikiwa sivyo, utakuwa na matatizo. Matatizo yatatokea wakati ujuzi huu wa kipekee, usio na hati haupo kwa wakati ufaao mahali pazuri. Wacha tuseme una mtu mmoja ambaye anajua jinsi ya kupeleka sehemu maalum - mtu hayupo, yuko likizo au mgonjwa - ndivyo hivyo, una shida.
Na msingi wa tatu ambao tumefika. Tuliifikia kupitia maumivu, damu, machozi - tulifikia hitimisho kwamba muundo wetu wowote una makosa, hata ikiwa hauna makosa. Tuliamua hili wenyewe: tunapopeleka kitu, tunapoingiza kitu katika uzalishaji, tunayo muundo ulio na makosa. Tumeunda mahitaji ambayo mfumo wetu lazima ukidhi.
Mahitaji ya kubadilisha toleo la programu
Kuna mahitaji matatu:
- Lazima turudishe utumaji haraka.
- Ni lazima tupunguze athari za upelekaji usiofanikiwa.
- Na lazima tuweze kupeleka haraka sambamba.
Hasa kwa utaratibu huo! Kwa nini? Kwa sababu, kwanza kabisa, wakati wa kupeleka toleo jipya, kasi sio muhimu, lakini ni muhimu kwako, ikiwa kitu kitaenda vibaya, kurudi haraka na kuwa na athari ndogo. Lakini ikiwa una seti ya matoleo katika uzalishaji, ambayo inageuka kuwa kuna kosa (nje ya bluu, hakukuwa na kupelekwa, lakini kuna kosa) - kasi ya kupelekwa baadae ni muhimu kwako. Je, tumefanya nini ili kukidhi mahitaji haya? Tuliamua kutumia mbinu ifuatayo:
Inajulikana sana, hatujawahi kuivumbua - hii ni kupeleka kwa Bluu/Kijani. Ni nini? Lazima uwe na nakala kwa kila kundi la seva ambazo programu zako zimesakinishwa. Nakala ni "joto": hakuna trafiki juu yake, lakini wakati wowote trafiki hii inaweza kutumwa kwa nakala hii. Nakala hii ina toleo la awali. Na wakati wa kupeleka, unasambaza msimbo kwenye nakala isiyotumika. Kisha unabadilisha sehemu ya trafiki (au yote) kwa toleo jipya. Kwa hivyo, ili kubadilisha mtiririko wa trafiki kutoka kwa toleo la zamani hadi jipya, unahitaji kufanya hatua moja tu: unahitaji kubadilisha usawa kwenye mto wa juu, ubadilishe mwelekeo - kutoka kwa mto mmoja hadi mwingine. Hii ni rahisi sana na kutatua tatizo la kubadili haraka na kurejesha haraka.Hapa suluhisho la swali la pili ni kupunguza: unaweza kutuma sehemu tu ya trafiki yako kwa mstari mpya, kwa mstari na msimbo mpya (wacha iwe, kwa mfano, 2%). Na hawa 2% sio 100%! Ikiwa ulipoteza 100% ya trafiki yako kwa sababu ya utumaji usiofanikiwa, hiyo inatisha; ikiwa umepoteza 2% ya trafiki yako, hiyo haipendezi, lakini haiogopi. Kwa kuongezea, watumiaji hawataweza hata kugundua hii, kwa sababu katika hali zingine (sio zote) mtumiaji yule yule, akibonyeza F5, atachukuliwa kwa toleo lingine la kufanya kazi.
Bluu/kijani kupeleka. Kuelekeza
Hata hivyo, si kila kitu ni rahisi sana "Bluu / Green kupeleka" ... Vipengele vyetu vyote vinaweza kugawanywa katika makundi matatu:
- hii ni sehemu ya mbele (kurasa za malipo ambazo wateja wetu wanaona);
- msingi wa usindikaji;
- adapta ya kufanya kazi na mifumo ya malipo (benki, MasterCard, Visa ...).
Na kuna nuance hapa - nuance iko katika njia kati ya mistari. Ukibadilisha tu 100% ya trafiki, huna matatizo haya. Lakini ikiwa unataka kubadili 2%, unaanza kuuliza maswali: "Jinsi ya kufanya hivyo?" Jambo rahisi zaidi ni moja kwa moja: unaweza kusanidi Round Robin katika nginx kwa chaguo nasibu, na unayo 2% kushoto, 98% kulia. Lakini hii haifai kila wakati.
Kwa mfano, kwa upande wetu, mtumiaji huingiliana na mfumo na ombi zaidi ya moja. Hii ni kawaida: maombi 2, 3, 4, 5 - mifumo yako inaweza kuwa sawa. Na ikiwa ni muhimu kwako kwamba maombi yote ya mtumiaji yaje kwenye mstari huo ambao ombi la kwanza lilikuja, au (hatua ya pili) maombi yote ya mtumiaji yanakuja kwenye mstari mpya baada ya kubadili (angeweza kuanza kufanya kazi mapema na mfumo, kabla ya kubadili), - basi usambazaji huu wa random haukufaa kwako. Kisha kuna chaguzi zifuatazo:
Chaguo la kwanza, rahisi zaidi, linatokana na vigezo vya msingi vya mteja (IP Hash). Una IP, na unaigawanya kutoka kulia kwenda kushoto kwa anwani ya IP. Kisha kesi ya pili niliyoelezea itakufanyia kazi, wakati kupelekwa kulifanyika, mtumiaji anaweza tayari kuanza kufanya kazi na mfumo wako, na kutoka wakati wa kupeleka maombi yote yataenda kwenye mstari mpya (kwa moja sawa, sema).Ikiwa kwa sababu fulani hii haikubaliani na wewe na lazima utume maombi kwa mstari ambapo ombi la awali la mtumiaji lilikuja, basi una chaguo mbili ...
Chaguo la kwanza: unaweza kununua nginx+ iliyolipwa. Kuna utaratibu wa vipindi vya Nata, ambao, kwa ombi la awali la mtumiaji, humpa mtumiaji kipindi na kukiunganisha kwa moja au nyingine ya juu. Maombi yote yatakayofuata ya mtumiaji ndani ya kipindi kizima cha kipindi yatatumwa kwenye sehemu ya juu ambapo kipindi kilichapishwa.Hii haikutufaa kwa sababu tayari tulikuwa na nginx ya kawaida. Kubadilisha kwa nginx+ sio kwamba ni ghali, ni kwamba tu ilikuwa chungu kwetu na sio sawa sana. "Vipindi vya Vijiti", kwa mfano, havikufanya kazi kwetu kwa sababu rahisi kwamba "Vipindi vya Vijiti" haviruhusu uelekezaji kulingana na "Aidha-au". Huko unaweza kubainisha kile tunachofanya "Vipindi vya Vijiti", kwa mfano, kwa anwani ya IP au kwa anwani ya IP na vidakuzi au kwa kigezo cha posta, lakini "Ama-au" ni ngumu zaidi hapo.
Kwa hiyo, tulikuja kwa chaguo la nne. Tulichukua nginx kwenye steroids (hii ni openresty) - hii ni nginx sawa, ambayo inasaidia pia kuingizwa kwa hati za mwisho. Unaweza kuandika hati ya mwisho, uipe "pumziko wazi", na hati hii ya mwisho itatekelezwa wakati ombi la mtumiaji linakuja.
Na tuliandika, kwa kweli, hati kama hiyo, tulijiweka "openresti" na katika hati hii tunapanga vigezo 6 tofauti kwa kuunganisha "Au". Kulingana na uwepo wa parameter moja au nyingine, tunajua kwamba mtumiaji alikuja kwenye ukurasa mmoja au mwingine, mstari mmoja au mwingine.
Bluu/kijani kupeleka. Faida na hasara
Bila shaka, labda iliwezekana kuifanya iwe rahisi kidogo (tumia "Vipindi vya Nata") sawa, lakini pia tuna nuance ambayo sio tu mtumiaji anaingiliana nasi ndani ya mfumo wa usindikaji mmoja wa shughuli moja ... Lakini mifumo ya malipo pia inaingiliana nasi: Baada ya kushughulikia muamala (kwa kutuma ombi kwa mfumo wa malipo), tunapokea nafuu.
Na tuseme, ikiwa ndani ya mzunguko wetu tunaweza kusambaza anwani ya IP ya mtumiaji katika maombi yote na kugawa watumiaji kulingana na anwani ya IP, basi hatutasema "Visa" sawa: "Jamani, sisi ni kampuni ya retro, tunaonekana. kuwa wa kimataifa (kwenye tovuti na nchini Urusi)... Tafadhali tupe anwani ya IP ya mtumiaji katika sehemu ya ziada, itifaki yako imesanifishwa”! Ni wazi kwamba hawatakubali.
Kwa hivyo, hii haikufanya kazi kwetu - tulifanya uwazi. Ipasavyo, na routing tulipata kitu kama hiki:Usambazaji wa Bluu/Kijani, ipasavyo, faida ambazo nilitaja na hasara.
Hasara mbili:
- unahitaji kujisumbua na uelekezaji;
- hasara kuu ya pili ni gharama.
Unahitaji seva mara mbili zaidi, unahitaji rasilimali mara mbili ya uendeshaji, unahitaji kutumia mara mbili ya jitihada nyingi ili kudumisha zoo hii yote.
Kwa njia, kati ya faida kuna jambo moja zaidi ambalo sijataja hapo awali: una hifadhi katika kesi ya ukuaji wa mzigo. Ikiwa una ukuaji wa kulipuka kwa mzigo, una idadi kubwa ya watumiaji, basi unajumuisha tu mstari wa pili katika usambazaji wa 50 hadi 50 - na mara moja una seva za x2 kwenye nguzo yako hadi utatue tatizo la kuwa na seva zaidi.
Jinsi ya kufanya kupelekwa haraka?
Tulizungumza juu ya jinsi ya kutatua shida ya kupunguzwa na kurudi kwa haraka, lakini swali linabaki: "Jinsi ya kupeleka haraka?"
Ni fupi na rahisi hapa.- Lazima uwe na mfumo wa CD (Utoaji Unaoendelea) - huwezi kuishi bila hiyo. Ikiwa una seva moja, unaweza kupeleka kwa mikono. Tuna karibu seva elfu moja na nusu na vipini elfu moja na nusu, bila shaka - tunaweza kupanda idara ya ukubwa wa chumba hiki tu kupeleka.
- Usambazaji lazima uwe sambamba. Ikiwa kupelekwa kwako ni kwa mlolongo, basi kila kitu ni mbaya. Seva moja ni ya kawaida, utakuwa unapeleka seva elfu moja na nusu siku nzima.
- Tena, kwa kuongeza kasi, hii labda sio lazima tena. Wakati wa kupeleka, mradi kawaida hujengwa. Una mradi wa wavuti, kuna sehemu ya mwisho (unafanya pakiti ya wavuti hapo, unakusanya npm - kitu kama hicho), na mchakato huu, kimsingi, ni wa muda mfupi - dakika 5, lakini dakika hizi 5 zinaweza. kuwa muhimu. Ndiyo sababu, kwa mfano, hatufanyi hivyo: tuliondoa dakika hizi 5, tunasambaza mabaki.
Vizalia vya programu ni nini? Artifact ni muundo uliokusanyika ambao sehemu zote za kusanyiko tayari zimekamilika. Tunahifadhi vizalia hivi vya programu kwenye hifadhi ya vizalia vya programu. Wakati fulani tulitumia hifadhi mbili kama hizo - ilikuwa Nexus na sasa jFrog Artifactory). Hapo awali tulitumia "Nexus" kwa sababu tulianza kutumia mbinu hii katika programu za java (ilifaa vizuri). Kisha wakaweka baadhi ya maombi yaliyoandikwa katika PHP humo; na "Nexus" haikufaa tena, na kwa hivyo tulichagua jFrog Artefactory, ambayo inaweza kuunda karibu kila kitu. Tumefikia hatua kwamba katika hazina hii ya vizalia vya programu tunahifadhi vifurushi vyetu vya binary ambavyo tunakusanya kwa seva.
Ukuaji wa mzigo unaolipuka
Tulizungumza juu ya kubadilisha toleo la programu. Jambo linalofuata tulilo nalo ni ongezeko kubwa la mzigo. Hapa, labda ninamaanisha kwa ukuaji wa mlipuko wa mzigo sio jambo sahihi kabisa ...
Tuliandika mfumo mpya - ni wa huduma-oriented, mtindo, nzuri, wafanyakazi kila mahali, foleni kila mahali, asynchrony kila mahali. Na katika mifumo hiyo, data inaweza kutiririka kupitia mtiririko tofauti. Kwa shughuli ya kwanza, mfanyakazi wa 1, 3, 10 anaweza kutumika, kwa shughuli ya pili - 2, 4, 5. Na leo, hebu sema, asubuhi una mtiririko wa data unaotumia wafanyakazi watatu wa kwanza, na jioni hubadilika sana, na kila kitu kinatumia wafanyakazi wengine watatu.
Na hapa zinageuka kuwa unahitaji kwa namna fulani kuongeza wafanyakazi, unahitaji kwa namna fulani kuongeza huduma zako, lakini wakati huo huo kuzuia bloat ya rasilimali.
Tumefafanua mahitaji yetu. Mahitaji haya ni rahisi sana: kwamba kuna ugunduzi wa Huduma, parameterization - kila kitu ni kawaida kwa ajili ya kujenga mifumo hiyo scalable, isipokuwa kwa pointi moja - uchakavu wa rasilimali. Tulisema kwamba hatuko tayari kufidia rasilimali ili seva zipashe joto hewa. Tulichukua "Consul", tukachukua "Nomad", ambayo inasimamia wafanyikazi wetu.Kwa nini hili ni tatizo kwetu? Hebu turudi nyuma kidogo. Sasa tuna takriban mifumo 70 ya malipo nyuma yetu. Asubuhi, trafiki hupitia Sberbank, basi Sberbank ilianguka, kwa mfano, na tunaibadilisha kwenye mfumo mwingine wa malipo. Tulikuwa na wafanyikazi 100 kabla ya Sberbank, na baada ya hapo tunahitaji kuongeza wafanyikazi 100 kwa mfumo mwingine wa malipo. Na inatamanika haya yote yatokee bila ushiriki wa mwanadamu. Kwa sababu ikiwa kuna ushiriki wa kibinadamu, kunapaswa kuwa na mhandisi ameketi hapo 24/7, ambaye anapaswa kufanya hivi tu, kwa sababu kushindwa vile, wakati mifumo 70 iko nyuma yako, hutokea mara kwa mara.
Kwa hiyo, tuliangalia Nomad, ambayo ina IP iliyo wazi, na tukaandika kitu chetu wenyewe, Scale-Nomad - ScaleNo, ambayo hufanya takriban zifuatazo: inafuatilia ukuaji wa foleni na kupunguza au kuongeza idadi ya wafanyakazi kulingana na mienendo. ya foleni. Tulipoifanya, tulifikiri: "Labda tunaweza kufungua chanzo?" Kisha wakamtazama - alikuwa rahisi kama kopecks mbili.
Kufikia sasa hatujafungua chanzo, lakini ikiwa ghafla baada ya ripoti, baada ya kugundua kuwa unahitaji kitu kama hicho, unahitaji, anwani zangu ziko kwenye slaidi ya mwisho - tafadhali niandikie. Ikiwa kuna angalau watu 3-5, tutafadhili.
Inavyofanya kazi? Hebu tuangalie! Kuangalia mbele: upande wa kushoto kuna kipande cha ufuatiliaji wetu: hii ni mstari mmoja, juu ni wakati wa usindikaji wa tukio, katikati ni idadi ya shughuli, chini ni idadi ya wafanyakazi.Ukiangalia, kuna hitilafu kwenye picha hii. Kwenye chati ya juu, moja ya chati ilianguka katika sekunde 45 - moja ya mifumo ya malipo ilishuka. Mara moja, trafiki ililetwa kwa dakika 2 na foleni ilianza kukua kwenye mfumo mwingine wa malipo, ambapo hapakuwa na wafanyakazi (hatukutumia rasilimali - kinyume chake, tulitupa rasilimali kwa usahihi). Hatukutaka joto - kulikuwa na idadi ndogo, karibu wafanyikazi 5-10, lakini hawakuweza kustahimili.
Grafu ya mwisho inaonyesha "hump", ambayo ina maana tu kwamba "Skaleno" iliongeza kiasi hiki mara mbili. Na kisha, wakati grafu ilishuka kidogo, aliipunguza kidogo - idadi ya wafanyakazi ilibadilishwa moja kwa moja. Ndivyo jambo hili linavyofanya kazi. Tulizungumza juu ya nambari ya 2 - "Jinsi ya kuondoa haraka sababu."
Ufuatiliaji. Jinsi ya kutambua haraka tatizo?
Sasa jambo la kwanza ni "Jinsi ya kutambua shida haraka?" Ufuatiliaji! Ni lazima tuelewe mambo fulani haraka. Ni mambo gani tunapaswa kuelewa haraka?
Mambo matatu!- Lazima tuelewe na kuelewa kwa haraka utendaji wa rasilimali zetu wenyewe.
- Ni lazima tuelewe kwa haraka kushindwa na kufuatilia utendaji wa mifumo ambayo iko nje yetu.
- Jambo la tatu ni kutambua makosa ya kimantiki. Huu ndio wakati mfumo unakufanyia kazi, kila kitu ni cha kawaida kulingana na viashiria vyote, lakini kitu kinakwenda vibaya.
Labda sitakuambia chochote kizuri hapa. Nitakuwa Captain Obvious. Tulitafuta kilichokuwa sokoni. Tuna "zoo ya kufurahisha". Hii ndio aina ya zoo tuliyo nayo sasa:
Tunatumia Zabbix kufuatilia maunzi, kufuatilia viashiria kuu vya seva. Tunatumia Okmeter kwa hifadhidata. Tunatumia "Grafana" na "Prometheus" kwa viashiria vingine vyote ambavyo havilingani na mbili za kwanza, baadhi na "Grafana" na "Prometheus", na baadhi na "Grafana" na "Influx" na Telegraf.Mwaka mmoja uliopita tulitaka kutumia New Relic. Jambo la kupendeza, linaweza kufanya kila kitu. Lakini kadiri anavyoweza kufanya kila kitu, yeye ni ghali sana. Tulipoongezeka na kufikia kiasi cha seva elfu 1,5, mchuuzi mmoja alikuja kwetu na kusema: "Hebu tufanye makubaliano ya mwaka ujao." Tuliangalia bei na tukasema hapana, hatutafanya hivyo. Sasa tunaachana na Relic Mpya, tuna takriban seva 15 zilizosalia chini ya ufuatiliaji wa Relic Mpya. Bei iligeuka kuwa ya porini kabisa.
Na kuna zana moja ambayo tuliitekeleza sisi wenyewe - hii ni Debugger. Mwanzoni tuliiita "Bagger," lakini kisha mwalimu wa Kiingereza akapita, akacheka sana, na kuiita "Debagger." Ni nini? Hii ni zana ambayo, kwa kweli, katika sekunde 15-30 kwa kila sehemu, kama "sanduku nyeusi" la mfumo, huendesha majaribio juu ya utendakazi wa jumla wa sehemu.
Kwa mfano, ikiwa kuna ukurasa wa nje (ukurasa wa malipo), anaifungua tu na kuangalia jinsi inapaswa kuonekana. Ikiwa hii ni usindikaji, hutuma "shughuli" ya mtihani na kuhakikisha kwamba "shughuli" hii inakuja. Ikiwa hii ni muunganisho na mifumo ya malipo, tunafuta ombi la jaribio ipasavyo, ambapo tunaweza, na kuona kuwa kila kitu kiko sawa nasi.
Ni viashiria vipi ni muhimu kwa ufuatiliaji?
Tunafuatilia nini hasa? Ni viashiria gani ni muhimu kwetu?
- Wakati wa kujibu / RPS kwenye pande ni kiashirio muhimu sana. Mara moja anajibu kuwa kuna kitu kibaya na wewe.
- Idadi ya ujumbe uliochakatwa katika foleni zote.
- Idadi ya wafanyakazi.
- Vipimo vya msingi vya usahihi.
Hatua ya mwisho ni kipimo cha "biashara", "biashara". Ikiwa unataka kufuatilia kitu sawa, unahitaji kufafanua metriki moja au mbili ambazo ni viashiria kuu kwako. Kipimo chetu ni matokeo (hii ni uwiano wa idadi ya miamala iliyofaulu kwa jumla ya mtiririko wa muamala). Ikiwa kitu kinabadilika ndani yake kwa muda wa dakika 5-10-15, inamaanisha tuna matatizo (ikiwa inabadilika sana).
Inaonekana kwetu ni mfano wa moja ya bodi zetu:
Upande wa kushoto kuna grafu 6, hii ni kwa mujibu wa mistari - idadi ya wafanyakazi na idadi ya ujumbe katika foleni. Kwa upande wa kulia - RPS, RTS. Chini ni kipimo sawa cha "biashara". Na katika metriki ya "biashara" tunaweza kuona mara moja kwamba kitu kilikwenda vibaya katika grafu mbili za kati ... Huu ni mfumo mwingine tu unaosimama nyuma yetu ambao umeanguka.Jambo la pili tulilopaswa kufanya ni kufuatilia kuanguka kwa mifumo ya malipo ya nje. Hapa tulichukua OpenTracing - utaratibu, kiwango, dhana ambayo inakuwezesha kufuatilia mifumo iliyosambazwa; na ilibadilishwa kidogo. Mtazamo wa kawaida wa OpenTracing unasema kwamba tunaunda ufuatiliaji kwa kila ombi la mtu binafsi. Hatukuhitaji hii, na tuliifunga kwa muhtasari, ufuatiliaji wa mkusanyiko. Tulitengeneza zana ambayo inaturuhusu kufuatilia kasi ya mifumo iliyo nyuma yetu.
Grafu inatuonyesha kwamba moja ya mifumo ya malipo ilianza kujibu katika sekunde 3 - tuna matatizo. Zaidi ya hayo, jambo hili litaguswa wakati matatizo yanaanza, kwa muda wa sekunde 20-30.Na darasa la tatu la makosa ya ufuatiliaji yaliyopo ni ufuatiliaji wa kimantiki.
Kuwa waaminifu, sikujua nini cha kuteka kwenye slide hii, kwa sababu tumekuwa tukitafuta kwa muda mrefu kwenye soko kwa kitu ambacho kingefaa kwetu. Hatukupata chochote, kwa hivyo tulilazimika kuifanya sisi wenyewe.
Ninamaanisha nini kwa ufuatiliaji wa kimantiki? Naam, fikiria: unajifanya mfumo (kwa mfano, clone ya Tinder); uliitengeneza, ukaizindua. Meneja aliyefanikiwa Vasya Pupkin aliiweka kwenye simu yake, anaona msichana huko, anampenda ... na kama hiyo haiendi kwa msichana - kama hiyo huenda kwa mlinzi wa usalama Mikhalych kutoka kituo hicho cha biashara. Meneja anashuka, kisha anashangaa: "Kwa nini mlinzi huyu Mikhalych anamtabasamu kwa kupendeza?"Katika hali kama hizi ... Kwa sisi, hali hii inaonekana tofauti kidogo, kwa sababu (niliandika) hii ni hasara ya sifa ambayo inaongoza kwa hasara za kifedha. Hali yetu ni kinyume chake: tunaweza kupata hasara za moja kwa moja za kifedha - kwa mfano, ikiwa tulifanya muamala kama uliofaulu, lakini haukufaulu (au kinyume chake). Ilinibidi kuandika zana yangu mwenyewe ambayo hufuatilia idadi ya miamala iliyofanikiwa kwa wakati kwa kutumia viashiria vya biashara. Sikupata chochote kwenye soko! Hili ndilo wazo ambalo nilitaka kuwasilisha. Hakuna kitu kwenye soko cha kutatua shida ya aina hii.
Hii ilikuwa juu ya jinsi ya kutambua shida haraka.
Jinsi ya kuamua sababu za kupeleka
Kundi la tatu la matatizo ambayo tunatatua ni baada ya kubaini tatizo, baada ya kuliondoa ni vyema tukaelewa sababu ya maendeleo, ya kupima, na kufanya kitu kuhusu hilo. Ipasavyo, tunahitaji kuchunguza, tunahitaji kuinua magogo.
Ikiwa tunazungumzia kuhusu magogo (sababu kuu ni magogo), wingi wa magogo yetu ni katika ELK Stack - karibu kila mtu ana sawa. Kwa wengine, inaweza kuwa katika ELK, lakini ukiandika magogo katika gigabytes, basi mapema au baadaye utakuja kwa ELK. Tunawaandika kwa terabytes.
Kuna tatizo hapa. Tukarekebisha, tukarekebisha kosa kwa mtumiaji, tukaanza kuchimba kilichopo, tukapanda Kibana, tukaingiza kitambulisho cha muamala pale na kupata kitambaa cha miguu namna hii (inaonyesha sana). Na hakuna chochote kilicho wazi katika kitambaa hiki cha miguu. Kwa nini? Ndio, kwa sababu haijulikani wazi ni sehemu gani ni ya mfanyakazi gani, ni sehemu gani ni ya sehemu gani. Na wakati huo tuligundua kuwa tunahitaji ufuatiliaji - OpenTracing ile ile ambayo nilizungumza juu yake.Tulifikiria hii mwaka mmoja uliopita, tukaelekeza umakini wetu kwenye soko, na kulikuwa na zana mbili hapo - "Zipkin" na "Jaeger". "Jager" kwa kweli ni mrithi wa kiitikadi kama huyo, mrithi wa kiitikadi wa "Zipkin". Kila kitu ni nzuri katika Zipkin, isipokuwa kwamba hajui jinsi ya kujumlisha, hajui jinsi ya kujumuisha magogo katika ufuatiliaji, kufuatilia wakati tu. Na "Jager" aliunga mkono hili.
Tuliangalia "Jager": unaweza kutumia programu, unaweza kuandika kwa Api (kiwango cha Api cha PHP wakati huo, hata hivyo, hakikuidhinishwa - hii ilikuwa mwaka mmoja uliopita, lakini sasa tayari imeidhinishwa), lakini huko. hakuwa mteja kabisa. "Sawa," tulifikiria, na tukaandika mteja wetu wenyewe. Tulipata nini? Hivi ndivyo inavyoonekana kama:
Katika Jaeger, nafasi zinaundwa kwa kila ujumbe. Hiyo ni, wakati mtumiaji anafungua mfumo, anaona vitalu moja au mbili kwa kila ombi linaloingia (1-2-3 - idadi ya maombi yanayoingia kutoka kwa mtumiaji, idadi ya vitalu). Ili kurahisisha watumiaji, tuliongeza lebo kwenye kumbukumbu na ufuatiliaji wa saa. Ipasavyo, kukitokea hitilafu, programu yetu itatia alama kwenye logi na lebo inayofaa ya Hitilafu. Unaweza kuchuja kwa lebo ya Hitilafu na misururu iliyo na kizuizi hiki yenye hitilafu pekee ndiyo itaonyeshwa. Hivi ndivyo inavyoonekana ikiwa tutapanua muda:
Ndani ya span kuna seti ya athari. Katika kesi hii, hizi ni athari tatu za majaribio, na ufuatiliaji wa tatu unatuambia kwamba hitilafu ilitokea. Wakati huo huo, hapa tunaona ufuatiliaji wa wakati: tuna kiwango cha wakati juu, na tunaona kwa muda gani hii au logi hiyo ilirekodi.Kwa hiyo, mambo yalituendea vyema. Tuliandika ugani wetu wenyewe na tukafungua chanzo. Ikiwa unataka kufanya kazi na ufuatiliaji, ikiwa unataka kufanya kazi na "Jager" katika PHP, kuna kiendelezi chetu, karibu kutumia, kama wanasema:
Tuna kiendelezi hiki - ni mteja wa OpenTracing Api, imetengenezwa kama php-extention, yaani, utahitaji kuikusanya na kuiweka kwenye mfumo. Mwaka mmoja uliopita hakukuwa na kitu tofauti. Sasa kuna wateja wengine ambao ni kama vipengele. Hapa ni juu yako: ama unasukuma vipengele na mtunzi, au utumie ugani kwako.Viwango vya ushirika
Tulizungumza juu ya amri tatu. Amri ya nne ni kusawazisha mbinu. Hii inahusu nini? Ni kuhusu hili:
Kwa nini neno "ushirika" hapa? Sio kwa sababu sisi ni kampuni kubwa au ya urasimu, hapana! Nilitaka kutumia neno "shirika" hapa katika muktadha kwamba kila kampuni, kila bidhaa inapaswa kuwa na viwango vyake, pamoja na wewe. Je, tuna viwango gani?
- Tunayo kanuni za upelekaji. Hatusogei popote bila yeye, hatuwezi. Tunapeleka karibu mara 60 kwa wiki, yaani, tunapeleka karibu kila mara. Wakati huo huo, tuna, kwa mfano, katika kanuni za kupeleka taboo juu ya kupelekwa siku ya Ijumaa - kwa kanuni, hatutumii.
- Tunahitaji nyaraka. Hakuna sehemu moja mpya inayoingia katika uzalishaji ikiwa hakuna nyaraka kwa hiyo, hata ikiwa ilizaliwa chini ya kalamu ya wataalamu wetu wa RnD. Tunahitaji kutoka kwao maagizo ya uwekaji, ramani ya ufuatiliaji na maelezo mafupi (vizuri, kama watayarishaji wa programu wanaweza kuandika) jinsi sehemu hii inavyofanya kazi, jinsi ya kuisuluhisha.
- Hatutatui sababu ya shida, lakini shida - kile nilichosema tayari. Ni muhimu kwetu kumlinda mtumiaji kutokana na matatizo.
- Tuna vibali. Kwa mfano, hatuzingatii kuwa wakati wa mapumziko ikiwa tulipoteza 2% ya trafiki ndani ya dakika mbili. Hii kimsingi haijajumuishwa katika takwimu zetu. Ikiwa ni zaidi katika asilimia ya masharti au ya muda, tayari tunahesabu.
- Na sisi huwa tunaandika postmortems. Chochote kitakachotokea kwetu, hali yoyote ambapo mtu alitenda isivyo kawaida katika uzalishaji itaonyeshwa katika uchunguzi wa maiti. Postmortem ni hati ambayo unaandika kile kilichotokea kwako, muda wa kina, ulichofanya ili kurekebisha na (hii ni kizuizi cha lazima!) utafanya nini ili kuzuia hili kutokea katika siku zijazo. Hii ni ya lazima na muhimu kwa uchambuzi unaofuata.
Ni nini kinachozingatiwa wakati wa kupumzika?
Haya yote yalisababisha nini?Hii ilisababisha ukweli kwamba (tulikuwa na matatizo fulani ya utulivu, hii haikufaa ama wateja au sisi) katika kipindi cha miezi 6 iliyopita kiashiria chetu cha uthabiti kilikuwa 99,97. Tunaweza kusema kwamba hii sio sana. Ndiyo, tuna kitu cha kujitahidi. Kati ya kiashiria hiki, karibu nusu ni utulivu, kama ilivyokuwa, sio yetu, lakini ya firewall ya programu ya wavuti, ambayo inasimama mbele yetu na hutumiwa kama huduma, lakini wateja hawajali kuhusu hili.
Tulijifunza kulala usiku. Hatimaye! Miezi sita iliyopita hatukuweza. Na kwa maelezo haya na matokeo, ningependa kuandika maelezo moja. Jana usiku kulikuwa na ripoti nzuri kuhusu mfumo wa udhibiti wa kinu cha nyuklia. Ikiwa watu walioandika mfumo huu wanaweza kunisikia, tafadhali sahau nilichosema kuhusu "2% sio wakati wa kupumzika." Kwako wewe, 2% ni wakati wa kupumzika, hata ikiwa kwa dakika mbili!
Ni hayo tu! Maswali yako.
Kuhusu wasawazishaji na uhamiaji wa hifadhidata
Swali kutoka kwa hadhira (hapa - B): - Habari za jioni. Asante sana kwa ripoti kama hiyo ya msimamizi! Swali fupi kuhusu wasawazishaji wako. Umetaja kuwa una WAF, ambayo ni, kama ninavyoelewa, unatumia aina fulani ya mizani ya nje ...
EK: - Hapana, tunatumia huduma zetu kama mizani. Katika hali hii, WAF ni zana ya ulinzi ya DDoS kwa ajili yetu pekee.
Katika: - Je, unaweza kusema maneno machache kuhusu wasawazishaji?
EK: - Kama nilivyosema tayari, hili ni kundi la seva katika uwazi. Sasa tuna vikundi 5 vya akiba ambavyo vinajibu kikamilifu... yaani, seva inayoendesha uwazi kwa njia ya kipekee, inawakilisha trafiki pekee. Ipasavyo, kuelewa ni kiasi gani tunashikilia: sasa tunayo mtiririko wa kawaida wa trafiki wa megabits mia kadhaa. Wanakabiliana, wanahisi vizuri, hawana hata kujisumbua wenyewe.
Katika: - Pia swali rahisi. Hapa kuna uwekaji wa Bluu/Kijani. Unafanya nini, kwa mfano, na uhamishaji wa hifadhidata?
EK: - Swali nzuri! Angalia, katika uwekaji wa Bluu/Kijani tuna foleni tofauti kwa kila mstari. Hiyo ni, ikiwa tunazungumzia kuhusu foleni za matukio ambazo hupitishwa kutoka kwa mfanyakazi hadi mfanyakazi, kuna foleni tofauti za mstari wa bluu na mstari wa kijani. Ikiwa tunazungumza juu ya hifadhidata yenyewe, basi tuliipunguza kwa makusudi kadri tulivyoweza, tukahamisha kila kitu kivitendo kwenye foleni; kwenye hifadhidata tunahifadhi tu rundo la shughuli. Na mrundikano wetu wa muamala ni sawa kwa laini zote. Na hifadhidata katika muktadha huu: hatuigawanyi kuwa bluu na kijani, kwa sababu matoleo yote mawili ya msimbo lazima yajue kinachotokea na shughuli.
Marafiki, pia nina zawadi ndogo ya kukuchochea - kitabu. Na ninapaswa kutunukiwa kwa swali bora zaidi.
Katika: - Habari. Asante kwa ripoti. Swali ni hili. Unafuatilia malipo, unafuatilia huduma unazowasiliana nazo... Lakini unafuatiliaje ili mtu kwa namna fulani aje kwenye ukurasa wako wa malipo, akafanya malipo, na mradi ukampa pesa? Hiyo ni, unafuatiliaje kuwa mfanyabiashara anapatikana na amekubali kupigiwa simu yako?
EK: - "Muuzaji" kwetu katika kesi hii ni huduma ya nje sawa kabisa na mfumo wa malipo. Tunafuatilia kasi ya majibu ya mfanyabiashara.
Kuhusu usimbaji wa hifadhidata
Katika: - Habari. Nina swali linalohusiana kidogo. Una data nyeti ya PCI DSS. Nilitaka kujua jinsi unavyohifadhi PAN kwenye foleni ambazo unahitaji kuhamishia? Je, unatumia usimbaji fiche wowote? Na hii inaongoza kwa swali la pili: kwa mujibu wa PCI DSS, ni muhimu mara kwa mara re-encrypt database katika kesi ya mabadiliko (kufukuzwa kwa wasimamizi, nk) - nini kinatokea kwa upatikanaji katika kesi hii?
EK: - Swali la kushangaza! Kwanza, hatuhifadhi PAN kwenye foleni. Hatuna haki ya kuhifadhi PAN mahali popote kwa fomu wazi, kimsingi, kwa hivyo tunatumia huduma maalum (tunaiita "Kademon") - hii ni huduma ambayo hufanya jambo moja tu: inapokea ujumbe kama pembejeo na kutuma. toa ujumbe uliosimbwa. Na tunahifadhi kila kitu na ujumbe huu uliosimbwa kwa njia fiche. Ipasavyo, urefu wetu muhimu ni chini ya kilobyte, ili hii ni mbaya na ya kuaminika.Katika: Je, unahitaji kilobaiti 2 sasa?
EK: - Inaonekana kama jana tu ilikuwa 256 ... Naam, wapi tena?!
Ipasavyo, hii ni ya kwanza. Na pili, suluhisho lililopo, linaunga mkono utaratibu wa usimbuaji tena - kuna jozi mbili za "keks" (funguo), ambazo hupeana "staha" ambazo husimbwa (ufunguo ni funguo, deki ni derivatives ya funguo ambazo husimba) . Na ikiwa utaratibu umeanzishwa (hufanyika mara kwa mara, kutoka miezi 3 hadi ± baadhi), tunapakua jozi mpya ya "keki", na tunasimba tena data. Tuna huduma tofauti ambazo huondoa data yote na kuisimba kwa njia mpya; Data huhifadhiwa karibu na kitambulisho cha ufunguo ambao umesimbwa kwa njia fiche. Ipasavyo, mara tu tunaposimba data kwa funguo mpya, tunafuta ufunguo wa zamani.
Wakati mwingine malipo yanahitajika kufanywa kwa mikono...
Katika: - Hiyo ni, ikiwa urejeshaji wa pesa umefika kwa operesheni fulani, bado utaiondoa kwa ufunguo wa zamani?
EK: - Ndiyo.
Katika: - Kisha swali moja dogo zaidi. Wakati aina fulani ya kushindwa, kuanguka, au tukio hutokea, ni muhimu kushinikiza kupitia shughuli kwa manually. Kuna hali kama hiyo.
EK: - Ndio, wakati mwingine.
Katika: - Unapata wapi data hii? Au unaenda kwenye hifadhi hii mwenyewe?
EK: - Hapana, sawa, bila shaka, tuna aina fulani ya mfumo wa nyuma wa ofisi ambao una kiolesura cha usaidizi wetu. Ikiwa hatujui ni hali gani muamala upo (kwa mfano, hadi mfumo wa malipo ujibu kwa kuisha kwa muda), hatujui priori, yaani, tunaweka hali ya mwisho tu kwa ujasiri kamili. Katika kesi hii, tunaweka shughuli kwa hali maalum ya usindikaji wa mwongozo. Asubuhi, siku inayofuata, mara tu usaidizi unapopokea taarifa kwamba shughuli kama hizo na kama hizo zinabaki kwenye mfumo wa malipo, wao huzichakata kwa mikono kwenye kiolesura hiki.
Katika: - Nina maswali kadhaa. Mmoja wao ni kuendelea kwa eneo la PCI DSS: unawekaje mzunguko wao? Swali hili ni kwa sababu msanidi programu angeweza kuweka chochote kwenye magogo! Swali la pili: jinsi gani unaweza kusambaza hotfixes? Hushughulikia katika hifadhidata ni chaguo moja, lakini kunaweza kuwa na marekebisho ya bure ya moto - ni utaratibu gani hapo? Na swali la tatu labda linahusiana na RTO, RPO. Upatikanaji wako ulikuwa 99,97, karibu miaka minne, lakini kama ninavyoelewa, una kituo cha pili cha data, kituo cha tatu cha data, na kituo cha data cha tano... Je, unazipatanishaje, unaziiga, na kila kitu kingine?EK: - Wacha tuanze na ya kwanza. Swali la kwanza lilikuwa ni kuhusu magogo? Tunapoandika kumbukumbu, tuna safu ambayo hufunika data zote nyeti. Anaangalia mask na nyanja za ziada. Ipasavyo, kumbukumbu zetu hutoka na data tayari iliyofunikwa na mzunguko wa PCI DSS. Hii ni moja ya kazi za kawaida zinazopewa idara ya upimaji. Wanatakiwa kuangalia kila kazi, ikiwa ni pamoja na kumbukumbu wanazoandika, na hii ni mojawapo ya kazi za kawaida wakati wa ukaguzi wa kanuni, ili kudhibiti kwamba msanidi hakuandika kitu. Ukaguzi unaofuata wa hii unafanywa mara kwa mara na idara ya usalama wa habari mara moja kwa wiki: kumbukumbu za siku ya mwisho zinachukuliwa kwa kuchagua na zinaendeshwa kupitia kichanganuzi maalum cha skana kutoka kwa seva za majaribio ili kuangalia kila kitu.
Kuhusu marekebisho ya moto. Hii imejumuishwa katika kanuni zetu za kupeleka. Tunayo kifungu tofauti kuhusu hotfixes. Tunaamini kuwa tunasambaza matoleo mapya saa moja kwa moja tunapohitaji. Mara tu toleo linapokusanywa, mara tu linapoendeshwa, mara tu tunapokuwa na vizalia vya programu, tunakuwa na msimamizi wa zamu anayepiga simu kutoka kwa usaidizi, na huitumia wakati inahitajika.Kuhusu "nines nne". Takwimu tuliyo nayo sasa imefikiwa kweli, na tuliijitahidi katika kituo kingine cha data. Sasa tuna kituo cha pili cha data, na tunaanza kuelekeza kati yao, na suala la urudufishaji wa kituo cha data mtambuka ni swali lisilo la maana. Tulijaribu kuitatua kwa wakati mmoja kwa kutumia njia tofauti: tulijaribu kutumia "Tarantula" sawa - haikufanya kazi kwetu, nitakuambia mara moja. Ndio maana tulimaliza kuagiza "sens" kwa mikono. Kwa kweli, kila programu katika mfumo wetu huendesha usawazishaji unaohitajika wa "mabadiliko - yamefanyika" kati ya vituo vya data kwa usawa.
Katika: - Ikiwa umepata ya pili, kwa nini haukupata ya tatu? Kwa sababu hakuna aliye na ubongo uliogawanyika bado ...
EK: - Lakini hatuna Ubongo uliogawanyika. Kwa sababu ya ukweli kwamba kila programu inaendeshwa na multimaster, haijalishi kwetu ni kituo gani ombi lilikuja. Tuko tayari kwa kuwa ikiwa moja ya vituo vyetu vya data itashindwa (tunategemea hili) na katikati ya ombi la mtumiaji hubadilisha kituo cha pili cha data, tuko tayari kumpoteza mtumiaji huyu, kwa hakika; lakini hizi zitakuwa vitengo, vitengo kamili.
Katika: - Habari za jioni. Asante kwa ripoti. Ulizungumza kuhusu kitatuzi chako, ambacho huendesha shughuli za majaribio katika toleo la umma. Lakini tuambie kuhusu shughuli za majaribio! Je, kina kina kipi?
EK: - Inapitia mzunguko kamili wa sehemu nzima. Kwa kipengele, hakuna tofauti kati ya shughuli ya majaribio na muamala wa uzalishaji. Lakini kutoka kwa mtazamo wa kimantiki, huu ni mradi tofauti katika mfumo, ambao shughuli za mtihani tu zinaendeshwa.
Katika: -Unaikata wapi? Hapa Core ametuma...
EK: - Tuko nyuma ya "Kor" katika kesi hii kwa miamala ya majaribio... Tuna kitu kama kuelekeza: "Kor" inajua ni mfumo gani wa malipo wa kutuma - tunatuma kwa mfumo wa malipo ghushi, ambao unatoa ishara ya http na Ni hayo tu.
Katika: - Niambie, tafadhali, maombi yako yaliandikwa kwa monolith moja kubwa, au uliikata katika huduma fulani au hata huduma ndogo?
EK: - Hatuna monolith, bila shaka, tuna maombi yanayolenga huduma. Tunatania kwamba huduma yetu imetengenezwa na monoliths - ni kubwa sana. Ni vigumu kuiita microservices, lakini hizi ni huduma ambazo wafanyakazi wa mashine zilizosambazwa hufanya kazi.
Ikiwa huduma kwenye seva imeathiriwa...
Katika: - Kisha nina swali linalofuata. Hata kama ilikuwa monolith, bado ulisema kuwa unayo seva nyingi za papo hapo, zote kimsingi zinachakata data, na swali ni: "Ikitokea maelewano ya seva moja ya papo hapo au programu, kiungo chochote cha mtu binafsi. , je, wana aina fulani ya udhibiti wa ufikiaji? Ni nani kati yao anayeweza kufanya nini? Je, niwasiliane na nani kwa taarifa gani?
EK: - Ndiyo, hakika. Mahitaji ya usalama ni makubwa sana. Kwanza, tuna uhamishaji wa data wazi, na bandari ni zile tu ambazo tunatarajia harakati za trafiki mapema. Ikiwa sehemu itawasiliana na hifadhidata (sema, na Muskul) kupitia 5-4-3-2, 5-4-3-2 pekee itafunguliwa, na bandari zingine na maelekezo mengine ya trafiki hayatapatikana. Kwa kuongeza, unahitaji kuelewa kwamba katika uzalishaji wetu kuna loops 10 tofauti za usalama. Na hata ikiwa programu iliathiriwa kwa njia fulani, Mungu asipishe mbali, mshambuliaji hataweza kufikia koni ya usimamizi wa seva, kwa sababu hii ni eneo tofauti la usalama wa mtandao.Katika: - Na katika muktadha huu, kinachovutia zaidi kwangu ni kwamba una mikataba fulani na huduma - wanachoweza kufanya, kupitia "vitendo" gani wanaweza kuwasiliana ... Na katika mtiririko wa kawaida, huduma zingine huuliza safu, orodha ya "vitendo" kwa upande mwingine. Hawaonekani kugeuka kwa wengine katika hali ya kawaida, na wana maeneo mengine ya wajibu. Ikiwa mmoja wao ameathiriwa, je, ataweza kuvuruga "vitendo" vya huduma hiyo?..
EK: - Naelewa. Ikiwa katika hali ya kawaida na mawasiliano ya seva nyingine iliruhusiwa kabisa, basi ndiyo. Kwa mujibu wa mkataba wa SLA, hatufuatilii kwamba unaruhusiwa tu "vitendo" 3 vya kwanza, na hauruhusiwi "vitendo" 4. Labda hii ni ya ziada kwetu, kwa sababu tayari tunayo mfumo wa ulinzi wa ngazi 4, kimsingi, kwa saketi. Tunapendelea kujilinda na contours, badala ya ngazi ya insides.
Jinsi Visa, MasterCard na Sberbank hufanya kazi
Katika: - Ninataka kufafanua hoja kuhusu kubadili mtumiaji kutoka kituo kimoja cha data hadi kingine. Ninavyojua, Visa na MasterCard hufanya kazi kwa kutumia itifaki ya 8583 ya upatanishi wa binary, na kuna mchanganyiko huko. Na nilitaka kujua, sasa tunamaanisha kubadili - ni moja kwa moja "Visa" na "MasterCard" au kabla ya mifumo ya malipo, kabla ya usindikaji?
EK: - Hii ni kabla ya mchanganyiko. Michanganyiko yetu iko katika kituo kimoja cha data.
Katika: - Kwa kusema, una sehemu moja ya unganisho?
EK: - "Visa" na "MasterCard" - ndio. Kwa sababu tu Visa na MasterCard zinahitaji uwekezaji mkubwa katika miundombinu ili kuhitimisha mikataba tofauti ili kupata jozi ya pili ya mchanganyiko, kwa mfano. Zimehifadhiwa ndani ya kituo kimoja cha data, lakini ikiwa, Mungu amekataza, kituo chetu cha data, ambapo kuna mchanganyiko wa kuunganisha kwa Visa na MasterCard, hufa, basi tutakuwa na uhusiano na Visa na MasterCard waliopotea ...
Katika: - Wanawezaje kuhifadhiwa? Ninajua kuwa Visa inaruhusu muunganisho mmoja tu kwa kanuni!
EK: - Wanasambaza vifaa wenyewe. Kwa hali yoyote, tulipokea vifaa ambavyo havijatumika tena ndani.
Katika: - Kwa hivyo stendi ni kutoka kwa Viunga vyao vya Chungwa?..
EK: - Ndiyo.
Katika: - Lakini vipi kuhusu kesi hii: ikiwa kituo chako cha data kitatoweka, unawezaje kuendelea kukitumia? Au trafiki inasimama tu?
EK: - Hapana. Katika kesi hii, tutabadilisha trafiki kwa kituo kingine, ambacho, kwa kawaida, kitakuwa ghali zaidi kwetu na ghali zaidi kwa wateja wetu. Lakini trafiki haitapitia uunganisho wetu wa moja kwa moja kwa Visa, MasterCard, lakini kupitia Sberbank ya masharti (iliyozidi sana).
Ninaomba msamaha kwa hasira ikiwa niliwakosea wafanyakazi wa Sberbank. Lakini kwa mujibu wa takwimu zetu, kati ya benki za Kirusi, Sberbank huanguka mara nyingi. Sio mwezi unapita bila kitu kinachoanguka kwenye Sberbank.
Baadhi ya matangazo 🙂
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com