Migrar un catálogo entre plataformas

El riesgo de una migración es el mismo de todo este módulo: que algo deje de vigilar sin que nadie lo vea. La defensa es un periodo en paralelo: la regla corre en las dos plataformas a la vez durante un tiempo fijado, se comparan las alertas con un criterio de paridad escrito de antemano, y solo cuando se cumple se apaga la versión antigua. Mientras no se cumple, la plataforma antigua sigue siendo la que protege.

Las migraciones se hacen por olas: grupos de reglas que comparten dependencias o riesgo, de modo que un fallo se descubre sobre pocas reglas y no sobre todo el catálogo a la vez.

Una regla rara vez vive sola. Puede leer una lista (de cuentas, de equipos), tomar un dato de un enriquecimiento (el inventario de equipos) o disparar una automatización (un playbook). Si esas piezas no existen en el destino, la regla se convierte bien y falla en funcionamiento. Abre el panel: dependencias dice de qué depende cada regla y si ya existe en la plataforma nueva.

El tamaño de las olas se decide con el riesgo y con la capacidad de revisión del equipo: cada regla de una ola necesita sus casos de prueba, su replay y su comparación de alertas. Una ola demasiado grande se revisa a medias. El catálogo, con la ola de cada regla, está en catalogo.

El periodo en paralelo solo protege si la plataforma antigua sigue encendida durante todo él. Compara plan_de_olas, que dice cuándo termina el paralelo de cada ola, con la fecha de vencimiento del contrato de la plataforma antigua (en contexto). Una ola cuyo paralelo termine después de esa fecha se queda sin la red de seguridad antes de haber demostrado la paridad.

El plan tiene dos problemas: una regla de la ola 2 depende de una lista que no existe y la ola 3 se queda sin paralelo completo. Quien dirige el proyecto tiene que decidir qué pide a la dirección, y no es lo mismo apagar a tiempo que apagar a salvo.