Despliegue canario

En un despliegue canario la versión nueva de una regla se activa en un subconjunto pequeño de las fuentes (unos servidores, una sede, un tipo de equipo) mientras el resto sigue con la versión anterior. Si ese subconjunto se comporta como se esperaba, el alcance crece por etapas. Si no, se detiene y el daño queda acotado a lo poco que se expuso.

Para que sirva, tres cosas se fijan antes: el alcance de cada etapa, cuánto dura y el criterio de paso (por ejemplo, un máximo de alertas por servidor y día). Decidir el criterio después de ver los números es hacer trampa a uno mismo. Y hace falta una comparación: la versión anterior en los mismos servidores.

Abre el panel. plan_canario fija las etapas; resultados_canario mide las ejecutadas. En la etapa 2 el volumen se disparó. La tabla etapa_2_por_servidor reparte las alertas de la v2.0 por servidor: un total grande puede venir de todos por igual o de uno solo, y la respuesta cambia el arreglo.

El criterio del plan se expresa por servidor y por día, no en total, para poder comparar etapas de distinto tamaño. Calcula cuántas alertas por servidor y día dio la v2.0 en la etapa 2 (divide las alertas entre los servidores y entre los días que duró la etapa) y compáralo con el máximo del plan.

Un volumen alto en un solo servidor casi nunca es una avalancha de conductas nuevas: suele ser algo que ese servidor hace de forma repetida. La tabla tareas_de_ambl_respaldo_01 agrupa las alertas del servidor por la tarea programada que las originó.

La etapa 2 superó con mucho el máximo del plan. La etapa 3 llevaría la v2.0 a los 40 servidores. Alguien propone subir el máximo del plan para que la etapa 2 cuente como superada.