HighLoad++, Evgeniy Kuzovlev (EcommPay IT): chì fà quandu un minutu di downtime costa $ 100000

Tutti parlanu di i prucessi di sviluppu è di prova, furmazione di u persunale, aumentu di a motivazione, ma sti prucessi ùn sò micca abbastanza quandu un minutu di downtime di serviziu custa enormi quantità di soldi. Cosa da fà quandu fate transazzione finanziaria sottu un strettu SLA? Cumu aumentà l'affidabilità è a tolleranza à i difetti di i vostri sistemi, piglià u sviluppu è a prova fora di l'equazioni?

A prossima cunferenza HighLoad++ si terrà u 6 è u 7 d'aprile di u 2020 in San Pietroburgo. Dettagli è biglietti per a lea. 9 nuvembre, 18 ore. HighLoad++ Mosca 00, Sala Delhi + Kolkata. Tesi è prisentazione.

Evgeniy Kuzovlev (in seguito - CE): - Amici, salutu ! Mi chjamu Kuzovlev Evgeniy. Sò di a cumpagnia EcommPay, una divisione specifica hè EcommPay IT, a divisione IT di u gruppu di cumpagnie. È oghje parlemu di i tempi di inattività - di cumu per evità, di cumu minimizzà e so cunsequenze si ùn pò micca esse evitata. U tema hè dichjaratu cusì: "Chì fà quandu un minutu di downtime costa $ 100"? In u futuru, i nostri numeri sò paragunabili.

Chì faci l'EcommPay IT?

Quale simu? Perchè sò quì davanti à voi ? Perchè aghju u dirittu di dì qualcosa quì ? E di ciò chì avemu da parlà quì in più detail ?

U gruppu di cumpagnie EcommPay hè un acquirente internaziunale. Tracemu i pagamenti in u mondu sanu - in Russia, Europa, Asia Sud-Est (Tuttu u mondu). Avemu 9 uffizii, 500 impiegati in totale, è circa un pocu menu di a mità di elli sò specialisti in IT. Tuttu ciò chì facemu, tuttu ciò chì facemu soldi, avemu fattu noi stessi.

Avemu scrittu tutti i nostri prudutti (è avemu assai di elli - in a nostra linea di grandi prudutti IT avemu circa 16 cumpunenti diffirenti) noi stessi; Scrivemu noi stessi, ci sviluppemu. È in u mumentu avemu fattu circa un milione di transazzione à ghjornu (milioni hè probabilmente u modu ghjustu per dì). Semu una cumpagnia abbastanza ghjovana - avemu solu circa sei anni.

6 anni fà era un tali startup quandu i picciotti sò ghjunti cù l'affari. Eranu uniti da un'idea (ùn c'era nunda d'altru chè una idea), è curriamu. Cum'è ogni startup, curriamu più veloce... Per noi, a rapidità era più impurtante chè a qualità.

À un certu puntu avemu firmatu: avemu capitu chì ùn pudemu micca più campà à quella velocità è cù quella qualità è avemu bisognu di fucalizza prima nantu à a qualità. À questu mumentu, avemu decisu di scrive una nova piattaforma chì seria curretta, scalabile è affidabile. Anu cuminciatu à scrive sta piattaforma (accuminciaru à invistisce, à sviluppà u sviluppu, à a prova), ma à un certu puntu anu capitu chì u sviluppu è a prova ùn ci permettenu micca di ghjunghje à un novu livellu di qualità di serviziu.

Fate un novu pruduttu, u mette in pruduzzione, ma ancu qualcosa andarà male in qualchì locu. È oghje parleremu di cumu ghjunghje à un novu livellu di qualità (cumu avemu fattu, nantu à a nostra sperienza), piglià u sviluppu è a prova fora di l'equazioni; Parleremu di ciò chì hè dispunibule per u funziunamentu - ciò chì l'operazione pò fà per sè stessu, ciò chì pò offre à a prova per influenzà a qualità.

I tempi di inattività. Cumandamenti di funziunamentu.

Sempre a petra principale, ciò chì avemu da parlà oghje hè u tempu di inattività. Una parolla terribili. Se avemu un tempu di inattività, tuttu hè male per noi. Emu currendu per alzà, l'amministratori tenenu u servitore - Diu ùn ne ùn cascà, cum'è dicenu in quella canzone. Hè ciò chì avemu da parlà oghje.

Quandu avemu cuminciatu à cambià i nostri approcci, avemu furmatu 4 cumandamenti. Li aghju presentati nantu à e diapositive:

Questi cumandamenti sò abbastanza sèmplice:

• Identificà rapidamente u prublema.
• Eliminate ancu più veloce.
• Aiutate à capisce u mutivu (più tardi, per i sviluppatori).
• È standardizà approcci.

Vogliu attirà a vostra attenzione à u puntu n ° 2. Ci sguassemu di u prublema, micca di risolve. A decisione hè secundaria. Per noi, a cosa primaria hè chì l'utilizatore hè prutettu da stu prublema. Esistirà in qualchì ambiente isolatu, ma questu ambiente ùn avarà micca cuntattu cù questu. In attu, andemu à traversu questi quattru gruppi di prublemi (alcuni in più dittaglii, altri in menu dettagliati), vi dicu ciò chì usemu, quale sperienza pertinente avemu in suluzioni.

Troubleshooting: Quandu succedenu è chì fà per elli?

Ma avemu da principià fora di l'ordine, avemu da principià cù u puntu N ° 2 - cumu per sguassà rapidamente u prublema? Ci hè un prublema - avemu bisognu di risolve. "Chì duvemu fà per questu?" - a quistione principale. È quandu avemu cuminciatu à pensà à cumu risolve u prublema, avemu sviluppatu per noi stessi alcuni requisiti chì a risoluzione di i prublemi deve seguità.

Per furmulà sti esigenze, avemu decisu di dumandà à noi stessi a quistione: "Quandu avemu prublemi"? È i prublemi, cum'è hè risultatu, sò in quattru casi:

• fallimentu hardware.
• I servizii esterni fiascatu.
• Cambia a versione di u software (a listessa implementazione).
• Crescita di carica esplosiva.

Ùn parlemu micca di i primi dui. Un malfunzionamentu di hardware pò esse risoltu abbastanza simplice: duvete avè tuttu duplicatu. Sì questi sò dischi, i dischi devenu esse assemblati in RAID; se questu hè un servitore, u servitore deve esse duplicatu; se avete una infrastruttura di rete, deve furnisce una seconda copia di l'infrastruttura di rete, vale à dì, pigliate è duplicà lu. È se qualcosa falla, cambiate à riservazione di putere. Hè difficiule di dì qualcosa di più quì.

