El planteamiento y cuándo aplica
Un entrevistador puede preguntar: “En un diseño de sistemas, ¿cómo utilizaría los presupuestos de error para equilibrar la confiabilidad y la velocidad de lanzamiento?”. Debe explicar cómo los SLI, los SLO y un presupuesto de error afectan los lanzamientos, los rollbacks, la capacidad y la coordinación del equipo. Esto se adapta a entrevistas de SRE, plataforma, backend y diseño de sistemas para roles senior que involucren alta disponibilidad, lanzamientos frecuentes o dependencias entre múltiples equipos.
Qué evalúa el entrevistador
La prueba no consiste en si puede recitar 99.99%. Se trata de si puede convertir un objetivo de experiencia del usuario en una regla de decisión operativa. Google SRE describe un presupuesto de error como el espacio restante por debajo de un SLO, utilizado para coordinar el trabajo de confiabilidad y la innovación; cuando el presupuesto se agota, los cambios ordinarios se pausan mientras se restaura la confiabilidad. Los entrevistadores también buscan una ventana de medición, calidad de los datos, entrega progresiva y excepciones auditables.
Preguntas aclaratorias para hacerse a uno mismo
Aclare quiénes son los usuarios, qué recorrido importa, dónde se encuentra el límite del servicio y si el objetivo es disponibilidad, latencia, frescura o corrección. Confirme la ventana del SLO, las regiones, la propiedad de las dependencias y la capacidad de rollback. Si faltan números, establezca suposiciones como una ventana de cuatro semanas, 99.9% de disponibilidad y medición por solicitud de usuario válida.
Una estructura de respuesta de 30 segundos
Utilice cinco pasos:
- Defina un SLI y un SLO visibles para el usuario.
- Calcule el presupuesto de error de la ventana y explique qué lo consume.
- Conecte el presupuesto a la entrega progresiva, el rollback automático y las compuertas de cambio.
- Cuando el presupuesto se agote, congele los cambios ordinarios y financie el trabajo de confiabilidad, con excepciones explícitas para seguridad y correcciones urgentes.
- Utilice postmortems, atribución de dependencias y tendencias del presupuesto para ajustar el siguiente ciclo de planificación.
Respuesta detallada paso a paso
1. Definir el SLI a partir de los resultados del usuario
No utilice por defecto el uso de CPU del servidor o la latencia promedio como el objetivo de confiabilidad. Para un servicio de solicitudes, elija la proporción de solicitudes exitosas y solicitudes por debajo de un umbral de latencia; para un trabajo asíncrono, utilice la finalización a tiempo o la frescura del resultado. Separe las fallas que impactan al usuario de los reintentos internos y del tráfico no válido para que el ruido no consuma el presupuesto.
2. Elegir un SLO explicable y una ventana
Por ejemplo, un 99.9% de solicitudes válidas exitosas durante cuatro semanas permite aproximadamente un 0.1% de fallas. La ventana controla la sensibilidad ante incidentes cortos y tendencias largas. Con múltiples SLO, establezca la regla de combinación: un recorrido de usuario crítico puede bloquear el lanzamiento, mientras que una métrica secundaria informa a las alertas y la planificación. No promedie porcentajes sin explicar la población y los pesos.
3. Atribuir el consumo de presupuesto a los cambios
Registre el presupuesto total, la tasa de consumo (burn rate) y la causa. Etiquete por separado lanzamientos, configuración, fallas de dependencias, escasez de capacidad y falsos positivos. Solo una atribución confiable le dice al equipo si debe corregir código, agregar capacidad, cambiar un contrato de dependencia o reparar el monitoreo. La política de ejemplo de Google también distingue entre fallas en el servicio, fallas cuya propiedad pertenece a otro equipo y tráfico fuera del alcance del SLO.
4. Diseñar compuertas de lanzamiento y rollback progresivo
Envíe un cambio ordinario a una pequeña fracción de tráfico o a una región, observe la tasa de error, la latencia y la tasa de consumo, y luego expándalo. La compuerta debe verificar tanto el presupuesto restante como la tasa de consumo en una ventana corta; un promedio mensual seguro puede ocultar un incidente que empeora rápidamente. Cuando el comportamiento sea inesperado, haga rollback antes de diagnosticar para reducir el tiempo de recuperación. El rollback también necesita idempotencia y compatibilidad de datos.
5. Definir qué sucede después de agotar el presupuesto
Agotar el presupuesto no significa que el desarrollo se detenga para siempre. Congele las funciones ordinarias y los cambios de datos no esenciales, y luego priorice la capacidad, las pruebas, el aislamiento de dependencias, la degradación elegante y las correcciones de causa raíz. Las correcciones de seguridad y los defectos urgentes que abordan el incumplimiento del SLO pueden ser excepciones, pero registre el motivo, el aprobador y la revisión de seguimiento para que lo “urgente” no se convierta en una vía de escape permanente.
6. Manejar dependencias y propiedad entre equipos
No oculte cada falla externa dentro del SLO del servicio. Rastree los errores de dependencias, de clientes y del servicio por separado, y haga explícita la responsabilidad sobre la reparación y la comunicación. Cuando los equipos discrepen sobre las reglas de presupuesto, alinéese en torno al recorrido del usuario y las mediciones compartidas, y luego escale a través del propietario del servicio. Transferir culpas no es una estrategia de confiabilidad.
Ejemplo de respuesta de alta calidad
Esta respuesta ficticia debe reemplazarse con sus propios números y límites:
Definiría SLI de tasa de éxito y latencia para la solicitud de usuario más importante. Supongamos que el SLO de éxito de solicitudes válidas es del 99.9% durante cuatro semanas, por lo que el presupuesto de error es del 0.1% de las solicitudes válidas. El monitoreo muestra el presupuesto restante, la tasa de consumo de una hora y la atribución de fallas, excluyendo el tráfico fuera del límite del servicio. Los lanzamientos comienzan en una región con una pequeña fracción de tráfico y se expanden gradualmente; cruzar un umbral de consumo detiene el despliegue y activa el rollback. Mientras el presupuesto sea saludable, producto y SRE pueden realizar entregas dentro del margen de riesgo. Una vez agotado, los cambios ordinarios se congelan y el equipo prioriza la capacidad, las pruebas, el aislamiento de dependencias y las correcciones de causa raíz, con excepciones registradas para trabajos de seguridad. Cada incidente recibe una revisión sin culpas y las correcciones entran en el siguiente ciclo de planificación. Por lo tanto, la velocidad de lanzamiento se rige por el presupuesto restante y el riesgo observado, más que por preferencias.
Errores comunes
Tratar el presupuesto de error como permiso para causar fallas
El presupuesto representa el espacio de fallas toleradas por el usuario, no una cuota para crear incidentes. Explique el impacto en el usuario, la ventana, la tasa de consumo y la propiedad de la reparación.
Proporcionar solo un número de disponibilidad
Sin un SLI, una población y una ventana, un 99.99% no puede guiar una decisión. Agregue solicitudes válidas, latencia o frescura, y reglas para excluir el tráfico irrelevante.
Congelar los lanzamientos para siempre tras no alcanzar el presupuesto
Eso ignora correcciones de seguridad, migraciones y trabajo de recuperación. Defina excepciones, aprobaciones, rollback y revisiones para que las excepciones no se conviertan en la ruta por defecto.
Ignorar la entrega progresiva y la compatibilidad del rollback
“Monitorear y lanzar” no es suficiente. Describa etapas de tráfico, condiciones de parada automática, orden de rollback y compatibilidad entre lecturas y escrituras antiguas y nuevas.
Preguntas de seguimiento y práctica avanzada
El SLO es saludable, pero la tasa de consumo de una hora es alta. ¿Realizaría el lanzamiento?
Compare el balance de la ventana larga con la tendencia de la ventana corta. Si el consumo es sostenido, detenga la expansión del tráfico, verifique si se trata de un impacto real en el usuario, un pico de tráfico o un defecto de monitoreo, y luego decida si hacer rollback.
Una dependencia externa agotó el presupuesto. ¿Debería congelarse también su equipo?
Verifique si el compromiso del servicio incluye la falla de esa dependencia y luego decida a partir del recorrido del usuario. Proteja a los usuarios y habilite la degradación incluso cuando la propiedad sea externa; la regla de congelamiento debe acordarse por adelantado con intercambio de evidencias y escalamiento.
Varios SLO fallan a la vez. ¿Cómo prioriza?
Clasifique por recorrido crítico del usuario, radio de impacto (blast radius), tasa de consumo y reversibilidad. Aborde primero el indicador que pueda expandir el incidente o bloquear la recuperación, luego los problemas de rendimiento locales, y exponga el balance de compensaciones (tradeoff).
Un product manager le pide lanzar después de agotarse el presupuesto. ¿Cómo responde?
Transforme el debate en datos: muestre el presupuesto restante, el impacto en el usuario, el costo del rollback y el tiempo de reparación. Ofrezca un experimento pequeño o un aplazamiento. Si persiste una emergencia empresarial genuina, utilice una excepción completamente registrada y programe el trabajo de confiabilidad y la revisión posterior.