Todo mundo fala sobre os processos de desenvolvimento e teste, treinamento de pessoal, aumento de motivação, mas esses processos não são suficientes quando um minuto de inatividade do serviço custa enormes quantias de dinheiro. O que fazer quando você realiza transações financeiras sob um SLA rigoroso? Como aumentar a confiabilidade e a tolerância a falhas dos seus sistemas, tirando o desenvolvimento e os testes da equação?
A próxima conferência HighLoad++ será realizada nos dias 6 e 7 de abril de 2020 em São Petersburgo. Detalhes e ingressos para . 9 de novembro, 18h. HighLoad++ Moscou 00, salão Delhi + Calcutá. Teses e .
Evgeniy Kuzovlev (doravante – CE): - Amigos, olá! Meu nome é Kuzovlev Evgeniy. Sou da empresa EcommPay, uma divisão específica é a EcommPay IT, a divisão de TI do grupo de empresas. E hoje falaremos sobre tempos de inatividade - sobre como evitá-los, sobre como minimizar suas consequências se não puderem ser evitados. O tópico é apresentado da seguinte forma: “O que fazer quando um minuto de inatividade custa US$ 100”? Olhando para o futuro, nossos números são comparáveis.
O que a EcomPay IT faz?
Quem somos nós? Por que estou aqui na sua frente? Por que tenho o direito de lhe contar algo aqui? E sobre o que falaremos aqui com mais detalhes?
O grupo de empresas EcommPay é um adquirente internacional. Processamos pagamentos em todo o mundo - na Rússia, Europa, Sudeste Asiático (em todo o mundo). Temos 9 escritórios, 500 funcionários no total, e aproximadamente pouco menos da metade deles são especialistas em TI. Tudo o que fazemos, tudo com que ganhamos dinheiro, nós mesmos fizemos.
Nós mesmos escrevemos todos os nossos produtos (e temos muitos deles - em nossa linha de grandes produtos de TI, temos cerca de 16 componentes diferentes); Nós nos escrevemos, nos desenvolvemos. E neste momento realizamos cerca de um milhão de transações por dia (milhões é provavelmente a forma correta de dizer isso). Somos uma empresa bastante jovem – temos apenas seis anos.
Há 6 anos, era uma startup quando os caras surgiram com o negócio. Eles estavam unidos por uma ideia (não havia mais nada além de uma ideia), e nós corremos. Como qualquer startup, rodamos mais rápido... Para nós a velocidade era mais importante que a qualidade.
Em algum momento paramos: percebemos que não poderíamos mais de alguma forma viver naquela velocidade e com aquela qualidade e precisávamos focar primeiro na qualidade. Neste momento, decidimos escrever uma nova plataforma que fosse correta, escalável e confiável. Começaram a escrever esta plataforma (começaram a investir, a desenvolver desenvolvimento, a testar), mas a certa altura perceberam que o desenvolvimento e os testes não nos permitiam atingir um novo nível de qualidade de serviço.
Você faz um novo produto, coloca-o em produção, mas ainda assim algo dá errado em algum lugar. E hoje falaremos sobre como chegar a um novo patamar de qualidade (como fizemos, sobre nossa experiência), tirando da equação o desenvolvimento e os testes; falaremos sobre o que está disponível para operação - o que a operação pode fazer sozinha, o que ela pode oferecer para testar a fim de influenciar a qualidade.
Tempos de inatividade. Mandamentos de operação.
Sempre a pedra angular principal, o que realmente falaremos hoje é o tempo de inatividade. Uma palavra terrível. Se tivermos tempo de inatividade, tudo será ruim para nós. Estamos correndo para levantá-lo, os administradores estão segurando o servidor - Deus não permita que não caia, como dizem naquela música. É sobre isso que falaremos hoje.
Quando começamos a mudar nossas abordagens, formamos 4 mandamentos. Eu os apresentei nos slides:
Esses mandamentos são bastante simples:
- Identifique rapidamente o problema.
- Livre-se disso ainda mais rápido.
- Ajude a entender o motivo (mais tarde, para desenvolvedores).
- E padronizar abordagens.
Gostaria de chamar a atenção para o ponto 2. Estamos nos livrando do problema, não resolvendo. Decidir é secundário. Para nós, o principal é que o usuário esteja protegido desse problema. Existirá em algum ambiente isolado, mas esse ambiente não terá nenhum contato com ele. Na verdade, vamos passar por esses quatro grupos de problemas (alguns com mais detalhes, outros com menos detalhes), vou contar o que usamos, que experiência relevante temos em soluções.
Solução de problemas: quando eles acontecem e o que fazer a respeito?
Mas começaremos fora de ordem, começaremos com o ponto número 2 - como nos livrar rapidamente do problema? Há um problema – precisamos resolvê-lo. "O que devemos fazer sobre isso?" - a questão principal. E quando começamos a pensar em como resolver o problema, desenvolvemos para nós mesmos alguns requisitos que a solução de problemas deve seguir.
Para formular estes requisitos, decidimos colocar-nos a seguinte questão: “Quando temos problemas”? E os problemas, como se viu, ocorrem em quatro casos:
- Falha de hardware.
- Os serviços externos falharam.
- Alteração da versão do software (a mesma implantação).
- Crescimento explosivo da carga.
Não falaremos sobre os dois primeiros. Um mau funcionamento de hardware pode ser resolvido de forma bastante simples: você deve duplicar tudo. Se forem discos, os discos devem ser montados em RAID; se for um servidor, o servidor deve ser duplicado; se você tiver uma infraestrutura de rede, você deve fornecer uma segunda cópia da infraestrutura de rede, ou seja, você pega e duplicá-lo. E se algo falhar, você muda para energia reservada. É difícil dizer mais alguma coisa aqui.
A segunda é a falha dos serviços externos. Para a maioria, o sistema não é um problema, mas não para nós. Como processamos pagamentos, somos um agregador que se posiciona entre o usuário (que insere os dados do seu cartão) e os bancos, sistemas de pagamento (Visa, MasterCard, Mira, etc.). Os nossos serviços externos (sistemas de pagamento, bancos) tendem a falhar. Nem nós nem você (se você tiver tais serviços) podemos influenciar isso.
O que fazer então? Existem duas opções aqui. Primeiro, se puder, você deve duplicar esse serviço de alguma forma. Por exemplo, se pudermos, transferimos o tráfego de um serviço para outro: por exemplo, os cartões foram processados através do Sberbank, o Sberbank está tendo problemas - transferimos o tráfego [condicionalmente] para o Raiffeisen. A segunda coisa que podemos fazer é perceber muito rapidamente a falha dos serviços externos e, por isso, falaremos sobre velocidade de resposta na próxima parte do relatório.
Na verdade, destes quatro, podemos influenciar especificamente a mudança de versões de software - tomar ações que levarão a uma melhoria da situação no contexto das implantações e no contexto do crescimento explosivo da carga. Na verdade, foi isso que fizemos. Aqui, novamente, uma pequena nota...
Desses quatro problemas, vários serão resolvidos imediatamente se você tiver uma nuvem. Se você estiver nas nuvens Microsoft Azhur, Ozone, ou usar nossas nuvens, do Yandex ou Mail, então pelo menos um mau funcionamento de hardware se torna um problema deles e tudo imediatamente fica bem para você no contexto de um mau funcionamento de hardware.
Somos uma empresa pouco convencional. Aqui todo mundo está falando sobre “Kubernets”, sobre nuvens - não temos “Kubernets” nem nuvens. Mas temos racks de hardware em muitos data centers e somos forçados a viver desse hardware, somos forçados a ser responsáveis por tudo isso. Portanto, falaremos neste contexto. Então, sobre os problemas. Os dois primeiros foram retirados dos colchetes.
Alterando a versão do software. Bases
Nossos desenvolvedores não têm acesso à produção. Por que é que? Acontece que temos certificação PCI DSS e nossos desenvolvedores simplesmente não têm o direito de entrar no “produto”. É isso, ponto final. De forma alguma. Portanto, a responsabilidade pelo desenvolvimento termina exatamente no momento em que o desenvolvimento envia a compilação para lançamento.
A nossa segunda base que temos, que também nos ajuda muito, é a ausência de conhecimento único e não documentado. Espero que seja o mesmo para você. Porque se não for esse o caso, você terá problemas. Surgirão problemas quando este conhecimento único e não documentado não estiver presente na hora certa e no lugar certo. Digamos que você tem uma pessoa que sabe implantar um componente específico - a pessoa não está, está de férias ou doente - é isso, você está com problemas.
E a terceira base a que chegamos. Chegamos a isso através de dor, sangue, lágrimas - chegamos à conclusão de que qualquer uma de nossas construções contém erros, mesmo que esteja livre de erros. Decidimos isso por nós mesmos: quando implantamos algo, quando colocamos algo em produção, temos uma compilação com erros. Formamos os requisitos que nosso sistema deve satisfazer.
Requisitos para alterar a versão do software
Existem três requisitos:
- Devemos reverter rapidamente a implantação.
- Devemos minimizar o impacto de uma implantação malsucedida.
- E devemos ser capazes de implantar rapidamente em paralelo.
Exatamente nessa ordem! Por que? Porque, em primeiro lugar, ao implantar uma nova versão, a velocidade não é importante, mas é importante para você, se algo der errado, reverter rapidamente e ter um impacto mínimo. Mas se você tiver um conjunto de versões em produção, para as quais há um erro (do nada, não houve implantação, mas há um erro) - a velocidade da implantação subsequente é importante para você. O que fizemos para atender a essas demandas? Recorremos à seguinte metodologia:
É bastante conhecido, nunca o inventamos - esta é a implantação Azul/Verde. O que é isso? Você deve ter uma cópia para cada grupo de servidores nos quais seus aplicativos estão instalados. A cópia está “quente”: não há tráfego nela, mas a qualquer momento esse tráfego pode ser enviado para esta cópia. Esta cópia contém a versão anterior. E no momento da implantação, você distribui o código para uma cópia inativa. Então você muda parte do tráfego (ou todo) para a nova versão. Assim, para alterar o fluxo de tráfego da versão antiga para a nova, você precisa realizar apenas uma ação: você precisa alterar o balanceador no upstream, mudar a direção - de um upstream para outro. Isso é muito conveniente e resolve o problema de troca rápida e reversão rápida.Aqui a solução para a segunda questão é a minimização: você pode enviar apenas parte do seu tráfego para uma nova linha, para uma linha com um novo código (seja, por exemplo, 2%). E esses 2% não são 100%! Se você perdeu 100% do seu tráfego devido a uma implantação malsucedida, isso é assustador; se você perdeu 2% do seu tráfego, isso é desagradável, mas não é assustador. Além disso, os usuários provavelmente nem perceberão isso, porque em alguns casos (não em todos) o mesmo usuário, pressionando F5, será levado para outra versão funcional.
Implantação azul/verde. Roteamento
No entanto, nem tudo é tão simples “implantação Azul/Verde”... Todos os nossos componentes podem ser divididos em três grupos:
- este é o frontend (páginas de pagamento que nossos clientes veem);
- núcleo de processamento;
- adaptador para trabalhar com sistemas de pagamento (bancos, MasterCard, Visa...).
E há uma nuance aqui - a nuance está no roteamento entre as linhas. Se você apenas mudar 100% do tráfego, não terá esses problemas. Mas se você quiser mudar 2%, você começa a se perguntar: “Como fazer isso?” A coisa mais simples é direta: você pode configurar o Round Robin no nginx por escolha aleatória e terá 2% à esquerda e 98% à direita. Mas isto nem sempre é adequado.
Por exemplo, no nosso caso, um usuário interage com o sistema com mais de uma solicitação. Isso é normal: 2, 3, 4, 5 solicitações - seus sistemas podem ser iguais. E se for importante para você que todas as solicitações do usuário cheguem à mesma linha em que veio a primeira solicitação, ou (segundo ponto) todas as solicitações do usuário cheguem à nova linha após a troca (ele poderia ter começado a trabalhar mais cedo com o sistema, antes da troca), - então esta distribuição aleatória não é adequada para você. Depois, existem as seguintes opções:
A primeira opção, a mais simples, é baseada nos parâmetros básicos do cliente (IP Hash). Você tem um IP e o divide da direita para a esquerda pelo endereço IP. Então o segundo caso que descrevi funcionará para você, quando a implantação ocorrer, o usuário já poderá começar a trabalhar com o seu sistema, e a partir do momento da implantação todas as solicitações irão para uma nova linha (para a mesma, digamos).Se por algum motivo isso não combina com você e você deve enviar solicitações para a linha de onde veio a solicitação inicial do usuário, então você tem duas opções...
Primeira opção: você pode comprar nginx+ pago. Existe um mecanismo de sessões Sticky, que, mediante solicitação inicial do usuário, atribui uma sessão ao usuário e a vincula a um ou outro upstream. Todas as solicitações subsequentes do usuário durante o tempo de vida da sessão serão enviadas para o mesmo upstream onde a sessão foi postada.Isso não nos convinha porque já tínhamos o nginx regular. Mudar para o nginx + não é caro, apenas foi um tanto doloroso para nós e não muito certo. “Sticks Sessions”, por exemplo, não funcionou para nós pela simples razão de que “Sticks Sessions” não permitem roteamento baseado em “Either-or”. Lá você pode especificar o que nós “Sticks Sessions” fazemos, por exemplo, por endereço IP ou por endereço IP e cookies ou por pós-parâmetro, mas “Either-or” é mais complicado aí.
Portanto, chegamos à quarta opção. Tomamos nginx com esteróides (isso é openresty) - este é o mesmo nginx, que também suporta a inclusão dos últimos scripts. Você pode escrever um último script, dar-lhe um “descanso aberto”, e este último script será executado quando a solicitação do usuário chegar.
E nós escrevemos, de fato, tal script, definimos “openresti” e neste script classificamos 6 parâmetros diferentes por concatenação “Or”. Dependendo da presença de um ou outro parâmetro, sabemos que o usuário chegou a uma página ou outra, a uma linha ou outra.
Implantação azul/verde. Vantagens e desvantagens
Claro, provavelmente foi possível torná-lo um pouco mais simples (use as mesmas “Sticky Sessions”), mas também temos uma nuance tal que não apenas o usuário interage conosco no âmbito de um processamento de uma transação... Mas os sistemas de pagamento também interagem conosco: depois de processarmos a transação (enviando uma solicitação ao sistema de pagamento), recebemos um coolback.
E digamos, se dentro do nosso circuito pudermos encaminhar o endereço IP do usuário em todas as solicitações e dividir os usuários com base no endereço IP, então não diremos o mesmo “Visa”: “Cara, somos uma empresa tão retrô, parece ser internacional (no site e na Rússia)... Forneça-nos o endereço IP do usuário em um campo adicional, seu protocolo é padronizado”! É claro que eles não concordarão.
Portanto, isso não funcionou para nós - fizemos openresty. Assim, com o roteamento obtivemos algo assim:A implantação Azul/Verde tem, portanto, as vantagens e desvantagens que mencionei.
Duas desvantagens:
- você precisa se preocupar com o roteamento;
- a segunda principal desvantagem é a despesa.
Você precisa do dobro de servidores, precisa do dobro de recursos operacionais, precisa despender o dobro de esforço para manter todo esse zoológico.
Aliás, entre as vantagens tem mais uma coisa que não mencionei antes: você tem reserva em caso de aumento de carga. Se você tiver um crescimento explosivo na carga, tiver um grande número de usuários, basta incluir a segunda linha na distribuição 50 a 50 - e imediatamente terá servidores x2 em seu cluster até resolver o problema de ter mais servidores.
Como fazer uma implantação rápida?
Conversamos sobre como resolver o problema de minimização e reversão rápida, mas a questão permanece: “Como implantar rapidamente?”
É curto e simples aqui.- Você deve ter um sistema de CD (Entrega Contínua) - você não pode viver sem ele. Se você tiver um servidor, poderá implantar manualmente. Temos cerca de mil e quinhentos servidores e mil e quinhentos identificadores, é claro - podemos plantar um departamento do tamanho desta sala apenas para implantar.
- A implantação deve ser paralela. Se sua implantação for sequencial, tudo estará ruim. Um servidor é normal, você implantará mil e quinhentos servidores o dia todo.
- Novamente, para aceleração, isso provavelmente não será mais necessário. Durante a implantação, o projeto geralmente é construído. Você tem um projeto web, há uma parte front-end (você faz um web pack lá, compila npm - algo assim), e esse processo é, em princípio, de curta duração - 5 minutos, mas esses 5 minutos podem seja crítico. É por isso que, por exemplo, não fazemos isso: removemos esses 5 minutos, implantamos artefatos.
O que é um artefato? Um artefato é uma construção montada na qual todas as peças da montagem já foram concluídas. Armazenamos esse artefato no armazenamento de artefatos. Ao mesmo tempo, usamos dois desses armazenamentos - era Nexus e agora jFrog Artifactory) Inicialmente usamos “Nexus” porque começamos a praticar essa abordagem em aplicativos Java (era adequada). Então eles colocaram alguns dos aplicativos escritos em PHP lá; e “Nexus” não era mais adequado e, portanto, escolhemos o jFrog Artefactory, que pode artefator quase tudo. Chegamos ao ponto em que neste repositório de artefatos armazenamos nossos próprios pacotes binários que coletamos para servidores.
Crescimento explosivo de carga
Conversamos sobre mudar a versão do software. A próxima coisa que temos é um aumento explosivo na carga. Aqui, provavelmente quero dizer que o crescimento explosivo da carga não é exatamente a coisa certa...
Escrevemos um novo sistema - é orientado para o serviço, moderno, bonito, trabalhadores em todos os lugares, filas em todos os lugares, assincronia em todos os lugares. E nesses sistemas, os dados podem fluir através de diferentes fluxos. Para a primeira transação, pode-se usar o 1º, 3º, 10º trabalhador, para a segunda transação - o 2º, 4º, 5º. E hoje, digamos, de manhã você tem um fluxo de dados que usa os três primeiros trabalhadores, e à noite muda drasticamente, e tudo usa os outros três trabalhadores.
E aqui acontece que você precisa de alguma forma dimensionar os trabalhadores, você precisa de alguma forma dimensionar seus serviços, mas ao mesmo tempo evitar o inchaço dos recursos.
Definimos nossos requisitos. Esses requisitos são bastante simples: que haja descoberta de serviços, parametrização – tudo é padrão para construir tais sistemas escaláveis, exceto por um ponto – depreciação de recursos. Dissemos que não estamos preparados para amortizar recursos para que os servidores aqueçam o ar. Pegamos o “Consul”, pegamos o “Nomad”, que administra nossos trabalhadores.Por que isso é um problema para nós? Vamos recuar um pouco. Agora temos cerca de 70 sistemas de pagamento atrás de nós. De manhã o tráfego passa pelo Sberbank, aí o Sberbank caiu, por exemplo, e mudamos para outro sistema de pagamento. Tínhamos 100 trabalhadores antes do Sberbank e depois disso precisamos aumentar drasticamente o número de 100 trabalhadores para outro sistema de pagamento. E é desejável que tudo isso aconteça sem a participação humana. Porque se houver participação humana, deveria haver um engenheiro sentado 24 horas por dia, 7 dias por semana, que só deveria estar fazendo isso, porque essas falhas, quando 70 sistemas estão atrás de você, acontecem regularmente.
Portanto, olhamos para o Nomad, que tem um IP aberto, e escrevemos nosso próprio, Scale-Nomad - ScaleNo, que faz aproximadamente o seguinte: monitora o crescimento da fila e reduz ou aumenta o número de trabalhadores dependendo da dinâmica da fila. Quando fizemos isso, pensamos: “Talvez possamos abrir o código?” Então eles olharam para ela - ela era tão simples quanto dois copeques.
Até agora não abrimos o código-fonte, mas se de repente, após o relatório, depois de perceber que você precisa de tal coisa, você precisa, meus contatos estão no último slide - por favor, escreva para mim. Se houver pelo menos 3-5 pessoas, iremos patrociná-lo.
Como funciona? Vamos dar uma olhada! Olhando para frente: no lado esquerdo está um pedaço do nosso monitoramento: esta é uma linha, no topo está o tempo de processamento do evento, no meio está o número de transações, na parte inferior está o número de trabalhadores.Se você olhar, há uma falha nesta imagem. No gráfico superior, um dos gráficos travou em 45 segundos - um dos sistemas de pagamento caiu. Imediatamente, o tráfego foi trazido em 2 minutos e a fila começou a crescer em outro sistema de pagamento, onde não havia trabalhadores (não utilizamos recursos - pelo contrário, descartamos o recurso corretamente). Não queríamos aquecer - havia um número mínimo, cerca de 5 a 10 trabalhadores, mas eles não conseguiam lidar.
O último gráfico mostra uma “corcunda”, que significa apenas que “Skaleno” dobrou esse valor. E aí, quando o gráfico caiu um pouco, ele reduziu um pouco - o número de trabalhadores foi alterado automaticamente. É assim que essa coisa funciona. Conversamos sobre o ponto número 2 - “Como se livrar rapidamente dos motivos”.
Monitoramento. Como identificar rapidamente o problema?
Agora o primeiro ponto é “Como identificar rapidamente o problema?” Monitoramento! Devemos entender certas coisas rapidamente. Que coisas devemos entender rapidamente?
Três coisas!- Devemos compreender e compreender rapidamente o desempenho dos nossos próprios recursos.
- Devemos compreender rapidamente as falhas e monitorar o desempenho dos sistemas que nos são externos.
- O terceiro ponto é identificar erros lógicos. É quando o sistema está funcionando para você, tudo está normal em todos os indicadores, mas algo dá errado.
Provavelmente não vou contar nada tão legal aqui. Serei o Capitão Óbvio. Procuramos o que havia no mercado. Temos um “zoológico divertido”. Este é o tipo de zoológico que temos agora:
Utilizamos o Zabbix para monitorar hardware, para monitorar os principais indicadores dos servidores. Usamos Okmeter para bancos de dados. Usamos “Grafana” e “Prometheus” para todos os outros indicadores que não se enquadram nos dois primeiros, alguns com “Grafana” e “Prometheus”, e alguns com “Grafana” com “Influx” e Telegraf.Há um ano, queríamos usar o New Relic. Que legal, ele pode fazer tudo. Mas por mais que ela possa fazer tudo, ela é tão cara. Quando chegamos ao volume de 1,5 mil servidores, um fornecedor veio até nós e disse: “Vamos fechar um acordo para o próximo ano”. Olhamos o preço e dissemos não, não faremos isso. Agora estamos abandonando o New Relic, temos cerca de 15 servidores restantes sob monitoramento do New Relic. O preço acabou sendo absolutamente selvagem.
E há uma ferramenta que nós mesmos implementamos - este é o Debugger. No início, chamamos-lhe “Bagger”, mas depois um professor de inglês passou, riu-se loucamente e rebatizou-o de “Debagger”. O que é isso? Esta é uma ferramenta que, de fato, em 15-30 segundos em cada componente, como uma “caixa preta” do sistema, executa testes de desempenho geral do componente.
Por exemplo, se houver uma página externa (página de pagamento), ele simplesmente abre e olha como deveria ficar. Se for processamento, ele envia uma “transação” de teste e garante que essa “transação” chegue. Se se tratar de uma ligação a sistemas de pagamento, disparamos um pedido de teste em conformidade, sempre que possível, e verificamos se está tudo bem connosco.
Quais indicadores são importantes para o monitoramento?
O que monitoramos principalmente? Que indicadores são importantes para nós?
- O tempo de resposta/RPS nas frentes é um indicador muito importante. Ele imediatamente responde que algo está errado com você.
- O número de mensagens processadas em todas as filas.
- Número de trabalhadores.
- Métricas básicas de correção.
O último ponto é a métrica de “negócios”, “negócios”. Se você quiser monitorar a mesma coisa, você precisa definir uma ou duas métricas que sejam os principais indicadores para você. Nossa métrica é o rendimento (esta é a proporção entre o número de transações bem-sucedidas e o fluxo total de transações). Se algo mudar nele em um intervalo de 5-10-15 minutos, significa que temos problemas (se mudar radicalmente).
O que parece para nós é um exemplo de um de nossos conselhos:
No lado esquerdo existem 6 gráficos, isto de acordo com as linhas - o número de trabalhadores e o número de mensagens nas filas. No lado direito – RPS, RTS. Abaixo está a mesma métrica de “negócios”. E na métrica “negócios” podemos ver imediatamente que algo deu errado nos dois gráficos do meio... Este é apenas mais um sistema que está atrás de nós e que caiu.A segunda coisa que tivemos de fazer foi monitorizar a queda dos sistemas de pagamentos externos. Aqui pegamos o OpenTracing - um mecanismo padrão, paradigma que permite rastrear sistemas distribuídos; e mudou um pouco. O paradigma padrão do OpenTracing diz que construímos um rastreamento para cada solicitação individual. Não precisávamos disso e o envolvemos em um resumo, um rastreamento de agregação. Criamos uma ferramenta que nos permite rastrear a velocidade dos sistemas atrás de nós.
O gráfico mostra que um dos sistemas de pagamento começou a responder em 3 segundos - temos problemas. Além disso, essa coisa reagirá quando os problemas começarem, em um intervalo de 20 a 30 segundos.E a terceira classe de erros de monitoramento que existe é o monitoramento lógico.
Para ser sincero, não sabia o que desenhar neste slide, pois já procurávamos há muito tempo no mercado algo que nos agradasse. Não encontramos nada, então tivemos que fazer isso nós mesmos.
O que quero dizer com monitoramento lógico? Bem, imagine: você cria um sistema (por exemplo, um clone do Tinder); você fez isso, lançou. O gerente de sucesso Vasya Pupkin colocou no telefone, viu uma garota lá, gostou dela... e isso não vai para a garota - o mesmo vai para o segurança Mikhalych do mesmo centro de negócios. O gerente desce e se pergunta: “Por que esse segurança Mikhalych sorri tão agradavelmente para ele?”Nessas situações... Para nós essa situação soa um pouco diferente, porque (escrevi) é uma perda de reputação que indiretamente leva a perdas financeiras. Nossa situação é oposta: podemos sofrer perdas financeiras diretas - por exemplo, se conduzimos uma transação como bem-sucedida, mas ela não teve sucesso (ou vice-versa). Tive que escrever minha própria ferramenta que monitorasse o número de transações bem-sucedidas ao longo do tempo usando indicadores de negócios. Não encontrei nada no mercado! Essa é exatamente a ideia que eu queria transmitir. Não há nada no mercado que resolva esse tipo de problema.
Tratava-se de como identificar rapidamente o problema.
Como determinar os motivos da implantação
O terceiro grupo de problemas que resolvemos é depois de identificarmos o problema, depois de nos livrarmos dele, seria bom entender o motivo do desenvolvimento, do teste, e fazer algo a respeito. Conseqüentemente, precisamos investigar, precisamos levantar as toras.
Se estamos falando de logs (o principal motivo são os logs), a maior parte de nossos logs está no ELK Stack - quase todo mundo tem o mesmo. Para alguns, pode não estar no ELK, mas se você gravar logs em gigabytes, mais cedo ou mais tarde chegará ao ELK. Nós os escrevemos em terabytes.
Há um problema aqui. Nós consertamos, corrigimos o erro para o usuário, começamos a desenterrar o que estava lá, subimos no Kibana, inserimos o id da transação lá e pegamos uma palmilha assim (mostra muito). E absolutamente nada está claro neste calçado. Por que? Sim, porque não está claro qual parte pertence a qual trabalhador, qual parte pertence a qual componente. E naquele momento percebemos que precisávamos de rastreamento - o mesmo OpenTracing de que falei.Pensamos nisso há um ano, voltamos nossa atenção para o mercado, e havia duas ferramentas lá - “Zipkin” e “Jaeger”. “Jager” é na verdade um herdeiro ideológico, um sucessor ideológico de “Zipkin”. Tudo é bom no Zipkin, exceto que ele não sabe agregar, não sabe incluir logs no rastreamento, apenas rastreamento de tempo. E “Jager” apoiou isso.
Vimos “Jager”: você pode instrumentar aplicativos, pode escrever em Api (o padrão API para PHP naquela época, porém, não foi aprovado - isso foi há um ano, mas agora já foi aprovado), mas lá não era absolutamente nenhum cliente. “Tudo bem”, pensamos, e escrevemos ao nosso próprio cliente. O que conseguimos? Isto é aproximadamente o que parece:
No Jaeger, spans são criados para cada mensagem. Ou seja, quando um usuário abre o sistema, ele vê um ou dois blocos para cada solicitação recebida (1-2-3 - o número de solicitações recebidas do usuário, o número de blocos). Para facilitar para os usuários, adicionamos tags aos logs e rastreamentos de tempo. Assim, em caso de erro, nosso aplicativo marcará o log com a tag de erro apropriada. Você pode filtrar por tag Error e somente os spans que contenham este bloco com erro serão exibidos. Isto é o que parece se expandirmos o intervalo:
Dentro do vão existe um conjunto de traços. Nesse caso, são três rastreamentos de teste e o terceiro rastreamento nos informa que ocorreu um erro. Ao mesmo tempo, aqui vemos um traço de tempo: temos uma escala de tempo no topo e vemos em que intervalo de tempo este ou aquele log foi registrado.Assim, as coisas correram bem para nós. Escrevemos nossa própria extensão e abrimos o código-fonte. Se você quer trabalhar com tracing, se quer trabalhar com “Jager” em PHP, aí está a nossa extensão, seja bem vinda, como dizem:
Temos essa extensão - é um cliente da API OpenTracing, é feita como extensão php, ou seja, você precisará montá-la e instalá-la no sistema. Há um ano não havia nada diferente. Agora existem outros clientes que são como componentes. Aqui cabe a você: ou você bombeia os componentes com um compositor ou usa a extensão que você escolhe.Padrões corporativos
Conversamos sobre os três mandamentos. O quarto mandamento é padronizar abordagens. Do que se trata? É sobre isso:
Por que a palavra “corporativo” está aqui? Não porque somos uma empresa grande ou burocrática, não! Eu queria usar a palavra “corporativo” aqui no contexto de que cada empresa, cada produto deveria ter seus próprios padrões, inclusive você. Que padrões temos?
- Temos regulamentos de implantação. Não vamos a lugar nenhum sem ele, não podemos. Implantamos cerca de 60 vezes por semana, ou seja, implantamos quase constantemente. Ao mesmo tempo, temos, por exemplo, nos regulamentos de implantação um tabu sobre os destacamentos na sexta-feira - em princípio, não implantamos.
- Exigimos documentação. Nem um único componente novo entra em produção se não houver documentação para ele, mesmo que tenha nascido sob a pena de nossos especialistas em P&D. Exigimos deles instruções de implantação, um mapa de monitoramento e uma descrição aproximada (bem, como os programadores podem escrever) de como esse componente funciona e como solucioná-lo.
- Resolvemos não a causa do problema, mas o problema - o que já disse. É importante para nós proteger o usuário de problemas.
- Temos autorizações. Por exemplo, não consideramos tempo de inatividade se perdermos 2% do tráfego em dois minutos. Basicamente, isso não está incluído em nossas estatísticas. Se for mais percentual ou temporário, já contamos.
- E sempre escrevemos post mortems. Aconteça o que acontecer conosco, qualquer situação em que alguém tenha se comportado de forma anormal na produção será refletida na autópsia. Uma postmortem é um documento no qual você escreve o que aconteceu com você, um momento detalhado, o que você fez para corrigir e (este é um bloco obrigatório!) o que você fará para evitar que isso aconteça no futuro. Isto é obrigatório e necessário para análise posterior.
O que é considerado tempo de inatividade?
A que tudo isso levou?Isto levou ao facto de (tivemos alguns problemas de estabilidade, isto não agradou nem aos clientes nem a nós) nos últimos 6 meses o nosso indicador de estabilidade foi de 99,97. Podemos dizer que isso não é muito. Sim, temos algo pelo que lutar. Desse indicador, cerca de metade é a estabilidade, por assim dizer, não da nossa, mas do firewall do nosso aplicativo web, que está na nossa frente e é usado como um serviço, mas os clientes não se importam com isso.
Aprendemos a dormir à noite. Finalmente! Há seis meses não podíamos. E nesta nota com os resultados, gostaria de fazer uma observação. Ontem à noite houve um relatório maravilhoso sobre o sistema de controle de um reator nuclear. Se as pessoas que escreveram este sistema puderem me ouvir, esqueça o que eu disse sobre “2% não é tempo de inatividade”. Para você, 2% é tempo de inatividade, mesmo que seja de dois minutos!
Isso é tudo! Suas perguntas.
Sobre balanceadores e migração de banco de dados
Pergunta do público (doravante – B): – Boa noite. Muito obrigado por esse relatório administrativo! Uma breve pergunta sobre seus balanceadores. Você mencionou que tem um WAF, ou seja, pelo que entendi, você usa algum tipo de balanceador externo...
EK: – Não, utilizamos nossos serviços como balanceador. Neste caso, o WAF é exclusivamente uma ferramenta de proteção DDoS para nós.
AT: – Você pode dizer algumas palavras sobre balanceadores?
EK: – Como já disse, este é um grupo de servidores em openresty. Agora temos 5 grupos de reserva que respondem exclusivamente... ou seja, um servidor que roda exclusivamente openresty, apenas faz proxy do tráfego. Assim, para entender quanto mantemos: agora temos um fluxo de tráfego regular de várias centenas de megabits. Eles enfrentam, se sentem bem, nem se esforçam.
AT: – Também uma pergunta simples. Aqui está a implantação Azul/Verde. O que você faz, por exemplo, com migrações de banco de dados?
EK: - Boa pergunta! Veja, na implantação Azul/Verde temos filas separadas para cada linha. Ou seja, se estamos falando de filas de eventos que são transmitidas de trabalhador para trabalhador, existem filas separadas para a linha azul e para a linha verde. Se estamos falando do banco de dados em si, então nós deliberadamente o restringimos tanto quanto pudemos, movemos tudo praticamente para filas; no banco de dados armazenamos apenas uma pilha de transações. E nossa pilha de transações é a mesma para todas as linhas. Com o banco de dados neste contexto: não o dividimos em azul e verde, pois ambas as versões do código devem saber o que está acontecendo com a transação.
Amigos, também tenho um pequeno prêmio para estimular vocês: um livro. E eu deveria ser premiado pela melhor pergunta.
AT: - Olá. Obrigado pelo relatório. A questão é esta. Você monitora pagamentos, monitora os serviços com os quais se comunica... Mas como você monitora para que uma pessoa de alguma forma acesse sua página de pagamento, faça um pagamento e o projeto credite dinheiro a ela? Ou seja, como você monitora se o marchante está disponível e aceitou seu callback?
EK: – “Comerciante” para nós neste caso é exatamente o mesmo serviço externo que o sistema de pagamento. Monitoramos a velocidade de resposta do comerciante.
Sobre criptografia de banco de dados
AT: - Olá. Eu tenho uma pergunta um pouco relacionada. Você tem dados confidenciais do PCI DSS. Queria saber como você armazena PANs nas filas para as quais precisa transferir? Você usa alguma criptografia? E isso leva à segunda questão: segundo o PCI DSS, é necessário recriptografar periodicamente o banco de dados em caso de alterações (demissão de administradores, etc.) - o que acontece com a acessibilidade neste caso?
EK: - Pergunta maravilhosa! Primeiramente, não armazenamos PANs em filas. Não temos o direito de armazenar PAN em nenhum lugar de forma clara, em princípio, então usamos um serviço especial (chamamos de “Kademon”) - este é um serviço que faz apenas uma coisa: recebe uma mensagem como entrada e envia uma mensagem criptografada. E armazenamos tudo com esta mensagem criptografada. Conseqüentemente, o comprimento da nossa chave é inferior a um kilobyte, o que é sério e confiável.AT: – Você precisa de 2 kilobytes agora?
EK: – Parece que foi ontem que foram 256... Bom, onde mais?!
Assim, este é o primeiro. E em segundo lugar, a solução que existe suporta o procedimento de reencriptação - existem dois pares de “keks” (chaves), que dão “decks” que encriptam (chave são as chaves, dek são derivados das chaves que encriptam) . E se o procedimento for iniciado (acontece regularmente, de 3 meses a ± alguns), baixamos um novo par de “bolos” e criptografamos novamente os dados. Temos serviços separados que extraem todos os dados e os criptografam de uma nova maneira; Os dados são armazenados próximos ao identificador da chave com a qual são criptografados. Conseqüentemente, assim que criptografarmos os dados com novas chaves, excluímos a chave antiga.
Às vezes os pagamentos precisam ser feitos manualmente...
AT: – Ou seja, se chegou o reembolso de alguma operação, você ainda vai descriptografá-la com a chave antiga?
EK: - Sim.
AT: – Depois mais uma pequena pergunta. Quando ocorre algum tipo de falha, queda ou incidente, é necessário realizar a transação manualmente. Existe tal situação.
EK: - Sim as vezes.
AT: – De onde você tira esses dados? Ou você mesmo vai a este depósito?
EK: – Não, claro, temos algum tipo de sistema de back-office que contém uma interface para nosso suporte. Se não sabemos em que estado se encontra a transação (por exemplo, até que o sistema de pagamento responda com um timeout), não sabemos a priori, ou seja, atribuímos o estado final apenas com total confiança. Neste caso, atribuímos à transação um status especial para processamento manual. Pela manhã do dia seguinte, assim que o suporte recebe a informação de que tais ou tais transações permanecem no sistema de pagamento, ele as processa manualmente nesta interface.
AT: – Tenho algumas perguntas. Uma delas é a continuação da zona PCI DSS: como você registra o circuito deles? Esta questão ocorre porque o desenvolvedor poderia ter colocado qualquer coisa nos logs! Segunda pergunta: como você implementa hotfixes? Usar identificadores no banco de dados é uma opção, mas pode haver hot-fixes gratuitos - qual é o procedimento aí? E a terceira pergunta provavelmente está relacionada ao RTO, RPO. Sua disponibilidade era de 99,97, quase quatro noves, mas pelo que entendi você tem um segundo data center, um terceiro data center e um quinto data center... Como você os sincroniza, replica e tudo mais?EK: - Vamos começar com o primeiro. A primeira pergunta foi sobre logs? Quando escrevemos logs, temos uma camada que mascara todos os dados confidenciais. Ela olha para a máscara e para os campos adicionais. Assim, nossos logs saem com dados já mascarados e um circuito PCI DSS. Esta é uma das tarefas regulares atribuídas ao departamento de testes. Eles são obrigados a verificar cada tarefa, incluindo os logs que escrevem, e esta é uma das tarefas regulares durante as revisões de código, a fim de controlar se o desenvolvedor não escreveu algo. As verificações subsequentes são realizadas regularmente pelo departamento de segurança da informação, cerca de uma vez por semana: os logs do último dia são coletados seletivamente e executados por meio de um scanner-analisador especial dos servidores de teste para verificar tudo.
Sobre hot-fixes. Isso está incluído em nossos regulamentos de implantação. Temos uma cláusula separada sobre hotfixes. Acreditamos que implantamos hotfixes XNUMX horas por dia, quando precisamos. Assim que a versão é montada, assim que ela é executada, assim que temos um artefato, temos um administrador de sistema de plantão em uma ligação do suporte, e ele implanta no momento que for necessário.Cerca de "quatro noves". O número que temos agora foi realmente alcançado e lutamos por isso em outro data center. Agora temos um segundo data center e estamos começando a rotear entre eles, e a questão da replicação entre data centers não é realmente uma questão trivial. Tentamos resolver ao mesmo tempo por meios diferentes: tentamos usar a mesma “Tarântula” - não deu certo para nós, já te conto. Por isso acabamos encomendando os “sens” manualmente. Na verdade, cada aplicativo em nosso sistema executa a sincronização necessária de “mudanças concluídas” entre data centers de forma assíncrona.
AT: – Se você conseguiu um segundo, por que não conseguiu um terceiro? Porque ninguém tem cérebro dividido ainda...
EK: – Mas não temos Split Brain. Devido ao fato de cada aplicação ser acionada por um multimaster, não nos importa a qual centro a solicitação chegou. Estamos preparados para o fato de que se um de nossos data centers falhar (contamos com isso) e no meio de uma solicitação do usuário mudar para o segundo data center, estaremos prontos para perder esse usuário, de fato; mas estas serão unidades, unidades absolutas.
AT: - Boa noite. Obrigado pelo relatório. Você falou sobre o seu depurador, que executa algumas transações de teste em produção. Mas conte-nos sobre transações de teste! Quão profundo isso vai?
EK: – Percorre o ciclo completo de todo o componente. Para um componente, não há diferença entre uma transação de teste e uma transação de produção. Mas do ponto de vista lógico, este é simplesmente um projeto separado no sistema, no qual apenas transações de teste são executadas.
AT: -Onde você corta? Aqui Core enviou...
EK: – Estamos atrás de “Kor” neste caso para transações de teste... Temos algo como roteamento: “Kor” sabe para qual sistema de pagamento enviar - enviamos para um sistema de pagamento falso, que simplesmente emite um sinal http e isso é tudo.
AT: – Diga-me, por favor, seu aplicativo foi escrito em um enorme monólito ou você o dividiu em alguns serviços ou mesmo microsserviços?
EK: – Não temos um monólito, claro, temos uma aplicação orientada a serviços. Brincamos que nosso serviço é feito de monólitos - eles são realmente bem grandes. É difícil chamar isso de microsserviços, mas são serviços nos quais operam trabalhadores de máquinas distribuídas.
Se o serviço no servidor estiver comprometido...
AT: – Então eu tenho a próxima pergunta. Mesmo que fosse um monólito, você ainda disse que tem muitos desses servidores instantâneos, todos eles basicamente processam dados, e a pergunta é: “No caso de comprometimento de um dos servidores instantâneos ou de um aplicativo, qualquer link individual , eles têm algum tipo de controle de acesso? Qual deles pode fazer o quê? Quem devo contatar para obter quais informações?
EK: - Sim definitivamente. Os requisitos de segurança são bastante sérios. Em primeiro lugar, temos movimentos de dados abertos, e os portos são apenas aqueles através dos quais antecipamos antecipadamente o movimento do tráfego. Se um componente se comunicar com o banco de dados (digamos, com Muskul) via 5-4-3-2, apenas 5-4-3-2 estará aberto para ele, e outras portas e outras direções de tráfego não estarão disponíveis. Além disso, você precisa entender que em nossa produção existem cerca de 10 loops de segurança diferentes. E mesmo que o aplicativo tenha sido de alguma forma comprometido, Deus me livre, o invasor não conseguirá acessar o console de gerenciamento do servidor, porque esta é uma zona de segurança de rede diferente.AT: – E neste contexto, o que é mais interessante para mim é que você tem certos contratos com serviços - o que eles podem fazer, através de quais “ações” eles podem entrar em contato entre si... E num fluxo normal, alguns serviços específicos solicitam alguns linha, uma lista de “ações” na outra. Eles não parecem recorrer a outras pessoas em uma situação normal e têm outras áreas de responsabilidade. Caso um deles seja comprometido, será capaz de atrapalhar as “ações” daquele serviço?..
EK: - Eu entendo. Se em uma situação normal com outro servidor a comunicação fosse permitida, então sim. De acordo com o contrato SLA, não monitoramos se você só tem permissão para as 3 primeiras “ações” e não tem permissão para as 4 “ações”. Provavelmente isso é redundante para nós, porque já temos um sistema de proteção de 4 níveis, em princípio, para circuitos. Preferimos defender-nos pelos contornos e não ao nível do interior.
Como funcionam Visa, MasterCard e Sberbank
AT: – Quero esclarecer um ponto sobre a mudança de um usuário de um data center para outro. Pelo que eu sei, Visa e MasterCard operam usando o protocolo binário síncrono 8583, e há combinações aí. E eu queria saber, agora queremos dizer mudar – é diretamente “Visa” e “MasterCard” ou antes dos sistemas de pagamento, antes do processamento?
EK: - Isso é antes das mixagens. Nossos mixes estão localizados no mesmo data center.
AT: – Grosso modo, você tem um ponto de conexão?
EK: – “Visa” e “MasterCard” - sim. Simplesmente porque Visa e MasterCard exigem investimentos bastante sérios em infraestrutura para celebrar contratos separados para obter um segundo par de mixes, por exemplo. Eles ficam reservados dentro de um data center, mas se, Deus me livre, nosso data center, onde há mixagens para conexão com Visa e MasterCard, morrer, então teremos uma conexão com Visa e MasterCard perdida...
AT: – Como podem ser reservados? Eu sei que a Visa permite, em princípio, apenas uma conexão!
EK: – Eles próprios fornecem os equipamentos. De qualquer forma, recebemos equipamentos totalmente redundantes por dentro.
AT: – Então o estande é do Connects Orange?..
EK: - Sim.
AT: – Mas e neste caso: se o seu data center desaparecer, como você pode continuar a usá-lo? Ou o trânsito simplesmente para?
EK: - Não. Neste caso, simplesmente transferiremos o tráfego para outro canal, o que, naturalmente, será mais caro para nós e mais caro para os nossos clientes. Mas o tráfego não passará pela nossa conexão direta com Visa, MasterCard, mas sim pelo Sberbank condicional (muito exagerado).
Peço desculpas imensamente se ofendi os funcionários do Sberbank. Mas de acordo com nossas estatísticas, entre os bancos russos, o Sberbank cai com mais frequência. Não passa um mês sem que algo caia no Sberbank.
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com