Encontré un error de análisis dentro de nuestro propio producto de análisis.
El canal de eventos funcionó. Sitios reales enviaron eventos reales. Un booleano interno todavía decía que el script de seguimiento no estaba instalado.
Esa contradicción importaba porque la bandera era el primer hito en nuestra puntuación de activación. Si seguía siendo falso, un sitio en funcionamiento podría permanecer en el segmento frío incluso después de que llegaran los datos.
El 21 de julio, la producción contaba con 36 plantas. Veintiuno habían recibido un primer evento. Sólo dos tenían script_installed configurado como verdadero.
Diecinueve instalaciones en funcionamiento fueron descritas como inactivas.
El problema no fue una cola retrasada ni un rastreador fallido. Habíamos creado una transición estatal que ningún camino de producción había realizado jamás.
El valor era correcto en el momento de la creación.
Cuando un cliente creó un sitio, script_installed comenzó como falso. Eso fue razonable. En ese momento, Zenovay no había recibido pruebas de que el guión se estuviera ejecutando.
La parte que faltaba llegó después.
Nuestro sistema registró la marca de tiempo del primer evento cuando llegaron los datos, pero nada cambió el indicador de instalación. La bandera tenía un escritor para el valor falso inicial y ningún escritor para el valor verdadero posterior.
Las pruebas hicieron que el error fuera fácil de pasar por alto. Proporcionaron dispositivos donde script_installed ya era verdadero y luego verificaron que la puntuación de activación manejaba el valor correctamente.
Se probó la función de puntuación. La transición que creó su entrada no lo fue.
Dos campos describen un hecho
Ya teníamos una señal más fuerte: first_event_at.
Esa marca de tiempo solo existe después de que la ruta de ingesta acepta un evento analítico real para el sitio. Es evidencia de algo que sucedió. El booleano era sólo una descripción de esa evidencia.
Una vez que ambos campos existieron, podrían estar en desacuerdo:
select count(*)
from websites
where first_event_at is not null
and script_installed is distinct from true;
La consulta arrojó 19.
Este es el riesgo de estado duplicado. Cada campo puede parecer válido de forma aislada. La contradicción aparece sólo cuando se comprueba la relación entre ellos.
Por qué el daño permaneció interno
La verificación de instalación de cara al cliente utilizó una condición más segura. Sólo avisaba cuando tanto la bandera era falsa como no existía un primer evento. A los clientes con datos reales no se les indicó incorrectamente que reinstalaran el rastreador.
El cron de activación también era de solo lectura. Registró telemetría y no envió correos electrónicos sobre el ciclo de vida.
Eso limitó el radio de la explosión, pero no hizo que el insecto fuera inofensivo. Los informes de activación internos clasificaban incorrectamente los equipos de trabajo. Cualquier decisión basada en ese segmento partiría de evidencia falsa.
La reparación
Adjuntamos la transición que falta al evento que prueba la instalación.
Cuando llega el primer evento de visitante, el mismo activador de base de datos que registra el primer evento ahora establece script_installed en verdadero y registra cuándo se vio el script por primera vez.
La actualización está cautelosa. Se ejecuta sólo mientras la verificación está pendiente o el indicador de instalación aún no es verdadero. Las visitas posteriores a la página no reescriben la misma fila del sitio ni generan una nueva entrada de auditoría para cada evento.
Luego completamos las 19 filas inconsistentes a partir de la evidencia existente del primer evento.
Después de la reparación, el estado histórico de producción tenía 21 sitios con un primer evento y 21 con la bandera de instalación puesta. El recuento de discrepancias fue cero.
Una nueva verificación de producción realizada el 20 de agosto aún arrojó cero sitios con eventos pero un indicador de instalación falso, y cero sitios con un indicador verdadero pero sin un primer evento.
Qué cambiamos en el proceso de revisión
La corrección del código fue pequeña. El cambio de revisión es más útil.
Primero, los hitos de activación necesitan un evento observable. “El script está instalado” es una etiqueta. “El primer evento fue aceptado en este momento” es evidencia.
En segundo lugar, las pruebas deben cubrir la transición que produce el estado. Una prueba unitaria perfecta para la función de puntuación no podría revelar que la producción nunca proporcionó el valor real.
En tercer lugar, los hechos duplicados necesitan una invariante. Si se espera que dos campos coincidan, ejecute la consulta de contradicción continuamente. No espere una auditoría manual.
Cuarto, los análisis internos merecen el mismo escepticismo que los análisis de clientes. Un embudo pulido todavía puede medir la ficción cuando un hito se deriva de un estado obsoleto.
La pregunta que usamos ahora.
Ya no preguntamos únicamente si el indicador de instalación es verdadero.
Preguntamos qué evento irreversible prueba que ocurrió el hito.
Para la instalación del rastreador, ese evento es simple: llegó el primer evento.
¿Qué estado de su producto se trata como un hecho aunque ningún evento de producción sea responsable de cambiarlo?
