HighLoad++, Evgeniy Kuzovlev (EcommPay IT): hvað á að gera þegar mínúta af niður í miðbæ kostar $100000

Allir tala um þróunar- og prófunarferla, þjálfun starfsfólks, aukna hvatningu, en þessi ferli duga ekki þegar mínúta af þjónustustoppi kostar gífurlega fjármuni. Hvað á að gera þegar þú framkvæmir fjármálaviðskipti samkvæmt ströngu SLA? Hvernig á að auka áreiðanleika og bilanaþol kerfa þinna, taka þróun og prófanir út úr jöfnunni?

Næsta HighLoad++ ráðstefna verður haldin 6. og 7. apríl 2020 í St. Pétursborg. Upplýsingar og miðar fyrir tengill. 9. nóvember, 18:00. HighLoad++ Moskvu 2018, Delhi + Kolkata salur. Ritgerðir og kynningu.

Evgeniy Kuzovlev (hér eftir – EB): - Vinir, halló! Ég heiti Kuzovlev Evgeniy. Ég er frá EcommPay fyrirtækinu, ákveðin deild er EcommPay IT, upplýsingatæknideild fyrirtækjasamsteypunnar. Og í dag munum við tala um stöðvunartíma - um hvernig á að forðast þær, um hvernig á að lágmarka afleiðingar þeirra ef ekki er hægt að forðast þær. Efnið er svohljóðandi: „Hvað á að gera þegar mínúta af niður í miðbæ kostar $ 100“? Þegar horft er fram á veginn eru tölur okkar sambærilegar.

Hvað gerir EkommPay IT?

Hver erum við? Af hverju stend ég hér fyrir framan þig? Af hverju á ég rétt á að segja þér eitthvað hér? Og hvað munum við tala nánar um hér?

EkommPay fyrirtækjasamsteypa er alþjóðlegur yfirtökuaðili. Við vinnum greiðslur um allan heim - í Rússlandi, Evrópu, Suðaustur-Asíu (allt um heiminn). Við erum með 9 skrifstofur, 500 starfsmenn alls, og um tæplega helmingur þeirra eru sérfræðingar í upplýsingatækni. Allt sem við gerum, allt sem við græðum á, gerðum við sjálf.

Við skrifuðum allar vörur okkar (og við eigum töluvert mikið af þeim - í línunni okkar af stórum upplýsingatæknivörum höfum við um 16 mismunandi íhluti) sjálf; Við skrifum sjálf, við þróum okkur sjálf. Og í augnablikinu gerum við um milljón viðskipti á dag (milljónir er líklega rétta leiðin til að segja það). Við erum frekar ungt fyrirtæki - við erum aðeins um sex ára gömul.

Fyrir 6 árum síðan var það svona gangsetning þegar krakkarnir komu með fyrirtækinu. Þeir sameinuðust af hugmynd (það var ekkert annað en hugmynd), og við hlupum. Eins og öll gangsetning, hlupum við hraðar... Fyrir okkur var hraði mikilvægari en gæði.

Á einhverjum tímapunkti hættum við: við áttuðum okkur á því að við gætum einhvern veginn ekki lengur lifað á þessum hraða og með þeim gæðum og við þyrftum að einbeita okkur að gæðum fyrst. Á þessari stundu ákváðum við að skrifa nýjan vettvang sem væri réttur, skalanlegur og áreiðanlegur. Þeir byrjuðu að skrifa þennan vettvang (þeir byrjuðu að fjárfesta, þróa þróun, prófa), en á einhverjum tímapunkti komust þeir að því að þróun og prófun leyfði okkur ekki að ná nýju stigi þjónustugæða.

Þú býrð til nýja vöru, setur hana í framleiðslu, en samt mun eitthvað fara úrskeiðis einhvers staðar. Og í dag munum við tala um hvernig á að ná nýju gæðastigi (hvernig við gerðum það, um reynslu okkar), taka þróun og prófanir út úr jöfnunni; við munum tala um hvað er í boði fyrir rekstur - hvað rekstur getur gert sjálfan sig, hvað hún getur boðið upp á að prófa til að hafa áhrif á gæði.

Niðurtímar. Starfsboðorð.

Alltaf aðal hornsteinninn, það sem við munum í raun tala um í dag er niður í miðbæ. Hræðilegt orð. Ef við erum með niður í miðbæ er allt slæmt fyrir okkur. Við erum að hlaupa til að hækka það, stjórnendur halda þjóninum - Guð forði það ekki, eins og þeir segja í því lagi. Þetta er það sem við munum tala um í dag.

Þegar við fórum að breyta aðferðum okkar mynduðum við 4 boðorð. Ég læt þá kynna á glærunum:

Þessi boðorð eru frekar einföld:

• Finndu vandamálið fljótt.
• Losaðu þig við það enn hraðar.
• Hjálpaðu til við að skilja ástæðuna (síðar, fyrir hönnuði).
• Og staðla aðferðir.

Ég vil vekja athygli á lið nr. 2. Við erum að losa okkur við vandann, ekki leysa hann. Ákvörðun er aukaatriði. Fyrir okkur er aðalatriðið að notandinn er verndaður fyrir þessu vandamáli. Það mun vera til í einhverju einangruðu umhverfi, en þetta umhverfi mun ekki hafa neina snertingu við það. Reyndar munum við fara í gegnum þessa fjóra hópa vandamála (sum í smáatriðum, sum í minna smáatriðum), ég mun segja þér hvað við notum, hvaða viðeigandi reynslu við höfum í lausnum.

Úrræðaleit: Hvenær gerast þau og hvað á að gera við þau?

En við byrjum óreglu, við byrjum á lið nr. 2 - hvernig á að losna fljótt við vandamálið? Það er vandamál - við þurfum að laga það. "Hvað eigum við að gera í þessu?" - aðalspurningin. Og þegar við fórum að hugsa um hvernig ætti að laga vandamálið, þróuðum við fyrir okkur nokkrar kröfur sem bilanaleit verður að fylgja.

Til að móta þessar kröfur ákváðum við að spyrja okkur spurningarinnar: „Hvenær eigum við í vandræðum“? Og vandamál, eins og það kom í ljós, eiga sér stað í fjórum tilvikum:

• Vélbúnaðarbilun.
• Ytri þjónusta mistókst.
• Að breyta hugbúnaðarútgáfu (sama uppsetning).
• Sprengilegur álagsvöxtur.

Við tölum ekki um fyrstu tvo. Vélbúnaðarbilun er hægt að leysa á einfaldan hátt: þú verður að hafa allt afritað. Ef þetta eru diskar verða diskarnir að vera settir saman í RAID; ef þetta er netþjónn verður þjónninn að vera afritaður; ef þú ert með netinnviði verðurðu að leggja fram annað eintak af netuppbyggingunni, það er að taka það og afritaðu það. Og ef eitthvað bilar skiptir þú yfir í varaafl. Það er erfitt að segja neitt meira hér.

Annað er bilun í ytri þjónustu. Fyrir flesta er kerfið alls ekki vandamál, en ekki fyrir okkur. Þar sem við vinnum úr greiðslum erum við samansafn sem stendur á milli notandans (sem slær inn kortagögn hans) og banka, greiðslukerfa (Visa, MasterCard, Mira o.s.frv.). Ytri þjónusta okkar (greiðslukerfi, bankar) hefur tilhneigingu til að mistakast. Hvorki við né þú (ef þú ert með slíka þjónustu) getum haft áhrif á þetta.

