Autores: Xiao Gangyi, Zhang Jun, Li Jinglei (Globalization Business Platform Team)

Existem certas diferenças entre os negócios, a tecnologia e a estrutura do comércio eletrônico globalizado e a tecnologia doméstica. Do ponto de vista da garantia de produção de segurança e garantia de qualidade, essas diferenças trouxeram mais desafios. Este artigo compartilhará com você informações relacionadas à produção de segurança e garantia de qualidade experiência.

I. Introdução

Como uma equipe com um rico acúmulo de tecnologia de comércio eletrônico doméstico, ao atender o negócio de comércio eletrônico global, por um lado, herdará naturalmente o sistema de tecnologia de comércio eletrônico doméstico para resolver os problemas comuns dos negócios de comércio eletrônico. Por outro lado, diante das diferenças de negócios, tecnologia, organização, cultura, política e outras dimensões, somos levados a desenvolver sistemas técnicos novos ou mais apropriados. Por exemplo, as características do estágio de desenvolvimento de negócios de comércio eletrônico internacional, as características da infraestrutura no exterior, as características dos negócios internacionais diferentes dos negócios domésticos, características culturais e do usuário e políticas e conformidade mais incontroláveis. No sistema técnico que exploramos há muitos anos, compartilhamos e explicamos a experiência relacionada à tecnologia e arquitetura de desenvolvimento no artigo anterior. Neste artigo, queremos compartilhar outra peça importante no campo técnico, a experiência relacionada à segurança produção e garantia de qualidade.

Antes de compartilhar a experiência técnica, primeiro desmontamos o comércio eletrônico global que atendemos em algumas dimensões-chave, que é também a compreensão de algumas características-chave do comércio eletrônico global ao longo de anos de experiência, e esses entendimentos são cruciais para nossa construção técnica. crucial.

1.1 Diferenças comerciais

Em termos de negócios, o e-commerce globalizado tem principalmente dois tipos básicos: book-to-book e cross-border.

Lazada, uma marca de e-commerce do Sudeste Asiático, é um típico negócio de livro-a-livro no exterior, que realiza principalmente a rápida construção de um sistema de e-commerce que oferece suporte a compradores e vendedores locais em um país ou região estrangeira. Tal modelo determina que a maioria dos comerciantes está localizada em países estrangeiros, a moeda será relativamente única e as capacidades operacionais precisam ser mais localizadas.

A marca de comércio eletrônico transfronteiriço AliExpress é um típico modelo de negócios transfronteiriço. Ele percebe principalmente que os comerciantes chineses podem vender mercadorias para compradores transfronteiriços por meio de nosso sistema sob a vantagem de produtos chineses. Os problemas envolvidos aqui serão bem diferentes . Em termos de idioma, moeda, fuso horário, categoria, atividade, diferença cambial, logística, cadeia de suprimentos, etc., precisamos de diferentes tecnologias para resolver o problema das diferenças. O negócio de comércio eletrônico é composto principalmente de sistema de comércio eletrônico, sistema de pagamento e sistema de logística. Existem certas diferenças entre as implementações técnicas internacionais e domésticas desses três sistemas.

1.2 Diferenças na arquitetura técnica

Em termos de tecnologia e arquitetura, também existem diferenças significativas:

Diferenças na infraestrutura: a maioria dos alvos de serviços de comércio eletrônico no exterior são cross-country, e as instalações de hardware no exterior são diferentes das domésticas. Portanto, sob a premissa de considerar a estabilidade, nosso sistema deve realizar sincronização de dados, reutilização do sistema, conformidade, etc. a um custo menor. Nossas palavras-chave técnicas aqui são implantação de várias unidades, implantação de salas de vários computadores e nuvem nativa. Esses pontos são críticos para a diferença no sistema de qualidade que construímos.

Diferenças na arquitetura do aplicativo: No campo da tecnologia de comércio eletrônico, geralmente construímos uma grande rede de sistemas técnicos por meio de diferentes aplicativos ou microsserviços, e cada aplicativo é dividido de acordo com seu respectivo campo. A diferença entre o comércio eletrônico doméstico é que nossos aplicativos ou serviços precisam considerar sites, ou seja, sites nacionais, e mesmo um servidor atende a vários sites nacionais por meio de vários nomes de domínio ao mesmo tempo. Além disso, em termos de arquitetura de aplicativos, em termos de como a plataforma intermediária ágil pode suportar bons negócios, projetamos a arquitetura de aplicativos do Church & Bazaar, para que a flexibilidade do aplicativo e a relação entre P&D e produção tenham sido qualitativamente melhorou. Ao mesmo tempo, também levanta os requisitos sobre como garantir a qualidade e a estabilidade do sistema.

Diferenças no processo de P&D: China e Taiwan precisam abstrair e fundir a lógica do comércio eletrônico o máximo possível, mas a natureza da diferenciação nacional inevitavelmente levará a um grande número de necessidades de personalização específicas do país e, assim, formará uma organização organizacional mais complexa estrutura, seja uma business-to-business ou uma operação localizada em negócios cross-level. Portanto, nosso sistema será desenvolvido em conjunto com mais engenheiros mais próximos dos usuários de e-commerce. Precisamos obter uma orquestração de aplicativos mais flexível, escrita paralela de código, liberação isolada, agendamento de tráfego e outros recursos. Em um processo de P&D mais flexível e amplo, a dificuldade de controle de qualidade sobe naturalmente para um nível mais alto.

Diferenças no estado de execução: Considerando as características do QPS, etc., no estado de execução, do ponto de vista de custo e desempenho, conseguimos paralelismo multilocatário e isolamento arquitetônico. Isso também determina que o trabalho do nosso sistema em termos de complexidade, testabilidade, solução de problemas, ambiente de teste, automação e construção de dados será mais complicado.

Diferenças na sincronização de dados: Ainda que nosso sistema possa ser reaproveitado por locatários no estado running, em termos de dados, considerando privacidade, segurança, compliance, performance, escalabilidade, etc., estamos fisicamente ou logicamente isolados por site. Em cenários transfronteiriços, para obter acesso rápido a produtos chineses globalmente, é necessário obter recursos de sincronização de dados de segundo nível. Isso traz dificuldade para a estabilidade do sistema e também aumenta a complexidade dos casos de teste.

