Resumen

  • Un cambio de configuración o de lógica puede torcer una salida automática sin encender las alarmas de infraestructura.
  • Sepuri propone validar el comportamiento del flujo en producción y convertir sus desvíos en nuevas pruebas.

Un panel verde declara que el servicio está sano. No demuestra que haya tomado la decisión correcta. Esa diferencia, incómoda y fácil de perder entre gráficos, sostiene la charla de Shruthi Sepuri en NANOG 98.

Su presentación, “From Testing to Reliability: Detecting Silent Failures in Production Systems”, figuró como una sesión de treinta minutos en Miami el 19 de octubre de 2026. El resumen oficial describe cómo una configuración, una regla o una dependencia puede cambiar el comportamiento de un sistema automatizado sin alterar las señales habituales de disponibilidad, latencia, errores o uso de recursos.

Las diapositivas muestran un escenario, no un incidente identificado. La infraestructura conserva el color verde mientras falla el motor de reglas, la decisión sale mal, se omite una validación y queda incompleto el rastro de auditoría. El material público no nombra un servicio ni un cliente afectados; la escena ilustra un modo de fallo. El problema que plantea es concreto: una tubería puede procesar datos y seguir produciendo decisiones incorrectas.

Sepuri traslada la medición hacia el trabajo que hace el servicio. Entre sus indicadores figuran la tasa de resultados correctos, la integridad de la cobertura de configuración, las anomalías en la distribución de salidas y la ejecución correcta de reglas frente a casos conocidos. A eso suma tráfico sintético que recorra la lógica de producción, comparaciones con un resultado de referencia después de cada cambio y una vuelta de los patrones observados hacia las pruebas.

El cambio editorial es importante para la operación: el sistema deja de “aprobar” solo porque respondió. Hay que definir qué decisión se esperaba, qué entradas pueden moverla y qué evidencia detectaría el resultado equivocado. En un flujo basado en reglas, eso supone revisar los campos obligatorios, confirmar la ruta de ejecución y asociar la salida con la versión de configuración.

Un cambio en la distribución no prueba por sí mismo que algo esté roto. Puede reflejar una carga distinta o una política nueva. La alerta sirve cuando llega con su contexto de cambio, un umbral explicable y alguien que conozca el resultado previsto. Sin esas piezas, el panel gana otra curva y el equipo, otra fuente de ruido.

La propuesta de Sepuri pone el comportamiento ejecutado por encima de la declaración de salud. Las pruebas deben recorrer la lógica que opera y regresar con evidencia que influya en el siguiente despliegue. Si solo se observa la infraestructura, un sistema puede seguir impecable mientras decide mal.

Fuentes: sesión oficial de NANOG 98 · diapositivas oficiales · retrato oficial de la ponente.