> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2020/w29-business-metrics-monitoring-and-end-to-end-canary-releases.md).

# W29-Monitoramento de métricas de negócio e liberação gradual de ponta a ponta

O incidente de produção da Meituan Pay na quarta-feira me trouxe duas reflexões.

Primeiro, uma breve retrospectiva. Participei de quase todos os momentos principais, da descoberta e resposta à investigação e eliminação do impacto. Embora o alcance e as consequências não tenham sido muito graves, olhando depois houve exposição ao risco durante todo o processo\*\*. Em certa medida, o caso revelou riscos sistêmicos nossos e merece servir de lição.\*\*

* **A descoberta e a resposta foram passivas e lentas.** O canal afetado era o pagamento por internet banking. Depois do redirecionamento do usuário, todos os serviços anteriores e posteriores esperavam o callback de sucesso do pagamento unificado. A falha aconteceu no banco, sem que frontend ou backend do checkout a percebessem. Assim, o usuário reclamou à área de negócio, que avisou o checkout. Quando recebemos muitos relatos na quarta-feira à tarde, não sabíamos havia quanto tempo o problema existia nem qual versão o introduzira. Isso dificultou ainda mais a investigação.
* **A investigação foi desordenada.** Como não sabíamos a versão de origem, investigamos toda a cadeia, do frontend ao serviço mais distante, com participação de todos os papéis e muita confusão. A primeira reação deveria ser conter a perda com rollback rápido. Mas ninguém sabia qual etapa, horário ou versão havia causado a falha. A localização levou bastante tempo.

Tirei duas lições.

* **Primeiro, avançar com firmeza no monitoramento de métricas de negócio.** Em pagamentos, a principal é a **taxa de sucesso**. No início, eu não entendia bem o benefício de monitorá-la em tempo real. Este caso me deu motivo para insistir. Em fluxos dependentes de terceiros, como internet banking, WeChat ou Alipay, não percebemos diretamente as falhas do parceiro. Só a taxa de sucesso em tempo real permite detectá-las. Hoje, o B2B gera um relatório D+1, sem atualização em tempo real nem monitoramento. **Há dois caminhos de implementação.** Um é mobilizar o backend do checkout e a equipe de dados. Já tentamos, mas faltava motivação; o incidente pode mudar isso. O outro é construir no frontend com raptor. Métricas compostas personalizadas permitem acompanhar a variação da taxa de sucesso entre períodos. Os valores absolutos do frontend não são exatos, mas bastam para detectar problemas a tempo. **O sistema de monitoramento do frontend do checkout será uma prioridade no planejamento do terceiro trimestre.**
* **Segundo, avançar na liberação gradual de ponta a ponta dos pagamentos B2B.** Depois do incidente, a Meituan Pay criou um grupo para melhorar monitoramento e alertas. Podemos aproveitar para integrar a liberação gradual entre frontend e backend. Hoje, o frontend do checkout tem duas opções. Uma distribui tráfego pelo final de tradeno, mas o mesmo usuário pode fazer vários pedidos e cair em versões diferentes, prejudicando muito a experiência. A outra publica nos servidores de liberação gradual e configura uma lista de usuários autorizados para validar em produção antes da liberação geral. Nenhuma é ideal. **Espero estabelecer no terceiro trimestre uma liberação gradual de ponta a ponta guiada pelo identificador único do usuário, garantindo iterações seguras e estáveis e preparando a base para testes A/B.**