Tothom parla dels processos de desenvolupament i proves, formació del personal, augment de la motivació, però aquests processos no són suficients quan un minut d'inactivitat del servei costa enormes quantitats de diners. Què fer quan realitzeu transaccions financeres sota un estricte SLA? Com augmentar la fiabilitat i la tolerància a errors dels vostres sistemes, eliminant el desenvolupament i les proves de l'equació?
La propera conferència HighLoad++ se celebrarà els dies 6 i 7 d'abril de 2020 a Sant Petersburg. Detalls i entrades per . 9 de novembre, 18:00 h. HighLoad++ Moscou 2018, Sala Delhi + Kolkata. Tesis i .
Evgeniy Kuzovlev (d'ara endavant - CE): - Amics, hola! Em dic Kuzovlev Evgeniy. Sóc de l'empresa EcommPay, una divisió específica és EcommPay IT, la divisió informàtica del grup d'empreses. I avui parlarem dels temps morts, de com evitar-los, de com minimitzar-ne les conseqüències si no es pot evitar. El tema s'indica de la següent manera: "Què cal fer quan un minut d'inactivitat costa 100 dòlars"? De cara al futur, els nostres números són comparables.
Què fa EcommPay IT?
Qui sóm? Per què estic aquí davant teu? Per què tinc dret a dir-te alguna cosa aquí? I de què parlarem aquí amb més detall?
El grup d'empreses EcommPay és un adquirent internacional. Processem pagaments a tot el món: a Rússia, Europa, el sud-est asiàtic (a tot el món). Tenim 9 oficines, 500 empleats en total, i aproximadament una mica menys de la meitat d'elles són especialistes en informàtica. Tot el que fem, tot el que fem diners, ho hem fet nosaltres mateixos.
Tots els nostres productes els vam escriure (i en tenim bastants; a la nostra línia de grans productes informàtics tenim uns 16 components diferents) nosaltres mateixos; Ens escrivim, ens desenvolupem. I de moment realitzem un milió de transaccions al dia (milions és probablement la manera correcta de dir-ho). Som una empresa bastant jove: només tenim uns sis anys.
Fa 6 anys va ser una startup quan els nois van venir amb el negoci. Els unia una idea (no hi havia res més que una idea), i vam córrer. Com qualsevol startup, vam córrer més ràpid... Per a nosaltres, la velocitat era més important que la qualitat.
En algun moment ens vam aturar: ens vam adonar que d'alguna manera ja no podíem viure a aquesta velocitat i amb aquesta qualitat i primer ens calia centrar-nos en la qualitat. En aquest moment, vam decidir escriure una nova plataforma que fos correcta, escalable i fiable. Van començar a escriure aquesta plataforma (van començar a invertir, desenvolupar desenvolupament, provar), però en algun moment es van adonar que el desenvolupament i les proves no ens permetien assolir un nou nivell de qualitat de servei.
Feu un producte nou, el poseu en producció, però tot i així alguna cosa sortirà malament en algun lloc. I avui parlarem de com arribar a un nou nivell de qualitat (com ho hem fet, de la nostra experiència), traient el desenvolupament i les proves fora de l'equació; parlarem del que està disponible per a l'operació: quina operació pot fer ella mateixa, què pot oferir a les proves per influir en la qualitat.
Temps morts. Manaments d'operació.
Sempre la pedra angular principal, del que parlarem avui és el temps d'inactivitat. Una paraula terrible. Si tenim temps d'inactivitat, tot és dolent per a nosaltres. Estem corrent per aixecar-lo, els administradors sostenen el servidor - Déu n'hi do que no caigui, com diuen en aquesta cançó. Això és del que parlarem avui.
Quan vam començar a canviar els nostres enfocaments, vam formar 4 manaments. Els tinc presentats a les diapositives:
Aquests manaments són bastant senzills:
- Identifica ràpidament el problema.
- Desfer-se'n encara més ràpid.
- Ajuda a entendre el motiu (més endavant, per als desenvolupadors).
- I estandarditzar els enfocaments.
M'agradaria cridar la vostra atenció sobre el punt núm. 2. Estem traient el problema, no solucionant-lo. Decidir és secundari. Per a nosaltres, el principal és que l'usuari estigui protegit d'aquest problema. Existirà en algun entorn aïllat, però aquest entorn no tindrà cap contacte amb ell. De fet, passarem per aquests quatre grups de problemes (alguns amb més detall, altres amb menys detall), us explicaré què fem servir, quina experiència rellevant tenim en solucions.
Resolució de problemes: quan succeeixen i què cal fer-hi?
Però començarem sense ordre, començarem pel punt núm. 2: com desfer-se ràpidament del problema? Hi ha un problema: hem de solucionar-lo. "Què hem de fer amb això?" - la pregunta principal. I quan vam començar a pensar com solucionar el problema, vam desenvolupar per nosaltres mateixos alguns requisits que la resolució de problemes ha de seguir.
Per formular aquests requisits, vam decidir fer-nos la pregunta: “Quan tenim problemes”? I els problemes, segons va resultar, es produeixen en quatre casos:
- Falla de maquinari.
- Els serveis externs han fallat.
- Canvi de la versió del programari (el mateix desplegament).
- Creixement de càrrega explosiva.
No parlarem dels dos primers. Un mal funcionament del maquinari es pot resoldre de manera senzilla: heu de tenir-ho tot duplicat. Si es tracta de discs, els discs s'han de muntar en RAID; si es tracta d'un servidor, el servidor s'ha de duplicar; si teniu una infraestructura de xarxa, heu de subministrar una segona còpia de la infraestructura de xarxa, és a dir, l'agafeu i duplicar-lo. I si alguna cosa falla, canvieu a la reserva d'energia. És difícil dir res més aquí.
El segon és el fracàs dels serveis externs. Per a la majoria, el sistema no és un problema en absolut, però no per a nosaltres. Com que processem els pagaments, som un agregador que s'interposa entre l'usuari (que introdueix les dades de la seva targeta) i els bancs, sistemes de pagament (Visa, MasterCard, Mira, etc.). Els nostres serveis externs (sistemes de pagament, bancs) solen fallar. Ni nosaltres ni vosaltres (si teniu aquests serveis) podem influir en això.
Què fer llavors? Aquí hi ha dues opcions. En primer lloc, si podeu, hauríeu de duplicar aquest servei d'alguna manera. Per exemple, si podem, transferim trànsit d'un servei a un altre: per exemple, les targetes es van processar a través de Sberbank, Sberbank té problemes: transferim trànsit [condicionalment] a Raiffeisen. La segona cosa que podem fer és notar molt ràpidament la fallada dels serveis externs i, per tant, parlarem de la velocitat de resposta a la següent part de l'informe.
De fet, d'aquests quatre, podem influir específicament en el canvi de versions de programari: prendre accions que condueixin a una millora de la situació en el context dels desplegaments i en el context d'un creixement explosiu de la càrrega. De fet, això és el que vam fer. Aquí, de nou, una petita nota...
D'aquests quatre problemes, diversos es resolen immediatament si teniu un núvol. Si esteu als núvols de Microsoft Azhur, Ozone o utilitzeu els nostres núvols, de Yandex o Mail, almenys un mal funcionament del maquinari es converteix en el seu problema i tot us anirà bé immediatament en el context d'un mal funcionament del maquinari.
Som una empresa una mica poc convencional. Aquí tothom parla de "Kubernets", de núvols: no tenim ni "Kubernets" ni núvols. Però tenim bastidors de maquinari a molts centres de dades, i estem obligats a viure d'aquest maquinari, ens veiem obligats a ser responsables de tot. Per tant, en parlarem en aquest context. Per tant, sobre els problemes. Els dos primers es van treure entre parèntesis.
Canvi de la versió del programari. Bases
Els nostres desenvolupadors no tenen accés a la producció. Per què això? Només tenim la certificació PCI DSS i els nostres desenvolupadors simplement no tenen dret a entrar al "producte". Això és tot, punt. En absolut. Per tant, la responsabilitat del desenvolupament acaba exactament en el moment en què el desenvolupament envia la compilació per al seu llançament.
La nostra segona base que tenim, que també ens ajuda molt, és l'absència de coneixement únic no documentat. Espero que us sigui igual. Perquè si no és així, tindreu problemes. Els problemes sorgiran quan aquest coneixement únic i indocumentat no estigui present en el moment adequat i en el lloc adequat. Suposem que tens una persona que sap desplegar un component concret -la persona no hi és, està de vacances o està malalta-, això és tot, tens problemes.
I la tercera base a la qual hem arribat. Vam arribar-hi a través del dolor, la sang, les llàgrimes; vam arribar a la conclusió que qualsevol de les nostres compilacions conté errors, encara que estigui lliure d'errors. Ho vam decidir nosaltres mateixos: quan despleguem alguna cosa, quan posem alguna cosa en producció, tenim una compilació amb errors. Hem format els requisits que el nostre sistema ha de satisfer.
Requisits per canviar la versió del programari
Hi ha tres requisits:
- Hem de revertir ràpidament el desplegament.
- Hem de minimitzar l'impacte d'un desplegament sense èxit.
- I hem de poder desplegar-nos ràpidament en paral·lel.
Exactament en aquest ordre! Per què? Perquè, en primer lloc, a l'hora de desplegar una nova versió, la velocitat no és important, però és important que, si alguna cosa va malament, retrocedeixi ràpidament i tingui un impacte mínim. Però si teniu un conjunt de versions en producció, per a la qual cosa resulta que hi ha un error (de sobte, no hi va haver cap desplegament, però hi ha un error), la velocitat del desplegament posterior és important per a vosaltres. Què hem fet per satisfer aquestes demandes? Hem recorregut a la següent metodologia:
És bastant conegut, no l'hem inventat mai: es tracta d'un desplegament blau/verd. Què és això? Heu de tenir una còpia per a cada grup de servidors en què estiguin instal·lades les vostres aplicacions. La còpia és "cálida": no hi ha trànsit, però en qualsevol moment aquest trànsit es pot enviar a aquesta còpia. Aquesta còpia conté la versió anterior. I en el moment del desplegament, desplegueu el codi a una còpia inactiva. A continuació, canvieu part del trànsit (o tot) a la nova versió. Per tant, per canviar el flux de trànsit de la versió antiga a la nova, només heu de fer una acció: heu de canviar l'equilibrador a l'aigua amunt, canviar la direcció, d'un corrent amunt a un altre. Això és molt convenient i resol el problema del canvi ràpid i la recuperació ràpida.Aquí la solució a la segona pregunta és la minimització: només podeu enviar una part del vostre trànsit a una línia nova, a una línia amb un codi nou (que sigui, per exemple, el 2%). I aquest 2% no són el 100%! Si heu perdut el 100% del trànsit a causa d'un desplegament infructuós, fa por; si heu perdut el 2% del trànsit, és desagradable, però no fa por. A més, és probable que els usuaris ni tan sols s'adonin d'això, perquè en alguns casos (no en tots) el mateix usuari, prement F5, passarà a una altra versió que funcioni.
Desplegament blau/verd. Encaminament
No obstant això, no tot és tan senzill "Desplegament blau/verd"... Tots els nostres components es poden dividir en tres grups:
- aquest és el frontend (pàgines de pagament que veuen els nostres clients);
- nucli de processament;
- adaptador per treballar amb sistemes de pagament (bancs, MasterCard, Visa...).
I aquí hi ha un matís: el matís rau en l'encaminament entre les línies. Si només canvieu el 100% del trànsit, no teniu aquests problemes. Però si voleu canviar el 2%, comenceu a fer preguntes: "Com fer-ho?" El més senzill és senzill: podeu configurar Round Robin a nginx per elecció aleatòria i teniu un 2% a l'esquerra i un 98% a la dreta. Però això no sempre és adequat.
Per exemple, en el nostre cas, un usuari interactua amb el sistema amb més d'una sol·licitud. Això és normal: 2, 3, 4, 5 sol·licituds: els vostres sistemes poden ser els mateixos. I si és important per a vostè que totes les sol·licituds de l'usuari arribin a la mateixa línia on va arribar la primera sol·licitud, o (segon punt) totes les peticions de l'usuari arribin a la nova línia després del canvi (podria haver començat a treballar abans amb el sistema, abans del canvi), llavors aquesta distribució aleatòria no és adequada per a vostè. Aleshores hi ha les opcions següents:
La primera opció, la més senzilla, es basa en els paràmetres bàsics del client (IP Hash). Tens una IP i la divideixes de dreta a esquerra per adreça IP. Aleshores, el segon cas que vaig descriure us funcionarà, quan es va produir el desplegament, l'usuari ja podria començar a treballar amb el vostre sistema i, des del moment del desplegament, totes les sol·licituds aniran a una nova línia (per exemple, a la mateixa).Si per algun motiu això no us convé i heu d'enviar sol·licituds a la línia on va arribar la sol·licitud inicial de l'usuari, teniu dues opcions...
Primera opció: podeu comprar nginx+ de pagament. Hi ha un mecanisme de sessions Sticky, que, a petició inicial de l'usuari, assigna una sessió a l'usuari i l'enllaça amb un o un altre aigües amunt. Totes les sol·licituds d'usuari posteriors durant la vida útil de la sessió s'enviaran al mateix aigües amunt on es va publicar la sessió.Això no ens va bé perquè ja teníem nginx normal. Canviar a nginx+ no és que sigui car, és només que ens va ser una mica dolorós i no és gaire correcte. "Sticks Sessions", per exemple, no ens va funcionar per la senzilla raó que "Sticks Sessions" no permeten l'encaminament basat en "Either-or". Allà podeu especificar què fem les "Sticks Sessions", per exemple, per adreça IP o per adreça IP i galetes o per postparàmetre, però "O-o" és més complicat allà.
Per tant, hem arribat a la quarta opció. Vam prendre nginx amb esteroides (això és openresty): aquest és el mateix nginx, que també admet la inclusió dels últims scripts. Podeu escriure un últim script, donar-li un "repòs obert" i aquest últim script s'executarà quan arribi la sol·licitud de l'usuari.
I vam escriure, de fet, aquest guió, ens vam establir "openresti" i en aquest guió ordenem 6 paràmetres diferents per concatenació "O". En funció de la presència d'un o altre paràmetre, sabem que l'usuari va arribar a una pàgina o una altra, a una línia o a una altra.
Desplegament blau/verd. Avantatges i inconvenients
Per descomptat, probablement era possible fer-ho una mica més senzill (utilitzar les mateixes "Sessions adhesives"), però també tenim un matís tal que no només l'usuari interactua amb nosaltres en el marc d'un processament d'una transacció... Però els sistemes de pagament també interactuen amb nosaltres: després de processar la transacció (enviant una sol·licitud al sistema de pagament), rebem una retroalimentació.
I diguem que, si dins del nostre circuit podem reenviar l'adreça IP de l'usuari en totes les sol·licituds i dividir els usuaris en funció de l'adreça IP, llavors no direm el mateix "Visa": "Amic, som una empresa tan retro, sembla que ser internacional (al lloc web i a Rússia)... Si us plau, proporcioneu-nos l'adreça IP de l'usuari en un camp addicional, el vostre protocol està estandarditzat”! Està clar que no es posaran d'acord.
Per tant, això no va funcionar per a nosaltres: vam fer openresty. En conseqüència, amb l'encaminament tenim alguna cosa com això:El desplegament blau/verd té, en conseqüència, els avantatges i els desavantatges que he esmentat.
Dos desavantatges:
- us heu de preocupar amb l'encaminament;
- el segon desavantatge principal és la despesa.
Necessiteu el doble de servidors, necessiteu el doble de recursos operatius, heu de gastar el doble d'esforç per mantenir tot aquest zoo.
Per cert, entre els avantatges hi ha una cosa més que no he esmentat abans: tens una reserva en cas de creixement de càrrega. Si teniu un creixement explosiu de càrrega, teniu un gran nombre d'usuaris, només heu d'incloure la segona línia a la distribució de 50 a 50, i immediatament teniu servidors x2 al vostre clúster fins que resolgueu el problema de tenir més servidors.
Com fer un desplegament ràpid?
Hem parlat de com resoldre el problema de la minimització i la recuperació ràpida, però la pregunta segueix sent: "Com implementar ràpidament?"
Aquí és breu i senzill.- Heu de tenir un sistema de CD (entrega continua) - no podeu viure sense ell. Si teniu un servidor, podeu implementar-lo manualment. Tenim aproximadament un miler i mig de servidors i un miler i mig de manetes, és clar: podem plantar un departament de la mida d'aquesta sala només per desplegar-lo.
- El desplegament ha de ser paral·lel. Si el vostre desplegament és seqüencial, tot està malament. Un servidor és normal, estaràs desplegant mil i mig de servidors tot el dia.
- De nou, per a l'acceleració, probablement això ja no sigui necessari. Durant el desplegament, el projecte normalment es construeix. Teniu un projecte web, hi ha una part frontal (hi feu un paquet web, compileu npm, una cosa així), i aquest procés és, en principi, de curta durada: 5 minuts, però aquests 5 minuts poden ser crític. Per això, per exemple, no ho fem: hem eliminat aquests 5 minuts, despleguem artefactes.
Què és un artefacte? Un artefacte és una construcció ensamblada en la qual ja s'han completat totes les peces de muntatge. Emmagatzemem aquest artefacte a l'emmagatzematge d'artefactes. En un moment vam fer servir dos d'aquests emmagatzematges: era Nexus i ara jFrog Artifactory). Al principi vam utilitzar "Nexus" perquè vam començar a practicar aquest enfocament en aplicacions de Java (s'adaptava bé). Després hi van posar algunes de les aplicacions escrites en PHP; i "Nexus" ja no era adequat i, per tant, vam triar jFrog Artefactory, que pot artefactoriitzar gairebé tot. Fins i tot hem arribat al punt que en aquest dipòsit d'artefactes emmagatzemem els nostres propis paquets binaris que recollim per als servidors.
Creixement de càrrega explosiva
Hem parlat de canviar la versió del programari. El següent que tenim és un augment explosiu de càrrega. Aquí, probablement vull dir que el creixement explosiu de la càrrega no és el correcte...
Hem escrit un nou sistema: està orientat al servei, està de moda, bonic, treballadors a tot arreu, cues a tot arreu, asincronia a tot arreu. I en aquests sistemes, les dades poden fluir a través de diferents fluxos. Per a la primera transacció, es pot utilitzar el 1r, 3r, 10è treballador, per a la segona transacció: el 2n, 4t, 5è. I avui, diguem-ne, al matí tens un flux de dades que utilitza els tres primers treballadors, i al vespre canvia dràsticament, i tot utilitza els altres tres treballadors.
I aquí resulta que cal escalar d'alguna manera els treballadors, d'alguna manera cal escalar els vostres serveis, però al mateix temps evitar la inflació dels recursos.
Hem definit els nostres requisits. Aquests requisits són bastant senzills: que hi hagi descobriment de serveis, parametrització: tot és estàndard per a la construcció d'aquests sistemes escalables, excepte un punt: la depreciació dels recursos. Vam dir que no estem preparats per amortitzar recursos perquè els servidors escalfen l'aire. Vam agafar "Cònsol", vam agafar "Nòmada", que gestiona els nostres treballadors.Per què això és un problema per a nosaltres? Anem una mica enrere. Ara tenim al voltant de 70 sistemes de pagament darrere nostre. Al matí, el trànsit passa per Sberbank, després Sberbank va caure, per exemple, i el canviem a un altre sistema de pagament. Teníem 100 treballadors abans de Sberbank, i després hem d'augmentar dràsticament 100 treballadors per a un altre sistema de pagament. I és desitjable que tot això passi sense la participació humana. Perquè si hi ha participació humana, hi hauria d'haver un enginyer assegut les 24 hores del dia, els 7 dies de la setmana, que només hauria de fer això, perquè aquests errors, quan hi ha 70 sistemes darrere, es produeixen regularment.
Per tant, vam mirar Nomad, que té una IP oberta, i vam escriure la nostra, Scale-Nomad - ScaleNo, que fa aproximadament el següent: supervisa el creixement de la cua i redueix o augmenta el nombre de treballadors en funció de la dinàmica. de la cua. Quan ho vam fer, vam pensar: "Potser el podem obrir de codi font?" Llavors la van mirar: era tan senzilla com dos copecs.
Fins ara no l'hem de codi obert, però si de sobte després de l'informe, després d'adonar-se que necessiteu una cosa així, ho necessiteu, els meus contactes estan a l'última diapositiva, si us plau, escriviu-me. Si hi ha almenys 3-5 persones, ho patrocinarem.
Com funciona? Fem una ullada! Mirant endavant: a la part esquerra hi ha una part del nostre seguiment: aquesta és una línia, a la part superior hi ha el temps de processament de l'esdeveniment, al mig hi ha el nombre de transaccions, a la part inferior hi ha el nombre de treballadors.Si mireu, hi ha un error en aquesta imatge. Al gràfic superior, un dels gràfics es va estavellar en 45 segons: un dels sistemes de pagament va caure. Immediatament, el trànsit es va introduir en 2 minuts i la cua va començar a créixer en un altre sistema de pagament, on no hi havia treballadors (no vam utilitzar recursos, al contrari, vam eliminar el recurs correctament). No volíem escalfar: hi havia un nombre mínim, uns 5-10 treballadors, però no van poder fer front.
L'últim gràfic mostra una "gepa", que només significa que "Skaleno" va duplicar aquesta quantitat. I després, quan el gràfic va baixar una mica, el va reduir una mica: el nombre de treballadors es va canviar automàticament. Així funciona aquesta cosa. Hem parlat del punt número 2: "Com desfer-se ràpidament de les raons".
Seguiment. Com identificar ràpidament el problema?
Ara el primer punt és "Com identificar ràpidament el problema?" Seguiment! Hem d'entendre certes coses ràpidament. Quines coses hem d'entendre ràpidament?
Tres coses!- Hem d'entendre i comprendre ràpidament el rendiment dels nostres propis recursos.
- Hem d'entendre ràpidament els errors i controlar el rendiment dels sistemes que ens són externs.
- El tercer punt és identificar errors lògics. És quan el sistema funciona per a vostè, tot és normal segons tots els indicadors, però alguna cosa va malament.
Probablement no us diré res tan genial aquí. Seré el capità Obvious. Hem buscat el que hi havia al mercat. Tenim un "zoològic divertit". Aquest és el tipus de zoo que tenim ara:
Utilitzem Zabbix per supervisar el maquinari, per supervisar els principals indicadors dels servidors. Utilitzem Okmeter per a bases de dades. Utilitzem "Grafana" i "Prometheus" per a tots els altres indicadors que no encaixen amb els dos primers, alguns amb "Grafana" i "Prometheus", i altres amb "Grafana" amb "Influx" i Telegraf.Fa un any volíem utilitzar New Relic. Una cosa genial, ho pot fer tot. Però per molt que pot fer-ho tot, és molt cara. Quan vam créixer a un volum d'1,5 mil servidors, un venedor va venir a nosaltres i ens va dir: "Concloem un acord per a l'any vinent". Hem mirat el preu i hem dit que no, que no ho farem. Ara estem abandonant New Relic, ens queden uns 15 servidors sota el seguiment de New Relic. El preu va resultar absolutament salvatge.
I hi ha una eina que hem implementat nosaltres mateixos: aquesta és Debugger. Al principi l'anomenàvem "Bagger", però després va passar un professor d'anglès, va riure boig i li va canviar el nom "Debagger". Què és això? Aquesta és una eina que, de fet, en 15-30 segons a cada component, com una "caixa negra" del sistema, realitza proves sobre el rendiment global del component.
Per exemple, si hi ha una pàgina externa (pàgina de pagament), simplement l'obre i mira com ha de quedar. Si s'està processant, envia una "transacció" de prova i s'assegura que aquesta "transacció" arribi. Si es tracta d'una connexió amb sistemes de pagament, enviarem una sol·licitud de prova en conseqüència, on podem, i comprovem que tot ens va bé.
Quins indicadors són importants per al seguiment?
Què monitoritzem principalment? Quins indicadors són importants per a nosaltres?
- El temps de resposta / RPS als fronts és un indicador molt important. Immediatament respon que hi ha alguna cosa malament amb tu.
- El nombre de missatges processats a totes les cues.
- Nombre de treballadors.
- Mètriques bàsiques de correcció.
L'últim punt és la mètrica "empresa", "empresa". Si voleu controlar el mateix, heu de definir una o dues mètriques que siguin els principals indicadors per a vosaltres. La nostra mètrica és el rendiment (aquesta és la relació entre el nombre de transaccions reeixides i el flux total de transaccions). Si alguna cosa hi canvia en un interval de 5-10-15 minuts, vol dir que tenim problemes (si canvia radicalment).
El que sembla per a nosaltres és un exemple d'un dels nostres taulers:
Al costat esquerre hi ha 6 gràfics, això és segons les línies: el nombre de treballadors i el nombre de missatges a les cues. Al costat dret - RPS, RTS. A continuació es mostra la mateixa mètrica "empresarial". I a la mètrica "empresarial" podem veure immediatament que alguna cosa va fallar als dos gràfics del mig... Aquest és només un altre sistema que ens queda darrere que ha caigut.El segon que havíem de fer era controlar la caiguda dels sistemes de pagament externs. Aquí vam agafar OpenTracing: un mecanisme, estàndard, paradigma que us permet rastrejar sistemes distribuïts; i es va canviar una mica. El paradigma estàndard d'OpenTracing diu que creem un rastre per a cada sol·licitud individual. No necessitàvem això, i ho vam embolicar en un resum, rastre d'agregació. Hem creat una eina que ens permet fer un seguiment de la velocitat dels sistemes que tenim darrere.
El gràfic ens mostra que un dels sistemes de pagament va començar a respondre en 3 segons: tenim problemes. A més, aquesta cosa reaccionarà quan comencin els problemes, en un interval de 20-30 segons.I la tercera classe d'errors de monitorització que existeix és la supervisió lògica.
Sincerament, no sabia què dibuixar en aquesta diapositiva, perquè feia temps que buscàvem al mercat alguna cosa que ens convingués. No vam trobar res, així que vam haver de fer-ho nosaltres mateixos.
Què entenc per seguiment lògic? Bé, imagineu-vos: us feu un sistema (per exemple, un clon de Tinder); ho has fet, l'has llançat. El gerent d'èxit Vasya Pupkin el va posar al telèfon, hi veu una noia, li agrada... i el mateix no li passa a la noia, sinó al vigilant de seguretat Mikhalych del mateix centre de negocis. El gerent baixa les escales i després es pregunta: "Per què aquest guàrdia de seguretat Mikhalych li somriu tan amablement?"En aquestes situacions... Per a nosaltres, aquesta situació sona una mica diferent, perquè (vaig escriure) es tracta d'una pèrdua de reputació que indirectament condueix a pèrdues financeres. La nostra situació és la contrària: podem patir pèrdues financeres directes, per exemple, si hem realitzat una transacció amb èxit, però no ha tingut èxit (o viceversa). Vaig haver d'escriure la meva pròpia eina que fes un seguiment del nombre de transaccions reeixides al llarg del temps mitjançant indicadors comercials. No he trobat res al mercat! Aquesta és exactament la idea que volia transmetre. No hi ha res al mercat per resoldre aquest tipus de problemes.
Es tractava de com identificar ràpidament el problema.
Com determinar els motius del desplegament
El tercer grup de problemes que resolem és després d'haver identificat el problema, després d'haver-ne desfet, seria bo entendre el motiu del desenvolupament, de la prova i fer-hi alguna cosa. En conseqüència, hem d'investigar, hem d'aixecar els registres.
Si estem parlant de registres (el motiu principal són els registres), la majoria dels nostres registres es troben a ELK Stack: gairebé tothom té el mateix. Per a alguns, pot ser que no estigui a ELK, però si escriviu registres en gigabytes, tard o d'hora arribareu a ELK. Els escrivim en terabytes.
Aquí hi ha un problema. Ho vam solucionar, vam corregir l'error per a l'usuari, vam començar a excavar el que hi havia, vam pujar a Kibana, vam introduir l'identificador de la transacció allà i vam aconseguir un estovalló com aquest (mostra molt). I no hi ha res clar en aquest estovalles. Per què? Sí, perquè no està clar quina part pertany a quin treballador, quina part pertany a quin component. I en aquell moment ens vam adonar que necessitàvem un seguiment, el mateix OpenTracing del qual vaig parlar.Ho vam pensar fa un any, vam dirigir la nostra atenció cap al mercat i hi havia dues eines: "Zipkin" i "Jaeger". "Jager" és de fet un hereu ideològic, un successor ideològic de "Zipkin". Tot és bo a Zipkin, excepte que no sap agregar, no sap incloure registres a la traça, només traça de temps. I "Jager" ho va donar suport.
Vam mirar "Jager": podeu instrumentar aplicacions, podeu escriure en Api (l'estàndard Api per a PHP en aquell moment, però, no estava aprovat; això va ser fa un any, però ara ja s'ha aprovat), però hi ha no era absolutament cap client. "D'acord", vam pensar i vam escriure al nostre propi client. Què hem aconseguit? Això és aproximadament el que sembla:
A Jaeger, es creen intervals per a cada missatge. És a dir, quan un usuari obre el sistema, veu un o dos blocs per a cada sol·licitud entrant (1-2-3 - el nombre de peticions entrants de l'usuari, el nombre de blocs). Per facilitar-ho als usuaris, hem afegit etiquetes als registres i traces de temps. En conseqüència, en cas d'error, la nostra aplicació marcarà el registre amb l'etiqueta d'error adequada. Podeu filtrar per etiqueta d'error i només es mostraran els trams que continguin aquest bloc amb un error. Això és el que sembla si ampliem l'abast:
A l'interior del van hi ha un conjunt de rastres. En aquest cas, es tracta de tres traces de prova, i la tercera traça ens indica que s'ha produït un error. Al mateix temps, aquí veiem una traça de temps: tenim una escala de temps a la part superior, i veiem en quin interval de temps es va registrar aquest o aquell registre.En conseqüència, les coses ens van anar bé. Hem escrit la nostra pròpia extensió i l'hem de codi obert. Si voleu treballar amb traça, si voleu treballar amb "Jager" en PHP, hi ha la nostra extensió, benvinguda a utilitzar, com diuen:
Tenim aquesta extensió: és un client per a l'Api OpenTracing, està fet com a extensió php, és a dir, l'haureu de muntar i instal·lar al sistema. Fa un any no hi havia res diferent. Ara hi ha altres clients que són com components. Aquí depèn de vostè: o bé bombeu els components amb un compositor, o feu servir l'extensió segons vosaltres.Estàndards corporatius
Hem parlat dels tres manaments. El quart manament és estandarditzar els enfocaments. De què va això? Es tracta d'això:
Per què la paraula "corporatiu" és aquí? No perquè siguem una empresa gran o burocràtica, no! Volia utilitzar la paraula "corporatiu" aquí en el context que cada empresa, cada producte hauria de tenir els seus propis estàndards, inclòs vostè. Quins estàndards tenim?
- Tenim normes de desplegament. No ens mourem enlloc sense ell, no podem. Despleguem unes 60 vegades a la setmana, és a dir, despleguem gairebé constantment. Al mateix temps, tenim, per exemple, a la normativa de desplegament un tabú sobre els desplegaments de divendres -en principi, no despleguem-.
- Necessitem documentació. Ni un sol component nou entra en producció si no hi ha documentació, encara que hagi nascut sota la ploma dels nostres especialistes en RnD. Els necessitem instruccions de desplegament, un mapa de seguiment i una descripció aproximada (bé, com poden escriure els programadors) de com funciona aquest component, com solucionar-lo.
- No solucionem la causa del problema, sinó el problema, el que ja he dit. És important per a nosaltres protegir l'usuari dels problemes.
- Tenim autoritzacions. Per exemple, no considerem temps d'inactivitat si perdem el 2% del trànsit en dos minuts. Això bàsicament no està inclòs a les nostres estadístiques. Si és més percentual o temporal, ja comptem.
- I sempre escrivim autopsies. Passi el que ens passi, qualsevol situació en què algú s'hagi comportat de manera anormal en la producció es reflectirà en l'autopsia. Una autopsia és un document en el qual s'escriu què et va passar, un calendari detallat, què has fet per corregir-ho i (és un bloc obligatori!) què faràs per evitar que això passi en el futur. Això és obligatori i necessari per a l'anàlisi posterior.
Què es considera temps d'inactivitat?
A què va portar tot això?Això va fer que (teníem certs problemes d'estabilitat, això no ens agradava ni als clients ni a nosaltres) durant els últims 6 mesos el nostre indicador d'estabilitat era de 99,97. Podem dir que això no és gaire. Sí, tenim alguna cosa per esforçar-nos. D'aquest indicador, aproximadament la meitat és l'estabilitat, per dir-ho, no de la nostra, sinó del nostre tallafoc d'aplicacions web, que es troba davant nostre i s'utilitza com a servei, però als clients no els importa això.
Vam aprendre a dormir a la nit. Per fi! Fa sis mesos no vam poder. I sobre aquesta nota amb els resultats, m'agradaria fer una nota. Ahir a la nit hi va haver un informe meravellós sobre el sistema de control d'un reactor nuclear. Si les persones que van escriure aquest sistema em poden escoltar, oblideu-vos del que vaig dir sobre "el 2% no és temps d'inactivitat". Per a tu, el 2% és temps d'inactivitat, encara que sigui durant dos minuts!
Això és tot! Les teves preguntes.
Sobre els equilibradors i la migració de bases de dades
Pregunta del públic (d'ara endavant – B): – Bona tarda. Moltes gràcies per aquest informe d'administració! Una breu pregunta sobre els vostres equilibradors. Vas esmentar que tens un WAF, és a dir, segons entenc, fas servir algun tipus d'equilibrador extern...
EK: – No, fem servir els nostres serveis com a equilibrador. En aquest cas, WAF és exclusivament una eina de protecció DDoS per a nosaltres.
AT: – Pots dir algunes paraules sobre els equilibradors?
EK: – Com ja he dit, aquest és un grup de servidors en openresty. Ara tenim 5 grups de reserva que responen exclusivament... és a dir, un servidor que funciona exclusivament amb openresty, només fa proxy el trànsit. En conseqüència, per entendre el que tenim: ara tenim un flux de trànsit regular de diversos centenars de megabits. S'enfronten, se senten bé, ni tan sols s'esforcen.
AT: – També una pregunta senzilla. Aquí teniu el desplegament blau/verd. Què feu, per exemple, amb les migracions de bases de dades?
EK: - Bona pregunta! Mira, al desplegament Blau/Verd tenim cues separades per a cada línia. És a dir, si estem parlant de cues d'esdeveniments que es transmeten de treballador a treballador, hi ha cues separades per a la línia blava i per a la línia verda. Si parlem de la base de dades en si, l'hem reduït deliberadament tant com vam poder, ho vam moure pràcticament tot a cues; a la base de dades només emmagatzemem una pila de transaccions. I la nostra pila de transaccions és la mateixa per a totes les línies. Amb la base de dades en aquest context: no la dividim en blau i verd, perquè ambdues versions del codi han de saber què està passant amb la transacció.
Amics, també tinc un petit premi per estimular-vos: un llibre. I hauria de ser premiat per la millor pregunta.
AT: - Hola. Gràcies pel reportatge. La pregunta és aquesta. Tu controles els pagaments, controles els serveis amb els quals et comuniques... Però com controles perquè d'alguna manera una persona entri a la teva pàgina de pagament, faci un pagament i el projecte l'acrediti diners? És a dir, com controleu que el comerciant està disponible i ha acceptat la vostra devolució?
EK: – "Comerciant" per a nosaltres en aquest cas és exactament el mateix servei extern que el sistema de pagament. Supervisem la velocitat de resposta del comerciant.
Sobre el xifratge de bases de dades
AT: - Hola. Tinc una pregunta una mica relacionada. Teniu dades sensibles de PCI DSS. Volia saber com emmagatzemeu les PAN a les cues a les quals heu de transferir? Feu servir algun xifratge? I això porta a la segona pregunta: segons PCI DSS, cal tornar a xifrar periòdicament la base de dades en cas de canvis (acomiadament d'administradors, etc.) - què passa amb l'accessibilitat en aquest cas?
EK: -Pregunta meravellosa! En primer lloc, no emmagatzemem els PAN a les cues. No tenim dret a emmagatzemar PAN en cap lloc en forma clara, en principi, de manera que utilitzem un servei especial (l'anomenem "Kademon"): aquest és un servei que només fa una cosa: rep un missatge com a entrada i envia un missatge xifrat. I ho emmagatzemem tot amb aquest missatge xifrat. En conseqüència, la longitud de la nostra clau és inferior a un kilobyte, de manera que això és seriós i fiable.AT: – Necessites 2 kilobytes ara?
EK: – Sembla que ahir va ser el 256... Bé, on més?!
En conseqüència, aquest és el primer. I en segon lloc, la solució que existeix, és compatible amb el procediment de tornar a xifrar: hi ha dos parells de "keks" (claus), que donen "decks" que xifren (la clau són les claus, els dek són derivats de les claus que xifren) . I si s'inicia el tràmit (succeeix regularment, de 3 mesos a ± alguns), descarreguem un nou parell de "pastissos" i tornem a xifrar les dades. Tenim serveis separats que extreuen totes les dades i les xifren d'una manera nova; Les dades s'emmagatzemen al costat de l'identificador de la clau amb la qual estan xifrades. En conseqüència, tan aviat com xifrem les dades amb claus noves, suprimim la clau antiga.
De vegades, els pagaments s'han de fer manualment...
AT: – És a dir, si ha arribat un reemborsament d'alguna operació, encara la desxifrareu amb la clau antiga?
EK: - Sí.
AT: – Aleshores una petita pregunta més. Quan es produeix algun tipus de fallada, caiguda o incident, cal impulsar la transacció manualment. Hi ha una situació així.
EK: - Sí de vegades.
AT: – D'on treu aquestes dades? O aneu vosaltres mateixos a aquest magatzem?
EK: – No, bé, és clar, tenim algun tipus de sistema de back-office que conté una interfície per al nostre suport. Si no sabem en quin estat es troba la transacció (per exemple, fins que el sistema de pagament respon amb un temps d'espera), no ho sabem a priori, és a dir, assignem l'estat final només amb total confiança. En aquest cas, assignem la transacció a un estat especial per al processament manual. Al matí, l'endemà, tan bon punt el suport rep informació que tal o tal transaccions romanen al sistema de pagament, les processa manualment en aquesta interfície.
AT: – Tinc un parell de preguntes. Un d'ells és la continuació de la zona PCI DSS: com registreu el seu circuit? Aquesta pregunta és perquè el desenvolupador podria haver posat qualsevol cosa als registres! Segona pregunta: com implementeu les correccions ràpides? L'ús d'identificadors a la base de dades és una opció, però pot haver-hi solucions ràpides gratuïtes: quin és el procediment? I la tercera pregunta probablement està relacionada amb RTO, RPO. La teva disponibilitat era de 99,97, gairebé quatre nou, però segons tinc entès, tens un segon centre de dades, un tercer centre de dades i un cinquè centre de dades... Com els sincronitzes, els reprodueixes i tota la resta?EK: -Comencem pel primer. La primera pregunta va ser sobre els registres? Quan escrivim registres, tenim una capa que emmascara totes les dades sensibles. Mira la màscara i els camps addicionals. En conseqüència, els nostres registres surten amb dades ja emmascarades i un circuit PCI DSS. Aquesta és una de les tasques habituals assignades al departament de proves. Estan obligats a comprovar cada tasca, inclosos els registres que escriuen, i aquesta és una de les tasques habituals durant les revisions de codi, per tal de controlar que el desenvolupador no hagi escrit alguna cosa. Les comprovacions posteriors d'això són realitzades periòdicament pel departament de seguretat de la informació aproximadament un cop per setmana: els registres de l'últim dia es prenen de manera selectiva i s'executen mitjançant un escàner-analitzador especial des dels servidors de prova per comprovar-ho tot.
Sobre les correccions ràpides. Això està inclòs a la nostra normativa de desplegament. Tenim una clàusula separada sobre les correccions. Creiem que despleguem solucions ràpides les XNUMX hores del dia quan ho necessitem. Tan bon punt es munta la versió, tan bon punt s'executa, tan bon punt tenim un artefacte, tenim un administrador del sistema de guàrdia en una trucada del suport, i el desplega en el moment en què és necessari.Uns "quatre nou". La xifra que tenim ara s'ha assolit realment i ens hem esforçat per aconseguir-la en un altre centre de dades. Ara tenim un segon centre de dades i estem començant a encaminar-nos entre ells, i el problema de la replicació entre centres de dades és realment una qüestió no trivial. Vam intentar resoldre-ho alhora amb diferents mitjans: vam intentar utilitzar la mateixa "Taràntula"; no ens va funcionar, us ho diré de seguida. Per això vam acabar ordenant els "sens" manualment. De fet, cada aplicació del nostre sistema executa la sincronització necessària "canvi fet" entre centres de dades de manera asíncrona.
AT: – Si n'has aconseguit un segon, per què no n'has aconseguit un tercer? Perquè ningú encara té el cervell dividit...
EK: – Però no tenim el cervell dividit. A causa del fet que cada aplicació està impulsada per un multimaster, no ens importa a quin centre va arribar la sol·licitud. Estem preparats per al fet que si un dels nostres centres de dades falla (confiem en això) i enmig d'una sol·licitud d'usuari canvia al segon centre de dades, estem preparats per perdre aquest usuari, de fet; però aquestes seran unitats, unitats absolutes.
AT: - Bona nit. Gràcies pel reportatge. Heu parlat del vostre depurador, que executa algunes transaccions de prova en producció. Però parla'ns de les transaccions de prova! Fins a quina profunditat arriba?
EK: – Passa pel cicle complet de tot el component. Per a un component, no hi ha diferència entre una transacció de prova i una de producció. Però des d'un punt de vista lògic, es tracta simplement d'un projecte independent del sistema, en el qual només s'executen transaccions de prova.
AT: -On ho talles? Aquí Core enviat...
EK: – Estem darrere de "Kor" en aquest cas per a transaccions de prova... Tenim una cosa com l'encaminament: "Kor" sap a quin sistema de pagament enviar - enviem a un sistema de pagament fals, que simplement dóna un senyal http i això és tot.
AT: – Digueu-me, si us plau, la vostra aplicació es va escriure en un monòlit enorme o la vau tallar en alguns serveis o fins i tot en microserveis?
EK: – No tenim un monòlit, és clar, tenim una aplicació orientada al servei. Bromem que el nostre servei està fet de monòlits: són realment bastant grans. És difícil anomenar-ho microserveis, però aquests són serveis en els quals operen els treballadors de les màquines distribuïdes.
Si el servei del servidor està compromès...
AT: —Llavors tinc la següent pregunta. Encara que fos un monòlit, encara vas dir que tens molts d'aquests servidors instantanis, bàsicament tots processen dades, i la pregunta és: “En cas de comprometre un dels servidors instantanis o una aplicació, qualsevol enllaç individual. , tenen algun tipus de control d'accés? Quin d'ells pot fer què? Amb qui m'he de contactar per obtenir quina informació?
EK: - Sí, definitivament. Els requisits de seguretat són força greus. En primer lloc, tenim moviments de dades obertes, i els ports només són aquells a través dels quals anticipem el moviment del trànsit. Si un component es comunica amb la base de dades (per exemple, amb Muskul) a través del 5-4-3-2, només hi estarà obert el 5-4-3-2, i altres ports i altres direccions de trànsit no estaran disponibles. A més, cal entendre que a la nostra producció hi ha uns 10 bucles de seguretat diferents. I encara que l'aplicació estigui compromesa d'alguna manera, Déu n'hi do, l'atacant no podrà accedir a la consola de gestió del servidor, perquè es tracta d'una zona de seguretat de xarxa diferent.AT: – I en aquest context, el que em sembla més interessant és que tens certs contractes amb serveis: què poden fer, a través de quines “accions” poden contactar entre ells... I en un flux normal, alguns serveis concrets demanen alguna cosa. fila, una llista d'"accions" a l'altra. Sembla que no recorren als altres en una situació normal i tenen altres àrees de responsabilitat. Si un d'ells es veu compromès, serà capaç d'interrompre les "accions" d'aquest servei?...
EK: - Entenc. Si en una situació normal amb un altre servidor es permetia la comunicació, llavors sí. D'acord amb el contracte de SLA, no controlem que només se li permetin les 3 primeres "accions" i que no se li permetin les 4 "accions". Això probablement és redundant per a nosaltres, perquè ja tenim un sistema de protecció de 4 nivells, en principi, per als circuits. Preferim defensar-nos amb els contorns, més que a nivell de l'interior.
Com funcionen Visa, MasterCard i Sberbank
AT: – Vull aclarir un punt sobre com canviar un usuari d'un centre de dades a un altre. Pel que jo sé, Visa i MasterCard funcionen amb el protocol síncron binari 8583, i hi ha barreges. I volia saber, ara ens referim a canviar: és directament "Visa" i "MasterCard" o abans dels sistemes de pagament, abans de processar-los?
EK: - Això és abans de les barreges. Les nostres barreges es troben al mateix centre de dades.
AT: – A grans trets, tens un punt de connexió?
EK: – "Visa" i "MasterCard" - sí. Simplement perquè Visa i MasterCard requereixen inversions força serioses en infraestructura per celebrar contractes separats per obtenir un segon parell de mescles, per exemple. Es reserven dins d'un mateix centre de dades, però si, Déu n'hi do, el nostre centre de dades, on hi ha barreges per connectar-se a Visa i MasterCard, mor, llavors tindrem una connexió amb Visa i MasterCard perduda...
AT: – Com es poden reservar? Sé que Visa només permet una connexió en principi!
EK: – Subministren ells mateixos els equips. En qualsevol cas, hem rebut equipaments totalment redundants a l'interior.
AT: – Llavors, l'estand és del seu Connects Orange?...
EK: - Sí.
AT: – Però què passa amb aquest cas: si el vostre centre de dades desapareix, com podeu continuar utilitzant-lo? O simplement s'atura el trànsit?
EK: - No. En aquest cas, simplement canviarem el trànsit a un altre canal, que, naturalment, serà més car per a nosaltres i més car per als nostres clients. Però el trànsit no passarà per la nostra connexió directa amb Visa, MasterCard, sinó per Sberbank condicional (molt exagerat).
Demano disculpes si he ofès els empleats de Sberbank. Però segons les nostres estadístiques, entre els bancs russos, Sberbank cau amb més freqüència. No passa un mes sense que alguna cosa caigui a Sberbank.
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com