Del borrador a producción y a retiro

El equipo usa cuatro estados de la lista de valores de status de Sigma. En experimental, la regla existe en el repositorio y no alerta a nadie. En test, alerta en modo sombra: las alertas llegan a ingeniería de detección y no al turno. En stable, alerta al turno. En deprecated, no se despliega, pero su archivo se conserva con el motivo.

El modo sombra existe porque cada alerta que llega al turno gasta minutos de analista, y una regla sin probar en producción es una regla que gasta esos minutos con falsos positivos que nadie midió. Ingeniería puede permitirse equivocarse en voz baja.

Pasar de test a stable no es una decisión de sensación: los criterios están escritos y se aplican igual a todas. Hay uno que se olvida con facilidad: los días de sombra se cuentan desde el último cambio de lógica, porque una regla que se modificó es, a efectos de prueba, otra regla.

Una regla que no cumple aún no es una regla mala: es una regla a la que le falta algo medible. Decir cuánto es lo que separa un «todavía no» de un «pasa» es lo que le da al autor un objetivo y al jefe una fecha.

Retirar una regla también es una decisión con criterio. Una regla se retira cuando lo que vigila ya no existe, cuando otra la sustituye con mejor lógica o cuando su ruido supera lo que aporta y no tiene arreglo. Se detecta cruzando cada regla en producción con el inventario de lo que la empresa tiene hoy.

El jefe de infraestructura pregunta si no sería más limpio borrar el archivo de la regla retirada. El repositorio guarda el historial, así que técnicamente nada se pierde. Pero un archivo borrado desaparece de las búsquedas, de la matriz de cobertura y de la vista de quien llegue después. Un archivo con status: deprecated, la fecha del retiro y el motivo en la descripción sigue contando la historia donde la gente mira.

Además, si mañana la pasarela vuelve a existir bajo otro nombre, quien la quiera vigilar empieza por el archivo retirado y no desde cero.