Algumas dessas diferenças são naturalmente determinadas por atributos de negócios. Alguns são novos problemas que trazemos quando solucionamos tecnicamente problemas de negócios ou de arquitetura. Do ponto de vista da segurança da produção e garantia da qualidade, essas diferenças nos trouxeram mais desafios e oportunidades de inovação tecnológica, que é o cerne de todo o sistema global de tecnologia.

2. Sistema de produção de segurança

2.1 Visão geral da arquitetura de alta disponibilidade global

A disponibilidade do sistema (Availability) foi proposta pela primeira vez no livro Practical Reliability Engineering de Patrick O'Connor.

Dentre eles, o MTTR é o Mean Time To Repair, ou seja, o tempo médio de reparo após uma falha do sistema, indicando a manutenibilidade do sistema. MTBF é o Mean Time Between Failure, ou seja, o tempo médio de não falha, indicando a confiabilidade do sistema.

Portanto, existem duas direções principais para garantir a alta disponibilidade do estado diário do sistema: melhorar o MTBF, aumentar o tempo sem falhas do sistema e melhorar a confiabilidade geral do sistema e a tolerância a falhas, mantendo o modo de estabilidade e a redundância do sistema. E, reduza o MTTR, encurte o tempo necessário para recuperação de falhas, facilite acidentes, mudanças, monitoramento de operação e manutenção, etc., e aumente a capacidade de manutenção do sistema.

Além das duas direções diárias de construção de alta disponibilidade acima, para sistemas de comércio eletrônico de grande escala, como manter alta estabilidade de serviço sob o impacto de picos de inundação durante a grande promoção e como descobrir os gargalos do sistema em relativamente breve estágio de preparação antes da grande promoção e compreender o núcleo geral Os links também são um link que não pode ser ignorado na construção de um sistema de alta disponibilidade.

Portanto, este artigo discutirá a arquitetura global de alta disponibilidade em três áreas:

Construção do sistema de alta disponibilidade
Grande promoção de construção de garantia de estabilidade
Aplicar arquitetura de alta disponibilidade

2.2 Construção do sistema de alta disponibilidade

Atualmente, o padrão comum na indústria para medir alta disponibilidade é 1-5-10,1 minuto para descoberta, 5 minutos para resposta/localização e 10 minutos para recuperação. Na prática anterior, a obtenção de 1-5-10 depende muito da equipe SRE, da familiaridade comercial da equipe, dos métodos de solução de problemas e da proficiência operacional prática. No entanto, à medida que a complexidade do sistema aumenta e as dependências do link se tornam cada vez mais complexas, o 1-5-10 tem requisitos cada vez mais altos para a equipe SRE.

Há uma certa diferença entre falhas de alta disponibilidade e falhas de negócios, e as falhas de alta disponibilidade são universais. Ao redor da falha, podemos armar direcionados. Em seguida, apresentaremos um sistema de falhas de alta disponibilidade construído em torno das definições de falhas na seção de internacionalização.

A seguir, analisaremos o processo de processamento de todo o sistema de alta disponibilidade a partir de uma falha em que a taxa de sucesso das ordens de transação cai. Primeiro, suponha que haja uma definição de falha: a taxa de sucesso do pedido cai 5% por 10 minutos.

2.2.1 Descoberta de um minuto

No caso de descoberta de falha, antigamente, a notificação de falha era emitida após aguardar uma queda de 5% por 10 minutos. A equipe SRE começou a intervir para lidar com o problema.

Quando a taxa de sucesso do pedido cai em 1%, 2% ou cai em 5% por 5 minutos, todos não estão cientes. Queremos adiantar o tempo para responder às falhas. Comece a intervir quando os indicadores do sistema estiverem anormais com antecedência.

Adicionamos um mecanismo de alerta antecipado de risco (mostrado pela linha sólida na Figura 1) após a descoberta da anormalidade dos indicadores do sistema e antes da ocorrência da falha. O alerta de risco é acionado pelo GOC, após o qual a equipe do SRE passa a intervir no tratamento do problema. Dessa forma, é muito provável que o risco seja eliminado quando a falha ocorrer.

Figura 1 Comparação do processo de alerta precoce de risco e o processo de emergência de falha original

2.2.2 Posicionamento de cinco minutos

Quando o problema é descoberto, precisamos localizar a causa o mais rápido possível. As falhas de alta disponibilidade são divididas em duas categorias: mudança e operação.

Para localizar esses dois tipos de falhas, você precisa saber várias informações:

Quais são os sistemas envolvidos na falha e suas dependências?
Qual sistema está causando o erro atual, qual é o sintoma e qual é a causa raiz?
Existe uma mudança relevante na falha: relacionada ao tempo, relacionada ao escopo?

Figura 2 Posicionando produtos em cinco minutos

Nos negócios globais, para aplicativos principais, uma estrutura de log unificada é adotada para coletar informações do aplicativo. As informações coletadas incluem todos os links de chamada RPC, parâmetros de saída principais (código de erro, sucesso) e informações de middleware. Por meio das informações de log coletadas pela estrutura de log, podemos restaurar as informações de topologia de link de todos os aplicativos principais e informações em tempo real, como taxa de sucesso, código de erro e RT da interface.

Quando ocorre um aviso de risco, duas informações principais podem ser conhecidas

Aplicação de entrada
cenário de problema

Através da aplicação de entrada e cenários de problemas, e informações de topologia do link, podemos localizar os nós que podem ter problemas a jusante do link.

Além da coleta de informações de link, também coletamos informações de alteração, incluindo alterações de lançamento, alterações de configuração e alterações operacionais. Ao alterar o algoritmo de correlação no cérebro, a alteração mais relevante para o cenário de falha atual é calculada.

Através do método acima, para ocorrências de alta disponibilidade, uma taxa de precisão de posicionamento de 2 minutos de mais de 90% pode ser alcançada. Após o posicionamento, o próximo passo é considerar como se recuperar.

2.2.3 Recuperação de dez minutos

Do trio 1-5-10, a recuperação de 10 minutos costuma ser a mais difícil.

Para falhas do tipo alteração, a velocidade de reversão das alterações de configuração é relativamente rápida e a reversão pode ser concluída em 10 minutos. Para alterações do tipo de versão, a recuperação de 10 minutos é difícil devido ao tempo de inicialização do aplicativo envolvido. De acordo com a situação no processo de liberação, estabeleça a capacidade de corte de fluxo de grão fino, que pode cortar o fluxo de máquinas problemáticas (máquinas liberadas). Mas para a situação que foi lançada, ainda se baseia na reversão completa do aplicativo.

