Software Architect · Módulo 15
Un sistema confiable no promete que nada se va a romper. Limita el daño, se recupera rápido y es honesto sobre su propio estado.
SLO · error budget · graceful degradation · recovery
Reliability es una calidad de servicio gestionada, con objetivos explícitos — no la esperanza de que el código salga bien.
Los SLO traducen reliability al lenguaje del producto
"Los trenes tienen que andar bien" es imposible de verificar. "El 99% de los trenes llega con menos de cinco minutos de demora" sí se puede medir.
Un SLA es una promesa al cliente. Un SLO es el objetivo interno. Un SLI es el indicador medido: availability, latency, error rate, freshness. El error budget dice cuántas fallas se toleran dentro del período.
El arquitecto usa los SLO para elegir trade-offs: si el error budget se está quemando, el equipo baja el riesgo de los releases; si sobra budget, se puede experimentar más rápido.
El fallo tiene que ser un escenario esperado
El plan de evacuación no se arma porque uno quiera un incendio. Se arma porque el incendio es posible.
La reliability se construye con timeouts, retries, bulkheads, rate limits, circuit breakers, backups, restore drills, health checks, runbooks e incident response. La prevention importa — pero también la detection, la mitigation y el recovery.
El sistema tiene que degradarse de forma controlada: si el recommendation engine se cae, el checkout sigue funcionando; si analytics está atrasado, la acción del usuario no debería quedar colgada por eso.
La reliability no se prueba con un slide deck — se prueba con un incidente o con un drill.
Ejemplo: graceful degradation del search
Si el panel de partidas del aeropuerto se apaga, el personal igual necesita una lista de respaldo de los vuelos.
El search service no está disponible. La product page se sigue abriendo, el catálogo muestra un fallback con productos populares y la UI le dice al usuario que la búsqueda está temporalmente limitada. Un alert llega al on-call y el runbook cubre la verificación del índice y el rollback.
El usuario ve una feature degradada — no el producto entero caído.
Antiejemplo: backup sin restore
Una llave de repuesto no sirve si nadie sabe qué puerta abre.
El equipo dice que los backups están configurados. Pero el restore nunca se probó, el RPO y el RTO son desconocidos, sólo una persona tiene acceso a los backups y el procedimiento de recovery no está documentado.
Un backup es sólo la mitad de la reliability. La garantía real aparece después de un restore drill exitoso.
- ¿Qué SLI reflejan realmente la experiencia del usuario? - ¿Cuál es el RPO y RTO de los datos críticos? - ¿Qué va a seguir funcionando si se cae una dependencia? - ¿Cuándo fue la última vez que se verificó el restore?