HighLoad++, Evgeniy Kuzovlev (EcommPay IT): cosa fare quando un minuto di inattività costa $ 100000

Tutti parlano di processi di sviluppo e test, di formazione del personale, di aumento della motivazione, ma questi processi non bastano quando un minuto di inattività del servizio costa enormi quantità di denaro. Cosa fare quando si effettuano transazioni finanziarie con uno SLA rigoroso? Come aumentare l'affidabilità e la tolleranza ai guasti dei vostri sistemi, eliminando sviluppo e test dall'equazione?

La prossima conferenza HighLoad++ si terrà il 6 e 7 aprile 2020 a San Pietroburgo. Dettagli e biglietti per collegamento. 9 novembre, 18:00. HighLoad++ Mosca 2018, Delhi + sala Calcutta. Tesi e presentazione.

Evgeniy Kuzovlev (di seguito – CE): - Amici, ciao! Mi chiamo Kuzovlev Evgeniy. Vengo dalla società EcommPay, una divisione specifica è EcommPay IT, la divisione IT del gruppo di società. E oggi parleremo dei tempi di inattività, di come evitarli, di come minimizzarne le conseguenze se non possono essere evitati. L'argomento è formulato come segue: "Cosa fare quando un minuto di inattività costa $ 100"? Guardando al futuro, i nostri numeri sono comparabili.

Cosa fa EcommPay IT?

Chi siamo noi? Perché sono qui di fronte a te? Perché ho il diritto di dirti qualcosa qui? E di cosa parleremo qui più nel dettaglio?

Il gruppo di società EcommPay è un acquirente internazionale. Elaboriamo pagamenti in tutto il mondo: in Russia, Europa, Sud-Est asiatico (tutto il mondo). Abbiamo 9 sedi, 500 dipendenti in totale, di cui circa poco meno della metà sono specialisti IT. Tutto ciò che facciamo, tutto ciò da cui guadagniamo, lo abbiamo fatto noi stessi.

Abbiamo scritto tutti i nostri prodotti (e ne abbiamo parecchi: nella nostra linea di prodotti IT di grandi dimensioni abbiamo circa 16 componenti diversi) noi stessi; Scriviamo noi stessi, sviluppiamo noi stessi. E al momento effettuiamo circa un milione di transazioni al giorno (milioni è probabilmente il modo giusto per dirlo). Siamo un'azienda abbastanza giovane: abbiamo solo circa sei anni.

6 anni fa era una tale startup quando i ragazzi si sono uniti all'attività. Erano uniti da un'idea (non c'era altro che un'idea), e noi corremmo. Come ogni startup, abbiamo corso più velocemente... Per noi la velocità era più importante della qualità.

Ad un certo punto ci siamo fermati: abbiamo capito che in qualche modo non potevamo più vivere a quella velocità e con quella qualità e dovevamo puntare prima sulla qualità. In questo momento, abbiamo deciso di scrivere una nuova piattaforma che fosse corretta, scalabile e affidabile. Hanno iniziato a scrivere questa piattaforma (hanno iniziato a investire, sviluppare sviluppo, testare), ma a un certo punto si sono resi conto che lo sviluppo e il test non ci permettevano di raggiungere un nuovo livello di qualità del servizio.

Realizzi un nuovo prodotto, lo metti in produzione, ma qualcosa andrà comunque storto da qualche parte. E oggi parleremo di come raggiungere un nuovo livello di qualità (come lo abbiamo fatto, della nostra esperienza), eliminando sviluppo e test dall'equazione; parleremo di ciò che è disponibile per l'operazione: cosa l'operazione può fare da sola, cosa può offrire ai test per influenzare la qualità.

Tempi di inattività. Comandamenti operativi.

Da sempre il cardine principale, ciò di cui parleremo effettivamente oggi sono i tempi di inattività. Una parola terribile. Se abbiamo tempi di inattività, tutto va male per noi. Stiamo correndo per sollevarlo, gli amministratori tengono il server - Dio non voglia che non cada, come si dice in quella canzone. Questo è ciò di cui parleremo oggi.

Quando abbiamo iniziato a cambiare i nostri approcci, abbiamo formato 4 comandamenti. Li ho presentati nelle diapositive:

Questi comandamenti sono abbastanza semplici:

• Identificare rapidamente il problema.
• Liberatene ancora più velocemente.
• Aiuta a capire il motivo (più tardi, per gli sviluppatori).
• E standardizzare gli approcci.

Vorrei attirare la vostra attenzione sul punto n. 2. Stiamo eliminando il problema, non risolvendolo. Decidere è secondario. Per noi la cosa principale è che l'utente sia protetto da questo problema. Esisterà in qualche ambiente isolato, ma questo ambiente non avrà alcun contatto con esso. In realtà, esamineremo questi quattro gruppi di problemi (alcuni in modo più dettagliato, altri in modo meno dettagliato), ti dirò cosa usiamo, quale esperienza rilevante abbiamo nelle soluzioni.

Risoluzione dei problemi: quando si verificano e cosa fare al riguardo?

Ma inizieremo in modo non corretto, inizieremo con il punto n. 2: come eliminare rapidamente il problema? C'è un problema: dobbiamo risolverlo. "Cosa dovremmo fare a riguardo?" - la domanda principale. E quando abbiamo iniziato a pensare a come risolvere il problema, abbiamo sviluppato per noi stessi alcuni requisiti che la risoluzione dei problemi deve seguire.

Per formulare queste esigenze abbiamo deciso di porci la domanda: “Quando abbiamo problemi”? E i problemi, come si è scoperto, si verificano in quattro casi:

• Guasto hardware.
• I servizi esterni non sono riusciti.
• Modifica della versione del software (la stessa distribuzione).
• Crescita del carico esplosivo.

Non parleremo dei primi due. Un malfunzionamento dell'hardware può essere risolto in modo molto semplice: è necessario duplicare tutto. Se si tratta di dischi i dischi devono essere assemblati in RAID; se si tratta di un server il server deve essere duplicato; se si dispone di un'infrastruttura di rete bisogna fornire una seconda copia dell'infrastruttura di rete, cioè la si prende e duplicarlo. E se qualcosa non funziona, passi alla potenza di riserva. È difficile dire altro qui.