2.3 Promoção da Construção da Garantia de Estabilidade

A grande promoção é o projeto que mais investe mão-de-obra todos os anos. Só para garantir a estabilidade da grande promoção, muitas vezes requer o investimento de milhares de pessoas-dia. Isso inclui vários projetos especiais de combinação e vários testes de estresse de link completo. Além disso, os recursos da máquina também atingiram o valor máximo a cada ano. No caso de garantir a estabilidade da grande promoção, como reduzir o custo de pessoal e hardware tornou-se a principal proposição da garantia da grande promoção.

2.3.1 Garantir a estabilidade da grande promoção e criar a certeza da grande promoção

Durante o processo de preparação, o mais crítico é o teste de estresse. O teste de pressão é dividido em várias etapas principais: avaliação de fluxo, aplicação de pressão e revisão do teste de pressão.

Para avaliação de tráfego, carregamos todo o processo e dados de avaliação de tráfego para o sistema. Depois de confirmar os principais indicadores na grande promoção, inseriremos os principais indicadores no sistema e o valor do tráfego de cada link principal será obtido A garantia de acompanhamento será baseada nisso. Os valores de fluxo são usados para preparar os recursos de hardware. Os alunos de desenvolvimento de cada domínio de negócios precisam apenas manter continuamente as fórmulas de cálculo dos indicadores-chave e do tráfego de entrada do sistema.

Nos testes de pressão anteriores, frequentemente havia problemas de baixa pressão e vazamento de pressão, resultando em fluxo anormal no pico da grande promoção. Esses fluxos anormais também causaram a falha do P1. Portanto, durante o processo de aplicação de pressão, coletamos os principais indicadores de tráfego e desempenho do sistema, comparamos com os resultados da avaliação de tráfego acima e descobrimos que o tráfego não atendia aos links esperados. Elimine o risco aumentando o fluxo ou aumentando a pressão. Além disso, através do motor de topologia do link, é realizada a comparação entre o tráfego diário e o tráfego de pressão para encontrar links que possam vazar pressão.

Através deste método, descobrimos muitos casos de baixa pressão e vazamento, o que garantiu a autenticidade do teste de pressão e garantiu a estabilidade da grande promoção.

2.3.2 Redução de custos e melhoria da eficiência

2.3.2.1 Custo de hardware

Grandes promoções costumam ter um recurso, ciclo curto e grande tráfego. No caso de teste sem estresse e pico de promoção não grande, os recursos de hardware não precisam tanto. Portanto, consideramos que da pressão ao link, temos a capacidade de expandir e contrair automaticamente a capacidade, reduzindo muito os recursos de contêineres que utilizamos.

Teste de pressão: Antes do início do teste de pressão, expanda a máquina de pressão e o recipiente comercial. Após o término do teste de pressão, encolha a máquina de pressão e o recipiente comercial.

Grande dia de promoção: A capacidade será expandida durante o período de grande promoção e a capacidade será reduzida durante o período de não grande promoção. Desta forma, podemos reduzir os recursos de contêineres em 50%.

Figura 3 Teste de estresse automatizado

2.3.2.2 Envelhecimento da mão de obra

A preparação para a promoção global envolve vários países e vários fusos horários. Para cada item especial de preparação para a promoção, basicamente revisamos sistematicamente o conteúdo da preparação. Exceto pelo trabalho de revisão, a maior parte pode ser feita no sistema. Isso reduz muito o trabalho de colaboração e integração de dados de todos. A pessoa encarregada da grande promoção também pode aprender sobre o andamento e os riscos dos preparativos atuais da grande promoção no sistema. Combinado com ferramentas automatizadas, como testes de estresse automatizados e valores autônomos, o investimento em pessoal é bastante reduzido.

Nas últimas grandes promoções, o número de pessoas aplicando pressão foi reduzido em 80% e a participação da equipe do projeto de garantia de grandes promoções foi reduzida em 30%.

Figura 4 Grande Bancada de Promoção

2.4 Arquitetura de Alta Disponibilidade do Sistema

Os capítulos acima descrevem as considerações de alta disponibilidade para falhas e preparações para grandes promoções. O próximo passo é principalmente a arquitetura de alta disponibilidade do sistema. A alta disponibilidade de cada sistema é a base para a alta disponibilidade de todo o negócio. A equipe SRE não consegue entender completamente cada sistema. Como garantir que todos os sistemas tenham os mesmos e altos padrões é a direção que precisamos considerar.

Aqui apresentamos um sistema de medição altamente disponível. A avaliação quantitativa é realizada para a confiabilidade, alto rendimento, supervisão e tolerância a falhas do sistema. Para cada pontuação, fornecemos estratégias e métodos de otimização sugeridos. Os alunos de cada sistema de negócios podem otimizar o sistema de maneira direcionada. E a equipe SRE também tem uma posição operacional. Ao melhorar continuamente o sistema de medição e adicionar indicadores, o responsável pelo sistema pode ser constantemente direcionado para otimizar a governança.

Figura 5 Sistema de medição de alta disponibilidade

As estatísticas desses indicadores geralmente são baseadas em dados online para estatísticas pós-evento. A qualidade de cada mudança ainda precisa ser garantida pela equipe técnica de qualidade. O sistema de produção de segurança é a proteção secundária construída no sistema de qualidade técnica.A produção de segurança é a mudança certa do sistema de qualidade, e o sistema de qualidade é a base da produção de segurança. Para garantir a estabilidade do sistema e dos negócios, também fizemos os mesmos esforços e explorações no sistema de garantia de qualidade.

3. Sistema de Garantia de Qualidade

A garantia de qualidade do sistema global de comércio eletrônico deve primeiro resolver os problemas de qualidade dos negócios de comércio eletrônico. É necessário construir diferentes sistemas de qualidade em diferentes links de comércio eletrônico para resolver os problemas mais críticos em vários campos. Ao mesmo tempo, levando em consideração as diferenças comerciais e técnicas entre o comércio eletrônico internacional e o comércio eletrônico doméstico, também haverá diferenças nos sistemas de qualidade ou métodos de implementação. por exemplo:

