Una línea de tiempo con cuatro relojes

Una línea de tiempo mezcla fuentes que no se pusieron de acuerdo en la hora. El sensor de red suele escribir en UTC; el servidor de correo, en la hora local de la empresa; y un equipo de usuario lleva el reloj que tenga, a veces con minutos de error. Si ordenas las filas tal como vienen, el correo parecerá posterior a la descarga que provocó, y la historia saldrá al revés.

El método es siempre el mismo: elegir una zona para todo (lo habitual es UTC), anotar para cada fuente en qué zona escribe y cuánto va su reloj adelantado o atrasado, y recién entonces ordenar. El desfase de un equipo se mide comparando uno de sus eventos con el mismo evento visto por el sensor, y se deja escrito junto al informe.

UTC-5 va cinco horas por detrás de UTC, así que para llevar una hora local a UTC se le suman cinco horas. Es una cuenta simple y por eso mismo la que más se olvida: un analista cansado deja el correo en su hora local, lo pone al lado de las horas del sensor y concluye que el correo llegó cinco horas antes de lo que ocurrió, o que llegó después de la descarga.

En el laboratorio hay una tabla de relojes con la zona de cada fuente y una tabla con los correos que recibió la usuaria lmorales esa mañana. Solo uno de ellos lleva un enlace; ese es el que interesa.

El registro de un equipo es precioso porque dice qué programa hizo cada cosa, pero su reloj es el menos fiable. En la tabla de relojes consta que el de CONTA-07 va 94 segundos adelantado: cuando el equipo escribe 09:15:29, la hora real era 94 segundos antes. Hay que restar el desfase y luego pasar a UTC; hacerlo al revés, o a medias, desordena justo los eventos que más cerca están entre sí.

Una buena comprobación es cruzar con el sensor: tras corregir, el evento del equipo tiene que caer a uno o dos segundos del evento equivalente en la red.

Cuando salta una alerta, la tentación es empezar la historia en ella, porque es el primer momento en que alguien supo algo. Pero la alerta mide cuándo se descubrió el incidente, no cuándo empezó. La línea de tiempo empieza en el primer evento que la evidencia permite enlazar con el resto de la cadena, aunque en ese momento nadie lo notara.

En este caso eso se ve en la tabla de alertas: antes de la alerta que se atendió hubo otra, de prioridad baja, que el turno cerró sin analizar. Reconstruir bien el principio no sirve para culpar a nadie: sirve para saber cuánto tiempo estuvo el incidente sin ser visto y qué señal se pudo haber atendido antes.

Con todo en UTC, la distancia entre dos eventos se calcula restando horas, y la que más importa a la dirección es la que va del primer evento enlazable a la alerta que se atendió: es el tiempo que el incidente corrió sin que nadie lo supiera. Se informa en minutos, sin redondear a «más o menos una hora».

La tabla de alertas trae la hora UTC de la que abrió el incidente. El primer evento enlazable ya lo calculaste en la tarea 2.