Il secondo è il fallimento dei servizi esterni. Per la maggior parte dei cittadini il sistema non è affatto un problema, ma per noi no. Poiché elaboriamo i pagamenti, siamo un aggregatore che si frappone tra l'utente (che inserisce i dati della sua carta) e le banche, i sistemi di pagamento (Visa, MasterCard, Mira, ecc.). I nostri servizi esterni (sistemi di pagamento, banche) tendono a fallire. Né noi né tu (se disponi di tali servizi) possiamo influenzare questo.

Cosa fare allora? Ci sono due opzioni qui. Innanzitutto, se puoi, dovresti duplicare questo servizio in qualche modo. Ad esempio, se possiamo, trasferiamo il traffico da un servizio a un altro: ad esempio, le carte sono state elaborate tramite Sberbank, Sberbank ha problemi: trasferiamo il traffico [condizionatamente] a Raiffeisen. La seconda cosa che possiamo fare è accorgerci molto rapidamente del guasto dei servizi esterni, e quindi parleremo della velocità di risposta nella prossima parte del rapporto.

Di questi quattro, infatti, possiamo influenzare in modo specifico il cambiamento delle versioni del software: intraprendere azioni che porteranno a un miglioramento della situazione nel contesto delle implementazioni e nel contesto di una crescita esplosiva del carico. In realtà, è quello che abbiamo fatto. Anche qui una piccola nota...

Di questi quattro problemi, molti si risolvono immediatamente se si dispone di un cloud. Se ti trovi nei cloud Microsoft Azhur, Ozone o utilizzi i nostri cloud, da Yandex o Mail, allora almeno un malfunzionamento dell'hardware diventa il loro problema e tutto va immediatamente bene per te nel contesto di un malfunzionamento dell'hardware.

Siamo un'azienda un po' non convenzionale. Qui tutti parlano di "Kubernet", di cloud: non abbiamo né "Kubernet" né cloud. Ma abbiamo rack di hardware in molti data center e siamo costretti a vivere con questo hardware, siamo costretti ad essere responsabili di tutto. Pertanto, parleremo in questo contesto. Quindi, riguardo ai problemi. I primi due sono stati tolti dalle parentesi.

Modifica della versione del software. Basi

I nostri sviluppatori non hanno accesso alla produzione. Perché? È solo che siamo certificati PCI DSS e i nostri sviluppatori semplicemente non hanno il diritto di entrare nel "prodotto". Questo è tutto, punto. Affatto. Pertanto, la responsabilità dello sviluppo termina esattamente nel momento in cui lo sviluppo invia la build per il rilascio.

La nostra seconda base che abbiamo, che ci aiuta molto, è l'assenza di conoscenze uniche e non documentate. Spero che sia lo stesso per te. Perché se così non fosse, avrai dei problemi. I problemi sorgeranno quando questa conoscenza unica e non documentata non sarà presente al momento giusto nel posto giusto. Diciamo che hai una persona che sa come implementare un componente specifico - la persona non è lì, è in vacanza o malata - tutto qui, hai problemi.

E la terza base a cui siamo arrivati. Ci siamo arrivati ​​attraverso dolore, sangue, lacrime: siamo giunti alla conclusione che qualsiasi nostra build contiene errori, anche se è priva di errori. Lo abbiamo deciso da soli: quando distribuiamo qualcosa, quando mettiamo qualcosa in produzione, abbiamo una build con errori. Abbiamo formato i requisiti che il nostro sistema deve soddisfare.

Requisiti per modificare la versione del software

I requisiti sono tre:

