Tutti parlano dei processi di sviluppo e testing, della formazione del personale, dell'aumento della motivazione, ma questi processi sono pochi quando un minuto di inattività del servizio costa cifre stratosferiche. Cosa fare quando si effettuano transazioni finanziarie sotto un rigoroso SLA? Come aumentare l'affidabilità e la resilienza dei propri sistemi, escludendo sviluppo e testing?
La prossima conferenza HighLoad++ si terrà il 6 e 7 aprile 2020 a San Pietroburgo. Maggiori dettagli e biglietti su . 9 novembre, 18:00. HighLoad++ Moscow 2018, sala “Delhi + Calcutta”. Abstract e .
Evgeny Kuzovlev (di seguito – EK): – Amici, ciao! Mi chiamo Kuzovlev Evgeny. Vengo dall'azienda EcommPay, in particolare dal dipartimento EcommPay IT, la divisione IT del gruppo. E oggi parleremo dei tempi di inattività: come evitarli e come minimizzarne le conseguenze, se non è possibile evitarli. Il tema è stato dichiarato così: «Cosa fare quando un minuto di inattività costa 100.000 dollari»? Noi, anticipando, i numeri sono comparabili.
Cosa fa EcommPay IT?
Chi siamo? Perché sono qui davanti a voi? Perché ho il diritto di raccontarvi qualcosa qui? E di cosa parleremo qui più dettagliatamente?
Il gruppo EcommPay è un acquirente internazionale. Elaboriamo pagamenti in tutto il mondo: in Russia, Europa, in Sud-Est Asiatico (All Around the World). Abbiamo 9 uffici, 500 dipendenti in totale e circa poco meno della metà di loro sono specialisti IT. Tutto ciò che facciamo, tutto su cui guadagniamo, lo abbiamo fatto noi stessi.
Abbiamo tutti i nostri prodotti (e sono abbastanza numerosi - nella nostra gamma di grandi prodotti IT abbiamo circa 16 diversi componenti) scritti da noi stessi; scriviamo noi, sviluppiamo noi. E attualmente gestiamo circa un milione di transazioni al giorno (milioni - probabilmente, sarebbe corretto dirlo in questo modo). Siamo un'azienda relativamente giovane - abbiamo circa sei anni.
Sei anni fa era una startup, quando ragazzi sono arrivati insieme al business. Erano uniti dall'idea (non c'era nient'altro, tranne che per l'idea) e siamo partiti. Come qualsiasi startup, correvamo più veloce... Per noi era più importante la velocità, non la qualità.
A un certo punto ci siamo fermati: ci siamo resi conto che non potevamo più vivere a quella velocità e con quella qualità e che dovevamo concentrarci principalmente sulla qualità. In quel momento abbiamo deciso di scrivere una nuova piattaforma, che fosse giusta, scalabile e affidabile. Abbiamo iniziato a lavorare su questa piattaforma (abbiamo cominciato a investire, sviluppare la programmazione, il testing), ma a un certo punto ci siamo resi conto che lo sviluppo e il testing non permettevano di raggiungere un nuovo livello qualitativo nel servizio.
State creando un nuovo prodotto, lo mettete in produzione, ma comunque qualcosa andrà storto. E oggi parleremo di come raggiungere un nuovo livello di qualità (di come ci siamo riusciti, della nostra esperienza), escludendo lo sviluppo e il testing; parleremo di cosa è disponibile per l'operatività – cosa può fare l'operatività da sola, cosa può proporre al testing per influenzare la qualità.
Downtime. I comandamenti dell'operatività.
Il sempre presente fondamentale di cui parleremo oggi è il downtime. Una parola terribile. Se abbiamo un downtime, è tutto un disastro. Corriamo a riparare, gli amministratori dei server sperano che non crolli, come cantano in quella canzone. Ecco di cosa parleremo oggi.
Quando abbiamo iniziato a cambiare il nostro approccio, abbiamo formulato 4 comandamenti. Li ho presentati nelle slide:
Questi comandamenti sono piuttosto semplici:
- Identificare rapidamente il problema.
- Eliminare il problema ancora più rapidamente.
- Aiutare a capire la causa (poi, per gli sviluppatori).
- E standardizzare gli approcci.
Voglio attirare la vostra attenzione sul punto n. 2. Ci liberiamo del problema, non lo risolviamo. Risolverlo è secondario. Per noi è fondamentale che l'utente sia protetto da questo problema. Esisterà in un certo ambiente isolato, ma questo ambiente non interagirà in alcun modo con lui. In effetti, passeremo in rassegna questi quattro gruppi di problemi (alcuni in modo più dettagliato, altri meno), vi racconterò cosa utilizziamo, quale esperienza abbiamo nelle soluzioni.
Risoluzione dei problemi: quando si verificano e cosa fare con loro?
Ma iniziamo non nell'ordine, iniziamo con il punto n° 2 - come risolvere rapidamente il problema? C'è un problema - dobbiamo affrontarlo. "Cosa dobbiamo fare?" è la domanda principale. E quando abbiamo iniziato a pensare a come risolvere il problema, abbiamo sviluppato alcuni requisiti a cui la risoluzione dei problemi deve attenersi.
Per formulare questi requisiti, abbiamo deciso di porci la domanda: "Quando abbiamo problemi?" E i problemi, come è emerso, si verificano in quattro casi:
- Guasto hardware.
- Interruzione dei servizi esterni.
- Cambio di versione del software (il famoso deploy).
- Crescita esplosiva del carico.
Non parleremo delle prime due. Il guasto hardware si risolve abbastanza facilmente: tutto deve essere duplicato. Se si tratta di dischi, devono essere configurati in RAID, se si tratta di un server, il server deve essere duplicato, se hai un'infrastruttura di rete, devi mettere una seconda copia dell'infrastruttura di rete, cioè prendi e duplica. E se qualcosa si guasta, ti colleghi a potenze di riserva. Qui è difficile dire di più.
Il secondo è l'interruzione dei servizi esterni. Per la maggior parte, questo non è affatto un problema, ma non per noi. Poiché elaboriamo i pagamenti, siamo un aggregatore che si trova tra l'utente (che inserisce i propri dati della carta) e le banche, i sistemi di pagamento ("Visa", "MasterCard", "Mira", ecc.). Ai nostri servizi esterni (sistemi di pagamento, banche) capita di avere dei guasti. Né noi né voi (se avete servizi del genere) possiamo influenzare questo.
Cosa fare allora? Qui ci sono due opzioni. Innanzitutto, se potete, dovete duplicare questo servizio in qualche modo. Ad esempio, se possiamo, reindirizziamo il traffico da un servizio all'altro: abbiamo elaborato, ad esempio, carte tramite "Sberbank", se "Sberbank" ha problemi - trasferiamo il traffico [condizionatamente] a "Raiffeisen". Secondo, ciò che possiamo fare è notare molto rapidamente i guasti dei servizi esterni, e quindi parleremo della velocità di reazione nella prossima parte della relazione.
Di fatto, di questi quattro possiamo influenzare concretamente il cambiamento delle versioni del software: compiere azioni che porteranno a un miglioramento della situazione nel contesto dei deployment e nel contesto dell'esplosione del carico. Infatti, è proprio ciò che abbiamo fatto. Qui, ancora una volta, una piccola nota…
Di questi quattro problemi, alcuni possono essere risolti immediatamente se avete il cloud. Se siete su «Microsoft Azure», «Ozon», utilizzando i nostri cloud, quelli di «Yandex» o «Mail», allora almeno il guasto hardware diventa un loro problema e tutto migliora subito nel contesto del guasto hardware.
Siamo una compagnia un po’ fuori dagli schemi. Qui tutti parlano di «Kubernetes», dei cloud - noi non abbiamo né «Kubernetes» né cloud. Abbiamo invece rack di hardware in molti data center e su questo hardware dobbiamo viverci, dobbiamo rispondere di tutto questo. Quindi, in questo contesto, parleremo. Ecco, riguardo ai problemi. I primi due li abbiamo messi da parte.
Cambiamento della versione del software. Fondamenti
I nostri sviluppatori non hanno accesso all'ambiente di produzione. Perché? Semplicemente perché siamo certificati secondo PCI DSS, e i nostri sviluppatori non hanno il diritto di accedere al «prod». Basta, punto. Completamente. Pertanto, la responsabilità dello sviluppo termina esattamente nel momento in cui lo sviluppo ha consegnato il build per il rilascio.
Il nostro secondo fondamento, che abbiamo, e che ci aiuta molto, è l'assenza di conoscenze uniche non documentate. Spero che sia lo stesso per voi. Perché, se non è così, avrete dei problemi. I problemi sorgono quando queste conoscenze uniche non documentate non sono presenti al momento giusto nel luogo giusto. Supponiamo che ci sia una persona che sa come deployare un componente specifico: se quella persona non è disponibile, è in ferie o malata, allora avete un problema.
E il terzo fondamento, a cui siamo giunti. Ci siamo arrivati attraverso la sofferenza, il sangue, le lacrime - siamo giunti al punto che ogni nostro build contiene errori, anche se è privo di errori. Abbiamo deciso: quando deployiamo qualcosa, quando portiamo qualcosa in prod - il nostro build ha degli errori. Abbiamo definito i requisiti che il nostro sistema deve soddisfare.
Requisiti per il cambiamento della versione del software
Questi requisiti sono tre:
- Dobbiamo essere in grado di annullare rapidamente il deployment.
- Dobbiamo minimizzare l'impatto di un deployment non riuscito.
- E dobbiamo avere la possibilità di essere dispiegati rapidamente in parallelo.
Proprio in questo ordine! Perché? Perché, prima di tutto, durante il dispiegamento di una nuova versione, la velocità non è importante, ma è importante per voi poter tornare rapidamente indietro se qualcosa va storto, riducendo al minimo l'impatto. Ma se avete un insieme di versioni in produzione dove è apparso un errore (come un fulmine a ciel sereno, non c'è stato un dispiegamento, ma l'errore è presente) – per voi è importante la velocità del dispiegamento successivo. Cosa abbiamo fatto per soddisfare questi requisiti? Abbiamo adottato una metodologia del genere:
È abbastanza nota, non l'abbiamo inventata noi – è il Blue/Green deploy. Cos'è? Per ogni gruppo di server dove risiedono le vostre applicazioni, dovete avere una copia. Una copia "calda": non ha traffico, ma in qualsiasi momento questo traffico può essere indirizzato a questa copia. Questa copia contiene la versione precedente. E al momento del dispiegamento, rilasciate il codice su una copia inattiva. Poi reindirizzate una parte del traffico (o tutto) sulla nuova versione. Così, per cambiare il flusso di traffico dalla vecchia versione alla nuova, è necessario fare solo un'azione: è necessario cambiare il bilanciatore upstream, cambiare la direzione - da un upstream all'altro. Questo è molto comodo e risolve il problema del passaggio rapido e del rollback veloce.Qui si risolve anche il secondo problema – minimizzazione: potete indirizzare sulla nuova linea, sulla linea con il nuovo codice solo una parte del vostro traffico (diciamo, per esempio, il 2%). E questi 2% – non sono il 100%! Se avete perso il 100% del traffico durante un dispiegamento fallito – è terribile, se avete perso il 2% del traffico – è sgradevole, ma non è tragico. Inoltre, è probabile che gli utenti non se ne accorgano nemmeno, perché in alcuni casi (non in tutti) lo stesso utente, premendo F5, finirà su un'altra versione funzionante.
Blue/Green deploy. Routing
Tuttavia, non è tutto così semplice nel ‘Blue/Green deploy’… Tutti i nostri componenti possono essere suddivisi in tre gruppi:
- questo è il frontend (pagine di pagamento che vedono i nostri clienti);
- il core del processo;
- un adattatore per lavorare con i sistemi di pagamento (banche, ‘MasterCard’, ‘Visa’…).
E c'è un aspetto da considerare: l'aspetto riguarda il routing tra le linee. Se si commuta semplicemente il 100% del traffico, non ci sono problemi. Ma se si desidera commutare il 2%, sorgono domande: "Come si fa?" La soluzione più semplice, diretta: è possibile configurare un'assegnazione casuale con Round Robin in nginx, e avrete il 2% a sinistra, il 98% a destra. Ma questo non sempre è adatto.
Ad esempio, l'utente interagisce con il sistema non con una sola richiesta. È normale: 2, 3, 4, 5 richieste – i vostri sistemi possono essere simili. E se è importante che tutte le richieste dell'utente arrivino alla stessa linea alla quale è arrivata la prima richiesta, o (secondo aspetto) che tutte le richieste dell'utente arrivino a una nuova linea dopo il passaggio (lavorare potrebbe aver iniziato prima con il sistema, prima del passaggio), allora questa distribuzione casuale non è adatta. Ci sono quindi le seguenti opzioni:
La prima opzione, la più semplice – basata sui parametri di base del cliente (IP Hash). Hai un IP, e dividi a destra e a sinistra in base all'indirizzo IP. Così avrai funzionato il secondo caso che ho descritto, quando è avvenuto il deploy, l'utente potrebbe aver già iniziato a lavorare con il tuo sistema, e dal momento del deploy tutte le richieste andranno sulla nuova linea (sulla stessa, diciamo).Se per qualche motivo questo non è adatto e devi necessariamente inviare le richieste alla linea dove è arrivata la richiesta iniziale dell'utente, allora hai due opzioni…
Prima opzione: puoi prendere nginx+ a pagamento. Lì c'è un meccanismo di Sticky sessions, che al primo invio dell'utente imposta una sessione per l'utente e la associa a un particolare upstream. Tutte le richieste successive dell'utente nell'ambito della durata della sessione saranno inviate allo stesso upstream a cui è stata impostata la sessione.Questo non ci è piaciuto, perché avevamo già un normale nginx. Passare a nginx+ non è che fosse costoso, semplicemente era per noi un po' doloroso e non molto corretto. Le "Sticky sessions" per noi, ad esempio, non hanno funzionato per la semplice ragione che le "Sticky sessions" non offrono la possibilità di fare routing secondo la logica "O-o". Puoi specificare che facciamo "Sticky sessions", ad esempio, in base all'indirizzo IP o in base all'indirizzo IP e ai cookie o ai parametri nel POST, ma "O-o" – lì diventa più complicato.
Perciò siamo giunti alla quarta opzione. Abbiamo preso nginx "potenziato" (questo è openresty) – è un nginx che supporta anche l'inclusione di script last. Puoi scrivere uno script last, fornirlo a questo "openresty", e questo lastscript verrà eseguito quando arriva una richiesta dell'utente.
E in effetti abbiamo scritto un piccolo script, abbiamo installato "openresty" e in questo script esaminiamo 6 diversi parametri concatenati con "O". A seconda della presenza di uno di questi parametri, sappiamo che l'utente è arrivato su una pagina o su un'altra, su una linea o su un'altra.
Deploy Blue/Green. Vantaggi e svantaggi
Certo, forse sarebbe stato possibile fare un po' più semplice (usare gli stessi "Sticky sessions"), ma abbiamo anche un aspetto particolare: non solo l'utente interagisce con noi all'interno di un processo di una singola transazione... Ma interagiscono con noi anche i sistemi di pagamento: dopo aver elaborato la transazione (inviando una richiesta al sistema di pagamento), riceviamo un callback.
E supponiamo che, se all'interno del nostro circuito possiamo passare l'indirizzo IP dell'utente in tutte le richieste e basarci sull'indirizzo IP degli utenti per separare, non possiamo dire a Visa: "Ragazzi, siamo una retro-compagnia, ci consideriamo internazionali (sul sito e in Russia)... Ma vi preghiamo di passarci, per favore, l'indirizzo IP dell'utente anche in un campo aggiuntivo, il vostro protocollo è standardizzato!" È chiaro che non saranno d'accordo.
Pertanto, ciò non ha funzionato per noi – abbiamo creato openresty. Di conseguenza, con il routing abbiamo ottenuto qualcosa di questo tipo:Il "Blue/Green deploy" ha, di conseguenza, vantaggi di cui ho parlato, e svantaggi.
Ci sono due svantaggi:
- devi occuparti del routing;
- il secondo svantaggio principale sono i costi.
Hai bisogno di due volte più server, hai bisogno di due volte più risorse operative, devi spendere il doppio della forza per mantenere tutto questo zoo.
A proposito, tra i vantaggi c'è un'altra cosa di cui non ho parlato prima: avete una riserva nel caso di un aumento del carico. Se il vostro carico aumenta in modo esplosivo, vi trovate sommersi da un gran numero di utenti, semplicemente attivate una seconda linea nella distribuzione 50-50 e avrete immediatamente il doppio dei server nel vostro cluster, finché non risolvete il problema della disponibilità dei server.
Come fare un deploy rapido?
Abbiamo parlato di come risolvere il problema della minimizzazione e del rollback veloce, ma la domanda rimane: «Come possiamo effettuare un deploy rapidamente?»
Qui è tutto semplice e conciso.- Dovete avere un sistema di CD (Continuous Delivery) – senza di esso non andate da nessuna parte. Se avete un solo server, potete fare il deploy manualmente. Abbiamo circa millecinquecento server e, ovviamente, farlo manualmente richiederebbe un reparto grande quanto questa sala, solo per il deploy.
- Il deploy deve essere parallelo. Se il vostro deploy è sequenziale, allora è un problema. Un server – va bene, millecinquecento server richiederebbero tutto il giorno per essere deployati.
- Ancora una volta, per velocizzare, questo è probabilmente già facoltativo. Durante il deploy di solito viene eseguita la compilazione del progetto. Se avete un progetto web, c'è la parte frontend (là fate il web-pack, raccogliete con npm – qualcosa del genere), questo processo in generale non è lungo – circa 5 minuti, ma quei 5 minuti possono essere critici. Perciò noi, ad esempio, non lo facciamo: abbiamo eliminato quei 5 minuti e deployiamo gli artefatti.
Cosa è un artefatto? L'artefatto è un build completato, in cui è già stata eseguita tutta la parte di compilazione. Questo artefatto lo conserviamo in un archivio di artefatti. Per un periodo abbiamo utilizzato due di questi archivi – era Nexus e ora jFrog Artifactory. Inizialmente abbiamo utilizzato Nexus perché abbiamo cominciato a praticare questo approccio nelle applicazioni Java (era molto adatto per questo). Poi abbiamo aggiunto parte delle applicazioni scritte in PHP e Nexus non era più adatto, quindi abbiamo scelto jFrog Artifactory, che è in grado di gestire praticamente tutto. Siamo arrivati addirittura al punto di conservare in questo archivio di artefatti i nostri pacchetti binari che raccogliamo per i server.
Aumento esplosivo del carico
Abbiamo parlato del cambiamento di versione del software. La prossima cosa che abbiamo è l'aumento esplosivo del carico. Qui, probabilmente, intendo per aumento esplosivo del carico qualcosa di non completamente corretto…
Abbiamo sviluppato un nuovo sistema: è orientato ai servizi, moderno e bello, con worker ovunque, code ovunque, asincronicità ovunque. In tali sistemi, i dati possono scorrere attraverso flussi diversi. Per la prima transazione possono essere coinvolti il 1°, il 3° e il 10° worker, mentre per la seconda transazione il 2°, il 4° e il 5°. E oggi, ad esempio, al mattino avete un flusso di dati che utilizza i primi tre worker, mentre la sera cambia drasticamente e utilizza altri tre worker.
Quindi, risulta che è necessario scalare i worker in qualche modo, è necessario scalare i vostri servizi, ma senza gonfiare le risorse.
Abbiamo stabilito dei requisiti. Questi requisiti sono abbastanza semplici: è essenziale che ci sia Service discovery, parametrizzazione – tutto standard per la costruzione di sistemi scalabili, tranne per un punto: l'ammortamento delle risorse. Abbiamo dichiarato che non siamo pronti ad ammortizzare le risorse, solo per avere server che riscaldano l’aria. Abbiamo adottato "Consul", abbiamo adottato "Nomad", che gestisce i nostri worker.Perché questo è un problema per noi? Torniamo un momento indietro. Attualmente, abbiamo circa 70 sistemi di pagamento. Al mattino, il traffico passa attraverso "Sberbank", poi, per esempio, "Sberbank" crolla, e lo dirottaamo su un altro sistema di pagamento. Avevamo 100 worker attivi fino a "Sberbank", e dopo dobbiamo rapidamente attivare 100 worker per un altro sistema di pagamento. E tutto questo dovrebbe avvenire senza l'intervento umano. Perché, se c'è un intervento umano, bisogna avere un ingegnere disponibile 24/7, dedicato solo a questo, poiché tali anomalie, con 70 sistemi monitorati, si verificano regolarmente.
Perciò abbiamo esaminato "Nomad", che ha un IP pubblico, e abbiamo sviluppato la nostra soluzione Scale-Nomad – ScaleNo, che fa qualcosa di simile: monitora l’aumento delle code e regola il numero di worker in base alla dinamica delle variazioni delle code. Quando l'abbiamo completata, abbiamo pensato: "Magari potremmo open source?" Poi l'abbiamo esaminata più da vicino – è semplice, come due centesimi.
Finora non l'abbiamo open source, ma se dopo la presentazione, dopo aver capito che avete bisogno di questo strumento, sorgesse la necessità, nell'ultima slide ci sono i miei contatti – per favore scrivetemi. Se riesce a raccogliere almeno 3-5 persone, noi la open sourceremo.
Come funziona? Diamo un'occhiata! Per non farla lunga: a sinistra c'è una parte del nostro monitoraggio: è una linea, in alto – il tempo di elaborazione degli eventi, al centro – il numero di transazioni, in basso – il numero di lavoratori.Se guardiamo, in questa immagine c'è un guasto. Nel grafico superiore una delle curve è uscita fuori dai 45 secondi – uno dei sistemi di pagamento è andato in down. Qui è stato mostrato il traffico per 2 minuti e c'è stata una crescita della coda su un altro sistema di pagamento, dove non c'erano lavoratori (non abbiamo utilizzato le risorse – al contrario, abbiamo gestito le risorse correttamente). Non volevamo sovraccaricare – c'erano un numero minimo, circa 5-10 lavoratori, ma non stavano facendo fronte.
Nell'ultimo grafico si vede un 'collo di bottiglia', che indica proprio che 'Scaleno' ha raddoppiato questo numero. E poi, quando il grafico è leggermente sceso, ha anche ridotto – il numero di lavoratori è stato modificato automaticamente. Ecco come funziona questa cosa. Abbiamo parlato del punto n. 2 – 'Come eliminare rapidamente le cause'.
Monitoraggio. Come identificare rapidamente un problema?
Ora il primo punto – 'Come identificare rapidamente un problema?' Monitoraggio! Dobbiamo comprendere rapidamente determinate cose. Quali cose dobbiamo capire velocemente?
Tre cose!- Dobbiamo comprendere rapidamente e capire l'efficienza delle nostre stesse risorse.
- Dobbiamo comprendere rapidamente i guasti, monitorare l'efficienza dei sistemi che per noi sono esterni.
- Il terzo punto – identificazione degli errori logici. Questo è quando il sistema funziona bene, secondo tutti i parametri, ma succede qualcosa di strano.
Qui probabilmente non dirò niente di particolarmente interessante. Sarò il capitano dell'Ovvio. Abbiamo esaminato cosa c'è sul mercato. Ci siamo ritrovati con uno 'zoo divertente'. Ecco quale zoo abbiamo attualmente:
Usiamo 'Zabbix' per monitorare l'hardware, per monitorare i principali indicatori dei server. 'Okmeter' lo utilizziamo per i database. 'Grafana' e 'Prometheus' li usiamo per tutti gli altri indicatori che non rientrano nei primi due, parte – con 'Grafana' e 'Prometheus', parte – 'Grafana' con 'Influx' e Telegraf.Un anno fa volevamo utilizzare New Relic. È uno strumento fantastico, fa tutto. Ma tanto fa, tanto costa. Quando siamo cresciuti fino a 1.500 server, ci ha contattato un venditore, dicendo: «Iniziamo a stipulare un contratto per il prossimo anno». Abbiamo guardato il prezzo e abbiamo deciso di no, non lo faremo. Adesso ci stiamo dismettendo da 'New Relic', ci sono circa 15 server rimasti sotto monitoraggio 'New Relic'. Il prezzo si è rivelato completamente folle.
E c'è uno strumento che abbiamo realizzato noi stessi – il Debugger. Inizialmente lo chiamavamo «Bagger», ma poi è passato da noi un insegnante d'inglese, ha riso tantissimo e lo abbiamo rinominato 'Debugger'. Cos'è? È uno strumento che, di fatto, in 15-30 secondi su ogni componente, come un 'black box' del sistema, avvia test sulla funzionalità generale del componente.
Ad esempio, se si tratta di una pagina esterna (pagina di pagamento) – la apre semplicemente e guarda come dovrebbe apparire. Se è un processo, lancia una 'transazione' di prova – verifica che questa 'transazione' arrivi. Se c'è connessione con i sistemi di pagamento – quindi inviamo una richiesta di prova dove possiamo e vediamo se 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 front-end – è un indicatore molto importante. Risponde subito se c'è qualcosa che non va.
- Il numero di messaggi elaborati in tutte le code.
- Il numero di worker.
- Principali metriche di correttezza.
L'ultimo punto è una metrica 'business', una metrica 'aziendale'. Se vuoi monitorare la stessa cosa, devi determinare una o due metriche che per te sono indicatori principali. Per noi, tale metrica è il tasso di successo (è il rapporto tra il numero di transazioni riuscite e il flusso totale delle transazioni). Se in essa cambia qualcosa in un intervallo di 5-10-15 minuti – significa che abbiamo dei problemi (se cambia in modo radicale).
Come appare per noi – un esempio di uno dei nostri dashboard:
A sinistra ci sono 6 grafici, corrispondenti alle linee: il numero di lavoratori e il numero di messaggi nelle code. A destra – RPS, RTS. In basso – la metrica "business". E su questa metrica "business" vediamo subito che qualcosa non va in due grafici medi… Questo è quando è crollato un altro sistema che ci supporta.La seconda cosa che dovevamo fare è monitorare il crollo dei sistemi di pagamento esterni. Qui abbiamo scelto OpenTracing – un meccanismo, uno standard, una paradigma che permette di tracciare sistemi distribuiti; e lo abbiamo leggermente modificato. La paradigma standard di OpenTracing dice che costruiamo la tracciatura di ogni singola richiesta. A noi questo non serviva, quindi l'abbiamo trasformato in tracciatura aggregata. Abbiamo creato uno strumento che ci permette di monitorare la velocità dei sistemi che ci supportano.
Il grafico ci mostra che uno dei sistemi di pagamento ha iniziato a rispondere in 3 secondi – abbiamo avuto problemi. Inoltre, questo sistema reagirà quando i problemi iniziano, in un intervallo di 20-30 secondi.E la terza classe di errori di monitoraggio che esiste è il monitoraggio logico.
A dire il vero, non sapevo cosa disegnare in questa diapositiva, perché abbiamo cercato a lungo sul mercato cose che sarebbero state adatte a noi. Non abbiamo trovato nulla, quindi abbiamo dovuto farlo noi.
Cosa intendo per monitoraggio logico? Beh, immaginate: create un sistema (ad esempio, un clone di "Tinder"); lo avete realizzato, avviato. Un manager di successo, Vasya Pupkin, lo ha installato sul suo telefono, vede una ragazza, la mette mi piace... ma il like non va alla ragazza – va al guardiano Mikhailovich di questo stesso centro commerciale. Il manager scende e poi si chiede: "Perché questo guardiano Mikhailovich gli sorride così piacevolmente"?In situazioni del genere… Per noi questa situazione suona un po' diversa, perché (come ho scritto) è una perdita di reputazione che porta indirettamente a perdite finanziarie. Noi abbiamo una situazione opposta: possiamo subire perdite finanziarie dirette – per esempio, se abbiamo effettuato una transazione ritenuta valida, ma in realtà è stata non valida (o viceversa). Abbiamo dovuto scrivere uno strumento interno che monitora, in base agli indicatori aziendali, il numero di transazioni di successo nel tempo. Non abbiamo trovato nulla sul mercato! Volevo proprio esprimere questo concetto. Sul mercato non c'è nulla per risolvere questo tipo di problemi.
Questo era a proposito di come identificare rapidamente un problema.
Come determinare le cause del deploy
Il terzo gruppo di problemi che affrontiamo è che, una volta identificato il problema e risolto, sarebbe utile capire la causa per lo sviluppo, per il testing e fare qualcosa al riguardo. Pertanto, dobbiamo esaminare, dobbiamo raccogliere i log.
Quando parliamo dei log (la causa principale sono i log), la maggior parte dei log è nel nostro ELK Stack – praticamente tutti fanno così. Alcuni, possiamo dire, non sono in ELK, ma se scrivete log in gigabyte, prima o poi arriverete a ELK. Noi li scriviamo in terabyte.
Qui c'è un problema. Abbiamo risolto un errore per l'utente, abbiamo iniziato a scavare per capire cosa fosse successo, siamo entrati in 'Kibana', abbiamo inserito l’ID della transazione e abbiamo ottenuto questo lungo resoconto (mostra molto). E in questo lungo resoconto non si capisce nulla. Perché? Perché non è chiaro quale parte appartenga a quale worker, quale parte appartiene a quale componente. E in quel momento abbiamo capito che avevamo bisogno di tracciamento – quel famoso OpenTracing di cui parlavo.Ci abbiamo pensato un anno fa, abbiamo rivolto lo sguardo verso il mercato, e lì ci sono risultate due strumenti – 'Zipkin' e 'Jaeger'. 'Jaeger' è in effetti un erede ideologico, un continuatore ideologico di 'Zipkin'. In 'Zipkin' va tutto bene, tranne per il fatto che non riesce ad aggregare, non riesce a includere i log nel tracciamento, solo il tracciamento dei tempi. E 'Jaeger' supportava questo.
Abbiamo esaminato "Eger": è possibile strumentare le applicazioni, è possibile scrivere in Api (lo standard Api per PHP a quel tempo, però, non era ancora approvato - era un anno fa, e ora è già approvato), e non c'era assolutamente un client. "Ok", abbiamo pensato, e abbiamo scritto il nostro client. Ecco come si presenta:
In "Eger", per ogni messaggio vengono creati dei span. Cioè, quando l'utente apre il sistema, vede uno o due blocchi per ogni richiesta in arrivo (1-2-3 - quanti più richieste in arrivo ci sono state dall'utente, tanti più blocchi ci saranno). Per facilitare agli utenti, abbiamo aggiunto dei tag ai log e alla tracciabilità temporale. Di conseguenza, in caso di errore, la nostra applicazione contrassegnerà il log con il relativo tag Error. È possibile filtrare per il tag Error e verranno visualizzati solo gli span che contengono quel blocco con l'errore. Ecco come appare, se espandiamo lo span:
All'interno dello span c'è un insieme di trace. In questo caso, ci sono tre trace di prova, e il terzo trace ci indica che c'è stato un errore. Qui vediamo anche la tracciabilità temporale: in alto abbiamo la linea temporale, e vediamo in quale intervallo di tempo è stato registrato quel log.Di conseguenza, abbiamo fatto un ottimo lavoro. Abbiamo scritto la nostra estensione, e l'abbiamo open-sourcata. Se volete lavorare con la tracciabilità, se volete utilizzare "Eger" in PHP - c'è la nostra estensione, benvenuti a usarla, come si suol dire:
La nostra estensione è un client per lavorare con l'OpenTracing Api, ed è realizzata come php-extension, quindi dovrete compilarla e integrarla nel sistema. Un anno fa non c'era nient'altro. Ora sono apparsi anche altri client, che sono componenti. Qui sta a voi: o scaricate i componenti con composer, oppure utilizzate l'estensione, a voi la scelta.Standard aziendali
Abbiamo parlato delle tre prescrizioni. La quarta prescrizione è standardizzare gli approcci. Di cosa si tratta? Si tratta più o meno di questo:
Perché qui si usa la parola "aziendali"? Non perché siamo una grande azienda o burocratica, no! La parola "aziendale" l'ho voluta usare in quel contesto, perché ogni azienda, ogni prodotto deve avere i propri standard, e anche voi. Quali standard abbiamo noi?- Abbiamo un regolamento per i deploy. Senza di esso non andiamo da nessuna parte e non possiamo muoverci. Effettuiamo circa 60 deploy a settimana, cioè i nostri deploy avvengono praticamente continuamente. Inoltre, abbiamo ad esempio nel regolamento dei deploy un divieto di effettuare deploy il venerdì – in linea di principio, non facciamo deploy.
- Abbiamo una documentazione obbligatoria. Nessun nuovo componente entra in produzione se non ha documentazione, anche se è stato creato dai nostri RnD. Richiediamo da loro un'istruzione per il deploy, una mappa di monitoraggio e una descrizione approssimativa (insomma, come possono scrivere i programmatori) di come funziona questo componente, come fare troubleshooting.
- Noi risolviamo non la causa del problema, ma il problema stesso – questo è ciò di cui ho già parlato. Per noi è importante proteggere l'utente dai problemi.
- Abbiamo dei margini di tolleranza. Ad esempio, non consideriamo downtime se perdiamo il 2 % del traffico per due minuti. Questo in pratica non entra nelle nostre statistiche. Se è di più in termini percentuali o temporali, lo consideriamo.
- E scriviamo sempre post-mortem. Qualunque cosa succeda, qualsiasi situazione in cui il sistema si comporti in modo anomalo in produzione sarà riflessa nel post-mortem. Il post-mortem è un documento in cui si scrive cosa è successo, un timing dettagliato, cosa è stato fatto per correggere e (questo è un blocco obbligatorio!) cosa si farà per evitare che accada in futuro. Questo è obbligatorio, necessario per l'analisi successiva.
Cosa considerare come downtime?
A cosa ha portato tutto questo?Questo ha portato al fatto che (abbiamo avuto alcuni problemi di stabilità, che non soddisfacevano né i clienti né noi) negli ultimi 6 mesi il nostro indicatore di stabilità è stato del 99,97. Si può dire che non è molto. Sì, abbiamo obiettivi da raggiungere. Di questo indicatore circa la metà – è stabilità che non è propriamente nostra, ma del nostro web application firewall, che si trova davanti a noi e viene utilizzato come servizio, ma ai clienti non interessa.
Abbiamo imparato a dormire la notte. Finalmente! Sei mesi fa non sapevamo farlo. E su questa nota, con le conclusioni, vorrei fare una piccola osservazione. Ieri sera c'era una presentazione meravigliosa su un sistema di gestione di reattori nucleari. Se ci sono persone che hanno scritto questo sistema che mi ascoltano – per favore, dimenticate ciò che ho detto riguardo al "2% non è downtime". Per voi il 2% è downtime, anche se per due minuti!
E questo è tutto! Le vostre domande.
Sui bilanciatori e la migrazione dal database
Domanda dal pubblico (d'ora in poi – D): – Buonasera. Grazie mille per questo intervento tecnico! Domanda breve, sul tema dei vostri bilanciatori. Avete accennato al fatto che avete un WAF, quindi, come capisco, come bilanciatore utilizzate un servizio esterno…
EK: – No, come bilanciatore utilizziamo i nostri servizi. In questo caso, il WAF è per noi esclusivamente uno strumento di protezione contro DDoS.
D: – Potreste dire qualche parola sui bilanciatori?
EK: – Come ho già detto, si tratta di un gruppo di server in openresty. Attualmente abbiamo 5 gruppi riservati che rispondono esclusivamente… cioè il server su cui è installato esclusivamente openresty, serve solo a proxyizzare il traffico. Per capire quanto gestiamo: attualmente, il nostro flusso di traffico normale è di qualche centinaio di megabit. Se la cavano bene, stanno comodi, nemmeno si stressano.
D: – Anche una domanda semplice. C'è il deployment Blue/Green. E cosa fate, per esempio, per le migrazioni dal database?
EK: – Buona domanda! Vedete, nel nostro deployment Blue/Green 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, come potevamo, praticamente abbiamo spostato tutto nelle code, nel database conserviamo solo lo stack delle transazioni. E lo stack delle transazioni è unico per tutte le linee. Con il database, in questo contesto: non lo dividiamo tra blu e verde, perché entrambe le versioni del codice devono sapere cosa succede con la transazione.
Amici, ho anche un piccolo premio per stimolarvi – un libro. E devo consegnarlo per la domanda migliore.
D: – Buonasera. Grazie per l'intervento. La domanda è la seguente. Monitorate i pagamenti, monitorate i servizi con cui interagite… Ma come monitorate che una persona sia in qualche modo arrivata alla vostra pagina di pagamento, ha completato il pagamento e il progetto ha accreditato i fondi? Cioè, come monitorate che il merchant sia disponibile e abbia accettato il vostro callback?
EK: – Il "merchant" per noi in questo caso è esattamente lo stesso servizio esterno della soluzione di pagamento. Monitoriamo la velocità di risposta del "merchant".
Sulla crittografia del database
D: – Salve. Ho una domanda accanto. Avete dati sensibili secondo il PCI DSS. Volevo sapere come conservate i PAN nelle code che dovete gestire? Usate qualche forma di crittografia? E la seconda domanda a seguire: secondo il PCI DSS è necessario ripristinare periodicamente il database in caso di cambiamenti (licenziamento di amministratori e così via) – come avviene in questo caso con la disponibilità?
EK: – Ottima domanda! Prima di tutto, non conserviamo i PAN nelle code. Non abbiamo il diritto di memorizzare i PAN in chiaro, in linea di principio, quindi utilizziamo un servizio speciale (lo chiamiamo "Keydemon") – è un servizio che fa solo una cosa: riceve un messaggio in input e restituisce un messaggio crittografato. E noi conserviamo solo quel messaggio crittografato. Di conseguenza, la lunghezza della chiave è di un kilobyte, in modo che sia davvero seria e affidabile.D: – Adesso sono già 2 kilobyte, giusto?
EK: – Sembrava che solo ieri fossero 256… Ma dove altro?!
Di conseguenza, questo è il primo punto. E in secondo luogo, la soluzione attuale supporta la procedura di ripristino della crittografia – ci sono due coppie di "cek" (chiavi) che forniscono "dek" che crittografano (key è chiave, dek è derivato dalle chiavi che crittografano). E in caso di avvio della procedura (che avviene regolarmente, da 3 mesi a ± qualche mese) carichiamo una nuova coppia di "cek" e avviene il ripristino dei dati. Abbiamo servizi distinti che estraggono tutti i dati, li crittografano di nuovo; ai dati è associato un identificatore della chiave con cui sono stati crittografati. Pertanto, non appena i dati sono crittografati con le nuove chiavi, eliminiamo le vecchie chiavi.
A volte è necessario effettuare pagamenti manualmente…
D: – Quindi se arriva un rimborso per un'operazione, decifrate utilizzando la chiave vecchia?
EK: – Sì.
D: – Allora un'altra piccola domanda. Quando si verifica un guasto, un'interruzione, un incidente, è necessario elaborare la transazione manualmente. Può verificarsi una situazione del genere.
EK: – Sì, può succedere.
D: – Da dove prendete questi dati? O andate voi manualmente in quel deposito?
EK: – No, beh, è chiaro – abbiamo un sistema di back-office che contiene un'interfaccia per il nostro supporto. Se non sappiamo in quale stato si trovi la transazione (per esempio, finché il sistema di pagamento non risponde con un timeout) – non lo sappiamo a priori, cioè attribuiamo lo stato finale solo quando siamo completamente certi. In questo caso, classifichiamo la transazione in uno stato speciale per l'elaborazione manuale. Al mattino, il giorno successivo, appena il supporto riceve l'informazione che nel sistema di pagamento sono rimaste tali transazioni, le elaborano manualmente tramite questa interfaccia.
D: – Ho un paio di domande. Una di queste è sul proseguimento della zona PCI DSS: come estraete i log del loro contesto? Questa domanda nasce dal fatto che lo sviluppatore potrebbe aver inserito qualsiasi cosa nei log! La seconda domanda: come distribuite le hotfix? A mano nel database – è una possibilità, ma potrebbero esserci hotfix gratuite – qual è la procedura? E la terza domanda, probabilmente, è collegata a RTO, RPO. La vostra disponibilità era del 99,97, quasi quattro nove, ma capisco che avete anche il secondo centro dati, il terzo centro dati e il quinto centro dati... Come vi occupate della loro sincronizzazione, replicazione e tutto il resto?EK: – Iniziamo dal primo. La prima domanda riguardava i log? Quando scriviamo i log, abbiamo un strato intermedio che maschera tutti i dati sensibili. Questa analizza in base a una maschera e campi aggiuntivi. Di conseguenza, i nostri log escono già con dati mascherati e nel contesto del PCI DSS. Questa è una delle attività regolari assegnate al dipartimento di test. Sono obbligati a controllare ogni attività, inclusi i log che scrivono, e questa è una delle routine di controllo durante la revisione del codice, per assicurarsi che lo sviluppatore non scriva dati inappropriati. La verifica successiva viene effettuata regolarmente dal dipartimento di sicurezza informatica circa una volta a settimana: vengono selezionati log del giorno scorso e vengono analizzati tramite uno scanner speciale dai server di test per controllare tutto questo.
Riguardo ai hot-fix. Questo è incluso nel nostro regolamento di deployment. Abbiamo un punto separato riguardante i hot-fix. Riteniamo di effettuare i deployment dei hot-fix 24 ore su 24 quando necessario. Non appena la versione è compilata, non appena è stata testata, non appena abbiamo l'artefatto, il nostro amministratore di sistema in turno viene contattato dal supporto e lo deploya nel momento in cui è necessario.Riguardo le «quattro nove». Il numero che abbiamo attualmente è stato realmente raggiunto, e ci eravamo impegnati per ottenerlo anche in un altro data center. Ora abbiamo un secondo data center e iniziamo a fare il routing tra di loro, e la questione della replicazione tra data center è un problema davvero complesso. Abbiamo cercato di risolverlo in vari modi: abbiamo tentato di utilizzare lo stesso «Tarantool» – non ha funzionato, lo dico subito. Pertanto abbiamo deciso di effettuare manualmente l'ordine per «sensor». Ogni applicazione infatti gestisce in modo asincrono la necessaria sincronizzazione «change – done» tra i data center.
D: – Se hai un secondo, perché non hai un terzo? Perché il Split-brain nessuno…
EK: – Noi non abbiamo il «Split-brain». Poiché ogni applicazione gestisce un multi-master, non ci importa in quale centro è arrivata la richiesta. Siamo pronti al fatto che, nel caso in cui un data center crolli (su questo ci stiamo preparando) e nel mezzo di una richiesta dell'utente venga switchato al secondo data center, siamo pronti a perdere quell'utente, realmente; ma saranno solo casi isolati, assolutamente pochi.
D: – Buona sera. Grazie per la relazione. Hai parlato del tuo debugger, che in produzione esegue alcune transazioni di test. Ma parlaci delle transazioni di test! Quanto in profondità scende?
EK: – Essa percorre l'intero ciclo di tutto il componente. Per il componente non ci sono differenze tra una transazione di test e una operativa. E dal punto di vista logico, è semplicemente un progetto separato nel sistema, su cui vengono eseguite solo transazioni di test.
D: – E dove la tagli? Ecco che il Core ha inviato…
EK: – Noi seguiamo il «Core» in questo caso per le transazioni di test… Abbiamo un concetto, chiamato routing: il «Core» sa in quale sistema di pagamento deve inviare – noi inviamo a un sistema di pagamento fittizio, che semplicemente restituisce un'http-reak e tutto.
D: – Mi scusi, ma la vostra applicazione è scritta come un enorme monolite, oppure l'avete suddivisa in vari servizi o addirittura in microservizi?
EK: – Certamente non è un monolite, abbiamo un'applicazione orientata ai servizi. Scherziamo dicendo che il nostro servizio consiste in monoliti – sono veramente piuttosto grandi. Non riusciamo a chiamarli microservizi, ma sono, appunto, servizi all'interno dei quali lavorano i worker di macchine distribuite.
Se un servizio sul server è compromesso…
D: – Allora ho la seguente domanda. Anche se fosse stato un monolite, avete comunque detto che avete molti server instant, tutti loro elaborano dati, e la domanda è la seguente: «In caso di compromissione di uno degli server instant o di un'applicazione, di un segmento specifico, hanno qualche controllo degli accessi? Chi può fare cosa? A chi rivolgersi per quali dati?
EK: – Sì, indubbiamente. I requisiti di sicurezza sono piuttosto seri. Innanzitutto, abbiamo movimenti di dati aperti, e le porte sono solo quelle che preventivamente prevediamo per il traffico. Se un componente comunica con il database (diciamo, con 'MySQL') tramite 5-4-3-2, solo quelle porte saranno aperte, e altre porte o altri flussi di traffico non saranno accessibili. Inoltre, è importante sapere che in produzione abbiamo circa 10 diversi contorni di sicurezza. E anche se l'applicazione venisse compromessa in qualche modo, non vorrei, il malintenzionato non riuscirebbe ad accedere alla console di gestione del server, perché appartiene a un'altra zona di sicurezza di rete.D: – In questo contesto mi interessa di più il fatto che ci sono dei contratti con i servizi – cosa possono fare, attraverso quali 'azioni' possono comunicare tra loro… E in un flusso normale, determinati servizi richiedono un certo insieme di 'azioni' da un altro. Non si rivolgono agli altri in una situazione normale, e hanno altre responsabilità. Se uno di essi viene compromesso, potrà chiamare le 'azioni' di quel servizio?..
EK: – Capisco. Se in una situazione normale con un altro server la comunicazione è stata completamente autorizzata, allora – sì. Secondo il contratto SLA non monitoriamo che ti siano consentite solo le prime 3 "azioni", mentre la 4ª "azione" non ti sia consentita. Questo, probabilmente, è superfluo per noi, perché abbiamo già un sistema di protezione a 4 livelli per i contorni. Preferiamo proteggerci tramite contorni, piuttosto che a livello interno.
Come funzionano Visa, MasterCard e "Sberbank"
D: – Vorrei chiarire un punto riguardo al cambio dell'utente da un data center a un altro. Per quanto ne so, "Visa" e "MasterCard" operano secondo il protocollo binario sincrono 8583, dove ci sono dei mix. E volevo sapere, attualmente si intende che il passaggio – riguarda direttamente "Visa" e "MasterCard" o fino ai sistemi di pagamento, fino ai processori?
EK: – Si tratta dei mix. I mix si trovano in un solo data center.
D: – In altre parole, avete un solo punto di connessione?
EK: – Per "Visa" e "MasterCard" – sì. Semplicemente perché "Visa" e "MasterCard" richiedono investimenti significativi nell'infrastruttura per stipulare singoli contratti per ottenere un secondo paio di mix, ad esempio. Sono riservati all'interno di un solo data center, ma se dovesse succedere qualcosa al data center dove si trovano i mix per connettersi a "Visa" e "MasterCard", perderemmo la connessione con "Visa" e "MasterCard"...
D: – Come possono essere riservati? So che "Visa" consente di avere solamente una connessione in linea di massima!
EK: – Loro forniscono l'attrezzatura. In ogni caso, ci è stata fornita dell'attrezzatura che è internamente ridondante.
D: – Quindi il rack è fornito dai loro Connects Orange?..
EK: – Sì.
D: – E in questo caso: se il vostro data center va giù, come si fa a continuare a usare? O il traffico si interrompe semplicemente?
EK: – No. In questo caso, semplicemente reindirizzeremo il traffico su un altro canale, che, ovviamente, costerà di più a noi e ai clienti. Ma il traffico non passerà attraverso la nostra connessione diretta a "Visa", "MasterCard", ma attraverso il condizionale "Sberbank" (molto semplificato).
Mi scuso sinceramente se ho toccato i dipendenti di "Sberbank". Ma secondo le nostre statistiche, tra le banche russe, "Sberbank" presenta le maggiori problematiche. Non passa mese senza che "Sberbank" non abbia qualche problema.
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Leggi di
Fonte: habr.com
