Na Uber, as equipes de engenharia lançam recursos para nossos vários aplicativos móveis simultaneamente em várias cidades do mundo, em vários fusos horários e em produtos diariamente. Para garantir que esses recursos sejam implementados com segurança, aproveitamos nossa plataforma de experimentação, uma ferramenta que nos permite monitorar como cada novo recurso afeta nosso software e sistemas por meio de um processo gradual de implementação.

Além de executar um teste completo em nosso código antes da implementação, queremos entender se um novo recurso pode interagir inadvertidamente com os recursos existentes em nossos aplicativos de maneira inesperada. Tradicionalmente, corrigir esses problemas exigia que os desenvolvedores dedicassem uma quantidade significativa de tempo investigando a origem das regressões em andamento, ou bugs, e mapeando-as de volta para os recursos que as causavam. Esse processo geralmente desacelera o desenvolvimento de recursos e pode impactar negativamente a experiência do usuário.

Portanto, criamos um novo sistema que permite identificar de maneira rápida e fácil qual recurso pode estar causando um problema. Juntamente com seu painel analítico de fácil utilização, o sistema permite lançamentos de recursos autônomos programados, já que podemos detectar e reverter recursos que apresentam problemas. Como os engenheiros podem detectar mais rapidamente a causa de uma regressão, podemos diminuir o impacto nos clientes, corrigindo quaisquer problemas antes que eles se tornem difundidos.

Melhorando a atribuição e a detecção de regressão

Nosso procedimento existente de lançamento gradual usa uma metodologia emprestada da experimentação científica: à medida em que lançamos um recurso para os clientes, o conjunto de usuários finais que o recebem é considerado o grupo de tratamento, enquanto os usuários finais restantes são o grupo de controle. Coletamos eventos dos grupos de tratamento e controle, correlacionando-os com diferentes métricas de integridade para verificar as regressões. Se detectarmos uma regressão, podemos reverter rapidamente a implementação e corrigir o problema.

Nossos colegas de engenharia, Eva Feng e Zhenyu Zhao, detalharam esse processo de lançamento no ano passado, em seu artigo “Building an Intelligent Experimentation Platform with Uber Engineering“.

Para ativar nosso sistema Auto Rollout, desenvolvemos o framework existente aprimorando seus recursos de monitoramento e adicionando um painel de análise, que permite que os desenvolvedores analisem facilmente a causa de uma regressão. Agora, se detectarmos uma regressão, podemos atribuí-la ao recurso que a causou, ao proprietário que criou o recurso e à parte do aplicativo em que a regressão foi introduzida.

Durante uma implementação, o sistema procura por eventos de estado do aplicativo, eventos de falha e eventos ANR (application-not-responding) entre as métricas que continuamente são despejadas em nossa plataforma de produção. O sistema correlaciona essas métricas com os eventos do recurso que está sendo implementado e, em seguida, passa os resultados por meio de um processador de estatísticas e um mecanismo de decisão para determinar se existe uma regressão. A saída do mecanismo de decisão determina qual ação o sistema Auto Rollout executa, seja revertendo no caso de uma regressão, ou continuando com a implementação do recurso.

A seção Mobile Metrics do painel de análise destaca o impacto do novo recurso nas diferentes partes do app. O painel na Figura 4, abaixo, indica que o recurso não teve impacto significativo no fluxo de confirmação, no fluxo de pagamento ou no fluxo de suporte do aplicativo:

A seção Mobile Metrics do painel de análíse destaca o impacto do novo recurso nas diferentes partes do app. O painel na Figura 4, abaixo, indica que o recurso não teve impacto significativo no fluxo de confirmação, no fluxo de pagamento ou no fluxo de suporte do aplicativo:

Nosso sistema de lançamentos graduais aprimorado, permite que os desenvolvedores avaliem o impacto do novo recurso implementado, e qualquer regressão detectada na plataforma do Uber pode ser atribuída a esse recurso.

Ciência por trás da análise

Subjacente ao sistema Auto Rollout, nossa plataforma de experimentação calcula cada métrica que usa correlacionando-a com os eventos experimentais. Para permitir lançamentos automatizados, aprimoramos a detecção de regressão para que o framework pudesse iniciar com mais precisão uma reversão.

O algoritmo de detecção de regressão executado em cada métrica é alimentado por um teste sequencial de razão de verossimilhança. Analisamos os seguintes eventos para calcular as métricas analisadas por esse sistema:

• Eventos mobile: o app mobile emite um evento de ponto de verificação nas seções do aplicativo. Esses eventos incluem “Solicitação de envio”, “Logado”, “Solicitar viagem”, entre outros.
• Eventos de falha: esses eventos são emitidos quando o aplicativo falha.
• Eventos ANR (Application Not Responding): esses eventos são emitidos quando o aplicativo está emperrado e não responde à interação do usuário.