Hvað á þá að gera? Hér eru tveir kostir. Í fyrsta lagi, ef þú getur, ættir þú að afrita þessa þjónustu á einhvern hátt. Til dæmis, ef við getum, flytjum við umferð frá einni þjónustu til annarrar: til dæmis voru kort unnin í gegnum Sberbank, Sberbank er í vandræðum - við flytjum umferð [skilyrt] til Raiffeisen. Annað sem við getum gert er að taka mjög fljótt eftir bilun í ytri þjónustu og því munum við tala um viðbragðshraða í næsta hluta skýrslunnar.

Reyndar, af þessum fjórum, getum við sérstaklega haft áhrif á breytingar á hugbúnaðarútgáfum - grípa til aðgerða sem leiða til bata á ástandinu í samhengi við dreifingu og í samhengi við sprengivaxinn álagsvöxt. Reyndar, það er það sem við gerðum. Hér, aftur, smá athugasemd...

Af þessum fjórum vandamálum eru nokkur leyst strax ef þú ert með ský. Ef þú ert í Microsoft Azhur, Ozone skýjunum, eða notar skýin okkar, frá Yandex eða Mail, þá verður að minnsta kosti vélbúnaðarbilun vandamál þeirra og allt verður strax í lagi fyrir þig í tengslum við vélbúnaðarbilun.

Við erum svolítið óhefðbundið fyrirtæki. Hér eru allir að tala um „Kubernets“, um ský - við höfum hvorki „Kubernets“ né ský. En við erum með rekki af vélbúnaði í mörgum gagnaverum, og við neyðumst til að lifa á þessum vélbúnaði, við erum neydd til að bera ábyrgð á þessu öllu. Þess vegna munum við tala í þessu samhengi. Svo, um vandamálin. Fyrstu tveir voru teknir út fyrir sviga.

Að breyta hugbúnaðarútgáfu. Basar

Hönnuðir okkar hafa ekki aðgang að framleiðslu. Afhverju er það? Það er bara það að við erum PCI DSS vottuð og þróunaraðilar okkar hafa einfaldlega ekki rétt til að komast inn í „vöruna“. Það er það, punktur. Alls. Þess vegna lýkur þróunarábyrgð nákvæmlega á því augnabliki þegar þróun sendir bygginguna til útgáfu.

Annar grundvöllur okkar sem við höfum, sem einnig hjálpar okkur mikið, er skortur á einstakri óskráðri þekkingu. Ég vona að það sé eins hjá þér. Vegna þess að ef þetta er ekki raunin muntu eiga í vandræðum. Vandamál munu koma upp þegar þessi einstaka, óskráða þekking er ekki til staðar á réttum tíma á réttum stað. Segjum að þú sért með eina manneskju sem veit hvernig á að nota ákveðinn íhlut - viðkomandi er ekki til staðar, hann er í fríi eða veikur - það er það, þú átt í vandræðum.

Og þriðji grunnurinn sem við erum komin að. Við komumst að því með sársauka, blóði, tárum - við komumst að þeirri niðurstöðu að öll smíði okkar innihaldi villur, jafnvel þótt það sé villulaust. Við ákváðum þetta sjálf: þegar við sendum eitthvað í notkun, þegar við komum einhverju í framleiðslu, erum við með smíði með villum. Við höfum mótað þær kröfur sem kerfið okkar verður að uppfylla.

Kröfur til að breyta hugbúnaðarútgáfu

Það eru þrjár kröfur:

