Ideas clave
- Empiece con las diez tablas que alimentan sus reportes más usados, no con todo el almacén de datos.
- Cinco tipos de controles cubren la mayoría de las fallas: frescura, unicidad, nulos, integridad referencial y rangos de valores.
- Decida de antemano a quién se avisa y qué ocurre cuando una prueba falla.
- Las pruebas son un activo vivo: agregue una cada vez que se escape un error.
La cifra que estuvo mal durante tres días
Un reporte muestra una fuerte caída de ingresos. La gente reacciona, se convocan reuniones y luego alguien descubre que una carga anterior falló en silencio y la tabla simplemente estaba desactualizada. Los datos no estaban mal de forma sutil; estaban atrasados, y nada avisó a nadie. La mayoría de los incidentes de datos son así: aburridos, detectables y costosos solo porque los encontró una persona en el peor momento.
Un conjunto pequeño de pruebas automáticas puede detectar la mayoría. Puede tener una primera versión útil en una semana si mantiene el alcance acotado.
Día 1: elija qué proteger
Liste los reportes y dashboards que la dirección y los clientes realmente usan. Rastree cada uno hasta las tablas de las que depende. Elija aproximadamente las diez tablas más importantes. Anote, para cada una, quién es su responsable y qué tan fresca debe estar. Ignore por ahora la cola larga: cubrir bien las diez correctas vale más que cubrir superficialmente quinientas.
Días 2 y 3: los cinco controles
- Frescura: ¿se actualizó esta tabla dentro de la ventana esperada? Compare la última marca de carga o de evento con la hora actual.
- Unicidad: ¿la clave es realmente única? Los identificadores de pedido o de cliente duplicados son una causa clásica de totales inflados.
- No nulos: ¿están completos los campos obligatorios? Concéntrese en claves, fechas, montos y estados, no en todas las columnas.
- Integridad referencial: ¿cada clave foránea apunta a un registro padre existente, como cada línea de pedido a un pedido y cada pedido a un cliente?
- Controles de valores y volumen: ¿los montos son no negativos donde corresponde, las fechas están en un rango razonable, los estados dentro de la lista permitida y el número de filas dentro de una banda razonable respecto al día anterior?
La mayoría de las herramientas modernas de datos soportan estos controles como pruebas declarativas, y también puede escribirlos como consultas SQL simples que devuelven cero filas cuando todo está bien. Use lo que su equipo pueda mantener.
Día 4: defina umbrales y severidad
No toda falla merece una alerta a medianoche. Clasifique las pruebas como bloqueantes o de advertencia. Una clave duplicada en una tabla de ingresos puede bloquear las construcciones posteriores; un pequeño aumento de nulos en un campo opcional quizá solo deba advertir. Para los controles de volumen, prefiera una banda de tolerancia basada en el historial reciente en lugar de un número fijo, para que los patrones semanales normales no generen ruido.
La fatiga de alertas mata los conjuntos de pruebas. Si un control se dispara con frecuencia y nadie actúa, ajústelo o elimínelo. Un conjunto silencioso en el que la gente confía vale más que uno ruidoso que todos silencian.
Día 5: conecte responsables y respuesta
- Envíe las alertas a un canal que el equipo responsable realmente lea, con el nombre de la tabla, el control que falló y un enlace a las filas con problemas.
- Nombre un responsable por tabla y una persona de guardia o de triaje rotativa para el conjunto de pruebas.
- Decida qué ocurre ante una falla: detener el pipeline, marcar el dashboard como desactualizado o continuar con un aviso visible.
- Muestre el estado de los datos donde la gente mira. Una hora de última actualización visible en el dashboard evita muchas falsas alarmas.
- Mantenga un breve manual con las fallas más comunes y sus causas habituales.
Después de la primera semana
Ejecute las pruebas en cada carga programada y, cuando pueda, sobre los cambios antes de desplegarlos. Registre qué pruebas fallan más y trate a los reincidentes como problemas de origen que deben resolverse con el responsable de la fuente, no como ruido que se debe suprimir.
Agregue una prueba cada vez que se escape un defecto. Si una unión incorrecta infló los totales el mes pasado, escriba el control de unicidad que la habría detectado. En unos meses el conjunto se convierte en un registro de sus modos de falla reales. Más adelante puede sumar conciliaciones con los sistemas de origen y pruebas de reglas de negocio, como que el ingreso neto nunca supere al bruto, pero los cinco controles básicos le dan la mayor parte de la seguridad con muy poco esfuerzo.