O número de aplicativos de site que aparecem devido a vários sites é relativamente maior. O código do kernel responsável pelo centro de negócios precisa ser executado simultaneamente em cada aplicativo de site de cada empresa. Como testar e cobrir com eficiência e como medir com precisão a taxa de cobertura.

Como o qps online é relativamente baixo, a proporção de ambiente de teste/ambiente oficial será significativamente maior e o custo do teste aumentará bastante. Ao mesmo tempo, vários negócios terão mais iterações paralelas devido a operações paralelas, o que aumentará significativamente o número de ambientes de teste necessários e exacerbará o problema de consumo excessivo de recursos de teste para o objeto testado. Como construir um sistema de ambiente de teste pode reduzir significativamente o custo do ambiente enquanto oferece suporte a iterações de negócios paralelas com mais eficiência.

Através de anos de iterações técnicas e várias campanhas de reconstrução técnica em larga escala no sistema global de comércio eletrônico, ao mesmo tempo em que oferece suporte a atualizações de negócios e tecnologia, ela resolveu muitos problemas e iterou continuamente o sistema de garantia de qualidade. Construímos recursos eficientes de automação e integração contínua, construímos uma tecnologia de ambiente de teste e um sistema operacional mais eficientes e transformamos a prevenção e o controle de perda de ativos de um único ponto para um sistema de cobertura de longo prazo que pode ser deslocado para a esquerda e para a direita. um processo padrão de P&D e ferramentas de suporte para medir e operar capacidades. Esses esforços são claramente refletidos na melhoria da tecnologia e eficiência.Ao mesmo tempo, os recursos de teste em vários campos são comercializados através da plataforma de qualidade e serviços amigáveis são fornecidos a outras equipes de negócios.

3.1 Sistema de automação

O desafio da automação predial

Implantação global e conformidade legal

No artigo anterior, apresentei os desafios da infraestrutura de internacionalização, e os testes automatizados também enfrentam os mesmos desafios. Devido às características da implantação global do objeto testado, juntamente com as restrições das leis e regulamentos de vários países, como a proibição de exportação e entrada de dados, a exibição de casos de teste e dados de teste e a operação e manutenção de casos de teste são demandas muito básicas. estão enfrentando grandes desafios.

arquitetura de código aberto

A última geração de arquitetura internacional realiza o loop fechado e a iteração independente do negócio (camada bazar) e da plataforma intermediária (camada igreja), o que significa que ela precisa ser capaz de testar de forma independente. O teste de interface tradicional testa apenas o aplicativo completo. O teste independente de mercado de camadas e camadas de igreja requer uma granularidade mais fina de testes automatizados e também requer que o foco dos testes automatizados mude da automação de caixa preta para a automação de caixa cinza.

3.1.1 Prática de Automação

Projetamos o sistema de automação de acordo com a teoria clássica de teste em camadas e aplicamos a tecnologia de reprodução de fluxo a vários links no teste em camadas, incluindo geração de teste de unidade, geração de teste de módulo, teste de interface, casos de teste de link e fornecemos casos de teste para os dados apoiar.

Figura 6 Pirâmide de teste hierárquico

3.1.1.1 Teste de unidade

O teste de unidade é o método preferido dos engenheiros de desenvolvimento para garantir a qualidade, mas ainda existem vários problemas que precisam ser resolvidos.

Os aplicativos antigos existentes carecem de base de teste de unidade e precisam ser complementados rapidamente;
É difícil construir dados de teste para sistemas complexos e são necessárias ferramentas de suporte;
A refatoração do sistema pode levar à falha em massa de testes de unidade, exigindo correções rápidas a baixo custo.

Para o código de estoque do sistema antigo, um caso de teste de unidade completo é construído diretamente através do fluxo, e o caso de teste de unidade do código de estoque é concluído rapidamente.

Para novas funções, geramos rapidamente o "esqueleto" básico do caso de teste de unidade por meio de análise estática, e o engenheiro de desenvolvimento pode concluir rapidamente um caso de teste de unidade após complementar os dados de teste.

Para cenários de reconstrução do sistema, os casos de teste de unidade são regenerados em lotes por meio de análise estática e reaquisição de tráfego, para que os testes de unidade possam se tornar ativos de substituição sustentáveis e evitar que se tornem um fardo para os engenheiros de desenvolvimento.

3.1.1.2 Teste de Interface

Negócios internacionalizados envolvem recursos multilocatários e multilocais. O custo de manutenção e gerenciamento de casos de uso aumentará significativamente com a expansão horizontal dos negócios. Portanto, coleta de casos de uso, manutenção e gerenciamento de casos de uso mais eficientes são necessários.

Na coleta de casos de uso, a estratégia de análise automática de recursos e desduplicação é adotada. No caso de ninguém envolvido, o conjunto de casos de uso pode ser depositado automaticamente e, em seguida, a experiência do especialista pode ser inserida manualmente para melhorar a riqueza de recursos e a cobertura de casos de uso.

Em termos de gerenciamento de casos de uso, a função tradicional de gerenciamento de conjuntos de casos de uso relativamente complexos é enfraquecida e a manutenção do caso de uso é realizada de maneira de hospedagem do sistema, e o caso de uso é agendado automaticamente de acordo com multilocatário, conformidade e outras condições durante a execução, garantindo precisão e reduzindo custos de intervenção manual.

Nos resultados da reprodução, por meio da análise agregada de deslocamentos e asserções, o número de classificações de falha é efetivamente reduzido, o custo da solução manual de problemas é reduzido e os resultados da medição de cobertura de código e cobertura de negócios são fornecidos após a execução.

Figura 8 Diagrama esquemático do princípio de teste de interface

3.1.1.3 Teste do Módulo

Para engenheiros de desenvolvimento, além dos testes de unidade, há uma forte demanda por testes de integração em pequena escala de um único cenário de negócios. Portanto, propomos um novo método de teste - teste de módulo. A granularidade do teste de módulo está entre o teste de unidade e o teste de interface, e testa principalmente os módulos com lógica relativamente coesa.

Figura 9 Comparação do escopo de teste entre teste de módulo, teste de unidade e teste de interface

A ideia do teste de módulo é executar o caso de teste diretamente na aplicação, podendo acessar os recursos e instâncias na aplicação durante o processo de execução do caso de teste, que é mais simples e real, mas o caso de teste ainda é um JUnit caso de uso, que é consistente com o teste de unidade.