• Dobbiamo ripristinare rapidamente la distribuzione.
• Dobbiamo ridurre al minimo l'impatto di una distribuzione non riuscita.
• E dobbiamo essere in grado di schierarci rapidamente in parallelo.
  Esattamente in quest'ordine! Perché? Perché, prima di tutto, quando si distribuisce una nuova versione, la velocità non è importante, ma è importante per te, se qualcosa va storto, tornare indietro rapidamente e avere un impatto minimo. Ma se hai una serie di versioni in produzione, per le quali risulta che c'è un errore (all'improvviso non c'è stata alcuna distribuzione, ma c'è un errore), la velocità della successiva distribuzione è importante per te. Cosa abbiamo fatto per soddisfare queste richieste? Abbiamo fatto ricorso alla seguente metodologia:

  
  
  È abbastanza noto, non l'abbiamo mai inventato: questa è la distribuzione Blu/Verde. Cos'è? È necessario disporre di una copia per ciascun gruppo di server su cui sono installate le applicazioni. La copia è “calda”: non c'è traffico su di essa, ma in qualsiasi momento questo traffico può essere inviato a questa copia. Questa copia contiene la versione precedente. E al momento della distribuzione, distribuisci il codice su una copia inattiva. Quindi trasferisci parte del traffico (o tutto) alla nuova versione. Pertanto, per modificare il flusso del traffico dalla vecchia versione a quella nuova, è necessario eseguire solo un'azione: è necessario modificare il bilanciatore a monte, cambiare la direzione, da uno a monte all'altro. Questo è molto conveniente e risolve il problema del cambio rapido e del rollback rapido.

  Qui la soluzione alla seconda domanda è la minimizzazione: puoi inviare solo una parte del tuo traffico su una nuova linea, su una linea con un nuovo codice (lascia che sia, ad esempio, il 2%). E questo 2% non è il 100%! Se hai perso il 100% del tuo traffico a causa di un’implementazione non riuscita, è spaventoso; se hai perso il 2% del tuo traffico, è spiacevole, ma non è spaventoso. Inoltre, molto probabilmente gli utenti non se ne accorgeranno nemmeno, perché in alcuni casi (non in tutti) lo stesso utente, premendo F5, verrà portato a un'altra versione funzionante.

  Schieramento Blu/Verde. Instradamento

  Tuttavia, non tutto è così semplice “Distribuzione blu/verde”... Tutti i nostri componenti possono essere divisi in tre gruppi:

  • questo è il frontend (le pagine di pagamento che vedono i nostri clienti);
  • nucleo di elaborazione;
  • adattatore per lavorare con sistemi di pagamento (banche, MasterCard, Visa...).

  E qui c'è una sfumatura: la sfumatura sta nel percorso tra le righe. Se trasferisci semplicemente il 100% del traffico, non avrai questi problemi. Ma se vuoi cambiare il 2%, inizi a fare domande: “Come farlo?” La cosa più semplice è semplice: puoi impostare Round Robin in nginx con una scelta casuale e hai il 2% a sinistra, il 98% a destra. Ma questo non è sempre adatto.

  Ad esempio, nel nostro caso, un utente interagisce con il sistema con più di una richiesta. Questo è normale: 2, 3, 4, 5 richieste: i tuoi sistemi potrebbero essere gli stessi. E se per te è importante che tutte le richieste dell'utente arrivino sulla stessa riga su cui è arrivata la prima richiesta, oppure (secondo punto) tutte le richieste dell'utente arrivino sulla nuova riga dopo il passaggio (avrebbe potuto iniziare a lavorare prima con sistema, prima del cambio), - allora questa distribuzione casuale non è adatta a te. Poi ci sono le seguenti opzioni:

  
  
  La prima opzione, la più semplice, si basa sui parametri base del client (IP Hash). Hai un IP e lo dividi da destra a sinistra per l'indirizzo IP. Quindi il secondo caso che ho descritto funzionerà per te, quando è avvenuta la distribuzione, l'utente potrebbe già iniziare a lavorare con il tuo sistema e dal momento della distribuzione tutte le richieste andranno su una nuova riga (ad esempio sulla stessa).

  Se per qualche motivo questo non ti soddisfa e devi inviare richieste alla linea da cui è arrivata la richiesta iniziale dell'utente, allora hai due opzioni...
  Prima opzione: puoi acquistare nginx+ a pagamento. Esiste un meccanismo di sessioni Sticky che, su richiesta iniziale dell'utente, assegna una sessione all'utente e la lega all'uno o all'altro upstream. Tutte le successive richieste degli utenti nel corso della durata della sessione verranno inviate allo stesso upstream in cui è stata pubblicata la sessione.

  Questo non ci andava bene perché avevamo già nginx regolare. Passare a nginx+ non è che sia costoso, è solo che è stato un po’ doloroso per noi e non molto giusto. Le “Sticks Sessions”, ad esempio, non hanno funzionato per noi per il semplice motivo che le “Sticks Sessions” non consentono il routing basato su “Oa-o”. Lì puoi specificare cosa facciamo noi “Sticks Sessions”, ad esempio, tramite indirizzo IP o tramite indirizzo IP e cookie o tramite postparametro, ma “O-o” lì è più complicato.

  Pertanto, siamo arrivati ​​​​alla quarta opzione. Abbiamo preso nginx con steroidi (questo è openresty): questo è lo stesso nginx, che supporta inoltre l'inclusione degli ultimi script. Puoi scrivere un ultimo script, dargli una "pausa aperta" e quest'ultimo script verrà eseguito quando arriva la richiesta dell'utente.

  E abbiamo scritto, infatti, uno script del genere, impostandoci "openresti" e in questo script ordiniamo 6 diversi parametri per concatenazione "Or". A seconda della presenza dell'uno o dell'altro parametro, sappiamo che l'utente è arrivato su una pagina o sull'altra, su una riga o sull'altra.

  Schieramento Blu/Verde. Vantaggi e svantaggi

  Naturalmente, probabilmente sarebbe stato possibile renderlo un po' più semplice (usare le stesse “Sticky Sessions”), ma abbiamo anche una tale sfumatura che non solo l'utente interagisce con noi nell'ambito di un'elaborazione di una transazione... Ma anche i sistemi di pagamento interagiscono con noi: dopo aver elaborato la transazione (inviando una richiesta al sistema di pagamento), riceviamo un coolback.
  E diciamo che se all'interno del nostro circuito possiamo inoltrare l'indirizzo IP dell'utente in tutte le richieste e dividere gli utenti in base all'indirizzo IP, allora non diremo la stessa “Visa”: “Amico, siamo un'azienda così retrò, ci sembra essere internazionale (sul sito web e in Russia)... Forniscici l'indirizzo IP dell'utente in un campo aggiuntivo, il tuo protocollo è standardizzato”! È chiaro che non saranno d'accordo.

  
  
  Pertanto, questo non ha funzionato per noi: abbiamo fatto openresty. Di conseguenza, con il routing abbiamo ottenuto qualcosa del genere:

  Il Blue/Green Deployment presenta, di conseguenza, i vantaggi e gli svantaggi che ho menzionato.

  Due svantaggi:

  • devi preoccuparti del routing;
  • il secondo principale svantaggio è la spesa.

  Hai bisogno del doppio dei server, hai bisogno del doppio delle risorse operative, devi spendere il doppio degli sforzi per mantenere l'intero zoo.

  A proposito, tra i vantaggi c'è un'altra cosa che non ho menzionato prima: hai una riserva in caso di aumento del carico. Se hai una crescita esplosiva del carico, hai un gran numero di utenti, includi semplicemente la seconda riga nella distribuzione da 50 a 50 e avrai immediatamente server x2 nel tuo cluster finché non risolvi il problema di avere più server.

  Come effettuare una distribuzione rapida?

  Abbiamo parlato di come risolvere il problema della minimizzazione e del rollback rapido, ma la domanda rimane: "Come implementare rapidamente?"

  
  
  Qui è breve e semplice.

  • Devi avere un sistema CD (Continuous Delivery): non puoi farne a meno. Se disponi di un server, puoi distribuirlo manualmente. Abbiamo circa un migliaio e mezzo di server e un migliaio e mezzo di handle, ovviamente: possiamo creare un dipartimento delle dimensioni di questa stanza solo per distribuirlo.
  • La distribuzione deve essere parallela. Se la tua distribuzione è sequenziale, allora tutto va male. Un server è normale, distribuirai un migliaio e mezzo di server tutto il giorno.
  • Anche in questo caso, per l'accelerazione, probabilmente non è più necessario. Durante la distribuzione, il progetto viene solitamente creato. Hai un progetto web, c'è una parte front-end (fai un web pack lì, compili npm - qualcosa del genere), e questo processo è, in linea di principio, di breve durata - 5 minuti, ma questi 5 minuti possono essere critico. Ecco perché, ad esempio, non lo facciamo: rimuoviamo questi 5 minuti, distribuiamo artefatti.

    Cos'è un artefatto? Un artefatto è una costruzione assemblata in cui tutte le parti di assemblaggio sono già state completate. Archiviamo questo artefatto nell'archivio artefatti. Un tempo utilizzavamo due di questi archivi: era Nexus e ora jFrog Artifactory). Inizialmente abbiamo utilizzato "Nexus" perché abbiamo iniziato a praticare questo approccio nelle applicazioni Java (si adattava bene). Poi vi inseriscono alcune delle applicazioni scritte in PHP; e “Nexus” non era più adatto, quindi abbiamo scelto jFrog Artefactory, che può artefattorizzare quasi tutto. Siamo persino arrivati ​​al punto che in questo repository di artefatti memorizziamo i nostri pacchetti binari che raccogliamo per i server.

  Crescita del carico esplosivo

  Abbiamo parlato di cambiare la versione del software. La prossima cosa che abbiamo è un aumento esplosivo del carico. Qui probabilmente intendo con crescita esplosiva del carico non proprio la cosa giusta...

  Abbiamo scritto un nuovo sistema: è orientato ai servizi, alla moda, bello, lavoratori ovunque, code ovunque, asincronia ovunque. E in tali sistemi, i dati possono fluire attraverso flussi diversi. Per la prima transazione è possibile utilizzare il 1°, 3°, 10° lavoratore, per la seconda transazione: il 2°, 4°, 5°. E oggi, diciamo, al mattino hai un flusso di dati che utilizza i primi tre lavoratori, e la sera cambia radicalmente, e tutto utilizza gli altri tre lavoratori.

  E qui si scopre che devi in ​​qualche modo ridimensionare i lavoratori, devi in ​​qualche modo ridimensionare i tuoi servizi, ma allo stesso tempo prevenire il gonfiamento delle risorse.

  
  
  Abbiamo definito le nostre esigenze. Questi requisiti sono abbastanza semplici: che ci sia la scoperta del servizio, la parametrizzazione: tutto è standard per la costruzione di sistemi così scalabili, tranne un punto: il deprezzamento delle risorse. Abbiamo detto che non siamo pronti ad ammortizzare le risorse affinché i server riscaldino l’aria. Abbiamo preso "Consul", abbiamo preso "Nomad", che gestisce i nostri lavoratori.

  Perché questo è un problema per noi? Facciamo un piccolo passo indietro. Oggi abbiamo alle spalle circa 70 sistemi di pagamento. Al mattino, il traffico passa attraverso Sberbank, poi Sberbank cade, ad esempio, e lo trasferiamo a un altro sistema di pagamento. Prima di Sberbank avevamo 100 lavoratori e successivamente dobbiamo aumentare drasticamente 100 lavoratori per un altro sistema di pagamento. Ed è auspicabile che tutto ciò avvenga senza la partecipazione umana. Perché se c'è partecipazione umana, dovrebbe esserci un ingegnere seduto lì 24 ore su 7, 70 giorni su XNUMX, che dovrebbe fare solo questo, perché tali guasti, quando hai XNUMX sistemi alle spalle, si verificano regolarmente.

  Pertanto, abbiamo esaminato Nomad, che ha un IP aperto, e abbiamo scritto la nostra cosa, Scale-Nomad - ScaleNo, che fa più o meno quanto segue: monitora la crescita della coda e riduce o aumenta il numero di lavoratori a seconda della dinamica della coda. Quando l’abbiamo fatto, abbiamo pensato: “Forse possiamo renderlo open source?” Poi la guardarono: era semplice come due centesimi.

  Finora non l'abbiamo reso open source, ma se all'improvviso dopo il rapporto, dopo aver realizzato che hai bisogno di una cosa del genere, ne hai bisogno, i miei contatti sono nell'ultima diapositiva, per favore scrivimi. Se ci sono almeno 3-5 persone, lo sponsorizzeremo.

  
  
  Come funziona? Diamo un'occhiata! Guardando al futuro: sul lato sinistro c'è una parte del nostro monitoraggio: questa è una riga, in alto c'è l'ora di elaborazione dell'evento, al centro c'è il numero di transazioni, in basso c'è il numero di lavoratori.

  Se guardi, c'è un problema tecnico in questa immagine. Nel grafico in alto, uno dei grafici si è bloccato in 45 secondi: uno dei sistemi di pagamento è andato in tilt. Immediatamente il traffico è stato portato in 2 minuti e la coda ha cominciato a crescere su un altro sistema di pagamento, dove non c'erano lavoratori (non abbiamo utilizzato le risorse, anzi, abbiamo smaltito correttamente la risorsa). Non volevamo il riscaldamento: c'era un numero minimo, circa 5-10 lavoratori, ma non riuscivano a farcela.

  L'ultimo grafico mostra una "gobba", il che significa semplicemente che "Skaleno" ha raddoppiato tale importo. E poi, quando il grafico è sceso un po', lo ha ridotto un po': il numero di lavoratori è stato modificato automaticamente. È così che funziona questa cosa. Abbiamo parlato del punto numero 2: "Come eliminare rapidamente i motivi".

  Monitoraggio. Come identificare rapidamente il problema?

  Ora il primo punto è “Come identificare rapidamente il problema?” Monitoraggio! Dobbiamo capire certe cose in fretta. Quali cose dovremmo capire velocemente?

  
  
  Tre cose!

  • Dobbiamo comprendere e comprendere rapidamente il rendimento delle nostre stesse risorse.
  • Dobbiamo comprendere rapidamente i guasti e monitorare le prestazioni dei sistemi esterni a noi.
  • Il terzo punto è identificare gli errori logici. Questo è quando il sistema funziona per te, tutto è normale secondo tutti gli indicatori, ma qualcosa va storto.

  Probabilmente non ti dirò niente di così interessante qui. Sarò Capitan Ovvio. Abbiamo cercato cosa c'era sul mercato. Abbiamo uno “zoo divertente”. Questo è il tipo di zoo che abbiamo adesso:

  
  
  Usiamo Zabbix per monitorare l'hardware, per monitorare i principali indicatori dei server. Usiamo Okmeter per i database. Usiamo "Grafana" e "Prometheus" per tutti gli altri indicatori che non si adattano ai primi due, alcuni con "Grafana" e "Prometheus", e alcuni con "Grafana" con "Influx" e Telegraf.

  Un anno fa volevamo utilizzare New Relic. Bella cosa, può fare tutto. Ma per quanto possa fare tutto, è così costosa. Quando siamo cresciuti fino a raggiungere un volume di 1,5mila server, un venditore è venuto da noi e ci ha detto: “Concludiamo un accordo per il prossimo anno”. Abbiamo guardato il prezzo e abbiamo detto di no, non lo faremo. Ora stiamo abbandonando New Relic, abbiamo circa 15 server rimasti sotto il monitoraggio di New Relic. Il prezzo si è rivelato assolutamente selvaggio.

  E c'è uno strumento che abbiamo implementato noi stessi: questo è Debugger. All'inizio lo chiamavamo "Bagger", ma poi passò un insegnante di inglese, rise selvaggiamente e lo ribattezzammo "Debagger". Cos'è? Si tratta di uno strumento che, infatti, in 15-30 secondi su ciascun componente, come una “scatola nera” del sistema, esegue test sulle prestazioni complessive del componente.

  Ad esempio, se c'è una pagina esterna (pagina di pagamento), la apre semplicemente e guarda come dovrebbe apparire. Se è in elaborazione, invia una "transazione" di prova e si assicura che questa "transazione" arrivi. Se si tratta di una connessione con sistemi di pagamento, lanciamo una richiesta di prova di conseguenza, dove possibile, e vediamo che per noi va tutto bene.

  Quali indicatori sono importanti per il monitoraggio?

  Cosa monitoriamo principalmente? Quali indicatori sono importanti per noi?

  
  

  • Il tempo di risposta/RPS sui fronti è un indicatore molto importante. Risponde immediatamente che qualcosa non va in te.
  • Il numero di messaggi elaborati in tutte le code.
  • Numero di lavoratori.
  • Metriche di correttezza di base.

  L'ultimo punto è la metrica "business", "business". Se vuoi monitorare la stessa cosa, devi definire una o due metriche che sono per te gli indicatori principali. La nostra metrica è il throughput (questo è il rapporto tra il numero di transazioni riuscite e il flusso totale delle transazioni). Se cambia qualcosa in un intervallo di 5-10-15 minuti, significa che abbiamo dei problemi (se cambia radicalmente).

  Quello che ci appare è un esempio di una delle nostre schede:

  
  
  Sul lato sinistro ci sono 6 grafici, secondo le linee: il numero di lavoratori e il numero di messaggi nelle code. Sul lato destro: RPS, RTS. Di seguito è riportata la stessa metrica “business”. E nella metrica “business” possiamo immediatamente vedere che qualcosa è andato storto nei due grafici centrali... Questo è solo un altro sistema che sta alle nostre spalle che è caduto.

  La seconda cosa da fare era monitorare il crollo dei sistemi di pagamento esterni. Qui abbiamo preso OpenTracing: un meccanismo, uno standard, un paradigma che consente di tracciare i sistemi distribuiti; ed è stato leggermente cambiato. Il paradigma standard di OpenTracing dice che costruiamo una traccia per ogni singola richiesta. Non ne avevamo bisogno e lo abbiamo racchiuso in una traccia riepilogativa e aggregativa. Abbiamo realizzato uno strumento che ci consente di monitorare la velocità dei sistemi dietro di noi.

  
  
  Il grafico ci mostra che uno dei sistemi di pagamento ha iniziato a rispondere in 3 secondi: abbiamo problemi. Inoltre, questa cosa reagirà quando inizieranno i problemi, ad un intervallo di 20-30 secondi.

  E la terza classe di errori di monitoraggio esistenti è il monitoraggio logico.

  Sinceramente non sapevo cosa disegnare su questa slide perché cercavamo da tempo sul mercato qualcosa che facesse al caso nostro. Non abbiamo trovato nulla, quindi abbiamo dovuto farlo da soli.

  
  
  Cosa intendo per monitoraggio logico? Bene, immagina: ti crei un sistema (ad esempio, un clone di Tinder); ce l'hai fatta, l'hai lanciata. Il manager di successo Vasya Pupkin l'ha messo sul suo telefono, vede una ragazza lì, le piace... e cose simili non vanno alla ragazza - cose simili vanno alla guardia di sicurezza Mikhalych dello stesso business center. Il direttore scende le scale e poi si chiede: "Perché questa guardia Mikhalych gli sorride così piacevolmente?"

  In tali situazioni... Per noi, questa situazione suona un po' diversa, perché (ho scritto) si tratta di una perdita di reputazione che porta indirettamente a perdite finanziarie. La nostra situazione è opposta: potremmo subire perdite finanziarie dirette, ad esempio se abbiamo condotto una transazione con successo, ma non ha avuto successo (o viceversa). Ho dovuto scrivere il mio strumento che tenga traccia del numero di transazioni riuscite nel tempo utilizzando indicatori aziendali. Non ho trovato nulla sul mercato! E' proprio questa l'idea che volevo trasmettere. Non c’è nulla sul mercato per risolvere questo tipo di problema.

  Si trattava di come identificare rapidamente il problema.

  Come determinare i motivi della distribuzione

  Il terzo gruppo di problemi che risolviamo è che dopo aver identificato il problema, dopo averlo eliminato, sarebbe bene capire il motivo dello sviluppo, del test e fare qualcosa al riguardo. Di conseguenza, dobbiamo indagare, dobbiamo sollevare i tronchi.

  
  
  Se parliamo di log (il motivo principale sono i log), la maggior parte dei nostri log si trova nello stack ELK: quasi tutti hanno lo stesso. Per alcuni, potrebbe non essere in ELK, ma se scrivi log in gigabyte, prima o poi arriverai a ELK. Li scriviamo in terabyte.

  
  
  C'è un problema qui. L'abbiamo risolto, corretto l'errore per l'utente, abbiamo iniziato a scavare quello che c'era, siamo saliti a Kibana, abbiamo inserito lì l'ID della transazione e abbiamo ottenuto una calzatura come questa (mostra molto). E assolutamente nulla è chiaro in questa calzatura. Perché? Sì, perché non è chiaro quale parte appartenga a quale lavoratore, quale parte appartenga a quale componente. E in quel momento ci siamo resi conto che avevamo bisogno del tracciamento, lo stesso OpenTracing di cui ho parlato.

  Lo abbiamo pensato un anno fa, abbiamo rivolto la nostra attenzione al mercato e lì c'erano due strumenti: "Zipkin" e "Jaeger". “Jager” è in effetti un tale erede ideologico, un successore ideologico di “Zipkin”. Tutto va bene in Zipkin, tranne che non sa come aggregare, non sa come includere i log nella traccia, solo la traccia temporale. E “Jager” lo ha sostenuto.

  Abbiamo esaminato "Jager": puoi strumentare le applicazioni, puoi scrivere in Api (lo standard Api per PHP a quel tempo, tuttavia, non era approvato - questo era un anno fa, ma ora è già stato approvato), ma lì non era assolutamente un cliente. "Va bene", abbiamo pensato e scritto al nostro cliente. Cosa abbiamo ottenuto? Questo è più o meno quello che sembra:

  
  
  In Jaeger vengono creati degli span per ogni messaggio. Cioè, quando l'utente apre il sistema, vede uno o due blocchi per ogni richiesta in arrivo (1-2-3 - il numero di richieste in arrivo dall'utente, il numero di blocchi). Per facilitare gli utenti, abbiamo aggiunto tag ai registri e alle tracce temporali. Di conseguenza, in caso di errore, la nostra applicazione contrassegnerà il registro con l'apposito tag Error. È possibile filtrare per tag Errore e verranno visualizzati solo gli intervalli che contengono questo blocco con un errore. Ecco come appare se espandiamo lo span:

  
  
  All'interno della campata è presente un insieme di tracce. In questo caso si tratta di tre tracce di test e la terza traccia ci informa che si è verificato un errore. Allo stesso tempo, qui vediamo una traccia temporale: abbiamo una scala temporale in alto e vediamo in quale intervallo di tempo è stato registrato questo o quel registro.

  Di conseguenza, le cose sono andate bene per noi. Abbiamo scritto la nostra estensione e l'abbiamo resa open source. Se vuoi lavorare con il tracciamento, se vuoi lavorare con “Jager” in PHP, c'è la nostra estensione, benvenuto da usare, come si suol dire:

  
  
  Abbiamo questa estensione: è un client per OpenTracing Api, è realizzato come estensione php, ovvero dovrai assemblarlo e installarlo sul sistema. Un anno fa non c’era niente di diverso. Ora ci sono altri client che sono come componenti. Qui dipende da te: o pompi i componenti con un compositore o usi l'estensione a tua scelta.

  Standard aziendali

  Abbiamo parlato dei tre comandamenti. Il quarto comandamento è standardizzare gli approcci. Cosa riguarda? Si tratta di questo:

  
  
  Perché qui c’è la parola “aziendale”? Non perché siamo un’azienda grande o burocratica, no! Ho voluto usare qui la parola “aziendale” nel contesto in cui ogni azienda, ogni prodotto dovrebbe avere i propri standard, compreso te. Quali standard abbiamo?

  
  

  • Abbiamo regolamenti di distribuzione. Non andiamo da nessuna parte senza di lui, non possiamo. Effettuiamo l'implementazione circa 60 volte a settimana, ovvero quasi costantemente. Allo stesso tempo, ad esempio, nel regolamento sullo schieramento abbiamo un tabù sugli schieramenti di venerdì: in linea di principio non lo facciamo.
  • Richiediamo documentazione. Non un singolo nuovo componente entra in produzione se non esiste documentazione, anche se è nato sotto la penna dei nostri specialisti RnD. Richiediamo da loro istruzioni di distribuzione, una mappa di monitoraggio e una descrizione approssimativa (beh, come possono scrivere i programmatori) di come funziona questo componente, come risolverlo.
  • Risolviamo non la causa del problema, ma il problema, quello che ho già detto. Per noi è importante proteggere l'utente da problemi.
  • Abbiamo le autorizzazioni. Ad esempio, non consideriamo tempi di inattività se perdiamo il 2% del traffico entro due minuti. Fondamentalmente questo non è incluso nelle nostre statistiche. Se è più in termini percentuali o temporaneo, lo contiamo già.
  • E scriviamo sempre autopsie. Qualunque cosa ci accada, qualsiasi situazione in cui qualcuno si sia comportato in modo anomalo durante la produzione si rifletterà nell'autopsia. Un'autopsia è un documento in cui scrivi cosa ti è successo, una tempistica dettagliata, cosa hai fatto per correggerlo e (questo è un blocco obbligatorio!) cosa farai per evitare che ciò accada in futuro. Questo è obbligatorio e necessario per l'analisi successiva.

  Cosa è considerato tempo di inattività?

  
  
  A cosa ha portato tutto questo?

  Ciò ha portato al fatto che (abbiamo avuto alcuni problemi con la stabilità, questo non andava bene né ai clienti né a noi) negli ultimi 6 mesi il nostro indicatore di stabilità era 99,97. Possiamo dire che questo non è molto. Sì, abbiamo qualcosa per cui lottare. Di questo indicatore, circa la metà è la stabilità, per così dire, non nostra, ma del nostro firewall per applicazioni web, che sta di fronte a noi e viene utilizzato come servizio, ma ai clienti non interessa.

  Abbiamo imparato a dormire la notte. Finalmente! Sei mesi fa non potevamo. E a proposito dei risultati, vorrei fare una nota. Ieri sera c'è stato uno splendido servizio sul sistema di controllo di un reattore nucleare. Se le persone che hanno scritto questo sistema possono ascoltarmi, per favore dimentica quello che ho detto su “il 2% non è tempo di inattività”. Per te il 2% è tempo di inattività, anche se per due minuti!

  È tutto! Le tue domande.

  
  

  Informazioni sui bilanciatori e sulla migrazione del database

  Domanda del pubblico (di seguito – B): – Buonasera. Grazie mille per questo rapporto amministrativo! Una breve domanda sui tuoi bilanciatori. Hai detto che hai un WAF, cioè, a quanto ho capito, usi una sorta di bilanciatore esterno...

  EK: – No, utilizziamo i nostri servizi come bilanciamento. In questo caso per noi WAF è esclusivamente uno strumento di protezione DDoS.

  A: – Puoi dire qualche parola sui bilanciatori?

  EK: – Come ho già detto, questo è un gruppo di server in openresty. Ora abbiamo 5 gruppi di riserva che rispondono in modo esclusivo... cioè un server che esegue esclusivamente openresty, inoltra solo il traffico. Di conseguenza, per capire quanto teniamo: ora abbiamo un flusso di traffico regolare di diverse centinaia di megabit. Ce la fanno, si sentono bene, non si sforzano nemmeno.

  A: – Anche una domanda semplice. Ecco lo schieramento Blu/Verde. Cosa fate, ad esempio, con le migrazioni dei database?

  EK: - Buona domanda! Guarda, nella distribuzione Blu/Verde abbiamo code separate per ogni linea. Cioè, se parliamo di code di eventi che vengono trasmesse da lavoratore a lavoratore, ci sono code separate per la linea blu e per la linea verde. Se parliamo del database stesso, lo abbiamo deliberatamente ristretto il più possibile, spostato tutto praticamente in coda, memorizziamo solo una pila di transazioni nel database. E il nostro stack di transazioni è lo stesso per tutte le righe. Con il database in questo contesto: non lo dividiamo in blu e verde, perché entrambe le versioni del codice devono sapere cosa sta succedendo con la transazione.

  Amici, ho anche un piccolo premio per spronarvi: un libro. E dovrei riceverlo per la domanda migliore.

  A: - Ciao. Grazie per la segnalazione La domanda è questa. Monitori i pagamenti, monitori i servizi con cui comunichi... Ma come monitorare affinché una persona in qualche modo arrivi alla tua pagina di pagamento, effettui un pagamento e il progetto gli accrediti dei soldi? Cioè come controlli che il commerciante sia disponibile e abbia accettato la tua richiamata?

  EK: – “Mercante” per noi in questo caso è esattamente lo stesso servizio esterno del sistema di pagamento. Monitoriamo la velocità di risposta del commerciante.

  Informazioni sulla crittografia del database

  A: - Ciao. Ho una domanda leggermente correlata. Hai dati sensibili PCI DSS. Volevo sapere come memorizzi i PAN nelle code in cui devi trasferirti? Usi qualche crittografia? E questo porta alla seconda domanda: secondo PCI DSS, è necessario crittografare periodicamente il database in caso di modifiche (licenziamento degli amministratori, ecc.) - cosa succede all'accessibilità in questo caso?

  
  
  EK: - Domanda meravigliosa! Innanzitutto non memorizziamo i PAN nelle code. In linea di principio non abbiamo il diritto di archiviare PAN da nessuna parte in forma chiara, quindi utilizziamo un servizio speciale (lo chiamiamo "Kademon") - questo è un servizio che fa solo una cosa: riceve un messaggio in input e invia inviare un messaggio crittografato. E conserviamo tutto con questo messaggio crittografato. Di conseguenza, la lunghezza della nostra chiave è inferiore a un kilobyte, quindi questo è serio e affidabile.

  A: – Ti servono 2 kilobyte adesso?

  EK: – Sembra solo ieri che fossero 256... Beh, dove sennò?!

  Di conseguenza, questo è il primo. E in secondo luogo, la soluzione esistente supporta la procedura di ricrittografia: ci sono due coppie di "keks" (chiavi), che danno "mazzi" che crittografano (le chiavi sono le chiavi, i dek sono derivati ​​delle chiavi che crittografano) . E se la procedura viene avviata (succede regolarmente, da 3 mesi a ± alcuni), scarichiamo un nuovo paio di “torte” e criptiamo nuovamente i dati. Disponiamo di servizi separati che estraggono tutti i dati e li crittografano in un modo nuovo; I dati vengono archiviati accanto all'identificatore della chiave con cui vengono crittografati. Di conseguenza, non appena crittifichiamo i dati con nuove chiavi, cancelliamo la vecchia chiave.

  A volte i pagamenti devono essere effettuati manualmente...

  A: – Cioè, se è arrivato un rimborso per qualche operazione, la decripterai ancora con la vecchia chiave?

  EK: - Sì.

  A: – Poi ancora una piccola domanda. Quando si verifica qualche tipo di guasto, caduta o incidente, è necessario portare a termine la transazione manualmente. C'è una situazione del genere.

  EK: - Si Qualche volta.

  A: – Da dove prendi questi dati? Oppure vai tu stesso in questo magazzino?

  EK: – No, beh, ovviamente abbiamo una sorta di sistema di back-office che contiene un'interfaccia per il nostro supporto. Se non sappiamo in quale stato si trova la transazione (ad esempio finché il sistema di pagamento non ha risposto con un timeout), non lo sappiamo a priori, ovvero assegniamo lo stato finale solo con piena fiducia. In questo caso, mettiamo la transazione in uno stato speciale per l'elaborazione manuale. Al mattino, il giorno successivo, non appena il supporto riceve informazioni che tali transazioni rimangono nel sistema di pagamento, le elaborano manualmente in questa interfaccia.

  
  
  A: – Ho un paio di domande. Uno di questi è la continuazione della zona PCI DSS: come si registra il loro circuito? Questa domanda è perché lo sviluppatore avrebbe potuto inserire qualsiasi cosa nei registri! Seconda domanda: come si implementano gli hotfix? Gli handle nel database sono un'opzione, ma potrebbero essere presenti hotfix gratuiti: qual è la procedura lì? E la terza domanda è probabilmente legata a RTO, RPO. La tua disponibilità era 99,97, quasi quattro nove, ma a quanto ho capito hai un secondo data center, un terzo data center e un quinto data center... Come li sincronizzi, li replichi e tutto il resto?

  EK: - Cominciamo dal primo. La prima domanda riguardava i log? Quando scriviamo i log, abbiamo un livello che maschera tutti i dati sensibili. Guarda la maschera e i campi aggiuntivi. Di conseguenza, i nostri log escono con dati già mascherati e un circuito PCI DSS. Questo è uno dei compiti regolari assegnati al reparto test. Sono tenuti a controllare ogni attività, inclusi i log che scrivono, e questa è una delle attività regolari durante le revisioni del codice, al fine di controllare che lo sviluppatore non abbia scritto qualcosa. I successivi controlli vengono effettuati regolarmente dal dipartimento di sicurezza informatica circa una volta alla settimana: i registri dell'ultimo giorno vengono selezionati selettivamente e vengono sottoposti a uno speciale scanner-analizzatore dai server di test per controllare tutto.
  Informazioni sugli hotfix. Ciò è incluso nelle nostre norme di implementazione. Abbiamo una clausola separata sugli hotfix. Riteniamo di implementare hotfix 24 ore su 24 quando ne abbiamo bisogno. Non appena la versione viene assemblata, non appena viene eseguita, non appena abbiamo un artefatto, abbiamo un amministratore di sistema in servizio su chiamata dal supporto e lo distribuisce nel momento in cui è necessario.

  Circa "quattro nove". La cifra che abbiamo ora è stata davvero raggiunta e ci siamo battuti per ottenerla in un altro data center. Ora abbiamo un secondo data center e stiamo iniziando a collegarli tra loro, e il problema della replica tra data center è davvero una questione non banale. Abbiamo provato a risolverlo contemporaneamente utilizzando mezzi diversi: abbiamo provato a utilizzare la stessa "Tarantola" - per noi non ha funzionato, te lo dirò subito. Ecco perché abbiamo finito per ordinare manualmente il "sens". Infatti, ogni applicazione nel nostro sistema esegue la necessaria sincronizzazione “modifica completata” tra i data center in modo asincrono.

  A: – Se ne hai avuto un secondo, perché non ne hai avuto un terzo? Perché nessuno ha ancora il cervello diviso...

  EK: – Ma non abbiamo Split Brain. Dato che ogni applicazione è gestita da un multimaster, per noi non ha importanza a quale centro sia arrivata la richiesta. Siamo pronti al fatto che se uno dei nostri data center fallisce (noi facciamo affidamento su questo) e nel mezzo di una richiesta dell'utente passa al secondo data center, siamo pronti a perdere questo utente, anzi; ma queste saranno unità, unità assolute.

  A: - Buonasera. Grazie per la segnalazione Hai parlato del tuo debugger, che esegue alcune transazioni di prova in produzione. Ma parlaci delle transazioni di prova! Quanto è profondo?

  EK: – Percorre il ciclo completo dell'intero componente. Per un componente non esiste alcuna differenza tra una transazione di prova e una transazione di produzione. Ma da un punto di vista logico, questo è semplicemente un progetto separato nel sistema, sul quale vengono eseguite solo transazioni di prova.

  A: -Dove lo tagli? Qui Core ha inviato...

  EK: – In questo caso siamo dietro "Kor" per transazioni di prova... Abbiamo una cosa come il routing: "Kor" sa a quale sistema di pagamento inviare - inviamo a un sistema di pagamento falso, che fornisce semplicemente un segnale http e È tutto.

  A: – Dimmi, per favore, la tua applicazione è stata scritta in un enorme monolite o l'hai suddivisa in alcuni servizi o addirittura microservizi?

  EK: – Ovviamente non abbiamo un monolite, abbiamo un’applicazione orientata ai servizi. Scherziamo dicendo che il nostro servizio è fatto di monoliti: sono davvero piuttosto grandi. È difficile chiamarli microservizi, ma si tratta di servizi all’interno dei quali operano i lavoratori delle macchine distribuite.

  Se il servizio sul server è compromesso...

  A: – Allora ho la prossima domanda. Anche se fosse un monolite, hai comunque detto che di questi server istantanei ce ne sono molti, fondamentalmente tutti elaborano dati, e la domanda è: "In caso di compromissione di uno dei server istantanei o di un'applicazione, ogni singolo collegamento , hanno una sorta di controllo degli accessi? Chi di loro può fare cosa? Chi devo contattare per quali informazioni?

  
  
  EK: - Sì, sicuramente. I requisiti di sicurezza sono piuttosto seri. In primo luogo, disponiamo di movimenti di dati aperti e i porti sono solo quelli attraverso i quali anticipiamo in anticipo il movimento del traffico. Se un componente comunica con il database (ad esempio con Muskul) tramite 5-4-3-2, gli sarà aperto solo 5-4-3-2 e altre porte e altre direzioni di traffico non saranno disponibili. Inoltre, devi capire che nella nostra produzione esistono circa 10 diversi loop di sicurezza. E anche se l'applicazione fosse in qualche modo compromessa, Dio non voglia, l'aggressore non sarà in grado di accedere alla console di gestione del server, perché si tratta di un'altra zona di sicurezza della rete.

  A: – E in questo contesto, quello che mi interessa di più è che ci sono certi contratti con i servizi – cosa possono fare, attraverso quali “azioni” possono mettersi in contatto tra loro... E in un flusso normale, alcuni servizi specifici richiedono alcuni riga, un elenco di "azioni" dall'altra. Non sembrano rivolgersi agli altri in una situazione normale e hanno altre aree di responsabilità. Se uno di essi viene compromesso, sarà in grado di interrompere le “azioni” di quel servizio?..

  EK: - Capisco. Se in una situazione normale con un altro server la comunicazione fosse consentita, allora sì. Secondo il contratto SLA, non controlliamo che ti siano consentite solo le prime 3 "azioni" e non ti siano consentite le 4 "azioni". Probabilmente questo è superfluo per noi, perché in linea di principio disponiamo già di un sistema di protezione a 4 livelli per i circuiti. Preferiamo difenderci sui contorni, piuttosto che a livello degli interni.

  Come funzionano Visa, MasterCard e Sberbank

  A: – Voglio chiarire un punto riguardo al passaggio di un utente da un data center all'altro. Per quanto ne so, Visa e MasterCard operano utilizzando il protocollo sincrono binario 8583 e lì ci sono dei mix. E volevo sapere, ora intendiamo il passaggio: è direttamente “Visa” e “MasterCard” o prima dei sistemi di pagamento, prima dell’elaborazione?

  EK: - Questo è prima dei mix. I nostri mix si trovano nello stesso data center.

  A: – In parole povere, avete un punto di connessione?

  EK: – “Visa” e “MasterCard” - sì. Semplicemente perché Visa e MasterCard richiedono investimenti piuttosto seri in infrastrutture per concludere contratti separati per ottenere, ad esempio, una seconda coppia di mix. Sono riservati all'interno di un data center, ma se, Dio non voglia, il nostro data center, dove ci sono mix per la connessione a Visa e MasterCard, muore, allora avremo perso la connessione con Visa e MasterCard...

  A: – Come possono essere prenotati? So che Visa in linea di principio consente una sola connessione!

  EK: – Forniscono loro stessi l’attrezzatura. In ogni caso, abbiamo ricevuto apparecchiature completamente ridondanti all'interno.

  A: – Quindi lo stand è del loro Connects Orange?..

  EK: - Sì.

  A: – Ma che dire di questo caso: se il tuo data center scompare, come puoi continuare a utilizzarlo? Oppure il traffico si ferma e basta?

  EK: - NO. In questo caso, trasferiremo semplicemente il traffico su un altro canale, il che, naturalmente, sarà più costoso per noi e più costoso per i nostri clienti. Ma il traffico non passerà attraverso il nostro collegamento diretto con Visa, MasterCard, ma attraverso il condizionale Sberbank (molto esagerato).

  Mi scuso selvaggiamente se ho offeso i dipendenti di Sberbank. Ma secondo le nostre statistiche, tra le banche russe, Sberbank cade più spesso. Non passa mese senza che qualcosa cada alla Sberbank.

  
  
  

  Alcuni annunci 🙂

  Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, cloud VPS per sviluppatori da $ 4.99, un analogo unico dei server entry-level, che è stato inventato da noi per te: Tutta la verità su VPS (KVM) E5-2697 v3 (6 core) 10 GB DDR4 480 GB SSD 1 Gbps da $ 19 o come condividere un server? (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).

  Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV da $199 In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi Come costruire Infrastructure Corp. classe con l'utilizzo di server Dell R730xd E5-2650 v4 del valore di 9000 euro per un centesimo?

Fonte: habr.com