Todo o mundo fala dos procesos de desenvolvemento e probas, formación do persoal, aumento da motivación, pero estes procesos non son suficientes cando un minuto de inactividade do servizo custa enormes cantidades de diñeiro. Que facer cando realizas transaccións financeiras baixo un SLA estrito? Como aumentar a fiabilidade e a tolerancia a fallos dos seus sistemas, eliminando o desenvolvemento e as probas da ecuación?
A próxima conferencia HighLoad++ celebrarase os días 6 e 7 de abril de 2020 en San Petersburgo. Detalles e entradas para . 9 de novembro, 18:00 h. HighLoad++ Moscow 2018, Delhi + Salón Kolkata. Teses e .
Evgeniy Kuzovlev (en diante - CE): - Amigos, ola! Chámome Kuzovlev Evgeniy. Son da empresa EcommPay, unha división específica é EcommPay IT, a división informática do grupo de empresas. E hoxe falaremos dos tempos de inactividade: sobre como evitalos, sobre como minimizar as súas consecuencias se non se pode evitar. O tema é o seguinte: "Que facer cando un minuto de inactividade custa 100 dólares"? De cara ao futuro, os nosos números son comparables.
Que fai EcommPay IT?
Quen somos? Por que estou aquí diante de ti? Por que teño dereito a dicirche algo aquí? E de que falaremos aquí con máis detalle?
O grupo de empresas EcommPay é un adquirente internacional. Procesamos pagos en todo o mundo: en Rusia, Europa, sueste asiático (en todo o mundo). Contamos con 9 oficinas, 500 empregados en total, e aproximadamente algo menos da metade delas son especialistas en informática. Todo o que facemos, todo o que gañamos cartos, fixémolo nós mesmos.
Escribimos todos os nosos produtos (e temos moitos deles; na nosa liña de produtos de TI grandes temos uns 16 compoñentes diferentes) nós mesmos; Escribimos nós mesmos, desenvolvémonos. E nestes momentos realizamos preto dun millón de transaccións ao día (millóns é probablemente a forma correcta de dicilo). Somos unha empresa bastante nova: só temos uns seis anos.
Hai 6 anos era unha empresa tan nova cando os mozos chegaron co negocio. Estaban unidos por unha idea (non había outra cousa que unha idea), e corremos. Como calquera startup, corríamos máis rápido... Para nós era máis importante a velocidade que a calidade.
Nalgún momento paramos: decatámonos de que xa non podíamos vivir dalgunha maneira a esa velocidade e con esa calidade e necesitabamos centrarnos primeiro na calidade. Neste momento, decidimos escribir unha nova plataforma que fose correcta, escalable e fiable. Comezaron a escribir esta plataforma (empezaron a investir, desenvolver desenvolvemento, probar), pero nalgún momento déronse conta de que o desenvolvemento e as probas non nos permitían alcanzar un novo nivel de calidade do servizo.
Fais un produto novo, póñase en produción, pero aínda así algo vai ir mal nalgún lugar. E hoxe falaremos de como chegar a un novo nivel de calidade (como o fixemos, da nosa experiencia), sacando da ecuación o desenvolvemento e as probas; falaremos do que está dispoñible para operar: que operación pode facer por si mesma, que pode ofrecer ás probas para influír na calidade.
Tempos de inactividade. Mandamentos de operación.
Sempre a pedra angular principal, do que falaremos hoxe é o tempo de inactividade. Unha palabra terrible. Se temos tempo de inactividade, todo é malo para nós. Estamos correndo para levantalo, os administradores sosteñen o servidor - Deus non queira que non caia, como din nesa canción. Isto é do que falaremos hoxe.
Cando comezamos a cambiar os nosos enfoques, formamos 4 mandamentos. Téñoos presentados nas diapositivas:
Estes mandamentos son moi sinxelos:
- Identifica rapidamente o problema.
- Deshacerse del aínda máis rápido.
- Axuda a comprender o motivo (máis tarde, para os desenvolvedores).
- E estandarizar enfoques.
Gustaríame chamarlle a atención sobre o punto no 2. Estamos a desfacernos do problema, non a solucionalo. Decidir é secundario. Para nós, o principal é que o usuario estea protexido deste problema. Existirá nalgún ambiente illado, pero este ambiente non terá ningún contacto con el. En realidade, repasaremos estes catro grupos de problemas (algúns con máis detalle, outros con menos detalle), vouvos contar o que utilizamos, que experiencia relevante temos en solucións.
Solución de problemas: cando ocorren e que facer con eles?
Pero comezaremos fóra de orde, comezaremos co punto número 2: como desfacerse rapidamente do problema? Hai un problema: hai que solucionalo. "Que debemos facer con isto?" - a pregunta principal. E cando comezamos a pensar en como solucionar o problema, desenvolvemos por nós mesmos algúns requisitos que debe seguir a resolución de problemas.
Para formular estes requisitos, decidimos facernos a pregunta: “Cando temos problemas”? E os problemas, como se viu, ocorren en catro casos:
- Fallo de hardware.
- Os servizos externos fallaron.
- Cambiando a versión do software (a mesma implantación).
- Crecemento de carga explosiva.
Non falaremos dos dous primeiros. Un mal funcionamento do hardware pódese resolver de forma sinxela: debes ter todo duplicado. Se se trata de discos, os discos deben estar ensamblados en RAID; se se trata dun servidor, o servidor debe estar duplicado; se tes unha infraestrutura de rede, debes achegar unha segunda copia da infraestrutura de rede, é dicir, levas e duplicalo. E se algo falla, cambia a reserva de enerxía. É difícil dicir algo máis aquí.
O segundo é o fallo dos servizos externos. Para a maioría, o sistema non é un problema en absoluto, pero non para nós. Xa que procesamos os pagos, somos un agregador que se interpón entre o usuario (que introduce os datos da súa tarxeta) e os bancos, sistemas de pago (Visa, MasterCard, Mira, etc.). Os nosos servizos externos (sistemas de pago, bancos) adoitan fallar. Nin nós nin ti (se tes tales servizos) podemos influír nisto.
Que facer entón? Aquí hai dúas opcións. En primeiro lugar, se podes, deberías duplicar este servizo dalgún xeito. Por exemplo, se podemos, transferimos o tráfico dun servizo a outro: por exemplo, as tarxetas procesáronse a través de Sberbank, Sberbank está a ter problemas: transferimos o tráfico [condicionalmente] a Raiffeisen. O segundo que podemos facer é notar moi rapidamente a falla dos servizos externos e, polo tanto, falaremos da velocidade de resposta na seguinte parte do informe.
De feito, destes catro, podemos influír especificamente no cambio de versións do software: tomar accións que permitan mellorar a situación no contexto dos despregamentos e no contexto dun crecemento explosivo da carga. En realidade, iso é o que fixemos. Aquí, de novo, unha pequena nota...
Destes catro problemas, varios resólvense inmediatamente se tes unha nube. Se estás nas nubes de Microsoft Azhur, Ozone ou usas as nosas nubes de Yandex ou Mail, polo menos un mal funcionamento do hardware convértese no seu problema e todo se volve ben inmediatamente no contexto dun mal funcionamento do hardware.
Somos unha empresa un pouco pouco convencional. Aquí todos falan de "Kubernets", de nubes: non temos nin "Kubernets" nin nubes. Pero temos racks de hardware en moitos centros de datos, e estamos obrigados a vivir con este hardware, estamos obrigados a ser responsables de todo. Polo tanto, falaremos neste contexto. Entón, sobre os problemas. Os dous primeiros foron sacados de corchetes.
Cambiando a versión do software. Bases
Os nosos desenvolvedores non teñen acceso á produción. Por que é iso? É só que temos a certificación PCI DSS e que os nosos desenvolvedores simplemente non teñen dereito a entrar no "produto". Iso é todo, punto. En todo. Polo tanto, a responsabilidade do desenvolvemento remata exactamente no momento en que o desenvolvemento envía a compilación para a súa publicación.
A nosa segunda base que temos, que tamén nos axuda moito, é a ausencia de coñecementos indocumentados únicos. Espero que sexa o mesmo para ti. Porque se non é así, terás problemas. Os problemas xurdirán cando este coñecemento único e indocumentado non estea presente no momento axeitado no lugar axeitado. Digamos que ten unha persoa que sabe despregar un compoñente específico -a persoa non está alí, está de vacacións ou está enferma- iso é todo, ten problemas.
E a terceira base á que chegamos. Chegamos a el a través de dor, sangue, bágoas; chegamos á conclusión de que calquera das nosas construcións contén erros, aínda que estea libre de erros. Decidimos isto por nós mesmos: cando implementamos algo, cando introducimos algo en produción, temos unha compilación con erros. Formamos os requisitos que o noso sistema debe satisfacer.
Requisitos para cambiar a versión do software
Hai tres requisitos:
- Debemos revertir rapidamente o despregamento.
- Debemos minimizar o impacto dunha implantación sen éxito.
- E debemos ser capaces de despregar rapidamente en paralelo.
Exactamente nesa orde! Por que? Porque, en primeiro lugar, ao despregar unha nova versión, a velocidade non é importante, pero é importante que, se algo vai mal, retrocede rapidamente e teña un impacto mínimo. Pero se tes un conxunto de versións en produción, para o que resulta que hai un erro (de nada, non houbo despregamento, pero hai un erro) - a velocidade da implantación posterior é importante para ti. Que fixemos para satisfacer estas demandas? Recorremos á seguinte metodoloxía:
É bastante coñecido, nunca o inventamos: esta é a implementación azul/verde. Que é? Debe ter unha copia para cada grupo de servidores nos que estean instaladas as súas aplicacións. A copia é "cálida": non hai tráfico nela, pero en calquera momento este tráfico pódese enviar a esta copia. Esta copia contén a versión anterior. E no momento da implantación, desenrola o código a unha copia inactiva. Despois cambias parte do tráfico (ou todo) á nova versión. Así, para cambiar o fluxo de tráfico da versión antiga á nova, só tes que facer unha acción: cómpre cambiar o equilibrador no río arriba, cambiar a dirección dun río arriba a outro. Isto é moi cómodo e resolve o problema da conmutación rápida e a recuperación rápida.Aquí a solución á segunda pregunta é a minimización: só pode enviar parte do seu tráfico a unha liña nova, a unha liña cun código novo (que sexa, por exemplo, o 2%). E este 2% non son 100%! Se perdeu o 100 % do tráfico debido a unha implantación non exitosa, é asustado; se perdeu o 2 % do tráfico, é desagradable, pero non asusta. Ademais, o máis probable é que os usuarios nin sequera noten isto, porque nalgúns casos (non en todos) o mesmo usuario, premendo F5, pasará a outra versión que funcione.
Implementación azul/verde. Enrutamento
Non obstante, non todo é tan sinxelo "Implemento azul/verde"... Todos os nosos compoñentes pódense dividir en tres grupos:
- este é o frontend (páxinas de pago que ven os nosos clientes);
- núcleo de procesamento;
- adaptador para traballar con sistemas de pago (bancos, MasterCard, Visa...).
E aquí hai un matiz: o matiz reside no enrutamento entre as liñas. Se cambias o 100 % do tráfico, non tes estes problemas. Pero se queres cambiar o 2 %, comeza a facer preguntas: "Como facelo?" O máis sinxelo é sinxelo: podes configurar Round Robin en nginx por elección aleatoria e tes un 2% á esquerda e un 98% á dereita. Pero isto non sempre é axeitado.
Por exemplo, no noso caso, un usuario interactúa co sistema con máis dunha solicitude. Isto é normal: 2, 3, 4, 5 solicitudes - os teus sistemas poden ser os mesmos. E se é importante para ti que todas as solicitudes do usuario cheguen á mesma liña na que chegou a primeira solicitude ou (segundo punto) todas as solicitudes do usuario cheguen á nova liña despois do cambio (podería comezar a traballar antes co sistema, antes do cambio), - entón esta distribución aleatoria non é adecuada para vostede. Despois hai as seguintes opcións:
A primeira opción, a máis sinxela, baséase nos parámetros básicos do cliente (IP Hash). Tes unha IP e divídea de dereita a esquerda por enderezo IP. Entón, o segundo caso que describín funcionará para vostede, cando se produciu o despregamento, o usuario xa podería comezar a traballar co seu sistema e, desde o momento da implantación, todas as solicitudes irán a unha nova liña (para a mesma, por exemplo).Se por algún motivo non che convén e debes enviar as solicitudes á liña onde chegou a solicitude inicial do usuario, tes dúas opcións...
Primeira opción: podes mercar nginx+ de pago. Existe un mecanismo de sesións adhesivas, que, a petición inicial do usuario, atribúe unha sesión ao usuario e enlázao a un ou outro. Todas as solicitudes de usuarios posteriores durante a vida útil da sesión enviaranse ao mesmo río arriba onde se publicou a sesión.Isto non nos conveña porque xa tiñamos nginx regular. Cambiar a nginx+ non é que sexa caro, é só que foi algo doloroso para nós e non é moi correcto. "Sticks Sessions", por exemplo, non funcionou para nós pola simple razón de que "Sticks Sessions" non permite o enrutamento baseado en "Either-or". Alí podes especificar o que facemos "Sticks Sessions", por exemplo, por enderezo IP ou por enderezo IP e cookies ou por posparámetro, pero "Ou ou" é máis complicado alí.
Polo tanto, chegamos á cuarta opción. Tomamos nginx con esteroides (isto é openresty) - este é o mesmo nginx, que admite ademais a inclusión dos últimos scripts. Podes escribir un último script, darlle un "descanso aberto" e este último script executarase cando chegue a solicitude do usuario.
E escribimos, de feito, tal guión, puxémonos "openresti" e neste guión ordenamos 6 parámetros diferentes por concatenación "Ou". Segundo a presenza dun ou doutro parámetro, sabemos que o usuario chegou a unha páxina ou outra, a unha liña ou a outra.
Implementación azul/verde. Vantaxes e inconvenientes
Por suposto, probablemente foi posible facelo un pouco máis sinxelo (usar as mesmas "Sesións adhesivas"), pero tamén temos tal matiz que non só o usuario interactúa connosco no marco dun procesamento dunha transacción... Pero os sistemas de pago tamén interactúan connosco: despois de procesar a transacción (enviando unha solicitude ao sistema de pago), recibimos un retroceso.
E digamos, se dentro do noso circuíto podemos reenviar o enderezo IP do usuario en todas as solicitudes e dividir os usuarios en función do enderezo IP, entón non lle diremos o mesmo "Visa": "Amigo, somos unha empresa tan retro, parece ser internacional (no sitio web e en Rusia)... Por favor, proporcione-nos o enderezo IP do usuario nun campo adicional, o seu protocolo está estandarizado”! Está claro que non se poñerán de acordo.
Polo tanto, isto non funcionou para nós - fixemos openresty. En consecuencia, co enrutamento obtivemos algo así:Blue/Green Deployment ten, en consecuencia, as vantaxes que mencionei e os inconvenientes.
Dúas desvantaxes:
- cómpre preocuparse co enrutamento;
- a segunda desvantaxe principal é o gasto.
Necesitas o dobre de servidores, necesitas o dobre de recursos operativos, tes que gastar o dobre de esforzo para manter todo este zoolóxico.
Por certo, entre as vantaxes hai unha cousa máis que non mencionei antes: tes unha reserva en caso de crecemento da carga. Se tes un crecemento explosivo na carga, tes un gran número de usuarios, simplemente inclúes a segunda liña na distribución de 50 a 50 e inmediatamente tes servidores x2 no teu clúster ata que resolvas o problema de ter máis servidores.
Como facer unha implantación rápida?
Falamos sobre como resolver o problema da minimización e a recuperación rápida, pero a pregunta segue sendo: "Como implementar rapidamente?"
Aquí é breve e sinxelo.- Debes ter un sistema de CD (entrega continua) - non podes vivir sen el. Se tes un servidor, podes implementar manualmente. Temos preto de mil e medio servidores e mil e medio de controladores, por suposto; podemos plantar un departamento do tamaño desta sala só para implementar.
- O despregamento debe ser paralelo. Se o teu despregamento é secuencial, todo está mal. Un servidor é normal, estarás despregando mil e medio servidores todo o día.
- De novo, para a aceleración, probablemente xa non sexa necesario. Durante a implantación, o proxecto adoita construírse. Tes un proxecto web, hai unha parte front-end (fai un paquete web alí, compilas npm, algo así), e este proceso é, en principio, de curta duración: 5 minutos, pero estes 5 minutos poden ser crítico. É por iso que, por exemplo, non facemos iso: eliminamos estes 5 minutos, despregamos artefactos.
Que é un artefacto? Un artefacto é unha construción ensamblada na que xa se completaron todas as pezas de montaxe. Almacenamos este artefacto no almacén de artefactos. No seu momento usamos dous almacenamentos deste tipo: era Nexus e agora jFrog Artifactory). Inicialmente usamos "Nexus" porque comezamos a practicar este enfoque en aplicacións java (quedaba ben). Despois meteron alí algunhas das aplicacións escritas en PHP; e "Nexus" xa non era axeitado, polo que escollemos jFrog Artefactory, que pode artefactorizar case todo. Mesmo chegamos ao punto de que neste repositorio de artefactos almacenamos os nosos propios paquetes binarios que recollemos para os servidores.
Crecemento de carga explosiva
Falamos de cambiar a versión do software. O seguinte que temos é un aumento explosivo da carga. Aquí, probablemente me refiro ao crecemento explosivo da carga non é o correcto...
Escribimos un novo sistema: está orientado aos servizos, está de moda, bonito, traballadores en todas partes, colas en todas partes, asincronía en todas partes. E nestes sistemas, os datos poden fluír a través de diferentes fluxos. Para a primeira transacción, pódese usar o 1º, 3º, 10º traballador, para a segunda transacción: o 2º, 4º, 5º. E hoxe, digamos, pola mañá tes un fluxo de datos que utiliza os tres primeiros traballadores, e pola noite cambia radicalmente, e todo usa os outros tres traballadores.
E aquí resulta que cómpre escalar dalgún xeito os traballadores, cómpre escalar dalgún xeito os seus servizos, pero ao mesmo tempo evitar o inchazo de recursos.
Definimos os nosos requisitos. Estes requisitos son moi sinxelos: que haxa Descubrimento de servizos, parametrización - todo é estándar para a construción destes sistemas escalables, agás un punto - a depreciación dos recursos. Dixemos que non estamos preparados para amortizar recursos para que os servidores quenten o aire. Collemos "Consul", collemos "Nómada", que xestiona os nosos traballadores.Por que é un problema para nós? Retrocedamos un pouco. Agora temos ao redor de 70 sistemas de pago detrás de nós. Pola mañá, o tráfico pasa por Sberbank, entón Sberbank caeu, por exemplo, e pasámolo a outro sistema de pago. Tiñamos 100 traballadores antes de Sberbank, e despois diso necesitamos aumentar drasticamente 100 traballadores para outro sistema de pago. E é desexable que todo isto suceda sen a participación humana. Porque se hai participación humana, debería haber un enxeñeiro alí sentado as 24 horas do día, os 7 días do día, que só debería estar facendo isto, porque estes fallos, cando hai 70 sistemas detrás, ocorren regularmente.
Por iso, miramos Nomad, que ten unha IP aberta, e escribimos o noso propio, Scale-Nomad - ScaleNo, que fai aproximadamente o seguinte: supervisa o crecemento da cola e reduce ou aumenta o número de traballadores dependendo da dinámica. da cola. Cando o fixemos, pensamos: "Quizais poidamos abrir o código?" Entón mirárona: era tan simple coma dous copeques.
Ata agora non o temos de código aberto, pero se de súpeto despois do informe, despois de entender que necesitas tal cousa, o necesitas, os meus contactos están na última diapositiva, escríbeme. Se hai polo menos 3-5 persoas, patrocinarémolo.
Cómo funciona? Imos botarlle unha ollada! Mirando cara adiante: no lado esquerdo hai unha parte do noso seguimento: esta é unha liña, na parte superior está o tempo de procesamento do evento, no medio está o número de transaccións, na parte inferior está o número de traballadores.Se miras, hai un fallo nesta imaxe. No gráfico superior, un dos gráficos fallou en 45 segundos; un dos sistemas de pago caeu. Inmediatamente, o tráfico entrou en 2 minutos e a cola comezou a crecer noutro sistema de pago, onde non había traballadores (non utilizamos recursos, pola contra, eliminamos o recurso correctamente). Non queriamos quentar: había un número mínimo, uns 5-10 traballadores, pero non podían facer fronte.
O último gráfico mostra unha "joroba", o que só significa que "Skaleno" duplicou esta cantidade. E entón, cando o gráfico caeu un pouco, reduciuno un pouco: o número de traballadores cambiouse automaticamente. Así funciona esta cousa. Falamos do punto número 2: "Como desfacerse rapidamente das razóns".
Seguimento. Como identificar rapidamente o problema?
Agora o primeiro punto é "Como identificar rapidamente o problema?" Seguimento! Debemos entender certas cousas rapidamente. Que cousas debemos entender rapidamente?
Tres cousas!- Debemos comprender e comprender rapidamente o rendemento dos nosos propios recursos.
- Debemos comprender rapidamente os fallos e supervisar o rendemento dos sistemas externos a nós.
- O terceiro punto é identificar erros lóxicos. Isto é cando o sistema está a traballar para ti, todo é normal segundo todos os indicadores, pero algo sae mal.
Probablemente non che diga nada tan xenial aquí. Serei o capitán Obvious. Buscamos o que había no mercado. Temos un "zoolóxico divertido". Este é o tipo de zoolóxico que temos agora:
Usamos Zabbix para supervisar o hardware, para supervisar os principais indicadores dos servidores. Usamos Okmeter para bases de datos. Usamos "Grafana" e "Prometheus" para todos os outros indicadores que non se axustan aos dous primeiros, algúns con "Grafana" e "Prometheus", e outros con "Grafana" con "Influx" e Telegraf.Hai un ano queriamos usar New Relic. Cousa xenial, pode facer de todo. Pero por moito que poida facer todo, é tan cara. Cando chegamos a un volume de 1,5 mil servidores, un vendedor veu a nós e díxonos: "Concluamos un acordo para o próximo ano". Miramos o prezo e dixemos que non, non o faremos. Agora estamos abandonando New Relic, quedan uns 15 servidores baixo a vixilancia de New Relic. O prezo resultou absolutamente salvaxe.
E hai unha ferramenta que nós mesmos implementamos: esta é Debugger. Ao principio chamámoslle "Bagger", pero despois pasou por alí un profesor de inglés, riu desconcertadamente e chamouno "Debagger". Que é? Esta é unha ferramenta que, de feito, en 15-30 segundos en cada compoñente, como unha "caixa negra" do sistema, realiza probas sobre o rendemento xeral do compoñente.
Por exemplo, se hai unha páxina externa (páxina de pago), simplemente ábrea e mira como debería verse. Se se está procesando, envía unha "transacción" de proba e asegúrase de que esta "transacción" chegue. Se se trata dunha conexión con sistemas de pago, enviamos unha solicitude de proba en consecuencia, onde podemos, e vemos que todo está ben con nós.
Que indicadores son importantes para o seguimento?
Que vixíamos principalmente? Que indicadores son importantes para nós?
- O tempo de resposta / RPS nas frontes é un indicador moi importante. Inmediatamente responde que algo está mal contigo.
- O número de mensaxes procesadas en todas as filas.
- Número de traballadores.
- Métricas básicas de corrección.
O último punto é a métrica "negocio", "negocio". Se queres controlar o mesmo, debes definir unha ou dúas métricas que sexan os principais indicadores para ti. A nosa métrica é o rendemento (esta é a relación entre o número de transaccións exitosas e o fluxo total de transaccións). Se algo cambia nel nun intervalo de 5-10-15 minutos, significa que temos problemas (se cambia radicalmente).
O que parece para nós é un exemplo dun dos nosos consellos:
No lado esquerdo hai 6 gráficos, isto é segundo as liñas: o número de traballadores e o número de mensaxes nas filas. No lado dereito: RPS, RTS. A continuación móstrase a mesma métrica "empresarial". E na métrica "empresarial" podemos ver inmediatamente que algo saíu mal nos dous gráficos do medio... Este é só outro sistema que está detrás de nós que caeu.O segundo que tiñamos que facer era vixiar a caída dos sistemas de pago externos. Aquí tomamos OpenTracing - un mecanismo, estándar, paradigma que che permite rastrexar sistemas distribuídos; e cambiouse un pouco. O paradigma estándar de OpenTracing di que construímos un rastrexo para cada solicitude individual. Non necesitabamos isto, e envolvémolo nun resumo, trazo de agregación. Creamos unha ferramenta que nos permite rastrexar a velocidade dos sistemas que hai detrás.
O gráfico móstranos que un dos sistemas de pago comezou a responder en 3 segundos: temos problemas. Ademais, esta cousa reaccionará cando comecen os problemas, nun intervalo de 20-30 segundos.E a terceira clase de erros de seguimento que existen é o seguimento lóxico.
Sinceramente, non sabía que debuxar nesta diapositiva, porque facía tempo que buscabamos no mercado algo que nos conveña. Non atopamos nada, así que tivemos que facelo nós.
Que quero dicir con seguimento lóxico? Pois imaxina: ti fas un sistema (por exemplo, un clon de Tinder); fixéchelo, lanzouno. O exitoso xestor Vasya Pupkin púxoo no seu teléfono, ve unha rapaza alí, gústalle... e o mesmo non lle vai á rapaza, o que vai ao garda de seguridade Mikhalych do mesmo centro de negocios. O xerente baixa e pregúntase: "Por que este garda de seguridade Mikhalych lle sorrí tan agradablemente?"En tales situacións... Para nós, esta situación soa un pouco diferente, porque (escribín) esta é unha perda de reputación que indirectamente leva a perdas financeiras. A nosa situación é a contraria: podemos sufrir perdas financeiras directas - por exemplo, se realizamos unha transacción como exitosa, pero non foi exitosa (ou viceversa). Tiven que escribir a miña propia ferramenta que rastrexa o número de transaccións exitosas ao longo do tempo usando indicadores comerciais. Non atopei nada no mercado! Esta é exactamente a idea que quería transmitir. Non hai nada no mercado que solucione este tipo de problemas.
Tratábase de como identificar rapidamente o problema.
Como determinar os motivos da implantación
O terceiro grupo de problemas que resolvemos é despois de identificar o problema, despois de desfacernos del, sería bo entender o motivo do desenvolvemento, das probas e facer algo ao respecto. En consecuencia, necesitamos investigar, necesitamos levantar os rexistros.
Se falamos de rexistros (o principal motivo son os rexistros), a maior parte dos nosos rexistros están en ELK Stack: case todos teñen o mesmo. Para algúns, quizais non estea en ELK, pero se escribes rexistros en gigabytes, tarde ou cedo chegarás a ELK. Escribimos en terabytes.
Hai un problema aquí. Arranxémolo, corriximos o erro para o usuario, comezamos a escavar o que había alí, subimos a Kibana, introducimos alí o identificador da transacción e obtivemos un pano coma este (mostra moito). E absolutamente nada está claro neste pano. Por que? Si, porque non está claro que parte pertence a que traballador, que parte pertence a que compoñente. E nese momento démonos conta de que necesitabamos rastrexar, o mesmo OpenTracing do que falei.Pensámolo hai un ano, centramos a nosa atención no mercado e alí había dúas ferramentas: "Zipkin" e "Jaeger". "Jager" é de feito un herdeiro ideolóxico, un sucesor ideolóxico de "Zipkin". Todo está ben en Zipkin, agás que non sabe como agregar, non sabe como incluír rexistros no rastrexo, só rastrexo do tempo. E "Jager" apoiou isto.
Miramos "Jager": podes instrumentar aplicacións, podes escribir en Api (o estándar Api para PHP naquel momento, non foi aprobado - isto foi hai un ano, pero agora xa foi aprobado), pero hai non era absolutamente ningún cliente. "Vale", pensamos e escribimos ao noso propio cliente. Que conseguimos? Isto é aproximadamente o que parece:
En Jaeger, créanse intervalos para cada mensaxe. É dicir, cando un usuario abre o sistema, ve un ou dous bloques para cada solicitude entrante (1-2-3 - o número de solicitudes entrantes do usuario, o número de bloques). Para facilitalo aos usuarios, engadimos etiquetas aos rexistros e aos trazos de tempo. En consecuencia, en caso de erro, a nosa aplicación marcará o rexistro coa etiqueta de erro adecuada. Podes filtrar por etiqueta de erro e só se mostrarán os tramos que conteñan este bloque cun erro. Así se ve se ampliamos o intervalo:
No interior do vano hai un conxunto de trazos. Neste caso, trátase de tres trazos de proba, e o terceiro indícanos que se produciu un erro. Ao mesmo tempo, aquí vemos un trazo de tempo: temos unha escala de tempo na parte superior e vemos en que intervalo de tempo se rexistrou este ou aquel rexistro.En consecuencia, as cousas saíronnos ben. Escribimos a nosa propia extensión e de código aberto. Se queres traballar co rastrexo, se queres traballar con "Jager" en PHP, existe a nosa extensión, benvido a usar, como din:
Temos esta extensión: é un cliente para a API OpenTracing, está feita como extensión php, é dicir, terás que montala e instalala no sistema. Hai un ano non había nada diferente. Agora hai outros clientes que son como compoñentes. Aquí depende de ti: ou tiras os compoñentes cun compositor ou usas a extensión que che depende.Estándares corporativos
Falamos dos tres mandamentos. O cuarto mandamento é estandarizar os enfoques. De que se trata isto? Trátase disto:
Por que está aquí a palabra "corporativo"? Non porque sexamos unha empresa grande ou burocrática, non! Quería usar a palabra "corporativo" aquí no contexto de que cada empresa, cada produto debería ter os seus propios estándares, incluído ti. Que estándares temos?
- Temos normas de implantación. Non nos movemos a ningún lado sen el, non podemos. Despregamos unhas 60 veces á semana, é dicir, despregámonos case constantemente. Ao mesmo tempo, temos, por exemplo, na normativa de despregamento un tabú sobre os despregamentos o venres -en principio, non despregamos-.
- Precisamos documentación. Nin un só compoñente novo entra en produción se non hai documentación para iso, aínda que naceu baixo a pluma dos nosos especialistas en RnD. Requirimos deles instrucións de implantación, un mapa de seguimento e unha descrición aproximada (ben, como poden escribir os programadores) de como funciona este compoñente, como solucionalo.
- Non resolvemos a causa do problema, senón o problema, o que xa dixen. É importante para nós protexer ao usuario dos problemas.
- Temos autorizacións. Por exemplo, non consideramos tempo de inactividade se perdemos o 2% do tráfico en dous minutos. Isto basicamente non está incluído nas nosas estatísticas. Se é máis porcentual ou temporal, xa contamos.
- E sempre escribimos autopsias. Pase o que nos pase, calquera situación na que alguén se comportou de xeito anormal na produción quedará reflectida na autopsia. A autopsia é un documento no que escribes o que che pasou, un calendario detallado, o que fixeches para corrixilo e (este é un bloque obrigatorio!) que farás para evitar que isto suceda no futuro. Isto é obrigatorio e necesario para a análise posterior.
Que se considera tempo de inactividade?
A que levou todo isto?Isto levou ao feito de que (tivemos certos problemas de estabilidade, isto non nos convenía nin aos clientes nin a nós) durante os últimos 6 meses o noso indicador de estabilidade foi de 99,97. Podemos dicir que isto non é moito. Si, temos algo polo que esforzarnos. Deste indicador, preto da metade é a estabilidade, por así dicilo, non da nosa, senón do noso firewall de aplicacións web, que está diante de nós e se usa como servizo, pero aos clientes non lles importa.
Aprendemos a durmir pola noite. Por fin! Hai seis meses non podíamos. E nesta nota cos resultados, gustaríame facer unha nota. Onte á noite houbo unha reportaxe marabillosa sobre o sistema de control dun reactor nuclear. Se as persoas que escribiron este sistema poden escoitarme, esquece o que dixen sobre "o 2 % non é tempo de inactividade". Para ti, o 2% é tempo de inactividade, aínda que sexa durante dous minutos.
Iso é todo! As túas preguntas.
Acerca de equilibradores e migración de bases de datos
Pregunta do público asistente (en diante – B): – Boas noites. Moitas grazas por este informe administrativo! Unha pequena pregunta sobre os teus equilibradores. Mencionaches que tes un WAF, é dicir, segundo o entendo, usas algún tipo de equilibrador externo...
EK: – Non, usamos os nosos servizos como equilibrador. Neste caso, WAF é exclusivamente unha ferramenta de protección contra DDoS para nós.
EN: – Podes dicir algunhas palabras sobre os equilibradores?
EK: – Como xa dixen, este é un grupo de servidores en openresty. Agora temos 5 grupos de reserva que responden exclusivamente... é dicir, un servidor que executa exclusivamente openresty, só proxy tráfico. En consecuencia, para entender o que temos: agora temos un fluxo de tráfico regular de varios centos de megabits. Afrontan, séntense ben, nin sequera se esforzan.
EN: – Tamén unha pregunta sinxela. Aquí está o despregamento azul/verde. Que fas, por exemplo, coas migracións de bases de datos?
EK: - Boa pregunta! Mira, no despregamento Azul/Verde temos colas separadas para cada liña. É dicir, se falamos de colas de eventos que se transmiten de traballador a traballador, hai colas separadas para a liña azul e para a verde. Se estamos a falar da propia base de datos, reducimos deliberadamente todo o que puidemos, movemos todo practicamente en filas; na base de datos só almacenamos unha pila de transaccións. E a nosa pila de transaccións é a mesma para todas as liñas. Coa base de datos neste contexto: non a dividimos en azul e verde, porque as dúas versións do código deben saber o que está a pasar coa transacción.
Amigos, tamén teño un pequeno premio para estimularvos: un libro. E debería ser premiado pola mellor pregunta.
EN: - Ola. Grazas polo informe. A pregunta é esta. Ti supervisas os pagos, supervisas os servizos cos que te comunicas... Pero como controlas para que, dalgún xeito, unha persoa chegase á túa páxina de pago, fixera un pago e o proxecto lle acredite diñeiro? É dicir, como controlas que o comerciante está dispoñible e aceptou a túa devolución de chamada?
EK: – "Comerciante" para nós neste caso é exactamente o mesmo servizo externo que o sistema de pago. Supervisamos a velocidade de resposta do comerciante.
Sobre o cifrado de bases de datos
EN: - Ola. Teño unha pregunta lixeiramente relacionada. Tes datos confidenciais de PCI DSS. Quería saber como almacenas os PAN nas filas nas que tes que transferir? Usas algún cifrado? E isto leva á segunda pregunta: segundo PCI DSS, é necesario volver cifrar periodicamente a base de datos en caso de cambios (despedimento de administradores, etc.) - que ocorre coa accesibilidade neste caso?
EK: - Marabillosa pregunta! En primeiro lugar, non almacenamos os PAN en filas. Non temos dereito a almacenar o PAN en ningún lugar de forma clara, en principio, polo que usamos un servizo especial (chamámoslle "Kademon") - este é un servizo que só fai unha cousa: recibe unha mensaxe como entrada e envía unha mensaxe cifrada. E gardamos todo con esta mensaxe cifrada. En consecuencia, a lonxitude da nosa chave é inferior a un kilobyte, polo que isto é serio e fiable.EN: – Necesitas 2 kilobytes agora?
EK: – Parece que onte mesmo foron 256... Ben, onde se non?!
En consecuencia, esta é a primeira. E, en segundo lugar, a solución que existe, admite o procedemento de re-cifrado: hai dous pares de "keks" (claves), que dan "decks" que cifran (a clave son as claves, dek son derivados das claves que encriptan) . E se se inicia o procedemento (ocorre regularmente, de 3 meses a ± algúns), descargamos un novo par de "bolos" e volvemos cifrar os datos. Temos servizos separados que extraen todos os datos e os cifran dun xeito novo; Os datos almacénanse xunto ao identificador da clave coa que se cifran. En consecuencia, en canto ciframos os datos con claves novas, eliminamos a clave antiga.
Ás veces, os pagos deben facerse manualmente...
EN: – É dicir, se chegou un reembolso por algunha operación, aínda o descifrará coa chave antiga?
EK: - Si.
EN: – Entón unha pequena pregunta máis. Cando se produce algún tipo de fallo, caída ou incidente, é necesario impulsar a transacción manualmente. Hai tal situación.
EK: - Si, ás veces.
EN: -¿De onde sacas estes datos? Ou vai vostede mesmo a este almacén?
EK: – Non, ben, claro, temos algún tipo de sistema de back-office que contén unha interface para o noso soporte. Se non sabemos en que estado está a transacción (por exemplo, ata que o sistema de pago respondeu cun tempo de espera), non o sabemos a priori, é dicir, asignamos o estado final só con total confianza. Neste caso, asignamos a transacción a un estado especial para o procesamento manual. Pola mañá, ao día seguinte, tan pronto como o soporte recibe información de que tal ou tal transacción permanecen no sistema de pago, procesaas manualmente nesta interface.
EN: – Teño un par de preguntas. Unha delas é a continuación da zona PCI DSS: como rexistras o seu circuíto? Esta pregunta débese a que o programador podería poñer calquera cousa nos rexistros. Segunda pregunta: como se implementan as correccións rápidas? Usar identificadores na base de datos é unha opción, pero pode haber correccións gratuítas: cal é o procedemento alí? E a terceira pregunta probablemente estea relacionada con RTO, RPO. A túa dispoñibilidade era de 99,97, case catro nove, pero segundo teño entendido, tes un segundo centro de datos, un terceiro centro de datos e un quinto centro de datos... Como sincronizalos, replicalos e todo o demais?EK: - Comezamos polo primeiro. A primeira pregunta foi sobre os rexistros? Cando escribimos rexistros, temos unha capa que enmascara todos os datos sensibles. Mira a máscara e os campos adicionais. En consecuencia, os nosos rexistros saen con datos xa enmascarados e un circuíto PCI DSS. Esta é unha das tarefas habituais asignadas ao departamento de probas. Están obrigados a comprobar cada tarefa, incluídos os rexistros que escriben, e esta é unha das tarefas habituais durante as revisións de código, para controlar que o programador non anotou nada. As comprobacións posteriores disto realízanse regularmente polo departamento de seguridade da información aproximadamente unha vez á semana: os rexistros do último día tómanse selectivamente e lévanse a cabo a través dun escáner-analizador especial desde os servidores de proba para comprobar todo.
Sobre as correccións rápidas. Isto está incluído nas nosas normas de implantación. Temos unha cláusula separada sobre as correccións rápidas. Cremos que implementamos correccións durante todo o día cando o necesitamos. En canto se monta a versión, tan pronto como se executa, en canto temos un artefacto, temos un administrador do sistema de garda nunha chamada do soporte, e el desprázao no momento en que sexa necesario.Sobre "catro nove". A cifra que temos agora conseguiuse de verdade, e esforzámonos por iso noutro centro de datos. Agora temos un segundo centro de datos, e estamos comezando a encamiñar entre eles, e o problema da replicación entre centros de datos é realmente unha cuestión non trivial. Tentamos resolvelo ao mesmo tempo usando diferentes medios: intentamos usar a mesma "Tarantula" - non nos resultou, digoche de inmediato. Por iso acabamos pedindo os "sens" manualmente. De feito, cada aplicación do noso sistema executa a necesaria sincronización "cambio - feito" entre centros de datos de forma asíncrona.
EN: - Se conseguiches un segundo, por que non conseguiches un terceiro? Porque ninguén aínda ten o cerebro dividido...
EK: – Pero non temos Cerebro dividido. Debido ao feito de que cada aplicación está dirixida por un multimaster, non nos importa a que centro chegou a solicitude. Estamos preparados para o feito de que se un dos nosos centros de datos falla (confiamos nisto) e no medio dunha solicitude de usuario cambia ao segundo centro de datos, estamos preparados para perder este usuario, de feito; pero estas serán unidades, unidades absolutas.
EN: - Boas tardes. Grazas polo informe. Falaches do teu depurador, que executa algunhas transaccións de proba en produción. Pero cóntanos sobre as transaccións de proba! Que profundidade chega?
EK: – Percorre o ciclo completo de todo o compoñente. Para un compoñente, non hai diferenza entre unha transacción de proba e unha transacción de produción. Pero desde un punto de vista lóxico, este é simplemente un proxecto separado no sistema, no que só se executan transaccións de proba.
EN: -¿Onde o cortas? Aquí Core enviou...
EK: – Estamos detrás de "Kor" neste caso para transaccións de proba... Temos algo como o enrutamento: "Kor" sabe a que sistema de pago enviar - enviamos a un sistema de pago falso, que simplemente dá un sinal http e iso é todo.
EN: – Dígame, por favor, a súa aplicación foi escrita nun enorme monólito ou a cortaches nalgúns servizos ou incluso microservizos?
EK: – Non temos un monólito, claro, temos unha aplicación orientada a servizos. Bromeamos dicindo que o noso servizo está feito de monolitos: son realmente bastante grandes. É difícil chamarlle microservizos, pero son servizos nos que operan os traballadores das máquinas distribuídas.
Se o servizo no servidor está comprometido...
EN: -Entón teño a seguinte pregunta. Aínda que fose un monólito, aínda dixeches que tes moitos destes servidores instantáneos, todos eles basicamente procesan datos, e a pregunta é: “En caso de comprometer un dos servidores instantáneos ou unha aplicación, calquera ligazón individual. , teñen algún tipo de control de acceso? Cal deles pode facer que? Con quen debo contactar para que información?
EK: - Si, definitivamente. Os requisitos de seguridade son bastante serios. En primeiro lugar, temos movementos de datos abertos, e os portos son só aqueles polos que anticipamos o movemento de tráfico con antelación. Se un compoñente se comunica coa base de datos (por exemplo, con Muskul) a través do 5-4-3-2, só estará aberto a el 5-4-3-2 e outros portos e outras direccións de tráfico non estarán dispoñibles. Ademais, cómpre entender que na nosa produción hai uns 10 bucles de seguridade diferentes. E aínda que a aplicación se vexa comprometida dalgún xeito, Deus o libre, o atacante non poderá acceder á consola de xestión do servidor, porque esta é unha zona de seguridade de rede diferente.EN: – E neste contexto, o que máis me interesa é que tes certos contratos con servizos: que poden facer, a través de que “accións” poden contactar entre eles... E nun fluxo normal, algúns servizos específicos solicitan algún fila, unha lista de "accións" na outra. Non parecen recorrer aos demais nunha situación normal, e teñen outras áreas de responsabilidade. Se un deles está comprometido, será capaz de interromper as "accións" dese servizo?...
EK: - Entendo. Se nunha situación normal con outro servidor se permitiu a comunicación, entón si. Segundo o contrato de SLA, non supervisamos que só se lle permitan as 3 primeiras "accións" e non se lle permitan as 4 "accións". Isto probablemente sexa redundante para nós, porque xa temos un sistema de protección de 4 niveis, en principio, para circuítos. Preferimos defendernos cos contornos, antes que a nivel dos interiores.
Como funcionan Visa, MasterCard e Sberbank
EN: – Quero aclarar un punto sobre o cambio dun usuario dun centro de datos a outro. Polo que sei, Visa e MasterCard funcionan usando o protocolo sincrónico binario 8583, e hai mesturas alí. E quería saber, agora queremos dicir cambiar: é directamente "Visa" e "MasterCard" ou antes dos sistemas de pago, antes do procesamento?
EK: - Isto é antes das mesturas. As nosas mesturas están situadas no mesmo centro de datos.
EN: – En liñas xerais, tes un punto de conexión?
EK: - "Visa" e "MasterCard" - si. Simplemente porque Visa e MasterCard requiren investimentos bastante serios en infraestruturas para celebrar contratos separados para obter un segundo par de mesturas, por exemplo. Están reservados nun centro de datos, pero se, Deus non o libre, o noso centro de datos, onde hai mesturas para conectarse a Visa e MasterCard, morre, entón teremos unha conexión con Visa e MasterCard perdida...
EN: – Como se poden reservar? Sei que Visa só permite unha conexión en principio!
EK: – Fornecen eles mesmos os equipos. En calquera caso, recibimos equipos que son totalmente redundantes no interior.
EN: – Entón o stand é do seu Connects Orange?...
EK: - Si.
EN: – Pero que pasa con este caso: se o teu centro de datos desaparece, como podes seguir usándoo? Ou simplemente para o tráfico?
EK: - Non. Neste caso, simplemente cambiaremos o tráfico a outra canle, que, naturalmente, será máis caro para nós e máis caro para os nosos clientes. Pero o tráfico non pasará pola nosa conexión directa con Visa, MasterCard, senón polo Sberbank condicional (moi esaxerado).
Pido desculpas se ofendín aos empregados de Sberbank. Pero segundo as nosas estatísticas, entre os bancos rusos, Sberbank cae con máis frecuencia. Non pasa un mes sen que se caia algo en Sberbank.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com