Planteamiento y contexto
Una métrica central de ingresos necesita una corrección en su tratamiento de reembolsos, mientras que cientos de paneles, alertas y productos de datos todavía usan la definición antigua. Diseña un contrato de versionado y obsolescencia de métricas que haga que el cambio sea explicable, migrable y reversible.
No limites la respuesta a un solo proveedor de catálogo o capa semántica. Concéntrate en definiciones, dependencias, ventanas de compatibilidad, compuertas de lanzamiento (release gates), avisos a consumidores y evidencia de retiro.
Qué evalúa el entrevistador
Límites semánticos
¿Puedes transformar el nombre de una métrica en un contrato que contenga fórmula, filtros, semántica temporal, granularidad, unidad, zona horaria, versión y propietario, en lugar de cambiar el SQL silenciosamente?
Análisis de impacto
¿Puedes enumerar paneles, alertas, exportaciones, modelos y APIs, distinguiendo las dependencias directas de las indirectas?
Gobernanza de la migración
¿Puedes ejecutar las versiones antigua y nueva en paralelo con fechas límite, aprobadores y estados de migración, en lugar de causar una ruptura repentina y oculta (big-bang break)?
Retiro verificable
¿Puedes demostrar el retiro mediante uso, conciliaciones, reproducción de alertas y evidencia de que las llamadas antiguas han desaparecido?
Preguntas de clarificación que debes hacer
- ¿El cambio es una corrección de errores (bug fix), un cambio en la definición de negocio o una migración de fuentes?
- ¿Finanzas, auditoría, recomputación histórica o retención legal requieren la métrica antigua?
- ¿Los consumidores usan SQL, BI, APIs, exportaciones o características de machine learning?
- ¿Existe un SLA interdepartamental o con clientes externos?
- ¿Cuánto tiempo pueden ejecutarse ambas versiones y quién puede extender esa ventana?
- Si los valores divergen, ¿hacemos rollback de la definición, de los datos o de la capa de presentación?
Marco de respuesta en 30 segundos
“Trataría la definición de la métrica como un contrato versionado que contiene fórmula, filtros, granularidad, semántica temporal y propietario. Primero construiría un grafo de dependencias y una instantánea de uso; luego publicaría una nueva versión manteniendo la antigua; cada respuesta expondría la versión y la hora de vigencia. La migración priorizaría a los consumidores de alto riesgo y usaría muestras fijas, reproducciones históricas y conciliaciones. Durante la obsolescencia (deprecation), notificaría a los propietarios y bloquearía el uso nuevo. Retiraría la métrica solo después de que las llamadas antiguas lleguen a cero, los consumidores críticos confirmen y los registros de auditoría estén completos, conservando al mismo tiempo definiciones recuperables e instantáneas de resultados.”
Análisis detallado paso a paso
Paso 1: Congelar el contrato actual
Registra el nombre de la versión antigua, fórmula, filtros, granularidad, unidad, zona horaria, fuente, frescura, propietario, sensibilidad y hora de vigencia. Genera una versión inmutable para cada cambio; nunca sobrescribas silenciosamente.
Paso 2: Construir grafos de dependencias y de riesgo
Recopila dependencias de la capa semántica, registros de consultas, metadatos de BI, trabajos programados, definiciones de alertas y llamadas a APIs. Marca a los consumidores financieros, visibles para clientes, casi en tiempo real y de machine learning; luego clasifica la migración por impacto y uso.
Paso 3: Definir la compatibilidad
Un cambio de alias o solo de visualización puede usar un alias de compatibilidad. Un cambio de fórmula, granularidad o semántica temporal obtiene una nueva versión. Las respuestas, los metadatos de exportación y la documentación devuelven la versión, la unidad y la referencia de definición para que los consumidores no tengan que adivinar.
Paso 4: Establecer compuertas para el nuevo lanzamiento
Ejecuta la nueva versión en un entorno de pruebas (sandbox) y con una cohorte pequeña de consumidores. Las compuertas verifican el análisis sintáctico de expresiones, valores de muestra, reproducción histórica, valores nulos, unidades, permisos, latencia y costo. Los propietarios y los consumidores afectados aprueban antes de la expansión.
Paso 5: Migrar y notificar
Asigna un propietario, una fecha límite y un estado a cada dependencia. Usa el estado del catálogo, verificaciones de CI, pistas de consulta (query hints) e informes recurrentes para notificar a los usuarios de la versión antigua. Bloquea nuevos paneles para que no hagan referencia a la versión antigua; las excepciones necesitan una fecha de expiración.
Paso 6: Aceptar, revertir y retirar
Compara versiones en muestras fijas, ventanas históricas y paneles críticos, explicando los cambios causados por reembolsos, datos tardíos o zonas horarias. Mantén la definición antigua y las instantáneas de resultados; pausa el retiro o regresa a la versión anterior cuando aparezcan anomalías. Retira únicamente después de que las llamadas antiguas lleguen a cero y los materiales de auditoría, confirmación de consumidores y rollback estén completos.
Ejemplo de respuesta sólida
“Congelaría la definición actual de ingresos como v1, documentando explícitamente el momento de reconocimiento, tratamiento de reembolsos, moneda, zona horaria, granularidad y propietario. Los registros de consultas y los metadatos del catálogo producirían un grafo de dependencias, marcando como de alto riesgo los informes financieros, las facturas de clientes y las alertas.
Si corregir los reembolsos cambia la fórmula, publicaría v2 en lugar de sobrescribir v1. Ambas versiones se ejecutarían en paralelo y los valores incluirían versión, unidad y frescura. CI bloquearía nuevas referencias a v1, mientras que la lista de migración registra propietarios y fechas límite. Conciliaría órdenes conocidas y meses fijos, y luego reproduciría alertas, exportaciones y APIs; cada diferencia necesita una explicación.
Una vez que los consumidores de alto riesgo confirmen, el uso de v1 sea continuamente cero y la documentación y los registros de auditoría estén completos, congelaría v1 en modo de solo lectura y establecería una fecha de apagado final. Conservaría su definición e instantáneas de resultados para que los informes históricos sigan siendo rastreables y las anomalías se puedan recuperar.”
Errores comunes
- Editar SQL con el mismo nombre, haciendo que los informes históricos cambien de significado silenciosamente.
- Inspeccionar solo las referencias del catálogo y pasar por alto registros de consultas, alertas, exportaciones o APIs.
- Reutilizar una misma clave de caché o tabla de resultados para las versiones antigua y nueva.
- Omitir campos de unidad, zona horaria, granularidad o versión, forzando a los consumidores a adivinar.
- Enviar un anuncio sin propietarios, fechas límite ni mecanismos de aplicación.
- Usar una diferencia promedio para ocultar la divergencia de un mes crítico o de un cliente de alto riesgo.
- Eliminar la definición antigua antes de que sea posible la explicación histórica o el rollback.
- Tratar una sola caída en el uso como prueba definitiva, pasando por alto trabajos por lotes (batch) y consultas de auditoría poco frecuentes.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Qué se considera un cambio que rompe la compatibilidad (breaking change)?
Un cambio en la fórmula, filtro, granularidad, unidad, zona horaria, confiabilidad de la fuente o semántica de permisos es un breaking change. La edición de un alias o descripción es compatible solo cuando el contrato del resultado permanece sin cambios.
Pregunta de seguimiento 2: ¿Cómo evitas que nuevos paneles adopten la versión antigua?
Marca la versión antigua como obsoleta (deprecated) y haz que CI y la capa semántica rechacen nuevas referencias. Las pistas de consulta (query hints) muestran el reemplazo; las excepciones requieren un propietario, motivo y expiración.
Pregunta de seguimiento 3: ¿Cómo demuestras que una diferencia numérica no es un error (bug)?
Reproduce muestras fijas, ventanas históricas, órdenes límite y totales de conciliación. Descompón las diferencias por reembolsos, retrasos, moneda y zona horaria, y luego obtén la aprobación formal del propietario de negocio.
Pregunta de seguimiento 4: ¿Qué pasa si un consumidor de baja frecuencia nunca migra?
Establece una fecha límite estricta basada en el riesgo y proporciona un informe de migración junto con la consulta de reemplazo. Permite extensiones controladas para consumidores de cumplimiento o facturación, registrando el motivo, aprobador y la nueva fecha.
Pregunta de seguimiento 5: ¿Se pueden responder preguntas históricas después del retiro?
Conserva definiciones inmutables, versiones, instantáneas de entrada o materiales reproducibles, y registra la versión utilizada por cada informe histórico. Eliminar un endpoint activo no elimina la evidencia de auditoría.