La latencia es una métrica de negocio, no de ingeniería 

Durante casi toda su vida, nuestro reporte de desempeño de red fue un producto del día siguiente. Ocurría un evento, la tubería procesaba durante la noche y los números aterrizaban en el escritorio de alguien a la mañana siguiente. Todo el mundo lo aceptaba. Simplemente era lo que tardaban los datos.

Ese encuadre es el error. ~12+ horas de latencia no son una característica técnica de una tubería. Son una decisión sobre quién dentro de la organización tiene permitido responder a la realidad, y con cuánto retraso.

El impuesto de las ~12+ horas

Cuando los datos tienen un día de antigüedad, el turno que pudo haber resuelto el problema ya se fue a casa. El ingeniero que vio la anomalía ya no está frente a la consola. El contexto que hacía interpretable el número (qué cambió, qué se desplegó, quién estaba de guardia) se evaporó. Lo que llega a la mañana siguiente no es información. Es arqueología.

Así que la organización se adapta. Construye una segunda capa informal de reportes hecha de intuición y llamadas telefónicas. Escala por corazonadas porque los números son demasiado lentos para discutir con ellos. Sobredimensiona la capacidad, porque comprar capacidad sale más barato que equivocarse en público. Nada de eso aparece en un tablero de latencia, y todo eso se paga.

Lo que cambian ~15 minutos

Reconstruimos la plataforma de datos global de la unidad de negocio Network Services alrededor de una sola pregunta: ¿puede la persona capaz de resolver esto verlo mientras todavía puede resolverlo? Eso puso la meta dentro de un turno, no dentro de un día. Aterrizamos en ~15 minutos.

Los resultados interesantes no fueron los que escribimos en el caso de negocio:

• Los escalamientos pasaron a basarse en evidencia y no en intuición, porque la evidencia llegaba a tiempo para poder citarla.
• La capa informal de reportes se atrofió, y con ella una enorme cantidad de esfuerzo humano que nadie medía.
• Las decisiones de capacidad se ajustaron, porque el costo de equivocarse bajó junto con el ciclo de retroalimentación.
• Los equipos empezaron a hacer mejores preguntas, porque vale la pena hacer una pregunta que se puede responder dentro de la hora.

Los estándares son un piso, no una meta

Existen especificaciones de industria sobre cómo se intercambian los datos de desempeño, y son útiles justo hasta el momento en que se convierten en la ambición. Un estándar de interfaz describe cómo se hablan los sistemas entre sí. No dice con cuánto retraso puede permitirse su negocio enterarse de las cosas. Son preguntas distintas, y solo la segunda tiene un costo asociado.

La meta correcta de latencia no es la que permite un estándar. Es la que devuelve la decisión al mismo turno en que ocurre el evento.

Cómo defenderlo

Los programas de latencia son difíciles de financiar porque el beneficio cae en el presupuesto de otros. El costo de ingeniería es concreto y suyo; los ahorros son difusos y ajenos. Esa asimetría mata más de estos proyectos que cualquier obstáculo técnico.

El argumento que funciona no habla de tuberías. Habla de latencia de decisión: nombre las decisiones que hoy se toman tarde o a ciegas, ponga un costo a la demora en cada una y muestre en qué se convierte esa cifra cuando los datos llegan dentro de la ventana en la que la decisión todavía existe. Entonces la conversación es sobre el negocio, y la tubería es un detalle de implementación, que es exactamente lo que es.