Toda a solução usa a tecnologia JavaAgent para realizar a comunicação em tempo real entre o caso de teste e o aplicativo em teste, o que garante que a modificação do caso de teste entre em vigor imediatamente e realize o teste imediatamente após a modificação.

Tabela 1 Comparação das características de teste de módulo, teste de unidade e teste de interface

O teste de módulo não apenas resolve o problema de teste de integração em pequena escala para engenheiros de desenvolvimento, mas também atende aos requisitos de teste independente da camada de mercado e da camada de igreja sob a arquitetura internacional de código aberto.

3.1.1.4 Assistência em P&D

Além do teste em camadas, para melhorar a eficiência do autoteste de P&D e antecipar a garantia de qualidade, fornecemos aos engenheiros de desenvolvimento ferramentas auxiliares de autoteste, incluindo recursos de teste de interface local antes do teste e recursos de depuração conjunta independente local.

Autoteste de interface

O autoteste da interface geralmente é realizado após a conclusão do teste de unidade e do teste de função do módulo. A estratégia é reutilizar a capacidade de teste da interface, fornecer um conjunto completo de processo de autoteste e funções relacionadas para P&D no IDE e vincular para a ramificação do código atual (mudança) , para que os engenheiros de desenvolvimento possam concluir rapidamente o teste em seu ambiente de codificação.

Figura 10 Processo de autoteste da interface

depuração conjunta local

A depuração conjunta é o último elo do autoteste de P&D, e também é um elo onde upstream e downstream são altamente acoplados, interdependentes e ineficientes. Para melhorar a eficiência da depuração conjunta, implementamos um conjunto de soluções locais de autoteste e depuração conjunta. A ideia é que o upstream e o downstream que participam da depuração conjunta compartilhem o mesmo caso de uso de link e modifiquem os dados correspondentes para a parte dependente de acordo com o contrato de interface, para que todos os engenheiros de desenvolvimento que participam da depuração conjunta possam concluir a depuração conjunta contando apenas com o caso de uso do link, realizando um desacoplamento completo.

Figura 11 Princípio de depuração conjunta local

3.1.2 Sistema de medição

3.1.2.1 Cobertura do código

A cobertura de código é um dos meios eficazes de medição de teste, mas a cobertura de código completa geralmente tem uma base enorme, o que não é propício para um gerenciamento fino. No processo de iteração diária, a cobertura de código incremental é mais intuitiva e você pode executar um gerenciamento de cobertura refinado para cada alteração de código e melhorar continuamente a cobertura de código.

Figura 12 Princípio da cobertura de código incremental

3.1.2.2 Análise da superfície de influência

Medir o risco também é uma parte importante do sistema de medição, e a análise da superfície de impacto pode ajudar os engenheiros de P&D a avaliar com mais precisão o impacto geral de cada mudança de função. Ao modelar o relacionamento de chamada de função no tráfego de coleta do ambiente de produção, forma-se um "grafo" contendo o relacionamento entre todas as funções. Através deste "grafo", pode-se analisar o upstream caller de cada função, ou seja, a função afetada.

A análise da superfície de impacto pode não apenas avaliar o impacto das mudanças de função em sistemas distribuídos, mas também ajudar os engenheiros de desenvolvimento de nível de igreja a avaliar com precisão o impacto de mudanças de nível de igreja no mercado em uma arquitetura internacional de código aberto.

Figura 13 Diagrama esquemático do princípio da análise da superfície de influência

3.1.3 Integração Contínua para Casos de Uso de Automação

3.1.3.1 O que é integração contínua para casos de uso de automação?

A diferença entre a integração contínua tradicional é o conceito do objeto em teste, e a integração contínua de casos de uso automatizados é uma inovação para resolver o problema de corrupção de casos de uso automatizados. A reprodução contínua é executada com a principal unidade de implantação de intervenção como a menor unidade de reprodução, o que reduz o ruído de execução e refina o estado de execução do caso de uso e fornece recursos de quantificação mais amigáveis, incluindo taxa de passagem do caso de uso, taxa de cobertura da interface, cobertura de código taxa e taxa de cobertura de negócios, etc., para ajudar os casos de uso a continuarem iterando.

3.1.3.2 Solução e Implementação

A fim de melhorar a versatilidade e escalabilidade, usamos funções de produto para realizar a produção, consumo e anticorrosão dos casos de uso, substituindo a manutenção manual. A plataforma de integração contínua suporta acesso a aplicativos, gerenciamento de coleta de casos de uso e configuração de execução de tempo.

Figura 14 Integração contínua automatizada

A plataforma de integração contínua é dividida principalmente em 4 módulos:

Gerenciamento de casos de uso: oferece suporte a várias plataformas de casos de uso de automação dentro do grupo
Reprodução precisa: defina a origem dos casos de uso e melhore a precisão do gerenciamento dos casos de uso
Anticorrosão de casos de uso: realize anticorrosão oportuna de casos de uso por meio de regras configuráveis, controle ambiental e alarmes em tempo real
Medição de resultados: fornece relatório de cobertura multidimensional, mais eficaz e conveniente para ajudar na iteração de casos de uso

3.1.3.3 Efeito

Você pode observar com facilidade e clareza os resultados da execução do caso de uso e várias taxas de cobertura dos principais objetos medidos nos últimos 20 dias e também dar outras sugestões de otimização.

Figura 15 Efeito de integração contínua

3.2 Ambiente de teste

3.2.1 Problemas do ambiente de teste

Problemas de eficiência de teste: a estabilidade do ambiente de teste afetará seriamente a eficiência dos testes upstream e downstream;
Problemas de recursos do ambiente de teste: a simultaneidade durante os períodos de pico de demanda envolve a preempção de ambientes de teste; durante os períodos de baixo pico de demanda, os ambientes de teste redundantes são deixados ociosos;
Problema de isolamento do ambiente de teste: os requisitos nos subdomínios precisam ser isolados uns dos outros; suporte rápido para depuração conjunta entre subdomínios;
Custo de uso do ambiente de teste: custo de perguntas e respostas do ambiente de teste e custo de construção;

3.2.2 Dificuldades no ambiente de teste

O isolamento do ambiente de teste suporta serviço de interface/HTTP síncrono e isolamento de mensagem assíncrona;
Os recursos do ambiente de teste são ocupados de forma flexível de acordo com a demanda e, ao mesmo tempo, o problema de expansão do ambiente de pré-lançamento também deve ser controlado;
Perguntas e respostas sobre o ambiente de teste: Problemas de negócios e problemas de sistema são frequentemente relatados como problemas ambientais, o que leva a uma solução de problemas demorada.Como localizar rapidamente o problema?

