Planteamiento y contexto
Diseña un servicio que calcule SLOs, presupuestos de errores y tasas de consumo para muchos servicios, y que active compuertas de confiabilidad y alertas. ¿Cómo manejas los datos tardíos, las ventanas, los silenciamientos, los backfills y las excepciones?
Esto encaja en roles de SRE, plataforma, backend y diseño de sistemas. El libro de trabajo de SRE de Google describe los presupuestos de errores como una forma de equilibrar la confiabilidad con la velocidad de entrega, mientras que las alertas por tasa de consumo se enfocan en qué tan rápido se consume ese presupuesto. El diseño debe conectar definiciones, cómputo, alertas, decisiones y auditabilidad.
Qué está evaluando el entrevistador
- Distinguir los eventos de SLI, el objetivo de SLO, el período de cumplimiento, el presupuesto de errores y la tasa de consumo.
- Explicar por qué las ventanas rápidas y lentas se complementan entre sí y cómo se controla el ruido.
- Diseñar la deduplicación, los datos tardíos, las muestras duplicadas, los backfills y el recálculo versionado.
- Separar las alertas de las compuertas de despliegue, la respuesta de guardia (on-call), los silenciamientos y las excepciones humanas.
- Establecer límites para el aislamiento de inquilinos (tenants), el costo de consultas, la trazabilidad histórica y los permisos.
- Validar políticas con métricas de calidad de datos y repetición (replay) en lugar de solo dibujar un panel de control.
Estructura de respuesta en 30 segundos
“Dividiría el servicio en especificaciones de SLO, ingesta de eventos, agregación de ventanas, cálculo de presupuesto, evaluación de políticas y auditoría de notificaciones. Cada SLO fija eventos exitosos y totales, objetivo, período de cumplimiento y versión; la tasa de consumo es la tasa de error observada dividida por la tasa de error permitida. Una ventana rápida detecta picos y una ventana lenta confirma la persistencia, con verificaciones de frescura y tamaño de muestra. Los datos tardíos o retroactivos (backfilled) crean un recálculo versionado en lugar de reescribir silenciosamente una decisión auditada”.
Análisis detallado paso a paso
Paso 1: Definir el SLI y el contrato de eventos
Una especificación de SLO nombra el servicio, el tipo de métrica, los eventos exitosos, los eventos totales, el objetivo, el período de cumplimiento, las dimensiones de agregación y la zona horaria. Los contadores necesitan una clave de deduplicación estable y la hora del evento. Las cancelaciones de clientes, las fallas de dependencias y los fallos de plataforma no deben mezclarse sin una política explícita. Una vez publicada, la especificación se versiona para que los cálculos históricos utilicen la versión que estaba activa en ese momento.
Paso 2: Calcular el presupuesto y la tasa de consumo
Para un objetivo del 99.9%, la proporción de error permitida durante el período de cumplimiento es del 0.1%. Divide la tasa de error de la ventana actual por esa tasa permitida para obtener la tasa de consumo: 1 consume el presupuesto al ritmo planificado, mientras que un valor superior a 1 lo consume más rápido. Almacena recuentos sin procesar y agregados con numeradores, denominadores y límites de tiempo para que los resultados puedan recalcularse en lugar de conservar solo un porcentaje.
Paso 3: Combinar ventanas rápidas y lentas
Una ventana rápida detecta un pico de lanzamiento rápidamente; una ventana lenta confirma que el impacto persiste. Una política registra ambas duraciones de ventana, umbrales de tasa de consumo, volumen mínimo de eventos y evaluaciones requeridas. Se activa solo cuando la frescura y el tamaño del denominador son suficientes. Los servicios pueden usar diferentes políticas, pero las plantillas deben indicar el propósito en lugar de forzar cada alerta a un solo umbral.
Paso 4: Manejar datos tardíos, duplicados y retroactivos (backfilled)
Haz que la ingesta sea idempotente por ID de evento o intervalo de tiempo (bucket), y persiste una marca de agua (watermark) de agregación y una versión de corrección. Los eventos tardíos dentro del retraso permitido activan el recálculo; los eventos fuera de él marcan los datos como incompletos. Un backfill no debe cambiar silenciosamente una notificación o compuerta antigua. Registra el valor anterior, el nuevo valor, el operador, el motivo y el ID de decisión afectado.
Paso 5: Conectar alertas, compuertas y excepciones
El servicio de alertas notifica y escala, el controlador de despliegues pausa o solicita aprobación, y el servicio de políticas emite un estado respaldado por evidencia. Una excepción tiene alcance, vencimiento, aprobador y motivo. Un silenciamiento suprime únicamente la notificación; no detiene el cálculo del presupuesto. Cada compuerta incluye el SLO, la ventana, los recuentos, la frescura y las versiones de reglas para que la decisión pueda auditarse.
Paso 6: Escalar y observar el servicio
Fragmenta (shard) la agregación por servicio, región e inquilino, limita las dimensiones de alta cardinalidad y almacena en caché las consultas repetidas. Monitorea el retraso de ingesta, la pérdida, la duplicación, la demora de agregación, el tiempo de evaluación, el éxito de las notificaciones y los errores de políticas. Reproduce incidentes históricos para validar ventanas e inyecta fallas para medir la latencia de extremo a extremo de evento a alerta y de evento a compuerta. Los datos incompletos deben mostrarse como desconocidos y escalarse, no reportarse como saludables.
Compensaciones, límites y ganancia de información
El servicio de presupuesto de errores convierte un objetivo de confiabilidad en una decisión de ingeniería auditable. Umbrales de tasa de consumo más sensibles aumentan el ruido y la carga de alertas; ventanas más largas responden más lentamente. Separa los hechos computados, las acciones de notificación y las decisiones de despliegue. Permite el recálculo corregido mientras conservas las versiones históricas. El servicio suministra evidencia compartida; no elige las prioridades del equipo.
Respuesta modelo de alta calidad
“Comenzaría con una especificación de SLO versionada que cubra eventos exitosos y totales, objetivo, período de cumplimiento, dimensiones y deduplicación. La ingesta idempotente almacena numeradores, denominadores, límites de tiempo y marcas de agua por servicio y ventana. La agregación calcula la tasa de error, la tasa de error permitida y la tasa de consumo. La evaluación de políticas utiliza una ventana rápida para picos y una ventana lenta para la persistencia, verificando el volumen mínimo y la frescura.
Las notificaciones, las compuertas de despliegue y las excepciones humanas son consumidores separados. El silenciamiento suprime la notificación pero mantiene el cómputo en ejecución; una compuerta emite evidencia con versiones de SLO, ventana, recuentos, reglas y datos; las excepciones son aprobadas, limitadas en el tiempo y auditables. Los datos tardíos generan un recálculo versionado en lugar de modificar silenciosamente una decisión previa.
A escala, aplico particionamiento (sharding) por servicio, región e inquilino, limito las etiquetas de alta cardinalidad y monitoreo el retraso de ingesta, duplicados, pérdidas, demoras de agregación y éxito de notificaciones. La repetición (replay) y la inyección de fallas validan la política. Los datos incompletos se marcan como desconocidos y se escalan en lugar de contabilizarse como cero errores”.
Errores comunes
- Almacenar solo el porcentaje del SLO → el tamaño de la muestra y los límites desaparecen → conservar el numerador, el denominador, la ventana y la marca de agua.
- Un único umbral para cada servicio → el riesgo y el tráfico difieren → versionar las políticas por objetivo, volumen y ventana.
- Tratar el silenciamiento como la detención del cálculo → se pierden los datos del presupuesto → suprimir solo las notificaciones y mantener la auditoría.
- Sobrescribir el historial con datos tardíos → las decisiones de lanzamiento no se pueden reconstruir → versionar los recálculos y conservar los valores antiguos y nuevos.
- Tratar los datos faltantes como saludables → las fallas de recolección quedan ocultas → mostrar como desconocido y alertar sobre la calidad de los datos.
- Hacer que una compuerta dependa del estado de la notificación → los reintentos de notificación cambian los resultados del lanzamiento → las compuertas deben leer evidencia de evaluación inmutable.
Preguntas de seguimiento y respuestas
¿Por qué usar tanto ventanas rápidas como lentas?
La ventana rápida reduce el tiempo de detección de picos; la ventana lenta filtra el ruido transitorio y confirma el consumo sostenido del presupuesto. Juntas equilibran la velocidad de respuesta y los falsos positivos, pero los umbrales deben validarse frente al volumen de eventos.
¿Qué sucede con una alerta antigua después de que un backfill cambia la tasa de consumo?
Conserva los registros antiguos de evaluación y notificación, crea un recálculo etiquetado con la nueva versión de datos e indica si la compuerta actual cambia. No elimines el historial; los responsables de guardia necesitan los hechos disponibles en ese momento.
¿Cómo evitas que las dimensiones de alta cardinalidad sobrecarguen el sistema?
Limita las etiquetas permitidas, muestrea particiones de inquilinos o rutas por nivel (tier), materializa solo vistas valiosas y aplica presupuestos y tiempos de espera (timeouts) a las consultas. Un SLO a nivel de servicio no debería requerir dimensiones ilimitadas.
¿Cómo evitan las excepciones eludir permanentemente las compuertas?
Vincula cada excepción a un servicio, cambio o rango de tiempo, exige un aprobador y un motivo, y aplica un vencimiento automático. Restaura la política predeterminada después y mide la cobertura de excepciones como una métrica de auditoría.