> 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/es/2020/w29-business-metrics-monitoring-and-end-to-end-canary-releases.md).

# W29-Monitoreo de métricas de negocio y despliegues graduales de extremo a extremo

El incidente de producción del miércoles en Meituan Pay me llevó a dos reflexiones.

Primero, un breve repaso. Participé en casi todos los momentos clave, desde la detección y la respuesta hasta el diagnóstico y la eliminación del impacto. Aunque el alcance y las consecuencias finales no fueron especialmente graves, al revisarlo vemos que hubo exposición al riesgo durante todo el recorrido. **En cierta medida dejó al descubierto nuestros propios riesgos sistémicos y merece que aprendamos de él.**

* **La detección y la respuesta fueron pasivas y lentas.** El problema afectó al canal de banca en línea. Una vez redirigido el usuario al banco, los componentes anteriores y posteriores del flujo esperan la notificación de pago exitoso del sistema de pagos unificado. El fallo ocurrió precisamente en el proceso de pago del banco y ni el frontend ni el backend de la caja lo percibieron. Por eso, el cliente informó al equipo de negocio y este a la caja. Cuando el miércoles por la tarde recibimos numerosos avisos, no sabíamos cuánto tiempo llevaba ocurriendo el problema ni qué versión lo había introducido. Esto complicó aún más el diagnóstico.
* **El diagnóstico fue caótico y desordenado.** Como no podíamos identificar la versión que había introducido el problema, tuvimos que investigar todo el flujo, desde el frontend hasta el último sistema dependiente. Participaron todos los roles y la situación fue confusa. La primera reacción ante un incidente debería ser contener las pérdidas y revertir a tiempo. Pero en aquel momento nadie sabía qué componente, desplegado cuándo y en qué versión, lo había causado. Localizar el problema llevó bastante tiempo.

De ahí extraigo dos aprendizajes.

* **Primero, impulsar con firmeza el monitoreo de las métricas de negocio.** En pagos, la métrica principal es la **tasa de éxito de los pagos**. Al principio no entendía bien el beneficio de vigilarla en tiempo real, pero este incidente me dio el impulso para hacerlo. Cuando dependemos de terceros, como al redirigir a la banca en línea, WeChat o Alipay, no percibimos sus fallos. Solo podemos detectarlos mediante el monitoreo en tiempo real de la tasa de éxito. Actualmente, la tasa de éxito de los pagos B2B se genera en informes D+1. No está disponible en tiempo real ni se monitorea. **Hay dos vías para implantar este monitoreo.** Una es impulsar el desarrollo de esta capacidad junto con el backend de la caja y el equipo de datos. Ya lo intentamos antes, pero les faltaba motivación; es posible que este incidente cambie su postura. La otra es construirlo desde el frontend con raptor. Podemos definir métricas compuestas personalizadas para vigilar la evolución de la tasa de éxito respecto al período anterior. Aunque los valores absolutos del frontend no sean exactos, bastan para detectar problemas a tiempo. **En la planificación del Q3, construir el sistema de monitoreo del frontend de la caja será una prioridad.**
* **Segundo, impulsar los despliegues graduales de extremo a extremo para los pagos B2B.** Después del incidente, Meituan Pay creó un grupo dedicado a mejorar el monitoreo y las alertas. Podemos aprovecharlo para avanzar en los despliegues graduales que abarquen frontend y backend. Hoy el frontend de la caja dispone de dos estrategias. Una distribuye el tráfico según los últimos dígitos del número de pedido tradeno, pero puede enviar a un mismo usuario a versiones distintas de la caja cuando hace varios pedidos, lo que perjudica mucho la experiencia. La otra consiste en desplegar primero en las máquinas destinadas a la prueba gradual, configurar usuarios en una lista de permitidos y verificar en producción. Tras la verificación, se despliega para todos. Ninguna de las dos es óptima. **Espero que en el Q3 construyamos un despliegue gradual de extremo a extremo basado en un identificador único de usuario, para mantener seguras y estables las siguientes versiones y sentar las bases de las pruebas A/B.**