3.2.3 Esquema do ambiente de teste

3.2.3.1 Plano de controle do ambiente de teste

Plano: tronco e construção de pré-lançamento do projeto; anticorrosão e controle ambiental; construção de ferramentas de investigação de problemas ambientais

Ambiente off-line: gerenciar e controlar mudanças relacionadas a BD, Tair e fundos, e outras necessidades não estão dentro do escopo de controle;

Ambiente de pré-lançamento: O ambiente de pré-lançamento do projeto é introduzido para suportar as mudanças de demanda diária. O ambiente de pré-lançamento do projeto não tem controle e pode ser construído imediatamente após o uso. Os recursos são liberados após a liberação ou encerramento das alterações. O ambiente de pré-lançamento do projeto é isolado pelo rótulo do ambiente, e depende de outras aplicações, e não está na lista de mudanças, e o mestre de roteamento libera o ambiente.

Fase de lançamento: A fase de lançamento inclui dois tipos de situações, uma após a conclusão do teste, implantação de produção e após a implantação do ambiente de backbone de pré-lançamento, é realizada a verificação de regressão funcional. A segunda é a aceitação do UAT de negócios. O ambiente de desenvolvimento da intervenção principal é implantado com base nas alterações do UAT; desenvolvimento da intervenção principal: adicionar regressão de função e controle de acesso do caso de teste (desenvolvimento da intervenção principal refere-se a um ambiente consistente com a versão do código do ambiente de produção , e é usado para fornecer um upload estável. ambiente dependente de downstream)

Figura 16 O reverso de uma mudança no ambiente de teste

3.2.3.2 Plano de isolamento do ambiente de pré-lançamento do projeto

Processo de encaminhamento de fluxo:

1) A solicitação HTTP do usuário entra na camada de acesso, e a camada de rede do grupo encaminha o tráfego para o ambiente principal de intervenção;

2) O ambiente principal de pré-lançamento marcará o tráfego como o identificador de roteamento de tráfego do ambiente de pré-lançamento do projeto;

3) Retornar ao ambiente de pré-lançamento do projeto-alvo através do serviço de agendamento de tráfego e encaminhá-lo para o ambiente de pré-lançamento do projeto-alvo pelo ambiente de lançamento da intervenção principal.

Esquema de isolamento de tráfego:

1) Isolamento de projetos de subdomínio: O isolamento é realizado por meio do padrão de ambiente de tráfego, e os requisitos não afetam uns aos outros, incluindo mensagens e serviços de interface;

2) Requisitos de depuração conjunta de vários domínios: O ambiente de pré-lançamento do projeto pode ser adicionado à depuração conjunta com um clique, e os aplicativos envolvidos na alteração serão atribuídos a um ambiente de depuração conjunta de pré-lançamento. ID chamam uns aos outros para apoiar o teste de depuração conjunta.

Figura 17 Isolamento do ambiente de pré-lançamento do projeto

3.2.3.3 Anticorrosão ambiental e solução de problemas

Objetivo: Tomar medidas como monitoramento do ambiente de pré-lançamento, pré-lançamento do projeto e backbone off-line para garantir a disponibilidade do ambiente, descobrir e tratar a corrupção ambiental.

Estratégia: Descubra ativamente anomalias ambientais por meio da disponibilidade do serviço e monitoramento da correção do negócio.

Figura 18 Estabilidade Ambiental

Atualmente, vários itens de governança, como "anormalidade do serviço HSF" e "saúde do negócio fora do padrão", foram acumulados para monitorar e medir se o ambiente é corrupto.

Conforme mencionado acima, o atual esquema de isolamento de tráfego da plataforma de negócios adota o esquema geral de isolamento de tráfego do grupo, que tem as seguintes vantagens:

Garantir que diferentes requisitos serão testados ao mesmo tempo sem interferir entre si;
Desenvolva autotestes para corrigir bugs e isolar o ambiente de teste para garantir desenvolvimento e teste eficientes.

No entanto, os seguintes problemas podem ser encontrados durante o uso:

Isolar exceções de serviço do ambiente, fazendo com que o tráfego seja encaminhado para a intervenção principal;
Não há implantação ponto a ponto dentro e fora da nuvem e o tráfego do usuário é roteado para a intervenção principal.

Os danos causados pela falha de isolamento incluem testes perdidos causados por erros de ramificação de teste, portanto, é necessário confirmar se o isolamento do ambiente é válido durante o processo de teste. Para aplicativos de link longo, a solução de problemas é mais problemática. Com base nisso, também fornecemos uma ferramenta de solução de problemas de link, que pode consultar e analisar todo o ambiente de aplicativos e informações da máquina que passaram de acordo com a ID da solicitação, ajudando os alunos de teste de negócios a solucionar problemas ambientais rapidamente, e o efeito é muito bom em combate real.

3.3 Plataforma de ferramentas de qualidade

3.3.1 Problemas

Para reduzir a carga de trabalho repetitiva e melhorar a capacidade de transferência da experiência dos especialistas em teste, muitas equipes de teste criarão portais para ferramentas de desempenho, como ferramentas de construção de dados e ferramentas de medição. Mas o problema mais profundo da construção de ferramentas é como continuar operando e iterando corretamente.

A enorme equipe de negócios tem uma longa história, resultando em ferramentas dispersas, links front-end e back-end complexos e nenhuma mentalidade de marca unificada.
Não há planejamento geral entre as ferramentas, há recursos de ferramentas ausentes e sobrepostos e a repetição de rodas é desenfreada.
O desenvolvimento e manutenção de novas ferramentas de teste em vários campos é caro e hostil para iniciantes.
Na atualização do sistema devops P&D, nativo da nuvem e outras arquiteturas, é difícil integrar e atualizar ferramentas de qualidade simultaneamente.
Não há índice de medição unificado para o efeito da ferramenta, o que dificulta a operação e a iteração.

3.3.2 Arquitetura e Design

Figura 19 Projeto de plataforma de ferramenta de qualidade

Figura 20 Esquema da plataforma da ferramenta de qualidade

3.3.3 Efeito