Personalize parâmetros de métricas

Para determinar a regressão de uma métrica, construímos o teste de hipótese como:

H0: |Signal in Treatment – Signal in Control| <= Threshold
H1: |Signal in Treatment – Signal in Control| > Threshold

Construímos um intervalo de confiança “sempre válido” (1-alfa) em torno da diferença entre os grupos de tratamento e controle usando testes sequenciais,

P(|Signal in Treatment – Signal in Control| > Threshold | H0) < alpha:

Onde alpha = Type I error (em estatística, um type I error significa um resultado falso-positivo).

Continuamos monitorando até que o tamanho da amostra atinja nosso tamanho de amostra esperado, de modo que:

P(|Signal in Treatment – Signal in Control| < Threshold | H1) < beta:

Onde beta = Type II error (em estatística, um type II error significa um resultado falso negativo).

Se nenhuma regressão for detectada, o lançamento será considerado seguro. Esse teste estatístico é construído usando um algoritmo de teste sequencial, que permite o monitoramento contínuo sem inflacionar o type I error. Monitoramos diferentes métricas para os aplicativos do passageiro e do motorista da Uber e do Uber Eats.

O Efeito Mínimo Detectável (MDE) indica a menor alteração que podemos detectar no tratamento em relação à experiência de controle. As métricas que usamos diferem em seu nível de ruído e detectabilidade, portanto, usamos limites de MDE diferentes para cada uma. Se usarmos um limite X de MDE, para termos 90% de certeza de que não há regressão > X, temos que prever o número de usuários que precisamos nos fluxos de tratamento e controle.

O gráfico abaixo indica que, para uma métrica com média de aproximadamente 0,8 para atingir um limiar de MDE de 3%, precisaríamos de pelo menos aproximadamente 18.000 usuários nos fluxos de tratamento e controle (combinados) antes de podermos chamar o lançamento de seguro com 90% confiança.

Agendando lançamentos de recursos

Além de facilitar para os engenheiros identificarem problemas com um novo recurso, nosso monitoramento aprimorado de regressão nos permite automatizar a implementação de recursos, já que o sistema pode reverter uma implementação se algo der errado. Nosso sistema Auto Rollout diminui a fadiga do desenvolvedor, já que os usuários não precisam ativar e monitorar manualmente cada etapa do lançamento, e isso faz todo o processo rodar mais rápido.

O sistema Auto Rollout consiste em dois componentes principais: a interface de usuário do Rollout, que permite que os usuários definam parâmetros de distribuição, e o processador Rollout Configuration, gerenciando o progresso de cada distribuição de recursos em todo o seu ciclo de vida.

UI do Rollout

O sistema Auto Rollout permite que os usuários definam alguns parâmetros de configuração através de uma interface de usuário simples. Eles podem escolher o grupo de tratamento para lançamento, a data de início e o número de dias durante os quais deveriam concluir o lançamento.

Configuração do Rollout

Cada lançamento tem um ciclo de vida, começando com a configuração inicial e terminando na conclusão. O processador Rollout Configuration gerencia o ciclo de vida, movendo o rollout através de seus estágios, monitorando as análises em segundo plano e atualizando os usuários em cada estágio.

Essa abordagem de mãos livres permite que os usuários lancem recursos sem precisar monitorá-los em vários dias. Os engenheiros podem iniciar imediatamente seus lançamentos ou agendá-los para uma data e hora futuras.

Implementação de hands-off bem-sucedida

Desde o lançamento, esse sistema executou milhares de lançamentos de maneira autônoma para recursos nos aplicativos da Uber. A adição do sistema Auto Rollouts resultou em várias vantagens para o fluxo de trabalho de engenharia da Uber:

Atribuição: uma regressão pode ser capturada e atribuída a um recurso ou proprietário específico.

• Maior segurança: os engenheiros podem configurar o sistema para distribuir o recurso a qualquer hora, dia ou noite, e ter a garantia de que ele será monitorado com base em várias métricas para regressões.
• Maior velocidade de implementação: a automação do sistema e a capacidade de capturar regressões dobraram nossa velocidade de lançamento de recursos.

Se você estiver interessado em criar soluções de implementação de recursos monitorados, automatizados e seguros, considere a possibilidade de se juntar à nossa equipe!

Assine nossa newsletter para acompanhar as mais recentes inovações da Uber Engineering.

***

Este artigo é do Uber Engineering. Ele foi escrito por Tim Knapik, Mandie Liu, David Schnurr, Sisil Mehta e Anando Sen. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/autonomous-rollouts-regression-analysis/