Este artículo sintetiza los conceptos clave de la charla «Observabilidad en Acción: Las Huellas del Sistema Bajo Presión», impartida por Kelly Tapia. El argumento central es que las métricas de las pruebas de performance, aunque necesarias, son insuficientes por sí solas para garantizar la calidad y estabilidad de un sistema. El performance indica el síntoma (p. ej., una tasa de error o un tiempo de respuesta), pero la observabilidad proporciona el diagnóstico, revelando el «qué», «dónde» y «por qué» de las fallas.
A través de un caso de estudio del sector bancario, se demuestra cómo una tasa de error del 1%, considerada aceptable según los criterios definidos, ocultaba una falla crítica en un flujo de transacciones de alto impacto monetario (pagos a empresas). Esta falla, invisible en los dashboards de performance, generó pérdidas millonarias y contractuales al pasar a producción.
La solución propuesta radica en complementar las pruebas de performance con prácticas de observabilidad, utilizando herramientas como Kibana para analizar los logs y las trazas del sistema. La implementación y seguimiento de un ID de transacción único para cada operación se presenta como una técnica fundamental para rastrear el recorrido completo de una petición a través de múltiples componentes, permitiendo identificar con precisión el punto exacto de la falla. Las recomendaciones finales se centran en adoptar una cobertura de pruebas más completa, validar los logs activamente y entender la arquitectura del sistema para anticipar y diagnosticar errores que las métricas superficiales no pueden revelar.
——————————————————————————–
1. El Caso de Estudio: El 1% de Error que Ocultaba una Falla Crítica
El análisis se centra en un caso real de una prueba de performance en el sector bancario, donde los resultados aparentemente exitosos enmascaraban un problema sistémico grave.
1.1. Contexto y Criterios de Aceptación
Se realizó una prueba de performance para un sistema bancario con criterios de aceptación claros, definidos en conjunto con el área de negocio. El enfoque principal estaba en mantener una tasa de error por debajo del 5%.
| Métrica | Criterio de Aceptación | Resultado Obtenido | Estado |
| Tasa de Error | Menor a 5% | 1% | Aprobado |
| Tiempo de Respuesta (Percentil 90) | 2 segundos | 1.2 segundos | Aprobado |
| Transacciones por Segundo (TPS) | 20 TPS | 50 TPS | Aprobado |
Con todos los indicadores en verde, el informe fue aprobado y el sistema pasó a producción.
1.2. Resultados Engañosos y Consecuencias en Producción
Días después del lanzamiento, comenzaron a llegar reclamos de usuarios, coincidiendo con períodos de alta concurrencia como los fines de mes. Aunque las métricas de performance fueron satisfactorias, existía un problema «silencioso» que no fue detectado.
El 1% de errores, que parecía insignificante, terminó generando:
• Pérdidas millonarias: Afectó un flujo transaccional con un alto valor monetario.
• Problemas contractuales: El fallo en los pagos a empresas implicó incumplimientos con terceros.
• Pérdida de confianza: Un impacto reputacional significativo en un sector crítico como el financiero.
La ponente subraya una lección clave: «buenas métricas no siempre garantizan que todo funcionó bien».
1.3. El Origen del Error: Segmentación de Flujos
El análisis profundo reveló que el error no estaba distribuido aleatoriamente. El sistema gestionaba dos flujos principales:
1. Pagos a Personas Naturales: Este flujo, de mayor volumen transaccional, funcionaba correctamente (0% de error) y seguía una ruta arquitectónica específica (APIs A, B).
2. Pagos a Empresas: Este flujo, de menor volumen pero mayor impacto monetario, era el que presentaba el 100% de los errores. Seguía una ruta diferente que invocaba un componente (API D) que se saturaba bajo carga y fallaba, provocando un error en cascada.
El error del 1% global era, en realidad, una tasa de fallo del 100% para un segmento específico y crítico de usuarios. Las métricas de performance no mostraron esta segmentación, ocultando la verdadera gravedad del problema.
2. Performance vs. Observabilidad: Del Síntoma al Diagnóstico
La charla establece una distinción fundamental entre medir el performance y observar un sistema para entender su comportamiento interno.
«El performance es el síntoma pero la observabilidad es el diagnóstico».
2.1. Las Limitaciones de las Métricas de Performance
Las métricas tradicionales responden a preguntas superficiales, pero fallan en proveer el contexto necesario para un análisis de causa raíz. Las métricas no muestran:
• El Qué: ¿Qué tipo de transacción específica está fallando?
• El Dónde: ¿En qué componente o microservicio exacto se origina el error?
• El Por Qué: ¿Cuál es la causa subyacente de la falla (saturación, lógica incorrecta, etc.)?
El performance puede detectar la existencia de un cuello de botella, pero no su ubicación precisa. Puede medir errores totales, pero no identificar si se concentran en un flujo particular.
2.2. El Poder de la Observabilidad
La observabilidad permite «detectar lo invisible» al sumergirse en las «huellas del sistema»: los logs y las trazas. A diferencia del performance, la observabilidad sí permite:
• Identificar por qué una operación tarda, señalando el componente específico que introduce latencia.
• Localizar exactamente qué componente genera el cuello de botella.
• Saber en qué parte del flujo está la falla, permitiendo aislar el problema.
• Detectar errores silenciosos o intermitentes que no se manifiestan como códigos de error HTTP obvios pero que indican un mal funcionamiento interno.
2.3. Tabla Comparativa
| Característica | Pruebas de Performance | Observabilidad |
| Enfoque | Mide métricas agregadas (tiempos, errores). | Analiza el comportamiento interno del sistema. |
| Pregunta que responde | ¿Cuánto tarda? ¿Cuál es la tasa de error total? | ¿Por qué tarda? ¿Dónde y por qué falla? |
| Detección de Cuellos de Botella | Detecta la existencia de un cuello de botella. | Identifica el componente exacto que lo genera. |
| Análisis de Errores | Mide el total de errores. | Sabe en qué parte del flujo está la falla. |
| Visibilidad | Puede pasar por alto errores internos o silenciosos. | Expone fallas invisibles y cuellos de botella ocultos. |
3. Herramientas y Técnicas para la Observabilidad Práctica
Para aplicar la observabilidad no basta con la intención; se requieren herramientas y metodologías específicas para seguir el rastro de las operaciones.
3.1. Las Huellas del Sistema: Logs y Trazas
Cada petición de un usuario deja un rastro (traza) a medida que viaja por los distintos componentes de la arquitectura (microservicios, bases de datos, APIs). Estos eventos se registran en logs. El análisis de estos logs permite reconstruir el viaje completo de la petición y entender el comportamiento del sistema en cada paso.
3.2. El Rol del ID de Transacción (Trace ID)
Un ID de transacción es un identificador único que se asigna a una operación en su origen (cuando el usuario hace clic) y viaja con ella a través de todos los componentes internos que invoca.
• Definición: «Es un código único que está presente en toda la trazabilidad que tiene un sistema».
• Función: Permite seguirle el rastro a una petición específica a lo largo de todo su camino, correlacionando los logs de diferentes servicios que participaron en la misma operación.
• Importancia: Es la herramienta clave para aislar el comportamiento de una sola transacción entre miles o millones, facilitando el diagnóstico de fallas.
3.3. Uso de Herramientas como Kibana
Se menciona a Kibana como una herramienta intuitiva y poderosa para la visualización y análisis de logs. Su uso práctico durante las pruebas de performance incluye:
• Filtrado por Tiempo: Aislar los logs generados exclusivamente durante la ventana de ejecución de la prueba.
• Búsqueda por Contenido: Realizar búsquedas para filtrar todos los logs que contengan la palabra «error» o códigos de estado específicos.
• Búsqueda por ID: Introducir el ID de una transacción fallida para ver su traza completa y el detalle de cada paso, incluyendo tiempos de respuesta por componente.
4. Recomendaciones Estratégicas (Observabilidad en Acción)
Para integrar la observabilidad en el ciclo de vida del testing, se proponen las siguientes acciones concretas:
1. Considerar una Cobertura Completa: En el diseño de los scripts de performance, incluir todas las casuísticas y tipos de datos posibles. Por ejemplo, si se prueban pagos, se deben incluir clientes naturales, jurídicos, con distintos tipos de documento (pasaporte, carnet de extranjería), ya que el error puede estar asociado a una data específica.
2. Validar los Logs y Seguir las Trazas: Durante la ejecución de las pruebas, no solo mirar los dashboards, sino también analizar los logs en tiempo real para verificar que el comportamiento del sistema se alinea con la arquitectura esperada y que no hay errores ocultos.
3. Exigir y Utilizar la Trazabilidad por ID: Como área de calidad, se puede recomendar y promover la implementación de IDs de transacción únicos en todos los componentes. Al generar informes de performance, es útil adjuntar una lista de los IDs de las transacciones que fallaron para facilitar el trabajo del equipo de desarrollo.
4. Analizar la Arquitectura del Sistema: Entender cómo se comunican los componentes internos es fundamental para diseñar pruebas de performance efectivas y para saber dónde buscar cuando las métricas indican un problema.
5. Conclusión: Una Nueva Perspectiva sobre el Testing
El mensaje final es un llamado a evolucionar la práctica del testing de performance, pasando de una simple validación de métricas a un análisis profundo del comportamiento del sistema. La observabilidad no reemplaza al performance, sino que lo complementa, proporcionando el contexto necesario para tomar decisiones informadas y evitar que errores aparentemente pequeños se conviertan en problemas críticos en producción. Es imperativo «ver más allá de lo que los números nos están mostrando» y enfocarse en lo que los dashboards, por diseño, no pueden mostrar.