Unificou o produto e a arquitetura técnica de várias ferramentas de teste de campo espalhadas para melhorar os recursos de operação sustentável;
Fornecer mais de 10 tipos de recursos de teste de plataforma para o mundo exterior e realizar atualizações 2.0, incluindo automação, ambiente, segurança de fundos, contas de teste, ferramentas abertas, etc.;
A plataforma atende mais de 8 diferentes departamentos de negócios, com média diária de UV>100 e média diária de PV>1000.

3.3.4 Um caso de incubação de plataforma de qualidade: reconhecimento de recursos e medição de negócios

A atualização da plataforma de qualidade não só atingiu o objetivo de melhorar as capacidades das ferramentas existentes, mas também contribuiu para o surgimento de muitas novas ferramentas, esclarecendo a relação entre vários produtos e redefinindo novos problemas. Entre eles, a ferramenta de medição de negócios implementada com a ajuda da atualização do sistema de etiquetas é um exemplo típico. Para testadores experientes, a cobertura incompleta do caso de teste é um problema inevitável. Diferente da cobertura de código, nosso objetivo de aprimorar as ferramentas de medição de negócios é medir a cobertura efetiva da força de uma perspectiva mais objetiva e real.

ponto de dor de negócios

Muitos casos de uso: A automação de vários aplicativos no comércio eletrônico internacional é baseada principalmente em casos de uso de coleta de tráfego e precipitação, e os casos de uso de um único aplicativo variam de milhares a centenas de milhares.

Muitos cenários: Os cenários de negócios do link do consumidor são complexos e é difícil classificar os cenários. Os cenários em diferentes domínios são classificados de maneiras diferentes.
Cobertura insuficiente dos cenários existentes: Embora existam muitos casos de uso, a cobertura dos cenários é insuficiente. Tomando como exemplo as transações, apenas os links do backbone podem ser cobertos, e alguns cenários especiais são fáceis de perder.
As atualizações de cobertura de cenário não são oportunas: novas funções adicionam novos cenários e os casos de uso não são atualizados a tempo, e a cobertura dos cenários correspondentes geralmente é perdida.
Impossível de medir: Não há calibre de cálculo de cobertura quando o projeto é entregue, é difícil avaliar os resultados da cobertura e o padrão de lançamento depende apenas da experiência humana

ideias de design

Figura 21 Identificação de recurso de caso de teste e esquema de medição de negócios

Para uma coleta mais abrangente de tráfego online, por meio de análise de algoritmo e uma pequena quantidade de participação manual, a aquisição automática de etiquetas comerciais de aplicativo único pode ser alcançada, melhorando a precisão da aquisição e reduzindo os custos de manutenção de etiquetas. Por meio de coloração de tráfego e outros recursos de análise de dados, o relacionamento da cadeia de tags é analisado e gerenciado on-line, para que cenários de negócios completos possam ser analisados. Obviamente, esse processo requer várias iterações para reduzir o ruído de alguns parâmetros especiais, e o objeto medido precisa sincronizar e manter os cenários de negócios em escala real que foram produzidos durante a iteração contínua. No momento, implementamos alguns aplicativos principais, complementando efetivamente um grande número de casos de teste descobertos.

3.4 Prevenção e Controle de Perda de Ativos

Falha de segurança de fundos refere-se à falha de perda de fundos on-line causada por motivos técnicos (incluindo defeitos de codificação, execução de alterações, brechas de design do sistema, brechas de segurança, etc.). Os cenários de perda de ativos são divididos nas duas categorias a seguir de acordo com o objeto da perda de ativos

Mais plataformas: Compradores, vendedores, plataformas, fornecedores, parceiros etc. a plataforma ou pela plataforma. Fluxo de saída/capital/dinheiro, etc.
Subcobrança pela plataforma: subcobrança de contas a receber, como comissões de plataforma e fretes ou diminuição de receita.

A tecnologia de comércio eletrônico internacional atende a vários negócios e estações nacionais, e a estrutura de implantação e o modo de operação aumentaram a dificuldade de prevenção e controle de perda de ativos, como o risco de atraso na sincronização de dados sob a estrutura de implantação de várias unidades e a complexidade de cálculos de várias moedas no modo internacional. Conversão de taxa de câmbio, questões de conformidade fiscal e tributária, vários fusos horários, vários idiomas, etc. Garantimos principalmente que o risco geral de perda de ativos seja controlável por meio de investimento contínuo em três aspectos: análise de cenário de perda de ativos, monitoramento de redução de ruído e regras de monitoramento inteligentes.

3.4.1 Análise do Cenário de Perda de Ativos

Divisão de negócios: Para módulos de negócios com riscos de perda de capital, como pedidos de transação, dedução de estoque, congelamentos de marketing, etc. Geralmente, envolve classificação de negócios, classificação de risco técnico, classificação de dependência forte e fraca, etc.
Consistência com o upstream: Verifique a consistência das requisições transferidas para esta aplicação, ou das mensagens que esta aplicação necessita consumir.
Consistência com downstream: Verifique a consistência do aplicativo transferido por este aplicativo ou o consumidor da mensagem enviada por este aplicativo.

3.4.2 Monitoramento de Perda de Ativos e Redução de Ruído

O monitoramento em si é ineficaz se tiver muito ruído. Especialmente no campo de monitoramento de perda de ativos, se não houver controle, o volume do alarme geralmente fica no nível de 10W/dia. Atualmente, unificamos as regras de monitoramento e verificação de todos os sites, como plataformas de comércio eletrônico, LAZADA e AE no mercado de segurança de fundos, e realizamos lógica contínua e script de alarme anticorrosão para um grande número de reconciliações existentes scripts.

Figura 22 Mercado de monitoramento de segurança de fundos

3.4.3 Regras de monitoramento inteligente

Atualmente, as principais ferramentas de monitoramento de perda de capital exigem participação manual na redação e depuração do script. No comércio eletrônico internacional, onde a expansão do site e dos negócios é normal, o custo marginal é alto; portanto, é necessária uma geração de script de verificação de segurança de capital completa e de baixo custo .maneira de reduzir custos de insumos tecnológicos. Com base no nível de campo do fluxo, analisamos o grau de correlação algoritmicamente e geramos automaticamente as regras de segurança do fundo.

Diagrama de arquitetura do produto:

Figura 23 Geração de regra de monitoramento de segurança de fundos