U sicondu hè u fallimentu di servizii esterni. Per a maiò parte, u sistema ùn hè micca un prublema in tuttu, ma micca per noi. Siccomu processemu pagamentu, simu un aggregatore chì si trova trà l'utilizatore (chì inserisce i dati di a so carta) è i banche, i sistemi di pagamentu (Visa, MasterCard, Mira, etc.). I nostri servizii esterni (sistemi di pagamentu, banche) tendenu à fallu. Nè noi nè voi (se avete tali servizii) ponu influenzà questu.

Chì fà allora ? Ci sò dui opzioni quì. Prima, se pudete, duvete duplicà stu serviziu in qualchì modu. Per esempiu, se pudemu, trasferemu u trafficu da un serviziu à l'altru: per esempiu, i carte sò stati processati attraversu Sberbank, Sberbank hà avutu prublemi - trasfiremu u trafficu [condizionalmente] à Raiffeisen. A seconda cosa chì pudemu fà hè di nutà u fallimentu di i servizii esterni assai rapidamente, è per quessa parleremu di a rapidità di risposta in a prossima parte di u rapportu.

In fatti, di sti quattru, pudemu influenzà specificamente u cambiamentu di versioni di u software - piglià azzioni chì portanu à una migliione di a situazione in u cuntestu di implementazioni è in u cuntestu di crescita splussiva in carica. In fatti, hè ciò chì avemu fattu. Eccu, di novu, una piccula nota...

Di sti quattru prublemi, parechji sò risolti immediatamente si avete un nuvulu. Sè vo site in u Microsoft Azhur, nuvole Ozone, o aduprà i nostri nuvuli, da Yandex o Mail, allura almenu un malfunction hardware diventa u so prublema è tuttu diventa subitu bè per voi in u cuntestu di un malfunction hardware.

Semu una cumpagnia pocu cunvinziunali. Quì tutti parlanu di "Kubernets", di nuvole - ùn avemu nè "Kubernets" nè nuvole. Ma avemu racks di hardware in parechji centri di dati, è simu furzati à campà nantu à questu hardware, simu furzati à esse rispunsevuli di tuttu. Dunque, parleremu in questu cuntestu. Allora, nantu à i prublemi. I primi dui sò stati cacciati da parentesi.

Cambia a versione di u software. Basi

I nostri sviluppatori ùn anu micca accessu à a produzzione. Perchè hè questu? Hè solu chì simu certificati PCI DSS, è i nostri sviluppatori simpricimenti ùn anu micca u dirittu di entre in u "pruduttu". Eccu, puntu. Per nunda. Dunque, a rispunsabilità di u sviluppu finisce esattamente in u mumentu chì u sviluppu sottumette a custruzione per a liberazione.

A nostra seconda basa chì avemu, chì ci aiuta ancu assai, hè l'absenza di cunniscenza unica senza documentu. Spergu chì hè listessa per voi. Perchè s'ellu ùn hè micca u casu, averete prublemi. I prublemi saranu quandu sta cunniscenza unicu è senza documentu ùn hè micca prisente à u mumentu propiu in u locu ghjustu. Diciamu chì avete una persona chì sapi cumu implementà un cumpunente specificu - a persona ùn hè micca quì, hè in vacanze o malatu - hè questu, avete prublemi.

È a terza basa à quale avemu ghjuntu. Ci hè ghjuntu à traversu dolore, sangue, lacrime - avemu ghjuntu à a cunclusione chì qualsiasi di i nostri custruzzioni cuntene errori, ancu s'ellu hè senza errore. Avemu decisu questu per noi stessi: quandu avemu implementatu qualcosa, quandu avemu rollu qualcosa in a produzzione, avemu una custruzzione cù errori. Avemu furmatu i requisiti chì u nostru sistema deve suddisfà.

Requisiti per cambià a versione di u software

Ci sò trè esigenze:

