Monitoreo y SLA

Cada patrón de este tema asume que te enteras

Redundancia Multi-AZ, health checks de Auto Scaling, un plan probado de recuperación ante desastres: cada patrón que ha cubierto este tema hasta ahora asume algo, en silencio. Asume que te enteras de que está ocurriendo una falla, idealmente antes de que se entere un usuario, y asume que alguien puede decir después, con números concretos, qué tan confiable fue realmente el sistema. Esta lección cubre las 2 mitades: el monitoreo, que es cómo te enteras, y los SLA, que son la promesa documentada sobre qué tan seguido no debiste haber tenido que enterarte.

Monitoreo: métricas, logs y alarmas

3 piezas cubren casi todo lo que hace una configuración de monitoreo. Una métrica es un número registrado a lo largo del tiempo: uso promedio de CPU, solicitudes por segundo, tasa de errores. Un log es el registro de un evento específico, una línea que dice exactamente qué pasó y cuándo, útil para investigar después de que algo ya salió mal, más que para vigilar una tendencia. Una alarma vigila una métrica contra un umbral y toma una acción en cuanto ese umbral se rompe durante un periodo definido.

Amazon CloudWatch es la implementación de AWS de las 3 cosas: recolecta métricas automáticamente de casi todos los servicios de AWS, guarda y te deja consultar logs, y te deja definir alarmas encima de cualquiera de los 2. Un ejemplo concreto: una alarma vigila el uso promedio de CPU en periodos de 5 minutos, y si se mantiene por encima del 80% durante 3 periodos consecutivos, la alarma se dispara, lo que podría avisarle a un ingeniero de guardia o, conectando con la lección anterior, alimentar directamente una política de seguimiento de destino de Auto Scaling que lanza más capacidad. Azure Monitor y Google Cloud Operations cumplen el mismo papel en sus propias plataformas; el vocabulario cambia un poco, pero métricas, logs y alarmas son las mismas 3 piezas en todos lados.

SLI, SLO, SLA: medir, apuntar, prometer

Estos 3 términos se usan casi como sinónimos en una conversación informal, y el límite de examen entre ellos vale la pena aprenderlo con precisión.

Un Service Level Indicator (SLI) es una medición cuantitativa de qué tan bien está funcionando un servicio realmente, como el porcentaje de solicitudes que tienen éxito. Un Service Level Objective (SLO) es la meta interna que fija un equipo para ese SLI, como "apuntamos a 99.95% de solicitudes exitosas". Un Service Level Agreement (SLA) es la versión externa y contractual: una promesa hecha a los clientes que, si se incumple, trae consecuencias financieras, típicamente un crédito de servicio.

Piensa en un SLI como la lectura del velocímetro de un auto, en un SLO como el límite de velocidad que el conductor se compromete a respetar en privado, y en un SLA como la promesa hecha a un pasajero de que el viaje no va a superar cierta velocidad, respaldada por un reembolso si eso pasa. La comparación se sostiene para la relación entre medir, apuntar y prometer, pero se rompe en 1 punto: un SLI casi nunca es una sola lectura instantánea como un velocímetro, normalmente se agrega en una ventana de tiempo, 1 hora o 1 mes, no una mirada en vivo al tablero.

Los proveedores fijan a propósito el SLO más estricto que el SLA. Si un SLA público promete 99.9% de disponibilidad, el SLO interno que guía la operación del día a día podría ser 99.95%, dándole al equipo un margen para notar y reaccionar antes de que una meta interna incumplida se convierta en una promesa externa incumplida y compensable.

Los nueves: cuánto cuesta un porcentaje de disponibilidad en tiempo real de inactividad

Los números de disponibilidad se comparan de forma casual, "estamos en 4 nueves", sin que siempre se registre lo que eso significa realmente en horas. Cada nueve adicional divide entre 10, aproximadamente, el tiempo de inactividad permitido, por eso el salto de 99.9% a 99.99% es un compromiso de ingeniería mucho más grande de lo que sugieren los números por sí solos.

La mayoría de los productos SaaS y las APIs apuntan a 3 nueves. 5 nueves se reserva para sistemas donde incluso unos minutos de inactividad anual traen consecuencias financieras o de seguridad reales, y cuesta proporcionalmente más diseñarlo así.

Ejemplo trabajado: leer un SLA real

El SLA de Amazon EC2 es un caso concreto y útil. Se compromete a un Monthly Uptime Percentage a nivel región de al menos 99.99%, y por separado a un Instance-Level Uptime Percentage de al menos 99.5% para instancias individuales. Si la disponibilidad real a nivel región cae por debajo en un mes dado, los niveles de crédito son 10% para 99.0% hasta (sin incluir) 99.99%, 30% para 95.0% hasta (sin incluir) 99.0%, y 100% por debajo de 95.0%.

En concreto: si la disponibilidad de EC2 a nivel región llega a 98.5% en un mes, eso cae en la banda de 95.0% a menos de 99.0%, y el cliente puede reclamar un crédito del 30% sobre la factura de ese servicio para el mes, aplicado en automático o a solicitud según el proveedor, no un reembolso en efectivo y no una compensación por los ingresos que la caída le haya costado al propio negocio del cliente.

Lo que un SLA promete, y lo que no

Es tentador tratar "respaldado por un SLA" como "esto nunca va a caerse" o como un seguro contra las pérdidas del negocio. Ninguna de las 2 cosas es cierta. Un SLA es un mecanismo de compensación por el propio incumplimiento del proveedor frente a su compromiso publicado, pagado como crédito contra facturas futuras. Comúnmente excluye ventanas de mantenimiento programado y factores fuera del control del proveedor, y, igual que el modelo de responsabilidad compartida de antes en este dominio, solo cubre el propio servicio del proveedor. Una caída causada por un error en el propio código de la aplicación del cliente es su problema de confiabilidad, algo que le toca monitorear y arreglar; ningún SLA de proveedor se escribió jamás para cubrirlo.

El límite: encadenar servicios empeora el número general, no lo mejora

Una carga de trabajo rara vez depende de un solo servicio. Encadena 3 servicios con disponibilidad individual de 99.99%, 99.95% y 99.9%, y es tentador asumir que el más fuerte ayuda a jalar el promedio hacia arriba. No lo hace: la disponibilidad compuesta multiplica las probabilidades individuales en vez de promediarlas, así que 99.99% por 99.95% por 99.9% da alrededor de 99.84%, peor que cualquier componente individual de la cadena. Cada dependencia agregada es un impuesto sobre la confiabilidad general, por eso los arquitectos cuentan cuántos servicios toca de verdad la ruta de una solicitud crítica, no solo qué tan confiable es cada uno por separado.

Pistas de examen: emparejar un escenario con el término correcto

Dónde te deja esto

Un SLA es un contrato de compensación fijado en un piso por debajo de lo que un proveedor apunta en privado para sí mismo, nunca una garantía de que nada va a fallar, y el monitoreo es lo que realmente te dice, en tiempo real, si hoy es uno de los días en que se pone a prueba ese piso. Con esto se cierra Seguridad y confiabilidad: ya puedes nombrar quién es dueño de cada tarea de seguridad, cómo se mantienen en pie los sistemas durante una falla, cómo se recuperan de una más grande de lo que la redundancia podía absorber, y qué significa realmente una promesa de disponibilidad cuando no se cumple. El próximo dominio pasa de lo que ya sabes a hacia dónde te lleva: las carreras en la nube y el camino de certificación que este curso ha estado construyendo desde el inicio.