Entre eles, o módulo de algoritmo usa o conjunto de dados gerado pelo módulo de análise de tráfego para analisar o algoritmo, incluindo processamento de dados, análise de relacionamento de campo, análise de relacionamento condicional e processamento de resultados . O fluxograma geral é o seguinte:

Figura 24 Julgamento de correlação de campo

Por meio da análise e agregação de dados acima, a saída do módulo de algoritmo é a relação entre campos + confiabilidade , que é usada pelo módulo de geração de regras de monitoramento para gerar itens de monitoramento automática ou manualmente.

3.5 SOP do processo de P&D

3.5.1 Pontos problemáticos existentes no processo de P&D

De acordo com a pesquisa, antes de não haver SOP, havia muitos pontos problemáticos no processo de P&D, entre os quais os principais pontos problemáticos são os seguintes:

A revisão/revisão técnica/teste de requisitos são todas operações off-line e os dados on-line estão ausentes;

O ambiente de pré-lançamento é instável e o ambiente de P&D e o ambiente de teste interferem um no outro;

O momento do CR é muito tarde e o melhor efeito do CR não foi exercido;

Cobertura insuficiente de testes de unidade e testes de integração contínua não desempenhou um papel completo;

A cobertura de negócios é difícil de medir e não há restrições.

3.5.2 Construir gradualmente o SOP do processo de P&D

O processo de derivação da construção de todo o SOP de P&D é o seguinte:

1) Observação: O atual processo irregular de P&D afeta a eficiência de P&D e a qualidade de P&D.

2) Pesquisa: obtenha apelos ou pontos problemáticos de diferentes perspectivas, investigando diferentes partes interessadas (PD, desenvolvimento, teste, etc.).

3) Triagem: Filtre as demandas ou pontos problemáticos que o TOP-N precisa resolver com urgência.

4) Análise: analise o status quo desses nós e obtenha soluções.

5) Aterrissagem: analise quais pontos problemáticos podem ser resolvidos reutilizando ou customizando ferramentas existentes, sem reinventar a roda, e quais pontos problemáticos precisam ser suportados pelo desenvolvimento de novos produtos.

6) Medição: A medição SOP adota um método de operação diferenciado. Os indicadores básicos de medição podem reutilizar diretamente os produtos de eficiência de P&D existentes para analisar e detalhar os dados. Novos indicadores precisam manter um conjunto separado de relatórios visuais para diferenciar as operações.

7) Crescimento: por meio da análise de dados ou feedback das partes interessadas, novos pontos problemáticos Top-N serão gerados e, em seguida, um sistema SOP de processo de P&D continuamente iterativo e generalizado será formado.

Figura 25 SOP do processo de P&D

Os resultados finais do sistema SOP do processo de P&D são os seguintes:

O SOP abrange todo o processo de P&D, adotando o método de " triagem de nós principais + foco em reuniões off-line + controle de processo on-line " para padronizar o processo de P&D, contando, analisando e detalhando os dados dos nós principais obtidos no processo e localizando o gargalo problemas no processo de P&D, melhorando assim a qualidade da engenharia e a eficiência de P&D.

Figura 26 Controle SOP do processo de P&D

3.5.3 Operação digital SOP

O objetivo do SOP de P&D é digitalizar o processo de P&D, melhorar a fluidez do processo de entrega de P&D, padronizar o processo de P&D e melhorar a qualidade do projeto.

O caminho de implementação do SOP leva principalmente as duas equipes de comerciantes e transações no departamento como pilotos e adota diferentes estratégias para implementar de acordo com as condições locais de acordo com os hábitos de diferentes equipes e o status quo do processo de P&D:

1) A equipe comercial adota o método de vinculação de projetos de atualização de arquitetura técnica para promover a atualização da eficiência de pesquisa e desenvolvimento e obter dados importantes.

2) A equipe de negócios adota a vinculação de excelentes projetos de engenharia e OKR, e promove a implantação de SOP e melhoria de desempenho por aplicação, com foco em indicadores incrementais de processo.

Depois de obter os dados do indicador-chave, ele pode ser usado para operação aprofundada do SOP. A medição do SOP adota um método de operação diferenciado, ou seja, os indicadores básicos de medição reutilizam diretamente o método mensurável de dados dos produtos de eficiência de P&D do grupo existente e novos indicadores precisam ser remantidos Um conjunto de relatórios de medição personalizados coleta e analisa as principais informações do nó no processo de P&D (revisão de requisitos, revisão técnica, criação e alteração, implantação, promoção de teste e liberação) para ajudar na governança de eficiência de P&D.

Figura 27 Objetivos da operação SOP do processo de P&D

Figura 28 Resultados da operação digital do SOP no processo de P&D

3.6 Globalização do Sistema de Garantia de Qualidade China Taiwan

A construção de qualidade nas áreas anteriores está integrada no sistema de qualidade, ou seja, o foco e o caminho chave do trabalho de qualidade. Trata-se de um sistema construído sobre infraestrutura de qualidade, mensurável e vinculado a indicadores-chave de negócios, que, por meio da construção e operação do SOP, percorre e aterrissa no processo de garantia de qualidade da plataforma global de e-commerce. Também operamos continuamente os dados de qualidade de várias dimensões por meio do relatório mensal de qualidade e atualizamos o sistema iterativamente.

4. Perspectivas Futuras

Comércio eletrônico transfronteiriço, comércio eletrônico internacional e comércio eletrônico globalizado tornaram-se pontos importantes na Internet nos últimos anos. Cada vez mais empresas começaram a desenvolver recursos técnicos ou produtos de comércio eletrônico transfronteiriço em várias dimensões. No contexto de formas e políticas internacionais imprevisíveis, as oportunidades e desafios que enfrentamos também são muito incertos. Mas do ponto de vista técnico, o objeto medido e o objeto de garantia de estabilidade devem ter certeza. Precisamos usar experiência e conhecimento para explorar e acumular para apoiar a evolução da tecnologia global de comércio eletrônico. No futuro, continuaremos a explorar aspectos como produção segura, governança de alta disponibilidade, garantia de qualidade mensurável e confiável e testes automatizados mais próximos da inteligência. Apoiaremos a tecnologia global e a iteração rápida de produtos com mais eficiência, clareza e a baixo custo e ser flexível para mais mudanças.

Exploração da Construção do Sistema Global de Produção de Segurança e Garantia de Qualidade