• Avemu da rinvià rapidamente a implementazione.
• Avemu da minimizzà l'impattu di una implementazione senza successu.
• È duvemu esse capace di implementà rapidamente in parallelu.
  Esattamente in questu ordine! Perchè? Perchè, prima di tuttu, quandu si sparghje una nova versione, a velocità ùn hè micca impurtante, ma hè impurtante per voi, se qualcosa va male, per rinvià rapidamente è avè un impattu minimu. Ma s'è vo avete un inseme di versioni in a pruduzzione, per quale si trova chì ci hè un errore (fora di u turchinu, ùn ci era micca implementazione, ma ci hè un errore) - a veloce di implementazione sussegwenti hè impurtante per voi. Chì avemu fattu per risponde à queste richieste ? Avemu ricursu à a metodulugia seguente:

  
  
  Hè abbastanza cunnisciutu, ùn l'avemu mai inventatu - questu hè u Blue / Green implementatu. Chì ghjè ? Duvete avè una copia per ogni gruppu di servitori in quale sò installate e vostre applicazioni. A copia hè "calda": ùn ci hè micca trafficu nantu à questu, ma in ogni mumentu stu trafficu pò esse mandatu à sta copia. Questa copia cuntene a versione precedente. È à u mumentu di a implementazione, stende u codice à una copia inattiva. Allora cambiate parte di u trafficu (o tuttu) à a nova versione. Cusì, per cambià u flussu di trafficu da a vechja versione à a nova, avete bisognu di fà una sola azzione: avete bisognu di cambià u balancer in upstream, cambià a direzzione - da un upstream à l'altru. Questu hè assai còmuda è risolve u prublema di u cambiamentu rapidu è u rollback rapidu.

  Quì a suluzione à a seconda quistione hè minimizazione: pudete mandà solu una parte di u vostru trafficu à una nova linea, à una linea cù un novu codice (per esempiu, 2%). È questi 2% ùn sò micca 100%! Sì avete persu u 100% di u vostru trafficu per via di una implementazione senza successu, hè spaventosa; Se persu u 2% di u vostru trafficu, hè spiacevoli, ma ùn hè micca spaventoso. Inoltre, l'utilizatori ùn anu micca prubabilmente nutatu questu, perchè in certi casi (micca in tutti) u listessu utilizatore, pressendu F5, serà purtatu à una altra versione di travagliu.

  Impiegazione blu / verde. Routing

  Tuttavia, micca tuttu hè cusì simplice "Blue / Green deploy"... Tutti i nostri cumpunenti ponu esse divisi in trè gruppi:

  • questu hè u frontend (pagine di pagamentu chì i nostri clienti vede);
  • core di trasfurmazioni;
  • adattatore per travaglià cù sistemi di pagamentu (banche, MasterCard, Visa...).

  E ci hè una sfumatura quì - a sfumatura si trova in a strada trà e linee. Se solu cambia u 100% di u trafficu, ùn avete micca questi prublemi. Ma se vulete cambià u 2%, cuminciate à dumandà dumande: "Cumu fà questu?" A cosa più simplice hè ghjustu: pudete stabilisce Round Robin in nginx per scelta aleatoria, è avete 2% à manca, 98% à diritta. Ma questu ùn hè micca sempre adattatu.

  Per esempiu, in u nostru casu, un utilizatore interagisce cù u sistema cù più di una dumanda. Questu hè normale: 2, 3, 4, 5 richieste - i vostri sistemi ponu esse listessi. È s'ellu hè impurtante per voi chì tutte e dumande di l'utilizatori venenu à a listessa linea nantu à quale hè vinuta a prima dumanda, o (secondu puntu) tutte e dumande di l'utilizatori venenu à a nova linea dopu à u cambiamentu (puderia avè principiatu à travaglià prima cù u sistema, prima di cambià), - allora sta distribuzione aleatoria ùn hè micca adattatu per voi. Allora ci sò e seguenti opzioni:

  
  
  A prima opzione, a più simplice, hè basatu annantu à i paràmetri basi di u cliente (IP Hash). Avete un IP, è dividite da diritta à manca per indirizzu IP. Allora u sicondu casu ch'e aghju descrittu hà da travaglià per voi, quandu a implementazione hè accaduta, l'utilizatore puderia digià principià à travaglià cù u vostru sistema, è da u mumentu di a implementazione tutte e dumande andaranu à una nova linea (à a stessa, dì).

  Se per una certa ragione questu ùn vi cunvene micca è duvete mandà richieste à a linea induve hè ghjunta a dumanda iniziale di l'utilizatore, allora avete duie opzioni ...
  Prima opzione: pudete cumprà nginx + pagatu. Ci hè un mecanismu di sessione Sticky, chì, nantu à a dumanda iniziale di l'utilizatore, assigna una sessione à l'utilizatore è a liga à unu o un altru upstream. Tutte e richieste di l'utilizatori successive in a vita di a sessione seranu mandate à u listessu upstream induve a sessione hè stata publicata.

  Questu ùn ci hè micca adattatu perchè avemu digià avutu nginx regular. Passà à nginx + ùn hè micca chì hè caru, hè solu chì era un pocu doloroso per noi è micca assai ghjustu. "Sticks Sessions", per esempiu, ùn hà micca travagliatu per noi per u mutivu simplice chì "Sticks Sessions" ùn permettenu micca u routing basatu annantu à "Either-or". Quì pudete specificà ciò chì facemu "Sticks Sessions", per esempiu, per l'indirizzu IP o per l'indirizzu IP è i cookies o per postparametru, ma "O-o" hè più cumplicatu quì.

  Dunque, avemu ghjuntu à a quarta opzione. Avemu pigliatu nginx nantu à steroidi (questu hè openresty) - questu hè u stessu nginx, chì sustene ancu l'inclusione di l'ultimi scripts. Pudete scrive un ultimu script, dà un "restu apertu", è questu ultimu script serà eseguitu quandu a dumanda di l'utilizatori vene.

  E avemu scrittu, in fattu, un tali script, stabilitu "openresti" è in questu script avemu sorte à traversu 6 paràmetri diffirenti per concatenation "Or". Sicondu a prisenza di unu o un altru paràmetru, sapemu chì l'utilizatore hè ghjuntu à una pagina o à l'altru, una linea o un altru.

  Impiegazione blu / verde. Vantaghji è disadvantages

  Di sicuru, era prubabilmente pussibule di fà un pocu più simplice (aduprate a stessa "Sessions Sticky"), ma avemu ancu una tale sfumatura chì micca solu l'utilizatore interagisce cun noi in u quadru di una trasfurmazioni di una transazzione ... Ma i sistemi di pagamentu ancu interagiscenu cun noi: Dopu avemu processatu a transazzione (inviendu una dumanda à u sistema di pagamentu), ricevemu un coolback.
  È dicemu, se in u nostru circuitu pudemu trasmette l'indirizzu IP di l'utilizatore in tutte e dumande è dividite l'utilizatori nantu à l'indirizzu IP, allora ùn diceremu micca u stessu "Visa": "Amicu, simu una cumpagnia cusì retro, paremu. per esse internaziunale (nantu à u situ web è in Russia)... Per piacè furniteci l'indirizzu IP di l'utilizatori in un campu supplementu, u vostru protokollu hè standardizatu "! Hè chjaru ch'elli ùn accunsenu micca.

  
  
  Dunque, questu ùn hà micca travagliatu per noi - avemu fattu openresty. In cunsiquenza, cù u routing avemu avutu qualcosa cum'è questu:

  Blue / Green Deployment hà, dunque, i vantaghji chì aghju citatu è i svantaghji.

  Dui svantaghji:

  • avete bisognu di fastidiu cù routing;
  • u sicondu svantaghju principale hè a spesa.

  Avete bisognu di duie volte di servitori, avete bisognu di duie volte di risorse operative, avete bisognu di spende duie volte di sforzu per mantene stu zoo sanu.

  Per via, trà i vantaghji ci hè una cosa più chì ùn aghju micca dettu prima: avete una riserva in casu di crescita di carica. Se tenete una crescita splussiva in a carica, avete un gran numaru d'utilizatori, allora simpricimenti includenu a seconda linea in a distribuzione 50 à 50 - è avete immediatamente servitori x2 in u vostru cluster finu à risolve u prublema di avè più servitori.

  Cumu fà una implementazione rapida?

  Avemu parlatu di cumu risolve u prublema di minimizazione è di rollback rapidu, ma a quistione resta: "Cumu implementà rapidamente?"

  
  
  Hè cortu è simplice quì.

  • Duvete avè un sistema CD (Consegna Continua) - ùn pudete micca campà senza ellu. Sì avete un servitore, pudete implementà manualmente. Avemu circa un milla è mezu servitori è un milla è mezu manichi, sicuru - pudemu plantà un dipartimentu di a dimensione di sta stanza solu per implementà.
  • A implementazione deve esse parallella. Se a vostra implementazione hè sequenziale, allora tuttu hè male. Un servitore hè normale, avete da implementà un è mezzo mila servitori tuttu u ghjornu.
  • In novu, per l'accelerazione, questu hè probabilmente più necessariu. Durante a implementazione, u prugettu hè di solitu custruitu. Avete un prughjettu web, ci hè una parte di front-end (fate un pacchettu web quì, compilate npm - qualcosa cusì), è questu prucessu hè, in principiu, di corta durata - 5 minuti, ma questi 5 minuti ponu esse criticu. Hè per quessa, per esempiu, ùn facemu micca cusì: sguassate questi minuti 5, implementemu artefatti.

    Cosa hè un artefattu? Un artefattu hè una custruzzione assemblata in quale tutte e parti di l'assemblea sò digià finite. Guardemu stu artefattu in u magazzinu di l'artifactu. In un tempu avemu usatu dui tali almacenamenti - era Nexus è avà jFrog Artifactory). Inizialmente avemu usatu "Nexus" perchè avemu principiatu à praticà stu approcciu in l'applicazioni java (si adattava bè). Allora ci mettenu alcune di l'applicazioni scritte in PHP; è "Nexus" ùn era più adattatu, è per quessa avemu sceltu jFrog Artefactory, chì pò artifactorize quasi tuttu. Avemu ancu ghjuntu à u puntu chì in questu repository di l'artefatti guardemu i nostri pacchetti binari chì cullemu per i servitori.

  Crescita di carica esplosiva

  Avemu parlatu di cambià a versione di u software. A prossima cosa chì avemu hè un aumentu splusivu di carica. Quì, probabilmente intendo da crescita splussiva di a carica ùn hè micca ghjustu ...

  Avemu scrittu un novu sistema - hè orientatu à u serviziu, di moda, bellu, travagliadori in ogni locu, fila in ogni locu, asincronia in ogni locu. È in tali sistemi, i dati ponu scorri attraversu diversi flussi. Per a prima transazzione, u 1u, 3u, 10u travagliu pò esse usatu, per a seconda transazzione - u 2, 4, 5. È oghje, dicemu, in a matina avete un flussu di dati chì usa i primi trè travagliadori, è à a sera cambia dramaticamente, è tuttu usa l'altri trè travagliadori.

  E quì si trova chì avete bisognu di scala di i travagliadori, avete bisognu di scala di i vostri servizii, ma à u stessu tempu impediscenu u bloat di risorse.

  
  
  Avemu definitu i nostri bisogni. Sti esigenze sò abbastanza sèmplice: chì ci hè Service scuperta, parameterization - tuttu hè standard per custruisce tali sistemi scalable, fora di un puntu - depreciation risorsa. Avemu dettu chì ùn simu pronti per ammortizà e risorse per chì i servitori scaldanu l'aria. Avemu pigliatu "Consul", avemu pigliatu "Nomad", chì gestisce i nostri travagliadori.

  Perchè hè questu un prublema per noi? Andemu un pocu in daretu. Avemu avà circa 70 sistemi di pagamentu daretu à noi. In a matina, u trafficu passa per Sberbank, dopu Sberbank hè cascatu, per esempiu, è cambiamu à un altru sistema di pagamentu. Avemu avutu 100 travagliadori prima di Sberbank, è dopu avemu bisognu di aumentà 100 travagliadori per un altru sistema di pagamentu. È hè desideratu chì tuttu questu succede senza participazione umana. Perchè s'ellu ci hè a participazione umana, ci deve esse un ingegnere à pusà quì 24/7, chì deve esse solu fà questu, perchè tali fallimenti, quandu i sistemi 70 sò daretu à voi, succede regularmente.

  Per quessa, avemu vistu Nomad, chì hà una IP aperta, è hà scrittu a nostra propria cosa, Scale-Nomad - ScaleNo, chì face apprussimatamente i seguenti: monitorizza a crescita di a fila è riduce o aumenta u nùmeru di travagliadori secondu a dinamica. di a fila. Quandu l'avemu fattu, avemu pensatu: "Forse pudemu apre u fonte?" Allora l'anu guardatu - era simplice quant'è dui copechi.

  Finu a ora ùn l'avemu micca apertu, ma se di colpu dopu à u rapportu, dopu avè capitu chì avete bisognu di una tale cosa, avete bisognu, i mo cuntatti sò in l'ultima slide - per piacè scrivitemi. Se ci sò almenu 3-5 persone, l'avemu sponsorizatu.

  
  
  Cumu funziona? Fighjemu un ochju ! Fighjendu avanti: à u latu manca ci hè un pezzu di u nostru surviglianza: questu hè una linea, in cima hè u tempu di prucessu di l'avvenimentu, in u mità hè u numeru di transacciones, in u fondu hè u numeru di travagliadori.

  Sè vo circate, ci hè un glitch in sta stampa. In u top chart, unu di i charts s'hè lampatu in 45 seconde - unu di i sistemi di pagamentu hè cascatu. Immediatamente, u trafficu hè statu purtatu in 2 minuti è a fila hà cuminciatu à cultivà nantu à un altru sistema di pagamentu, induve ùn ci era micca travagliadori (ùn avemu micca utilizatu risorse - à u cuntrariu, avemu disposti di a risorsa currettamente). Ùn vulemu micca scaldà - ci era un numeru minimu, circa 5-10 travagliadori, ma ùn puderanu micca affruntà.

  L'ultimu graficu mostra una "gobba", chì significa solu chì "Skaleno" duppiò sta quantità. È dopu, quandu u graficu hè cascatu un pocu, hà riduciutu un pocu - u numeru di travagliadori hè cambiatu automaticamente. Hè cusì chì sta cosa funziona. Avemu parlatu di u puntu numeru 2 - "Cumu sguassate rapidamente di e ragioni".

  Surviglianza. Cumu identificà rapidamente u prublema?

  Avà u primu puntu hè "Cumu identificà rapidamente u prublema?" Surviglianza ! Avemu da capisce rapidamente certe cose. Chì cose duvemu capisce rapidamente?

  
  
  Trè cose !

  • Avemu da capisce è capisce rapidamente a prestazione di e nostre risorse.
  • Avemu da capisce rapidamente i fallimenti è monitorizà u rendiment di i sistemi chì sò esterni à noi.
  • U terzu puntu hè identificà errori lògichi. Questu hè quandu u sistema hè travagliatu per voi, tuttu hè normale secondu tutti l'indicatori, ma qualcosa va male.

  Probabilmente ùn vi diceraghju nunda di cusì bellu quì. Seraghju u Capitanu Obvious. Avemu cercatu ciò chì era nantu à u mercatu. Avemu un "zoo divertente". Questu hè u tipu di zoo chì avemu avà:

  
  
  Utilizemu Zabbix per monitorà u hardware, per monitorizà i principali indicatori di i servitori. Avemu aduprà Okmeter per basa di dati. Avemu aduprà "Grafana" è "Prometheus" per tutti l'altri indicatori chì ùn sò micca adattati per i primi dui, alcuni cù "Grafana" è "Prometheus", è alcuni cù "Grafana" cù "Influx" è Telegraf.

  Un annu fà vulemu aduprà New Relic. Una cosa bella, pò fà tuttu. Ma quantu pò fà tuttu, hè cusì caru. Quandu avemu crisciutu à un voluminu di 1,5 mila servitori, un venditore hè ghjuntu à noi è hà dettu: "Concludemu un accordu per l'annu prossimu". Fighjemu u prezzu è dicemu micca, ùn faremu micca cusì. Avà abbandunemu New Relic, avemu circa 15 servitori lasciati sottu u monitoraghju di New Relic. U prezzu hè diventatu assolutamente salvaticu.

  È ci hè un strumentu chì avemu implementatu noi stessi - questu hè Debugger. À u primu l'avemu chjamatu "Bagger", ma dopu un prufessore d'inglese passò, si ridia furiosamente, è l'hà rinominatu "Debagger". Chì ghjè ? Questu hè un strumentu chì, in fattu, in 15-30 seconde nantu à ogni cumpunente, cum'è una "scatola nera" di u sistema, esegue teste nantu à u rendiment generale di u cumpunente.

  Per esempiu, s'ellu ci hè una pagina esterna (pagina di pagamentu), simpricimenti l'apre è vede cumu si deve vede. S'ellu hè trattatu, manda una prova "transazzione" è assicura chì sta "transazzione" ghjunghje. S'ellu hè una cunnessione cù i sistemi di pagamentu, sparemu una dumanda di prova per quessa, induve pudemu, è vede chì tuttu hè bè cun noi.

  Chì indicatori sò impurtanti per u monitoraghju?

  Chì monitoremu principalmente? Chì indicatori sò impurtanti per noi?

  
  

  • U tempu di risposta / RPS in fronti hè un indicatore assai impurtante. Ellu risponde immediatamente chì qualcosa hè sbagliatu cun voi.
  • U numeru di missaghji trattati in tutte e fila.
  • Numero di travagliadori.
  • Metriche di correzzione di basa.

  L'ultimu puntu hè "affari", "affari" metrica. Se vulete monitorà a stessa cosa, avete bisognu di definisce una o duie metriche chì sò i principali indicatori per voi. A nostra metrica hè u throughput (questu hè u rapportu di u numeru di transazzione successu à u flussu di transazzione tutale). Se qualcosa cambia in questu in un intervalu di 5-10-15 minuti, significa chì avemu prublemi (se cambia radicalmente).

  Ciò chì pare per noi hè un esempiu di unu di i nostri bordi:

  
  
  À u latu manca ci sò 6 gràfiche, questu hè secondu e linee - u numeru di travagliadori è u numeru di missaghji in a fila. À u latu drittu - RPS, RTS. Quì sottu hè a stessa metrica di "affari". È in a metrica di "affari" pudemu immediatamente vede chì qualcosa hà sbagliatu in i dui gràfici mediani ... Questu hè solu un altru sistema chì ferma daretu à noi chì hè cascatu.

  A seconda cosa chì avemu avutu à fà era monitorà a caduta di i sistemi di pagamentu esterni. Quì avemu pigliatu OpenTracing - un mecanismu, standard, paradigma chì vi permette di traccia sistemi distribuiti; è hè statu cambiatu un pocu. U paradigma standard OpenTracing dice chì custruemu una traccia per ogni dumanda individuale. Ùn avemu micca bisognu di questu, è l'avemu impannillatu in un riassuntu, traccia di aggregazione. Avemu fattu un strumentu chì ci permette di seguità a vitezza di i sistemi daretu à noi.

  
  
  U graficu ci mostra chì unu di i sistemi di pagamentu hà cuminciatu à risponde in 3 seconde - avemu prublemi. Inoltre, sta cosa reagisce quandu i prublemi cumincianu, à un intervalu di 20-30 seconde.

  È a terza classa d'errore di monitoraghju chì esiste hè u monitoraghju logicu.

  Per esse onesto, ùn sapia micca ciò chì disegnà nantu à sta slide, perchè eramu cercatu assai tempu nantu à u mercatu per qualcosa chì ci cunvene. Ùn avemu trovu nunda, cusì avemu avutu da fà noi.

  
  
  Chì vogliu dì per surviglianza logica? Ebbè, imaginate: fate un sistema (per esempiu, un clone di Tinder); l'avete fattu, lanciatu. U manager di successu Vasya Pupkin hà messu nantu à u so telefunu, vede una zitella quì, li piace ... è u cum'è ùn và à a zitella - u cum'è va à u guardianu di sicurità Mikhalych da u stessu centru cummerciale. U direttore scende, è poi si dumanda: "Perchè stu guardianu di sicurità Mikhalych li sorrisu cusì piacevule?"

  In tali situazioni... Per noi, sta situazione sona un pocu sfarente, perchè (aghju scrittu) questu hè una perdita di reputazione chì indirettamente porta à perdite finanziarie. A nostra situazione hè u cuntrariu: pudemu soffrenu perditi finanziarii diretti - per esempiu, se avemu fattu una transazzione cum'è successu, ma ùn era micca successu (o vice versa). Aviu avutu à scrive u mo propiu strumentu chì traccia u nùmeru di transazzione successu cù u tempu utilizendu indicatori di cummerciale. Ùn aghju trovu nunda in u mercatu ! Questa hè esattamente l'idea chì vulia trasmette. Ùn ci hè nunda in u mercatu per risolve stu tipu di prublema.

  Questu era cumu per identificà rapidamente u prublema.

  Cumu determinà i motivi per a implementazione

  U terzu gruppu di prublemi chì risolvemu hè dopu avè identificatu u prublema, dopu chì avemu sbarazzatu, saria bonu per capiscenu u mutivu di u sviluppu, per pruvà, è fà qualcosa. In cunsiquenza, avemu bisognu di investigà, avemu bisognu di elevà i logs.

  
  
  Se parlemu di logs (u mutivu principale hè logs), a maiò parte di i nostri logs sò in ELK Stack - quasi tutti anu u stessu. Per alcuni, pò esse micca in ELK, ma se scrivite logs in gigabytes, prima o dopu vi venerà in ELK. Li scrivemu in terabytes.

  
  
  Ci hè un prublema quì. L'avemu riparatu, currettu l'errore per l'utilizatore, hà cuminciatu à scavà ciò chì ci era, cullò in Kibana, intrì in l'identificatore di transazzione quì è hà avutu un pede cum'è questu (mostra assai). È assolutamente nunda ùn hè chjaru in questu footcloth. Perchè? Iè, perchè ùn hè micca chjaru chì parte appartene à quale travagliadore, chì parte appartene à quale cumpunente. È in quellu mumentu avemu capitu chì avemu bisognu di traccia - u stessu OpenTracing chì aghju parlatu.

  Avemu pensatu questu un annu fà, turnò a nostra attenzione versu u mercatu, è ci era dui strumenti - "Zipkin" è "Jaeger". "Jager" hè in fattu un tali eredi ideologicu, un successore ideologicu di "Zipkin". Tuttu hè bonu in Zipkin, salvu chì ùn sapi micca cumu aggregate, ùn sapi micca cumu include logs in a traccia, solu traccia di u tempu. È "Jager" sustene questu.

  Avemu guardatu à "Jager": pudete strumentà l'applicazioni, pudete scrive in Api (u standard Api per PHP in quellu tempu, però, ùn era micca appruvatu - questu era un annu fà, ma avà hè statu appruvatu), ma ci era assolutamente nisun cliente. "Va bè", avemu pensatu, è hà scrittu u nostru cliente. Chì avemu avutu ? Questu hè apprussimatamente ciò chì pare:

  
  
  In Jaeger, i spazii sò creati per ogni missaghju. Hè, quandu un utilizatore apre u sistema, vede unu o dui blocchi per ogni dumanda entrata (1-2-3 - u nùmeru di richieste entrate da l'utilizatore, u nùmeru di blocchi). Per fà più faciule per l'utilizatori, avemu aghjustatu tag à i logs è tracce di u tempu. Dunque, in casu d'errore, a nostra applicazione marcarà u logu cù u tag Errore appropritatu. Pudete filtrà per tag d'errore è solu spans chì cuntenenu stu bloccu cù un errore seranu visualizati. Eccu ciò chì pare si espansione u span:

  
  
  Dentru u span ci hè un inseme di tracce. In questu casu, sò trè tracce di prova, è a terza traccia ci dice chì un errore hè accadutu. À u stessu tempu, quì vedemu una traccia di u tempu: avemu una scala di u tempu in cima, è vedemu in quale intervallu di tempu questu o quellu logu hè statu arregistratu.

  Dunque, e cose sò andate bè per noi. Avemu scrittu a nostra propria estensione è l'avemu apertu. Se vulete travaglià cù traccia, se vulete travaglià cù "Jager" in PHP, ci hè a nostra estensione, benvenuta à aduprà, cum'è dicenu:

  
  
  Avemu sta estensione - hè un cliente per l'Api OpenTracing, hè fattu cum'è php-extension, vale à dì, avete bisognu di assemblellu è installate in u sistema. Un annu fà ùn ci era nunda di sfarente. Avà ci sò altri clienti chì sò cum'è cumpunenti. Quì hè à voi: o vi pump out i cumpunenti cù un cumpusituri, o voi aduprà estensione up à voi.

  Norme corporative

  Avemu parlatu di i trè cumandamenti. U quartu cumandamentu hè di standardizà approcci. Chì hè questu? Si tratta di questu:

  
  
  Perchè a parolla "corporate" hè quì? Micca perchè simu una cumpagnia grande o burocràtica, nò ! Vuliu aduprà a parolla "corporate" quì in u cuntestu chì ogni cumpagnia, ogni pruduttu deve avè i so standard, cumpresu voi. Chì standard avemu?

  
  

  • Avemu rigulamenti di implementazione. Ùn ci movemu in ogni locu senza ellu, ùn pudemu micca. Implementemu circa 60 volte à settimana, vale à dì, implementemu quasi constantemente. À u listessu tempu, avemu, per esempiu, in i regulamenti di implementazione un tabù nantu à e implementazioni u venneri - in principiu, ùn avemu micca implementatu.
  • Avemu bisognu di documentazione. Ùn ci hè micca un solu novu cumpunente in a produzzione s'ellu ùn ci hè micca documentazione per questu, ancu s'ellu hè natu sottu a penna di i nostri specialisti RnD. Avemu bisognu di elli struzzioni di implementazione, una mappa di monitoraghju è una descrizzione approssimativa (bene, cum'è i programatori ponu scrive) di cumu funziona stu cumpunente, cumu risolve i prublemi.
  • Ùn risolvemu micca a causa di u prublema, ma u prublema - ciò chì aghju digià dettu. Hè impurtante per noi di prutezzione di l'utilizatori da i prublemi.
  • Avemu l'autorizazioni. Per esempiu, ùn avemu micca cunsideratu u tempu d'inattività si perdemu u 2% di u trafficu in dui minuti. Bastamente ùn hè micca inclusu in e nostre statistiche. S'ellu hè più in termini di percentuale o tempuranee, avemu digià contatu.
  • È avemu sempre scrivite post mortems. Qualunque cosa succede à noi, ogni situazione induve qualchissia hà cumportatu anormalmente in a produzzione serà riflessa in u post-mortem. Un postmortem hè un documentu in u quale scrive ciò chì hè accadutu per voi, un timing detallatu, ciò chì avete fattu per correggià è (questu hè un bloccu ubligatoriu!) Ciò chì fate per impedisce chì questu succede in u futuru. Questu hè ubligatoriu è necessariu per l'analisi sussegwenti.

  Cosa hè cunsideratu downtime?

  
  
  Chì hà purtatu tuttu questu?

  Questu hà purtatu à u fattu chì (avemu avutu certi prublemi cù stabilità, questu ùn hè micca adattatu nè à i clienti nè à noi) in l'ultimi mesi 6 u nostru indicatore di stabilità era 99,97. Pudemu dì chì questu ùn hè micca assai. Iè, avemu qualcosa à strincà. Di questu indicatore, circa a mità hè a stabilità, per esse, micca di a nostra, ma di u nostru firewall di l'applicazioni web, chì si trova davanti à noi è hè utilizatu com'è serviziu, ma i clienti ùn anu micca cura di questu.

  Avemu amparatu à dorme a notte. Finalmente! Sei mesi fà ùn pudemu micca. È nantu à sta nota cù i risultati, vogliu fà una nota. A notte passata ci hè statu un rapportu maravigliu nantu à u sistema di cuntrollu di un reactore nucleare. Se e persone chì anu scrittu stu sistema mi ponu sente, per piacè scurdate di ciò chì aghju dettu di "2% ùn hè micca un downtime". Per voi, 2% hè downtime, ancu s'ellu per dui minuti!

  Eccu tuttu! E vostre dumande.

  
  

  À propositu di equilibrari è migrazione di basa di dati

  Quistione di u publicu (in seguitu – B) : – Bona sera. Grazie mille per un tali rapportu amministratore! Una breve quistione nantu à i vostri balancers. Avete dettu chì avete un WAF, vale à dì, cum'è l'aghju capitu, utilizate un tipu di equilibratore esternu ...

  EK: - Innò, usemu i nostri servizii cum'è un equilibratore. In questu casu, WAF hè solu un strumentu di prutezzione DDoS per noi.

  IN: – Pudete dì uni pochi di parolle nantu à i balancers ?

  EK: - Cumu aghju digià dettu, questu hè un gruppu di servitori in openresty. Avemu avà 5 gruppi di riserva chì rispundenu esclusivamente ... vale à dì, un servitore chì corre solu openresty, solu proxy trafficu. In cunsiquenza, per capiscenu quantu tenemu: avemu avà un flussu di trafficu regulare di parechji centu megabits. Affruntà, si sentenu bè, ùn si stende mancu.

  IN: - Ancu una quistione simplice. Eccu l'implementazione Blue / Green. Chì fate, per esempiu, cù migrazioni di basa di dati?

  EK: - Bona dumanda ! Fighjate, in l'implementazione Blu / Verde avemu file separati per ogni linea. Vale à dì, se parlemu di fila di l'avvenimenti chì sò trasmessi da u travagliu à u travagliu, ci sò file separati per a linea blu è per a linea verde. Se parlemu di a basa di dati stessu, allora l'avemu ristretta deliberatamente quant'è pudemu, trasfirìu tuttu praticamenti in fila; in a basa di dati guardemu solu una pila di transazzioni. È a nostra pila di transazzione hè a stessa per tutte e linee. Cù a basa di dati in questu cuntestu: ùn avemu micca dividitu in blu è verde, perchè e duie versioni di u codice deve sapè ciò chì succede cù a transazzione.

  Amici, aghju ancu un picculu premiu per spularvi - un libru. È duverebbe esse premiatu per a megliu dumanda.

  IN: - Bonghjornu. Grazie per u rapportu. A quistione hè questu. Monitorate i pagamenti, seguite i servizii cù quale cumunicà ... Ma cumu monitorate cusì chì una persona in qualchì manera hè ghjunta à a vostra pagina di pagamentu, hà fattu un pagamentu, è u prughjettu hà creditu di soldi? Questu hè, cumu seguite chì u marchant hè dispunibule è hà accettatu u vostru callback?

  EK: - "Merchant" per noi in questu casu hè esattamente u stessu serviziu esternu cum'è u sistema di pagamentu. Monitoremu a velocità di risposta di u mercante.

  Circa a criptografia di basa di dati

  IN: - Bonghjornu. Aghju una quistione ligeramente ligata. Avete dati sensittivi PCI DSS. Vuliu sapè cumu guardate i PAN in fila chì avete bisognu di trasferisce? Aduprate una criptografia? E questu porta à a seconda quistione: sicondu u PCI DSS, hè necessariu di criptà periodicamente a basa di dati in casu di cambiamenti (licenziamentu di amministratori, etc.) - chì succede à l'accessibilità in questu casu?

  
  
  EK: - Meravigliosa dumanda ! Prima, ùn guardemu micca i PAN in fila. Ùn avemu micca u dirittu di almacenà PAN in ogni locu in forma chjara, in principiu, cusì avemu aduprà un serviziu speciale (chiamemu "Kademon") - questu hè un serviziu chì face una sola cosa: riceve un missaghju cum'è input è manda. fora un missaghju criptatu. E guardamu tuttu cù stu missaghju criptatu. Per quessa, a nostra lunghezza chjave hè sottu à un kilobyte, perchè questu hè seriu è affidabile.

  IN: - Avete bisognu di 2 kilobytes avà?

  EK: – Pare ch’è eri era 256... Ebbè, induve d’altru ?

  Per quessa, questu hè u primu. E siconda, a suluzione chì esiste, sustene a prucedura di re-encryption - ci sò duie coppie di "keks" (chjavi), chì dà "decks" chì cifri (chjavi sò i chjavi, dek sò derivati ​​di e chjavi chì cifri). . È se a prucedura hè iniziata (succede regularmente, da 3 mesi à ± alcuni), scaricamu un novu paru di "paste", è riciframu i dati. Avemu servizii separati chì strappanu tutti i dati è criptanu in una nova manera; I dati sò guardati vicinu à l'identificatore di a chjave cù quale hè criptatu. In cunsiquenza, appena avemu criptatu i dati cù novi chjave, sguassate a vechja chjave.

  Calchì volta u pagamentu deve esse fattu manualmente ...

  IN: - Vale à dì, s'ellu hè ghjuntu un rimborsu per qualchì operazione, l'avete sempre decriptatu cù a chjave antica?

  EK: - Iè.

  IN: – Allora una altra petite dumanda. Quandu ci hè qualchì tipu di fallimentu, caduta o incidente, hè necessariu di spinghje a transazzione manualmente. Ci hè una tale situazione.

  EK: - Iè, qualchì volta.

  IN: – Induve pigliate sti dati ? O andate voi stessu in stu magazzinu?

  EK: - No, bè, sicuru, avemu un tipu di sistema di back-office chì cuntene una interfaccia per u nostru supportu. Se ùn sapemu micca in quale statutu hè a transazzione (per esempiu, finu à chì u sistema di pagamentu hà rispostu cù un timeout), ùn sapemu micca a priori, vale à dì, assignemu u statutu finali solu cun piena fiducia. In questu casu, assignemu a transazzione à un statutu speciale per u prucessu manuale. A matina, u ghjornu dopu, appena u supportu riceve infurmazioni chì tali transacciones restanu in u sistema di pagamentu, i processanu manualmente in questa interfaccia.

  
  
  IN: – Aghju un paru di dumande. Unu di elli hè a continuazione di a zona PCI DSS: cumu fate u so circuitu? Sta quistione hè perchè u sviluppatore puderia avè messu qualcosa in i logs! Siconda quistione: cumu si sparghje i hotfix? Maniglie in a basa di dati hè una opzione, ma ci ponu esse hot-fixes gratuiti - quale hè a prucedura quì? È a terza quistione hè probabilmente ligata à RTO, RPO. A vostra dispunibilità era 99,97, quasi quattru nove, ma cum'è l'aghju capitu, avete un secondu centru di dati, un terzu centru di dati, è un quintu centru di dati... Cumu sincronizà, riplicà, è tuttu u restu?

  EK: - Cuminciamu cù u primu. Era a prima quistione nantu à i logs? Quandu scrivimu logs, avemu una capa chì maschera tutte e dati sensittivi. Ella guarda a maschera è i campi supplementari. In cunsiquenza, i nostri logs escenu cù dati digià mascherati è un circuitu PCI DSS. Il s'agit d'une des tâches régulières assignées à l'équipe de test. Sò tenuti à verificà ogni compitu, cumpresi i logs chì scrivenu, è questu hè unu di i travaglii rigulari durante i rivisioni di codice, per cuntrullà chì u sviluppatore ùn hà micca scrittu qualcosa. I cuntrolli successivi di questu sò realizati regularmente da u dipartimentu di sicurità di l'infurmazioni circa una volta à settimana: i logs per l'ultimu ghjornu sò pigliati selettivamente è sò eseguiti per un scanner-analizzatore speciale da i servitori di teste per verificà tuttu.
  À propositu di hot-fixes. Questu hè inclusu in i nostri reguli di implementazione. Avemu una clause separata nantu à i hotfixes. Cridemu chì implementemu hotfixes intornu à u clock quandu avemu bisognu. Appena chì a versione hè assemblata, appena hè ghjunta, appena avemu un artefattu, avemu un amministratore di u sistema in turnu nantu à una chjama da u supportu, è l'implementa à u mumentu quandu hè necessariu.

  Circa "quattru nove". A figura chì avemu avà hè stata veramente ottenuta, è avemu strived per questu in un altru centru di dati. Avà avemu un secondu centru di dati, è avemu principiatu a strada trà elli, è u prublema di a replicazione di u centru di dati cross-data hè veramente una quistione micca triviale. Avemu pruvatu à risolve in un tempu cù diversi mezi: avemu pruvatu à utilizà a stessa "Tarantula" - ùn hà micca travagliatu per noi, vi dicu subitu. Hè per quessa chì avemu finitu per urdinà i "sens" manualmente. In fatti, ogni applicazione in u nostru sistema eseguisce a sincronizazione necessaria "cambiamentu - fattu" trà i centri di dati in modu asincronu.

  IN: – S’è vo avete una seconda, perchè ùn avete micca una terza ? Perchè nimu hà ancu split-brain...

  EK: - Ma ùn avemu micca Split Brain. A causa di u fattu chì ogni applicazione hè guidata da un multimaster, ùn importa micca à quale centru hè ghjuntu a dumanda. Semu pronti per u fattu chì se unu di i nostri centri di dati falla (cunfiamu nantu à questu) è in u mità di una dumanda di l'utilizatori cambia à u sicondu centru di dati, simu pronti à perde stu utilizatore, veramente; ma questi seranu unità, unità assolute.

  IN: - Bona sera. Grazie per u rapportu. Avete parlatu di u vostru debugger, chì eseguisce alcune transazzione di teste in produzzione. Ma diteci di e transacciones di prova! Quantu prufonda và?

  EK: - Passa per u ciculu sanu di tuttu u cumpunente. Per un cumpunente, ùn ci hè micca differenza trà una transazzione di prova è una produzzione. Ma da un puntu di vista lògicu, questu hè solu un prughjettu separatu in u sistema, nantu à quale solu transazzione di teste sò eseguite.

  IN: - Induve l'avete tagliatu ? Eccu Core hà mandatu...

  EK: - Semu daretu à "Kor" in questu casu per transacciones di prova... Avemu una cosa cum'è routing: "Kor" sà à quale sistema di pagamentu per mandà - mandemu à un sistema di pagamentu falsu, chì simpricimenti dà un signalu http è eccu tuttu.

  IN: - Dimmi, per piacè, a vostra applicazione hè stata scritta in un monolitu enormu, o l'avete tagliatu in certi servizii o ancu microservizi ?

  EK: - Ùn avemu micca un monolitu, sicuru, avemu una applicazione orientata à u serviziu. Ci scherzamu chì u nostru serviziu hè fattu di monoliti - sò veramente abbastanza grande. Hè difficiuli di chjamà microservizi, ma questi sò servizii in quale operanu i travagliadori di e macchine distribuite.

  Se u serviziu nantu à u servitore hè cumprumissu ...

  IN: – Allora aghju a prossima dumanda. Ancu s'ellu era un monolitu, avete sempre dettu chì avete parechji di questi servitori istantanei, tutti basamente processanu dati, è a quistione hè: "In casu di un cumprumissu di unu di i servitori instantani o una applicazione, ogni ligame individuale. , anu qualchì tipu di cuntrollu di accessu ? Quale di elli pò fà chì? Quale deve cuntattà per quale infurmazione?

  
  
  EK: - Iè, sicuru. I bisogni di sicurità sò abbastanza serii. Prima, avemu i movimenti di dati aperti, è i porti sò solu quelli attraversu quale anticipemu u muvimentu di u trafficu in anticipu. Se un cumpunente cumunicà cù a basa di dati (per dì, cù Muskul) via 5-4-3-2, solu 5-4-3-2 serà apertu à questu, è altri porti è altre direzzione di trafficu ùn saranu micca dispunibili. Inoltre, avete bisognu di capiscenu chì in a nostra pruduzzione ci sò circa 10 cicli di sicurità diffirenti. E ancu s'ellu l'appiecazione era in qualchì modu cumprumissu, Diu ùn ci vole, l'attaccante ùn puderà micca accede à a cunsola di gestione di u servitore, perchè questu hè una zona di sicurezza di rete diversa.

  IN: – È in questu cuntestu, ciò chì hè più interessante per mè hè chì avete certi cuntratti cù servizii - ciò chì ponu fà, per quale "azzioni" ponu cuntattà l'altri... È in un flussu normale, certi servizii specifichi dumandanu qualchi fila, una lista di "azzioni" da l'altru. Ùn parenu micca vultà à l'altri in una situazione normale, è anu altri spazii di rispunsabilità. Se unu di elli hè cumprumissu, serà capace di disturbà l'"azzioni" di quellu serviziu?...

  EK: - Capiscu. Se in una situazione normale cù un altru servitore a cumunicazione hè stata permessa in tuttu, allora sì. Sicondu u cuntrattu SLA, ùn monitoremu micca chì vi sò permessi solu i primi 3 "azzioni", è ùn avete micca permessu di i 4 "azzioni". Questu hè prubabilmente redundant per noi, perchè avemu digià un sistema di prutezzione di 4 livelli, in principiu, per i circuiti. Preferimu à difende cù i contorni, piuttostu chè à u livellu di l'internu.

  Cumu funziona Visa, MasterCard è Sberbank

  IN: - Vogliu chjarificà un puntu nantu à cambià un utilizatore da un centru di dati à l'altru. Quantu sò, Visa è MasterCard operanu cù u protocolu sincronu binariu 8583, è ci sò mischii. E vulia sapè, avà significhemu cambià - hè direttamente "Visa" è "MasterCard" o prima di i sistemi di pagamentu, prima di trasfurmà?

  EK: - Questu hè prima di i mischi. I nostri mischi sò situati in u stessu centru di dati.

  IN: – À pocu pressu, avete un puntu di cunnessione ?

  EK: - "Visa" è "MasterCard" - iè. Semplicemente perchè Visa è MasterCard necessitanu investimenti abbastanza serii in infrastruttura per cuncludi cuntratti separati per ottene una seconda coppia di mischi, per esempiu. Sò riservati in un centru di dati, ma s'è, Diu ùn ci vole, u nostru centru di dati, induve ci sò mischi per cunnette à Visa è MasterCard, mori, allora avemu una cunnessione cù Visa è MasterCard persu...

  IN: – Cumu ponu esse riservati ? Sò chì Visa permette solu una cunnessione in principiu!

  EK: - Forninu l'equipaggiu stessu. In ogni casu, avemu ricevutu l'equipaggiu chì hè cumplettamente redundant in l'internu.

  IN: - Allora u stand hè da u so Connects Orange?...

  EK: - Iè.

  IN: – Ma chì hè di questu casu: se u vostru centru di dati sparisce, cumu pudete cuntinuà à aduprà? O u trafficu ferma solu?

  EK: - Innò. In questu casu, avemu da solu cambià u trafficu à un altru canale, chì, naturalmente, serà più caru per noi è più caru per i nostri clienti. Ma u trafficu ùn passà per a nostra cunnessione diretta à Visa, MasterCard, ma à traversu u Sberbank cundizionale (assai esageratu).

  Mi scusemu in modu salvaticu se aghju offesu l'impiegati di Sberbank. Ma sicondu i nostri statistiche, trà i banche russi, Sberbank casca più spessu. Ùn passa micca un mese senza chì qualcosa cascata à Sberbank.

  
  
  

  Certi annunzii 🙂

  Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, cloud VPS per sviluppatori da $ 4.99, un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: Tutta a verità nantu à VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps da $ 19 o cumu si sparte un servitore? (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).

  Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV da $ 199 in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa Cumu custruisce una infrastruttura corp. classa cù l'usu di i servitori Dell R730xd E5-2650 v4 valenu 9000 XNUMX euro per un centesimu?

Source: www.habr.com