Confiabilidad y operaciones

Un sistema perfectamente seguro que se cae le sigue fallando a todos los que dependen de él. Este tema pasa de quién protege tus recursos en la nube a cómo se mantienen funcionando: los patrones de redundancia que sobreviven una falla de hardware, la automatización que ajusta la capacidad a la demanda, el plan para cuando una falla es más grande de lo que la redundancia por sí sola puede absorber, y la forma en que los equipos realmente se enteran de que algo salió mal.

Qué cubre este tema

• alta disponibilidad y tolerancia a fallos, y por qué una recuperación automática breve y una interrupción cero son 2 garantías distintas, y con precios distintos
• redundancia activo-activo y activo-pasivo, y cómo repartir cómputo y bases de datos entre zonas de disponibilidad elimina un punto único de falla
• escalabilidad y elasticidad, y por qué la capacidad de un sistema para crecer no es lo mismo que crecer y encogerse solo, en automático, según la demanda en tiempo real
• la mecánica de un grupo de Auto Scaling: capacidad mínima, deseada y máxima, y las políticas de escalado por seguimiento de destino, por pasos y programado
• el Recovery Time Objective y el Recovery Point Objective, y las 4 estrategias de recuperación ante desastres, de respaldo y restauración a multi-sitio activo/activo, que cambian costo por velocidad de recuperación
• monitoreo con métricas, logs y alarmas, y la diferencia entre un SLI, un SLO y un SLA

Por qué importa

Cada patrón de este tema responde una versión de la misma pregunta: qué pasa cuando algo falla de todos modos. El hardware falla a las 2 a.m. sin importar qué tan bueno sea el código, así que la redundancia Multi-AZ y la distinción entre alta disponibilidad y tolerancia a fallos deciden si esa falla es invisible o apenas sobrevivible. La demanda nunca se mantiene plana, así que la escalabilidad y la elasticidad deciden si un equipo paga su peor día del año todo el año, o solo cuando de verdad llega. La redundancia dentro de una región eventualmente se topa con una falla más grande de lo que fue diseñada para absorber, que es exactamente lo que existen para acotar el Recovery Time Objective, el Recovery Point Objective y una estrategia probada de recuperación ante desastres.

Nada de esto significa algo sin una forma de enterarte de que ocurrió una falla y de decir, con números, qué tan confiable fue realmente un sistema. Eso es lo que cierran el monitoreo y los SLA en este tema: métricas y alarmas que detectan un problema en minutos en vez de por una queja de un cliente, y una lectura clara de qué compensa el SLA de un proveedor y qué nunca cubre. Juntos, este tema te da el vocabulario que espera tanto una entrevista de trabajo en la nube como el camino de certificación de este curso: no solo cómo construir un sistema resiliente, sino cómo demostrar, con números, que se mantuvo así.