Planteamiento y contexto
El servicio tiene un SLO de disponibilidad del 99.99% y un error budget mensual del 0.01%. Las fallas visibles para el usuario ya han superado el presupuesto y, aun así, una funcionalidad que afecta una renovación importante está a la espera de ser implementada. Explique cómo define los indicadores, verifica que el presupuesto realmente se haya agotado, decide qué cambios se pausan y restablece un ritmo de lanzamientos saludable.
Google SRE considera el error budget como el margen de fallo permitido por un SLO: mientras exista margen, los equipos pueden lanzar cambios de forma razonable; una vez agotado, normalmente se congelan los cambios, salvo correcciones urgentes de seguridad y soluciones para la falla actual. Esto constituye un insumo para las decisiones de riesgo, no una prohibición absoluta a nivel de producto.
Qué evalúa el entrevistador
Una respuesta sólida comienza con SLI centrados en el usuario y conecta el consumo del presupuesto con los tiempos de lanzamiento, rollback y recuperación. Anticipe preguntas sobre por qué las métricas de servidor pueden distorsionar la disponibilidad real del usuario, cómo distinguir un pico breve de un consumo sostenido (burn), qué evidencia justifica una excepción y quién tiene la autoridad para levantar un congelamiento.
«Detener todo el desarrollo» pasa por alto obligaciones de seguridad, integridad de datos y cumplimiento normativo. «El negocio es importante, así que lancemos» descarta un lenguaje compartido de gestión de riesgos.
Preguntas para clarificar primero
Impacto en el usuario y delimitación de métricas
Confirme que los SLI provengan de flujos de usuario reales e incluyan clientes, dependencias y flujos de trabajo críticos. Separe los fallos de peticiones, la latencia, los datos incorrectos y la indisponibilidad; un promedio simple puede ocultar la latencia de cola (tail latency) o un impacto severo en un segmento específico de clientes.
Ventana del presupuesto y burn rate
Aclare si el presupuesto es mensual, trimestral o móvil, además del burn rate actual y el nivel de incertidumbre. El saldo disponible debe responder a «¿cuánto tiempo podemos sostener esto?» en lugar de limitarse a mostrar solo un porcentaje.
Valor y riesgo del lanzamiento
Evalúe el valor en términos de ingresos, cumplimiento y seguridad. ¿Es posible realizar un despliegue canary, hacer rollback o limitar la funcionalidad a tenants seleccionados? Sin un valor verificable y una vía de recuperación, la presión de los clientes no constituye evidencia suficiente de riesgo.
Respuesta de 30 segundos
«Primero valido los SLI del lado del usuario, la ventana del SLO y el burn rate, comprobando si la señal es sostenida o si se trata de un error de instrumentación. Si el presupuesto está verdaderamente agotado, pauso los lanzamientos no esenciales y oriento la capacidad y el esfuerzo de ingeniería a restablecer el SLO, corregir causas raíz y validar la monitorización. Los cambios de seguridad, cumplimiento normativo o mitigación de incidentes pueden ser excepciones siempre que sean pequeños, reversibles y cuenten con un responsable asignado. Para la funcionalidad del cliente importante, buscaría aislamiento por tenant o un despliegue canary postergado, y luego utilizaría una revisión de riesgos para decidir si se procede. Una vez que regrese el margen de presupuesto acordado, reabriría los lanzamientos de forma gradual y evaluaría si el SLO realmente representa el valor para el usuario».
Solución paso a paso
Paso 1: Definir los SLI como resultados de usuario
Defina la tasa de éxito, la latencia de extremo a extremo y la exactitud para los flujos de trabajo críticos, utilizando datos del cliente o del edge siempre que sea posible. Especifique qué cuenta como una petición válida, las ventanas de mantenimiento y la segmentación de tenants. Si a los usuarios les interesa la finalización de una exportación, cree un SLI de finalización de tareas en lugar de depender únicamente de una respuesta HTTP 200 de la API.
Paso 2: Calcular el presupuesto y el burn rate
Un objetivo de disponibilidad del 99.99% permite una tasa de fallas del 0.01% en la ventana seleccionada; la cantidad de minutos depende de dicha ventana y del método de cómputo. Utilice una única consulta para calcular el presupuesto restante, el burn rate y la incertidumbre, etiquetando los retrasos de datos. Antes de actuar ante una anomalía, revise si existen recuentos duplicados, telemetría faltante o problemas de atribución a dependencias.
Paso 3: Establecer compuertas de lanzamiento (release gates)
Cuando el presupuesto es saludable, los lanzamientos normales aún exigen mecanismos de rollback y monitorización. A medida que se acerca al agotamiento, aumente el nivel de revisión y reduzca el tamaño de los lotes y la exposición en despliegues canary. Una vez agotado, congele los cambios no esenciales; permita únicamente correcciones de incidentes, labores de integridad de datos, parches de seguridad críticos o cambios de cumplimiento normativo con evidencia de rollback. Implemente esta compuerta en herramientas y en una matriz de responsabilidades en lugar de depender de acuerdos verbales.
Paso 4: Evaluar una excepción
Para cada excepción, registre el beneficio para el usuario, el riesgo, los tenants expuestos, el porcentaje de tráfico, la condición de rollback y la ventana de observación. El aislamiento a un único tenant, el tráfico en la sombra (shadow traffic) o el uso restringido a usuarios internos son evidencias útiles. Producto, el responsable del cambio y SRE deben aprobar conjuntamente; una promesa comercial por sí sola no puede definir la decisión.
Paso 5: Restablecer la confiabilidad antes de buscar la perfección
Durante el congelamiento, resuelva las causas raíz, los límites de capacidad y las brechas de monitorización, estableciendo un SLO de recuperación, un margen presupuestario y una fecha límite. Si el objetivo exige un esfuerzo desmedido y prolongado, ajústelo en una revisión formal, pero no altere la ventana de medición ni excluya fallas a posteriori solo para habilitar un lanzamiento.
Paso 6: Comunicar a los clientes y a los equipos
Explique el flujo de trabajo afectado, el rango temporal, las medidas de mitigación y la fecha de la próxima actualización. Ofrezca una alternativa verificable o un cronograma para la funcionalidad del cliente; no prometa un tiempo de recuperación sin verificar. Utilice un único panel de control de presupuestos, un cronograma de incidentes y una lista de responsables a nivel interno para reducir las fricciones políticas entre producto e ingeniería.
Paso 7: Gestionar la recuperación
Cuando el presupuesto alcance el umbral acordado, reabra los lanzamientos por etapas, comenzando con lotes pequeños. Revise los cambios fallidos, el retraso en la detección, la duración del rollback y el impacto en los clientes. Si el SLO no representa el valor para el usuario, proponga una modificación respaldada por datos. Conserve los registros de congelamientos, excepciones, aprobaciones y resultados para la revisión trimestral de riesgos.
Respuesta de muestra de alta calidad
No tomaría una decisión categórica basada únicamente en que «ventas tiene urgencia» o «el presupuesto es cero». Validaría los SLI del lado del usuario, la ventana estadística, la integridad de los datos y el burn rate, descartando errores de instrumentación y duplicidad de recuentos. Si el presupuesto está verdaderamente agotado, congelaría los lanzamientos no esenciales e invertiría recursos en la recuperación, correcciones y monitorización. Las áreas de seguridad, cumplimiento, reparación de datos y mitigación de incidentes podrían solicitar una excepción.
Si la funcionalidad del cliente clave debe avanzar, aislaría a los tenants, usaría un despliegue canary reducido, configuraría rollback automático y definiría una ventana de observación. Producto, el responsable del cambio y SRE aprobarían conjuntamente tras documentar beneficios, riesgos y condiciones de parada. Tras la recuperación del presupuesto, levantaría el congelamiento gradualmente y evaluaría si el SLO mide resultados reales para los usuarios antes de modificar los objetivos o el proceso.
Errores comunes
- Error: Congelar absolutamente todos los cambios tras agotar el presupuesto. → Por qué falla: Se pueden retrasar temas de seguridad, reparación de datos y mitigación de incidentes. → Solución: Definir excepciones acotadas, aprobadores y evidencias de rollback.
- Error: Utilizar únicamente la latencia promedio del servidor. → Por qué falla: Pasa por alto fallos en los clientes, la latencia de cola y la experiencia en tenants críticos. → Solución: Definir SLI de extremo a extremo basados en los flujos del usuario.
- Error: Cambiar la ventana del SLO o excluir fallas para poder lanzar. → Por qué falla: El presupuesto pierde comparabilidad y se oculta el riesgo. → Solución: Mantener la ventana actual y aplicar gobernanza formal para modificaciones posteriores.
- Error: Considerar que un canary exitoso es prueba suficiente para un lanzamiento completo. → Por qué falla: El nivel de exposición, las dependencias y el riesgo de cola son diferentes. → Solución: Escalar de manera gradual con rollback automático.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cuánto presupuesto representa el 99.99%?
La tasa de fallas permitida en la ventana seleccionada es del 0.01%. Convertir esto a minutos requiere conocer la ventana de tiempo, el método de conteo y si la métrica se basa en peticiones o en tiempo. La clave radica en explicitar la ventana en lugar de ofrecer una cifra absoluta sin contexto.
Pregunta de seguimiento 2: ¿Una funcionalidad prometida por ventas califica como excepción?
El valor comercial por sí solo no otorga una excepción. Se debe demostrar el impacto en el usuario, en los ingresos o en el cumplimiento normativo; aportar evidencia de aislamiento, canary, rollback y observación; y obtener la aprobación conjunta. Si no es posible mitigar la exposición, aplace la funcionalidad y ofrezca una alternativa.
Pregunta de seguimiento 3: ¿Qué ocurre si el cálculo del presupuesto pudiera ser erróneo?
Congele los lanzamientos de alto riesgo mientras comprueba en paralelo la cobertura de telemetría, el recuento duplicado, el retraso temporal, la atribución de dependencias y muestras de clientes. Recalcule tras la corrección, pero no amplíe la exposición mientras el resultado sea incierto.
Pregunta de seguimiento 4: ¿Cuándo se debe modificar el SLO?
Modifíquelo cuando una operación estable y los datos de revisión demuestren que el objetivo no se alinea con el valor para el usuario, los costos o la capacidad operativa. Documente previamente el objetivo anterior, el nuevo, el impacto y el aprobador. Un incidente o la presión por lanzar no justifican reducir un objetivo de forma improvisada.
Pregunta de seguimiento 5: ¿Cómo saber cuándo termina el congelamiento?
Defina previamente las condiciones de recuperación: que el SLI cumpla el objetivo durante una ventana de observación, que el presupuesto se haya recuperado hasta cierto umbral, que las correcciones de causa raíz estén verificadas y que el mecanismo de rollback funcione. A continuación, reanude con un lote pequeño y continúe monitorizando en lugar de regresar inmediatamente a la velocidad normal.