• Við verðum fljótt að draga til baka dreifinguna.
• Við verðum að lágmarka áhrif misheppnaðar dreifingar.
• Og við verðum að geta dreift hratt samhliða.
  Nákvæmlega í þessari röð! Hvers vegna? Vegna þess að fyrst og fremst, þegar þú setur upp nýja útgáfu, er hraði ekki mikilvægur, en það er mikilvægt fyrir þig, ef eitthvað fer úrskeiðis, að snúa hratt til baka og hafa lágmarks áhrif. En ef þú ert með sett af útgáfum í framleiðslu, þar sem það kemur í ljós að það er villa (upp úr þurru, það var engin dreifing, en það er villa) - hraði síðari dreifingar er mikilvægur fyrir þig. Hvað höfum við gert til að mæta þessum kröfum? Við notuðum eftirfarandi aðferðafræði:

  
  
  Það er nokkuð vel þekkt, við höfum aldrei fundið það upp - þetta er Blue/Green dreifing. Hvað það er? Þú verður að hafa eintak fyrir hvern hóp netþjóna sem forritin þín eru sett upp á. Afritið er „heitt“: það er engin umferð á því, en hvenær sem er er hægt að senda þessa umferð á þetta eintak. Þetta eintak inniheldur fyrri útgáfu. Og á þeim tíma sem dreifing er sett upp, rúllar þú kóðanum út í óvirkt eintak. Síðan skiptir þú hluta af umferðinni (eða öllu) yfir í nýju útgáfuna. Þannig að til að breyta umferðarflæðinu frá gömlu útgáfunni í þá nýju þarftu að gera aðeins eina aðgerð: þú þarft að breyta jafnvægisbúnaðinum í andstreymis, breyta stefnu - frá einum andstreymis til annars. Þetta er mjög þægilegt og leysir vandamálið við fljótlega skiptingu og fljótlega afturköllun.

  Hér er lausnin á seinni spurningunni að lágmarka: þú getur aðeins sent hluta af umferð þinni á nýja línu, í línu með nýjum kóða (látum það vera t.d. 2%). Og þessi 2% eru ekki 100%! Ef þú tapaðir 100% af umferð þinni vegna misheppnaðrar dreifingar, þá er það skelfilegt; ef þú tapaðir 2% af umferð þinni er það óþægilegt, en það er ekki skelfilegt. Þar að auki munu notendur líklegast ekki einu sinni taka eftir þessu, því í sumum tilfellum (ekki í öllum) verður sami notandi, sem ýtir á F5, fluttur í aðra virka útgáfu.

  Blá/græn uppsetning. Leiðsögn

  Hins vegar er ekki allt svo einfalt „Blue/Green deploy“... Öllum íhlutum okkar má skipta í þrjá hópa:

  • þetta er framhliðin (greiðslusíður sem viðskiptavinir okkar sjá);
  • vinnslu kjarna;
  • millistykki til að vinna með greiðslukerfum (banka, MasterCard, Visa...).

  Og það er blæbrigði hér - blæbrigðið liggur í leiðinni á milli línanna. Ef þú skiptir bara 100% af umferðinni, þá ertu ekki með þessi vandamál. En ef þú vilt skipta um 2% byrjarðu að spyrja spurninga: "Hvernig á að gera þetta?" Það einfaldasta er beint áfram: þú getur sett upp Round Robin í nginx eftir handahófi og þú hefur 2% til vinstri, 98% til hægri. En þetta hentar ekki alltaf.

  Til dæmis, í okkar tilviki, hefur notandi samskipti við kerfið með fleiri en einni beiðni. Þetta er eðlilegt: 2, 3, 4, 5 beiðnir - kerfin þín gætu verið þau sömu. Og ef það er mikilvægt fyrir þig að allar beiðnir notandans komi á sömu línu og fyrsta beiðnin kom á, eða (annar liður) allar beiðnir notandans berast í nýju línuna eftir skiptingu (hann hefði getað byrjað að vinna fyrr með kerfi, áður en skipt er), - þá hentar þessi tilviljanakennda dreifing ekki þér. Þá eru eftirfarandi valkostir:

  
  
  Fyrsti valkosturinn, sá einfaldasti, er byggður á grunnbreytum viðskiptavinarins (IP Hash). Þú ert með IP og þú skiptir henni frá hægri til vinstri eftir IP tölu. Þá mun annað tilvikið sem ég lýsti virka fyrir þig, þegar uppsetningin átti sér stað gæti notandinn þegar byrjað að vinna með kerfið þitt, og frá því augnabliki sem uppsetningin fer fram munu allar beiðnir fara í nýja línu (í þá sömu, td).

  Ef þetta hentar þér af einhverjum ástæðum ekki og þú verður að senda beiðnir á línuna þar sem upphaflega, upphaflega beiðni notandans kom, þá hefurðu tvo möguleika...
  Fyrsti valkosturinn: þú getur keypt borgað nginx+. Það er Sticky session vélbúnaður, sem, eftir fyrstu beiðni notandans, úthlutar lotu til notandans og bindur hana við einn eða annan andstreymis. Allar síðari notendabeiðnir innan lífstíma lotunnar verða sendar til sama andstreymis þar sem lotan var birt.

  Þetta hentaði okkur ekki vegna þess að við vorum þegar með venjulegan nginx. Að skipta yfir í nginx+ er ekki það að það sé dýrt, það er bara að það var svolítið sársaukafullt fyrir okkur og ekki mjög rétt. „Sticks Sessions“, til dæmis, virkaði ekki fyrir okkur af þeirri einföldu ástæðu að „Sticks Sessions“ leyfa ekki beina út frá „Annaðhvort-eða“. Þar geturðu tilgreint hvað við „Sticks Sessions“ gerum, til dæmis með IP-tölu eða IP-tölu og vafrakökum eða með postparameter, en „Annaðhvort-eða“ er flóknara þar.

  Þess vegna komum við að fjórða valkostinum. Við tókum nginx á sterum (þetta er openresty) - þetta er sama nginx, sem styður að auki innlimun síðustu forskrifta. Þú getur skrifað síðasta handrit, gefið því „opna hvíld“ og þetta síðasta handrit verður keyrt þegar notendabeiðnin kemur.

  Og við skrifuðum í raun slíkt handrit, settum okkur „openresti“ og í þessu handriti flokkum við í gegnum 6 mismunandi breytur með samtengingu „Eða“. Það fer eftir tilvist einnar eða annarrar breytu, við vitum að notandinn kom á eina síðu eða aðra, eina línu eða aðra.

  Blá/græn dreifing. Kostir og gallar

  Auðvitað var líklega hægt að gera þetta aðeins einfaldara (notaðu sömu „Sticky Sessions“), en við höfum líka þann blæ að ekki aðeins notandinn hefur samskipti við okkur innan ramma einnar vinnslu á einni færslu... En greiðslukerfi hafa einnig samskipti við okkur: Eftir að við vinnum úr viðskiptunum (með því að senda beiðni til greiðslukerfisins) fáum við afturköllun.
  Og við skulum segja, ef inni í hringrásinni okkar getum við framsent IP tölu notandans í öllum beiðnum og skipt notendum út frá IP tölunni, þá munum við ekki segja sama „Visa“: „Guð, við erum svo retro fyrirtæki, okkur virðist að vera alþjóðlegur (á vefsíðunni og í Rússlandi)... Vinsamlegast gefðu okkur upp IP-tölu notandans í viðbótarreit, samskiptareglur þínar eru staðlaðar“! Það er ljóst að þeir verða ekki sammála.

  
  
  Þess vegna virkaði þetta ekki fyrir okkur - við gerðum openresty. Í samræmi við það, með vegvísun fengum við eitthvað á þessa leið:

  Blue/Green Deployment hefur, í samræmi við það, þá kosti sem ég nefndi og galla.

  Tveir ókostir:

  • þú þarft að skipta þér af leiðsögn;
  • annar helsti ókosturinn er kostnaðurinn.

  Þú þarft tvöfalt fleiri netþjóna, þú þarft tvöfalt fleiri rekstrarauðlindir, þú þarft að eyða tvöfalt meiri fyrirhöfn til að viðhalda öllum þessum dýragarði.

  Við the vegur, meðal kostanna er eitt enn sem ég hef ekki nefnt áður: þú hefur varasjóð ef álagsvöxtur er. Ef þú ert með mikla aukningu á álagi, ertu með mikinn fjölda notenda, þá tekurðu einfaldlega aðra línuna inn í 50 til 50 dreifinguna - og þú ert strax kominn með x2 netþjóna í þyrpingunni þinni þar til þú leysir vandamálið með að hafa fleiri netþjóna.

  Hvernig á að gera hraðvirka dreifingu?

  Við ræddum um hvernig á að leysa vandamálið við að lágmarka og skjóta afturköllun, en spurningin er enn: "Hvernig á að dreifa fljótt?"

  
  
  Hér er stutt og einfalt.

  • Þú verður að vera með geisladiskakerfi (Stöðug afhending) - þú getur ekki lifað án þess. Ef þú ert með einn netþjón geturðu dreift handvirkt. Við erum með um eitt og hálft þúsund netþjóna og eitt og hálft þúsund handföng, auðvitað - við getum plantað deild á stærð við þetta herbergi bara til að dreifa.
  • Dreifing verður að vera samhliða. Ef dreifing þín er í röð, þá er allt slæmt. Einn netþjónn er eðlilegur, þú munt vera með eitt og hálft þúsund netþjóna allan daginn.
  • Aftur, fyrir hröðun er þetta líklega ekki lengur nauðsynlegt. Meðan á dreifingu stendur er verkefnið venjulega byggt. Þú ert með vefverkefni, það er framhlið (þar gerirðu vefpakka, þú safnar saman npm - eitthvað svoleiðis) og þetta ferli er í grundvallaratriðum stutt - 5 mínútur, en þessar 5 mínútur geta vera gagnrýninn. Þess vegna, til dæmis, gerum við það ekki: við fjarlægðum þessar 5 mínútur, við sendum gripi.

    Hvað er gripur? Artifact er samsett bygging þar sem allir samsetningarhlutar hafa þegar verið kláraðir. Við geymum þennan grip í gripageymslunni. Á sínum tíma notuðum við tvær slíkar geymslur - það var Nexus og nú jFrog Artifactory. Við notuðum upphaflega „Nexus“ vegna þess að við byrjuðum að æfa þessa nálgun í Java forritum (það hentaði vel). Síðan settu þeir nokkur af forritunum sem eru skrifuð í PHP þar inn; og „Nexus“ hentaði ekki lengur og því völdum við jFrog Artefactory, sem getur smíðað nánast allt. Við höfum meira að segja komist að því að í þessari gripageymslu geymum við okkar eigin tvöfalda pakka sem við söfnum fyrir netþjóna.

  Sprengilegur álagsvöxtur

  Við ræddum um að breyta hugbúnaðarútgáfunni. Það næsta sem við höfum er sprengifim aukning á álagi. Hér meina ég líklega með sprengilegum vexti álagsins ekki alveg rétt...

  Við skrifuðum nýtt kerfi - það er þjónustumiðað, smart, fallegt, starfsmenn alls staðar, biðraðir alls staðar, ósamstilltur alls staðar. Og í slíkum kerfum geta gögn streymt í gegnum mismunandi flæði. Fyrir fyrstu færsluna er hægt að nota 1., 3., 10. starfsmann, fyrir aðra færslu - 2., 4., 5. Og í dag, við skulum segja, á morgnana hefurðu gagnaflæði sem notar fyrstu þrjá starfsmennina og á kvöldin breytist það verulega og allt notar hina þrjá starfsmennina.

  Og hér kemur í ljós að þú þarft einhvern veginn að stækka starfsmennina, þú þarft einhvern veginn að stækka þjónustu þína, en á sama tíma koma í veg fyrir uppblásinn auðlinda.

  
  
  Við höfum skilgreint kröfur okkar. Þessar kröfur eru frekar einfaldar: að það sé Þjónustuuppgötvun, breytugreining - allt er staðlað til að byggja upp slík stigstærð kerfi, nema einn punktur - auðlindaafskrift. Við sögðum að við værum ekki tilbúin að afskrifa auðlindir þannig að netþjónarnir hiti loftið. Við tókum „Consul“, við tókum „Nomad“, sem stjórnar starfsmönnum okkar.

  Hvers vegna er þetta vandamál fyrir okkur? Við skulum fara aðeins til baka. Nú eru um 70 greiðslukerfi að baki. Um morguninn fer umferð í gegnum Sberbank, þá féll Sberbank til dæmis og við skiptum honum yfir í annað greiðslukerfi. Við vorum með 100 starfsmenn fyrir Sberbank og eftir það þurfum við að fjölga verulega um 100 starfsmenn fyrir annað greiðslukerfi. Og það er æskilegt að allt þetta gerist án þátttöku manna. Vegna þess að ef það er mannleg þátttaka ætti það að vera verkfræðingur sem situr þarna allan sólarhringinn, sem ætti bara að gera þetta, því svona bilanir, þegar 24 kerfi eru að baki, gerast reglulega.

  Þess vegna skoðuðum við Nomad, sem er með opna IP, og skrifuðum okkar eigin hlut, Scale-Nomad - ScaleNo, sem gerir um það bil eftirfarandi: það fylgist með vexti biðröðarinnar og fækkar eða fjölgar starfsmanna eftir gangverki af röðinni. Þegar við gerðum það hugsuðum við: "Kannski getum við opnað það?" Svo horfðu þeir á hana - hún var eins einföld og tvær kopekjur.

  Hingað til höfum við ekki fengið það opið, en ef skyndilega eftir skýrsluna, eftir að þú áttar þig á því að þú þarft slíkt, þarftu það, tengiliðir mínir eru á síðustu glærunni - vinsamlegast skrifaðu mér. Ef það eru að minnsta kosti 3-5 manns munum við styrkja það.

  
  
  Hvernig það virkar? Við skulum skoða! Horft fram á við: vinstra megin er hluti af vöktun okkar: þetta er ein lína, efst er tími vinnslu atburða, í miðjunni er fjöldi viðskipta, neðst er fjöldi starfsmanna.

  Ef þú skoðar þá er galli í þessari mynd. Á efsta töflunni hrundi eitt af töflunum á 45 sekúndum - eitt greiðslukerfanna fór niður. Strax kom umferð inn á 2 mínútum og röðin fór að stækka á öðru greiðslukerfi, þar sem engir starfsmenn voru (við nýttum ekki fjármagn - þvert á móti ráðstuðum við auðlindinni rétt). Við vildum ekki hita - það var lágmarksfjöldi, um 5-10 starfsmenn, en þeir réðu ekki við.

  Síðasta línuritið sýnir „hnúð“ sem þýðir bara að „Skaleno“ tvöfaldaði þessa upphæð. Og svo, þegar línuritið lækkaði aðeins, minnkaði hann það aðeins - fjölda starfsmanna var breytt sjálfkrafa. Þannig virkar þetta. Við ræddum um lið númer 2 - "Hvernig á að losna fljótt við ástæður."

  Eftirlit. Hvernig á að bera kennsl á vandamálið fljótt?

  Nú er fyrsti liðurinn "Hvernig á að bera kennsl á vandamálið fljótt?" Eftirlit! Við verðum að skilja ákveðna hluti fljótt. Hvaða hluti ættum við að skilja fljótt?

  
  
  Þrennt!

  • Við verðum að skilja og skilja fljótt árangur eigin auðlinda okkar.
  • Við verðum að skilja bilanir fljótt og fylgjast með frammistöðu kerfa sem eru utan við okkur.
  • Þriðja atriðið er að bera kennsl á rökfræðilegar villur. Þetta er þegar kerfið er að virka fyrir þig, allt er eðlilegt samkvæmt öllum vísbendingum, en eitthvað fer úrskeiðis.

  Ég mun sennilega ekki segja þér neitt svona flott hér. Ég verð Captain Obvious. Við leituðum að því sem var á markaðnum. Við erum með „skemmtilegur dýragarður“. Þetta er svona dýragarður sem við höfum núna:

  
  
  Við notum Zabbix til að fylgjast með vélbúnaði, til að fylgjast með helstu vísbendingum netþjóna. Við notum Okmeter fyrir gagnagrunna. Við notum „Grafana“ og „Prometheus“ fyrir alla aðra vísbendingar sem passa ekki við fyrstu tvo, sumir með „Grafana“ og „Prometheus“ og sumir með „Grafana“ með „Influx“ og Telegraf.

  Fyrir ári síðan vildum við nota New Relic. Flott mál, það getur allt. En eins mikið og hún getur gert allt, þá er hún svo dýr. Þegar við vorum orðnir 1,5 þúsund netþjónar kom söluaðili til okkar og sagði: „Við skulum gera samning fyrir næsta ár. Við skoðuðum verðið og sögðum nei, við munum ekki gera það. Nú erum við að yfirgefa New Relic, við eigum um 15 netþjóna eftir undir eftirliti New Relic. Verðið reyndist algjörlega villt.

  Og það er eitt tól sem við útfærðum sjálf - þetta er Debugger. Í fyrstu kölluðum við það „Bagger“ en svo gekk enskukennari framhjá, hló ógurlega og nefndi hana „Debagger“. Hvað það er? Þetta er tól sem í raun, á 15-30 sekúndum á hverjum íhlut, eins og „svartur kassi“ kerfisins, keyrir próf á heildarframmistöðu íhlutans.

  Til dæmis ef það er ytri síða (greiðslusíða) opnar hann hana einfaldlega og skoðar hvernig hún á að líta út. Ef þetta er í vinnslu sendir hann prufu „færslu“ og sér til þess að þessi „færsla“ berist. Ef þetta er tenging við greiðslukerfi þá skjótum við prófbeiðni í samræmi við það, þar sem við getum, og sjáum að allt er í lagi hjá okkur.

  Hvaða vísbendingar eru mikilvægar til að fylgjast með?

  Hvað fylgjumst við aðallega með? Hvaða vísbendingar eru mikilvægar fyrir okkur?

  
  

  • Viðbragðstími / RPS á vígstöðvum er mjög mikilvægur mælikvarði. Hann svarar strax að eitthvað sé að þér.
  • Fjöldi unninna skeyta í öllum biðröðum.
  • Fjöldi starfsmanna.
  • Grunnmælingar um réttmæti.

  Síðasti punkturinn er „viðskipti“, „viðskipti“ mæligildi. Ef þú vilt fylgjast með því sama þarftu að skilgreina einn eða tvo mælikvarða sem eru helstu vísbendingar fyrir þig. Mælikvarði okkar er afköst (þetta er hlutfall fjölda vel heppnaðra viðskipta af heildarfærsluflæði). Ef eitthvað breytist í því með 5-10-15 mínútna millibili þýðir það að við eigum í vandræðum (ef það breytist verulega).

  Hvernig það lítur út fyrir okkur er dæmi um eina af stjórnunum okkar:

  
  
  Vinstra megin eru 6 línurit, þetta er í samræmi við línurnar - fjöldi starfsmanna og fjöldi skilaboða í biðröðunum. Hægra megin - RPS, RTS. Hér að neðan er sama „viðskipta“ mæligildi. Og í "viðskipta" mæligildinu getum við strax séð að eitthvað fór úrskeiðis í tveimur miðgröfunum... Þetta er bara enn eitt kerfið sem stendur fyrir aftan okkur og hefur fallið.

  Annað sem við þurftum að gera var að fylgjast með falli ytri greiðslukerfa. Hér tókum við OpenTracing - vélbúnaður, staðall, hugmyndafræði sem gerir þér kleift að rekja dreifð kerfi; og það var aðeins breytt. Hið staðlaða OpenTracing hugmyndafræði segir að við byggjum upp ummerki fyrir hverja einstaka beiðni. Við þurftum þetta ekki og vöfðum því inn í samantekt, samansafn. Við gerðum tæki sem gerir okkur kleift að fylgjast með hraða kerfanna fyrir aftan okkur.

  
  
  Línuritið sýnir okkur að eitt af greiðslukerfunum byrjaði að svara á 3 sekúndum - við eigum í vandræðum. Þar að auki mun þessi hlutur bregðast við þegar vandamál byrja, með 20-30 sekúndna millibili.

  Og þriðji flokkurinn af vöktunarvillum sem eru til staðar er rökrétt eftirlit.

  Satt að segja vissi ég ekki hvað ég átti að teikna á þessari glæru, því við höfðum lengi verið að leita á markaðnum að einhverju sem hentaði okkur. Við fundum ekkert svo við urðum að gera það sjálf.

  
  
  Hvað á ég við með rökréttu eftirliti? Jæja, ímyndaðu þér: þú býrð til kerfi (til dæmis Tinder klón); þú gerðir það, ræstir það. Árangursríkur framkvæmdastjóri Vasya Pupkin setti það á símann sinn, sér stúlku þar, líkar við hana ... og þess háttar fer ekki til stúlkunnar - slíkt fer til öryggisvarðarins Mikhalych frá sömu viðskiptamiðstöðinni. Framkvæmdastjórinn fer niður og spyr sig svo: „Af hverju brosir þessi öryggisvörður Mikhalych svona skemmtilega til hans?

  Í slíkum aðstæðum... Fyrir okkur hljómar þessi staða aðeins öðruvísi, því (ég skrifaði) þetta er orðsporstap sem leiðir óbeint til fjárhagslegs taps. Staðan okkar er þveröfug: Við gætum orðið fyrir beinu fjárhagslegu tjóni - til dæmis ef við gerðum viðskipti sem vel heppnuðust, en þau voru misheppnuð (eða öfugt). Ég þurfti að skrifa mitt eigið tól sem fylgist með fjölda vel heppnaðra viðskipta með tímanum með því að nota viðskiptavísa. Fann ekkert á markaðnum! Þetta er einmitt hugmyndin sem ég vildi koma á framfæri. Það er ekkert á markaðnum til að leysa svona vandamál.

  Þetta snerist um hvernig hægt væri að bera kennsl á vandamálið fljótt.

  Hvernig á að ákvarða ástæður dreifingar

  Þriðji hópurinn af vandamálum sem við leysum er eftir að við höfum greint vandamálið, eftir að við höfum losnað við það, væri gott að skilja ástæðuna fyrir þróuninni, til að prófa, og gera eitthvað í því. Í samræmi við það þurfum við að rannsaka, við þurfum að hækka stokkana.

  
  
  Ef við erum að tala um logs (aðal ástæðan er logs), þá er meginhluti logs okkar í ELK Stack - næstum allir hafa það sama. Fyrir suma er það kannski ekki í ELK, en ef þú skrifar logs í gígabætum, þá kemur fyrr eða síðar til ELK. Við skrifum þær í terabætum.

  
  
  Hér er vandamál. Við redduðum því, leiðréttum villuna fyrir notandann, fórum að grafa út hvað var þarna, klifruðum upp í Kibana, settum inn færslukennið þar og fengum svona fótklút (sýnir margt). Og nákvæmlega ekkert er á hreinu í þessum fótaklæði. Hvers vegna? Já, vegna þess að það er ekki ljóst hvaða hluti tilheyrir hvaða starfsmanni, hvaða hluti tilheyrir hvaða hluta. Og á því augnabliki áttuðum við okkur á því að við þurftum að rekja - sama OpenTracing og ég talaði um.

  Við hugsuðum þetta fyrir ári síðan, beinum athygli okkar að markaðnum og það voru tvö verkfæri þar - „Zipkin“ og „Jaeger“. „Jager“ er í raun svo hugmyndafræðilegur erfingi, hugmyndafræðilegur arftaki „Zipkin“. Allt er gott í Zipkin, nema að það veit ekki hvernig á að safna saman, það veit ekki hvernig á að taka logs inn í rakninguna, aðeins tímarekja. Og „Jager“ studdi þetta.

  Við skoðuðum „Jager“: þú getur hljóðfæraforrit, þú getur skrifað í Api (Api staðallinn fyrir PHP á þeim tíma var hins vegar ekki samþykktur - þetta var fyrir ári síðan, en nú hefur það þegar verið samþykkt), en þar var nákvæmlega enginn viðskiptavinur. „Allt í lagi,“ hugsuðum við og skrifuðum okkar eigin viðskiptavin. Hvað fengum við? Svona lítur þetta í grófum dráttum út:

  
  
  Í Jaeger eru spannar búnar til fyrir hvert skeyti. Það er að segja að þegar notandi opnar kerfið sér hann einn eða tvo blokka fyrir hverja beiðni sem berast (1-2-3 - fjöldi beiðna sem berast frá notanda, fjöldi blokka). Til að auðvelda notendum bættum við merkjum við annálana og tímaspor. Í samræmi við það, ef villa er, mun forritið okkar merkja annálinn með viðeigandi villumerki. Þú getur síað eftir villumerki og aðeins spönn sem innihalda þennan kubb með villu birtast. Svona lítur það út ef við stækkum breiddina:

  
  
  Inni í spaninu er sett af ummerkjum. Í þessu tilviki eru þetta þrjú prófunarspor og þriðja sporið segir okkur að villa hafi átt sér stað. Á sama tíma, hér sjáum við tímaspor: við höfum tímakvarða efst og við sjáum á hvaða tímabili þessi eða hinn loginn var skráður.

  Það gekk því vel hjá okkur. Við skrifuðum okkar eigin viðbót og við opnum hana. Ef þú vilt vinna með rakningu, ef þú vilt vinna með „Jager“ í PHP, þá er viðbótin okkar, velkomið að nota, eins og sagt er:

  
  
  Við erum með þessa viðbót - hún er viðskiptavinur fyrir OpenTracing Api, hún er gerð sem php-framlenging, það er að segja að þú þarft að setja hana saman og setja hana upp á kerfið. Fyrir ári síðan var ekkert öðruvísi. Nú eru aðrir viðskiptavinir sem eru eins og íhlutir. Hér er það undir þér komið: annað hvort dælir þú íhlutunum út með tónskáldi, eða þú notar framlengingu upp til þín.

  Staðlar fyrirtækja

  Við töluðum um boðorðin þrjú. Fjórða boðorðið er að staðla aðferðir. Um hvað snýst þetta? Þetta snýst um þetta:

  
  
  Af hverju er orðið "fyrirtæki" hér? Ekki vegna þess að við erum stórt eða skrifræðislegt fyrirtæki, nei! Ég vildi nota orðið „fyrirtæki“ hér í því samhengi að hvert fyrirtæki, sérhver vara ætti að hafa sína eigin staðla, þar með talið þú. Hvaða staðla höfum við?

  
  

  • Við höfum dreifingarreglur. Við erum ekki að flytja neitt án hans, við getum það ekki. Við sendum um 60 sinnum í viku, það er, við sendum nánast stöðugt. Á sama tíma höfum við, til dæmis, í útsetningarreglugerðinni bannorð um útsendingar á föstudag - í grundvallaratriðum sendum við ekki út.
  • Við þurfum skjöl. Ekki einn nýr íhlutur kemst í framleiðslu ef engin skjöl eru fyrir honum, jafnvel þótt hann hafi fæðst undir penna RnD sérfræðinga okkar. Við krefjumst frá þeim dreifingarleiðbeiningar, vöktunarkort og grófa lýsingu (eins og forritarar geta skrifað) á því hvernig þessi hluti virkar, hvernig á að leysa hann.
  • Við leysum ekki orsök vandans, heldur vandamálið - það sem ég sagði þegar. Það er mikilvægt fyrir okkur að vernda notandann fyrir vandamálum.
  • Við höfum heimildir. Við lítum til dæmis ekki á það sem niður í miðbæ ef við misstum 2% af umferð innan tveggja mínútna. Þetta er í grundvallaratriðum ekki innifalið í tölfræði okkar. Ef það er meira í prósentum talið eða tímabundið, teljum við nú þegar.
  • Og við skrifum alltaf skurðaðgerðir. Hvað sem verður um okkur, allar aðstæður þar sem einhver hegðar sér óeðlilega í framleiðslu mun endurspeglast í eftirlíkingu. Postmortem er skjal þar sem þú skrifar hvað kom fyrir þig, nákvæma tímasetningu, hvað þú gerðir til að leiðrétta það og (þetta er skylda blokk!) hvað þú munt gera til að koma í veg fyrir að þetta gerist í framtíðinni. Þetta er skylda og nauðsynlegt fyrir síðari greiningu.

  Hvað telst niðurtími?

  
  
  Til hvers leiddi þetta allt?

  Þetta leiddi til þess að (við áttum í vissum vandræðum með stöðugleika, þetta hentaði hvorki viðskiptavinum né okkur) síðastliðna 6 mánuði var stöðugleikavísirinn 99,97. Við getum sagt að þetta er ekki mjög mikið. Já, við höfum eitthvað að stefna að. Af þessum mælikvarða er um helmingur stöðugleiki, sem sagt, ekki okkar, heldur eldvegg vefforrita okkar, sem stendur fyrir framan okkur og er notaður sem þjónusta, en viðskiptavinum er sama um þetta.

  Við lærðum að sofa á nóttunni. Loksins! Fyrir sex mánuðum gátum við það ekki. Og á þessari athugasemd með niðurstöðunum vil ég gera eina aths. Í gærkvöldi var dásamleg skýrsla um stjórnkerfi fyrir kjarnaofn. Ef fólkið sem skrifaði þetta kerfi getur heyrt í mér, vinsamlegast gleymdu því sem ég sagði um „2% er ekki niður í miðbæ“. Fyrir þig eru 2% niður í miðbæ, jafnvel þó í tvær mínútur!

  Það er allt og sumt! Spurningar þínar.

  
  

  Um jafnvægismenn og gagnaflutninga

  Spurning frá sal (hér eftir – B): – Gott kvöld. Þakka þér kærlega fyrir svona stjórnandaskýrslu! Stutt spurning um jafnvægismennina þína. Þú nefndir að þú sért með WAF, semsagt eins og ég skil það þá notarðu einhverskonar ytri jafnvægisbúnað...

  EK: – Nei, við notum þjónustu okkar sem jafnvægistæki. Í þessu tilfelli er WAF eingöngu DDoS verndartól fyrir okkur.

  IN: – Geturðu sagt nokkur orð um jafnvægismenn?

  EK: – Eins og ég sagði þegar, þetta er hópur netþjóna í openresty. Núna erum við með 5 varahópa sem svara eingöngu... þ.e. þjónn sem keyrir eingöngu openresty, hann proxar bara umferð. Í samræmi við það, til að skilja hversu mikið við eigum: við erum nú með reglulegt umferðarflæði upp á nokkur hundruð megabita. Þeir takast á við, þeim líður vel, þeir reyna ekki einu sinni á sig.

  IN: — Einnig einföld spurning. Hér er blá/græn uppsetning. Hvað gerirðu til dæmis við gagnaflutninga?

  EK: - Góð spurning! Sko, í Blue/Green dreifingu höfum við aðskildar biðraðir fyrir hverja línu. Það er, ef við erum að tala um viðburðarraðir sem eru sendar frá starfsmanni til starfsmanns, þá eru aðskildar biðraðir fyrir bláu línuna og fyrir grænu línuna. Ef við erum að tala um gagnagrunninn sjálfan, þá þrengdum við hann vísvitandi eins mikið og við gátum, færðum allt nánast í biðraðir; í gagnagrunninum geymum við bara stafla af viðskiptum. Og viðskiptastafla okkar er sá sami fyrir allar línur. Með gagnagrunninn í þessu samhengi: við skiptum honum ekki í blátt og grænt, því báðar útgáfur kóðans verða að vita hvað er að gerast með viðskiptin.

  Vinir, ég á líka smá verðlaun til að hvetja ykkur áfram - bók. Og ég ætti að fá það fyrir bestu spurninguna.

  IN: - Halló. Takk fyrir skýrsluna. Spurningin er þessi. Þú fylgist með greiðslum, þú fylgist með þjónustunni sem þú hefur samskipti við... En hvernig fylgist þú með því að einhver kom einhvern veginn inn á greiðslusíðuna þína, greiddi og verkefnið færði honum peninga? Það er, hvernig fylgist þú með því að sölustaðurinn sé tiltækur og hafi samþykkt svarhringingu þína?

  EK: – „Merchant“ fyrir okkur í þessu tilfelli er nákvæmlega sama ytri þjónusta og greiðslukerfið. Við fylgjumst með viðbragðshraða söluaðila.

  Um dulkóðun gagnagrunns

  IN: - Halló. Ég er með svolítið tengda spurningu. Þú ert með PCI DSS viðkvæm gögn. Mig langaði að vita hvernig þú geymir PAN í biðröðum sem þú þarft að flytja inn í? Notarðu einhverja dulkóðun? Og þetta leiðir til seinni spurningarinnar: samkvæmt PCI DSS er nauðsynlegt að dulkóða gagnagrunninn reglulega ef breytingar verða (uppsögn stjórnenda osfrv.) - hvað verður um aðgengi í þessu tilfelli?

  
  
  EK: - Dásamleg spurning! Í fyrsta lagi geymum við ekki PAN í biðröðum. Við höfum ekki rétt til að geyma PAN hvar sem er á skýru formi, í grundvallaratriðum, svo við notum sérstaka þjónustu (við köllum hana „Kademon“) - þetta er þjónusta sem gerir aðeins eitt: hún fær skilaboð sem inntak og sendir út dulkóðuð skilaboð. Og við geymum allt með þessum dulkóðuðu skilaboðum. Samkvæmt því er lyklalengd okkar undir kílóbæti, þannig að þetta er alvarlegt og áreiðanlegt.

  IN: – Þarftu 2 kílóbæt núna?

  EK: – Það lítur út fyrir að það hafi verið 256 í gær... Jæja, hvar annars staðar?!

  Samkvæmt því er þetta sú fyrsta. Og í öðru lagi, lausnin sem er til, hún styður endurdulkóðunarferlið - það eru tvö pör af „keks“ (lykla), sem gefa „dekk“ sem dulkóða (lykillinn eru lyklarnir, dek eru afleiður lyklanna sem dulkóða) . Og ef aðferðin er hafin (það gerist reglulega, frá 3 mánuðum til ± sumra), halum við niður nýju pari af „kökum“ og við dulkóðum gögnin aftur. Við höfum sérstaka þjónustu sem rífur út öll gögn og dulkóðar þau á nýjan hátt; Gögnin eru geymd við hlið auðkennis lykilsins sem þau eru dulkóðuð með. Í samræmi við það, um leið og við dulkóðum gögnin með nýjum lyklum, eyðum við gamla lyklinum.

  Stundum þarf að greiða handvirkt...

  IN: – Það er að segja, ef endurgreiðsla hefur borist fyrir einhverja aðgerð, muntu samt afkóða hana með gamla lyklinum?

  EK: - Já.

  IN: — Svo ein lítil spurning í viðbót. Þegar einhvers konar bilun, fall eða atvik eiga sér stað er nauðsynlegt að keyra í gegnum viðskiptin handvirkt. Það er svona ástand.

  EK: - Já stundum.

  IN: — Hvaðan færðu þessi gögn? Eða ferðu sjálfur í þessa geymslu?

  EK: – Nei, auðvitað erum við með einhvers konar bakskrifstofukerfi sem inniheldur viðmót fyrir stuðning okkar. Ef við vitum ekki í hvaða stöðu viðskiptin eru (til dæmis þar til greiðslukerfið svaraði með tímamörkum), vitum við ekki fyrirfram, það er að segja að við úthlutum lokastöðunni aðeins með fullu öryggi. Í þessu tilviki úthlutum við færslunni í sérstaka stöðu fyrir handvirka vinnslu. Að morgni, daginn eftir, um leið og stuðningur fær upplýsingar um að slíkar og slíkar færslur séu eftir í greiðslukerfinu, vinna þeir úr þeim handvirkt í þessu viðmóti.

  
  
  IN: — Ég hef nokkrar spurningar. Einn af þeim er framhald PCI DSS svæðisins: hvernig skráir þú hringrás þeirra? Þessi spurning er vegna þess að verktaki gæti hafa sett hvað sem er í annálana! Önnur spurning: hvernig seturðu út flýtileiðréttingar? Notkun handföng í gagnagrunninum er einn möguleiki, en það geta verið ókeypis bráðaleiðréttingar - hvernig er aðferðin þar? Og þriðja spurningin tengist líklega RTO, RPO. Framboð þitt var 99,97, tæpar fjórar níur, en eins og ég skil það, þá ertu með annað gagnaver, þriðja gagnaver og fimmta gagnaver... Hvernig samstillir þú þær, endurteknar þær og allt hitt?

  EK: - Við skulum byrja á því fyrsta. Var fyrsta spurningin um logs? Þegar við skrifum logs höfum við lag sem felur öll viðkvæm gögn. Hún lítur á grímuna og á viðbótarreitin. Í samræmi við það koma skrárnar okkar út með gögnum sem þegar eru grímuð og PCI DSS hringrás. Þetta er eitt af þeim reglulegu verkefnum sem prófunardeildinni eru falin. Þeim er gert að athuga hvert verkefni, þar með talið annálana sem þeir skrifa, og þetta er eitt af reglulegu verkunum við kóðadóma, til að stjórna því að verktaki hafi ekki skrifað eitthvað niður. Eftirfarandi athuganir á þessu eru framkvæmdar reglulega af upplýsingaöryggisdeild um það bil einu sinni í viku: annálar fyrir síðasta dag eru teknar með vali og þær keyrðar í gegnum sérstakan skanna-greiningartæki frá prófunarþjónum til að athuga allt.
  Um heitar lagfæringar. Þetta er innifalið í dreifingarreglum okkar. Við höfum sérstaka klausu um flýtileiðréttingar. Við trúum því að við setjum upp flýtileiðir allan sólarhringinn þegar við þurfum á því að halda. Um leið og útgáfan er sett saman, um leið og hún er keyrð, um leið og við erum með grip, erum við með kerfisstjóra á vakt sem hringir frá stuðningi, og hann setur það í notkun á því augnabliki sem það er nauðsynlegt.

  Um "fjórar níur". Sú tala sem við höfum núna hefur sannarlega náðst og við sóttumst eftir því í öðru gagnaveri. Núna erum við með annað gagnaver og við erum að byrja að fara á milli þeirra og spurningin um afritun milli gagnavera er sannarlega ekki léttvæg spurning. Við reyndum að leysa það í einu með mismunandi aðferðum: við reyndum að nota sömu "Tarantúlu" - það virkaði ekki fyrir okkur, ég skal segja þér það strax. Þess vegna enduðum við á því að panta "sens" handvirkt. Reyndar keyrir hvert forrit í kerfinu okkar nauðsynlega „breyta – gert“ samstillingu milli gagnavera ósamstillt.

  IN: - Ef þú fékkst annan, hvers vegna fékkstu þá ekki þann þriðja? Vegna þess að enginn er með klofna heila ennþá...

  EK: - En við höfum ekki Split Brain. Vegna þess að hver umsókn er knúin áfram af fjölmeistara skiptir okkur ekki máli hvaða miðstöð beiðnin kom til. Við erum tilbúin fyrir þá staðreynd að ef eitt af gagnaverunum okkar bilar (við treystum á þetta) og í miðri notendabeiðni skiptir yfir í annað gagnaverið, erum við tilbúin að missa þennan notanda, örugglega; en þetta verða einingar, algjörar einingar.

  IN: - Gott kvöld. Takk fyrir skýrsluna. Þú talaðir um villuleitina þína, sem keyrir nokkrar prufufærslur í framleiðslu. En segðu okkur frá prófunarviðskiptum! Hversu djúpt fer það?

  EK: - Það fer í gegnum alla hringrás alls íhlutsins. Fyrir íhlut er enginn munur á próffærslu og framleiðslu. En frá rökréttu sjónarhorni er þetta einfaldlega sérstakt verkefni í kerfinu, þar sem aðeins próffærslur eru keyrðar á.

  IN: -Hvar klippirðu það af? Hér sendi Core...

  EK: – Við erum á bak við „Kor“ í þessu tilviki fyrir prófunarfærslur... Við höfum eitthvað sem heitir routing: „Kor“ veit í hvaða greiðslukerfi á að senda - við sendum í falskt greiðslukerfi, sem gefur einfaldlega http merki og það er allt og sumt.

  IN: – Segðu mér, vinsamlegast, var umsóknin þín skrifuð í einum risastórum einlitum, eða klipptir þú hana í einhverja þjónustu eða jafnvel örþjónustu?

  EK: - Við erum ekki með einliða, auðvitað erum við með þjónustumiðað forrit. Við grínast með að þjónustan okkar sé gerð úr einlitum - þeir eru í raun frekar stórir. Það er erfitt að kalla það örþjónustur, en þetta er þjónusta þar sem starfsmenn dreifðra véla starfa.

  Ef þjónustan á þjóninum er í hættu...

  IN: — Þá er ég með næstu spurningu. Jafnvel þótt þetta væri einlitur sagðirðu samt að þú sért með marga af þessum skyndiþjónum, þeir vinna allir í grundvallaratriðum úr gögnum og spurningin er: „Ef það er málamiðlun á einum af skyndiþjónunum eða forriti, hvaða einstaka hlekkur sem er. , hafa þeir einhvers konar aðgangsstýringu? Hver þeirra getur gert hvað? Hvern ætti ég að hafa samband við til að fá hvaða upplýsingar?

  
  
  EK: - Já örugglega. Öryggiskröfurnar eru nokkuð alvarlegar. Í fyrsta lagi erum við með opnar gagnahreyfingar og hafnirnar eru aðeins þær sem við sjáum fyrir um umferðarhreyfingu fyrirfram. Ef íhlutur hefur samskipti við gagnagrunninn (td við Muskul) í gegnum 5-4-3-2 verður aðeins 5-4-3-2 opinn fyrir hann og aðrar hafnir og aðrar umferðarleiðbeiningar verða ekki tiltækar. Að auki þarftu að skilja að í framleiðslu okkar eru um 10 mismunandi öryggislykkjur. Og jafnvel þótt forritið hafi á einhvern hátt verið í hættu, Guð forði frá sér, mun árásarmaðurinn ekki geta fengið aðgang að stjórnborði netþjónsins, vegna þess að þetta er annað netöryggissvæði.

  IN: – Og í þessu samhengi, það sem er áhugaverðara fyrir mig er að þú ert með ákveðna samninga við þjónustu - hvað þeir geta gert, í gegnum hvaða "aðgerðir" þeir geta haft samband... röð, listi yfir „aðgerðir“ á hinni. Þeir virðast ekki snúa sér til annarra í venjulegum aðstæðum og þeir bera önnur ábyrgðarsvið. Ef einhver þeirra er í hættu, mun það geta truflað „aðgerðir“ þeirrar þjónustu?

  EK: - Ég skil. Ef í venjulegum aðstæðum með öðrum miðlara voru samskipti yfirleitt leyfð, þá já. Samkvæmt SLA samningnum fylgjumst við ekki með því að þú hafir aðeins leyft fyrstu 3 „aðgerðirnar“ og þér er ekki leyfðar þessar 4 „aðgerðir“. Þetta er líklega óþarfi fyrir okkur, vegna þess að við erum nú þegar með 4 stiga verndarkerfi, í grundvallaratriðum, fyrir rafrásir. Við kjósum að verja okkur með útlínunum, frekar en á stigi innviðanna.

  Hvernig Visa, MasterCard og Sberbank virka

  IN: – Ég vil skýra atriði um að skipta notanda úr einu gagnaveri yfir í annað. Eftir því sem ég best veit starfa Visa og MasterCard með 8583 tvíundarsamstilltu samskiptareglunni og það eru blöndur þar. Og mig langaði að vita, nú meinum við að skipta - er það beint „Visa“ og „MasterCard“ eða fyrir greiðslukerfi, fyrir vinnslu?

  EK: - Þetta er fyrir blöndun. Blöndurnar okkar eru staðsettar í sama gagnaveri.

  IN: – Í grófum dráttum, ertu með einn tengipunkt?

  EK: – „Visa“ og „MasterCard“ - já. Einfaldlega vegna þess að Visa og MasterCard krefjast nokkuð alvarlegra fjárfestinga í innviðum til að gera sérstaka samninga til að fá annað par af blöndum, til dæmis. Þau eru frátekin innan einni gagnaveri, en ef guð forði okkur frá því að gagnaverið okkar, þar sem eru blöndur til að tengjast Visa og MasterCard, deyr, þá missum við tengingu við Visa og MasterCard...

  IN: – Hvernig er hægt að taka þau frá? Ég veit að Visa leyfir aðeins eina tengingu í grundvallaratriðum!

  EK: – Þeir útvega búnaðinn sjálfir. Allavega fengum við búnað sem er algjörlega óþarfur að innan.

  IN: – Þannig að standurinn er frá Connects Orange?

  EK: - Já.

  IN: – En hvað um þetta mál: ef gagnaverið þitt hverfur, hvernig geturðu haldið áfram að nota það? Eða stoppar umferðin bara?

  EK: - Nei. Í þessu tilviki munum við einfaldlega skipta um umferð yfir á aðra rás, sem auðvitað verður dýrari fyrir okkur og dýrari fyrir viðskiptavini okkar. En umferðin mun ekki fara í gegnum beina tengingu okkar við Visa, MasterCard, heldur í gegnum skilyrtan Sberbank (mjög ýkt).

  Ég biðst innilega afsökunar ef ég móðgaði starfsmenn Sberbank. En samkvæmt tölfræði okkar, meðal rússnesku bankanna, fellur Sberbank oftast. Það líður ekki mánuður án þess að eitthvað detti af hjá Sberbank.

  
  
  

  Nokkrar auglýsingar 🙂

  Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, cloud VPS fyrir forritara frá $4.99, einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: Allur sannleikurinn um VPS (KVM) E5-2697 v3 (6 kjarna) 10GB DDR4 480GB SSD 1Gbps frá $19 eða hvernig á að deila netþjóni? (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).

  Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 sjónvarp frá $199 í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um Hvernig á að byggja upp infrastructure Corp. flokki með notkun Dell R730xd E5-2650 v4 netþjóna að verðmæti 9000 evrur fyrir eyri?

Heimild: www.habr.com