Tres Patrones Clásicos de Cascada

Las Fallas Viajan a Través de Dependencias

Patrón 1: Manada de Trueno. Un recurso compartido (cache, bloqueo, base de datos) falla o reinicia. Cada cliente que dependía de él vuelve a intentar simultáneamente. La inundación sobrepasa lo que vuelve a activarse; los intentos de nuevo se amontonan más rápido que la recuperación puede absorberlos; la recuperación nunca se completa.

Patrón 2: Tormenta de Intentos. Un servicio downstream ralentíza. Los llamadores de arriba, en lugar de fallar, intentan de nuevo. Los intentos se multiplican por la carga original. El servicio lento se ralentiza aún más, desencadenando más intentos. Finalmente, la carga supera incluso una versión saludable del servicio.

Patrón 3: Cola de muerte. Una cola de procesamiento sin retroalimentación recibe más rápido de lo que procesa. La cola crece ilimitadamente. El consumo agota la memoria; el consumidor se cae; reinicia; encuentra una cola aún más grande; se cae de nuevo.

Hilo común: una pequeña perturbación inicial desencadena un bucle de retroalimentación positiva. La respuesta del sistema amplifica el fallo en lugar de atenuarlo.

Mecanismos de Atenuación

Retraso exponencial con jitter. Los clientes que intentan de nuevo esperan más tiempo cada vez, con desviación aleatoria. Evita las olas sincronizadas de intentos.

Interruptor de circuito. Un llamador sigue la tasa de fallo de un downstream. Más allá de un umbral, el llamador para de llamar durante un período de enfriamiento y falla de inmediato sus propias solicitudes.

Bulbo. Aísla recursos por dependencia. Pila de conexiones A para la base de datos, piscina de conexiones B para el caché. Una base de datos lenta no puede estrechar a todas las conexiones; las llamadas al caché continúan.

Drenaje de carga. Cuando está sobrecargado, descarta solicitudes en la orilla en lugar de aceptarlas y fallar lentamente. Un 429 en 1 ms es mejor que un 500 en 30 segundos.

Presión de retroalimentación. Lentos productores cuando los consumidores no pueden mantener el ritmo. Las colas se vuelven limitadas; los emisores bloquean; la fuente original de trabajo siente la fricción.

Diagnostique una Cascada

Un equipo de API se derrumba durante un failover de base de datos rutinario. Cronología:

- 14:00:00 — el operador promueve la base de datos de reserva. Disponibilidad esperada: ~10 segundos.

- 14:00:08 — la primaria está inalcanzable. Las solicitudes de API tier comienzan a fallar con errores de conexión de base de datos.

- 14:00:08 — API tier intenta volver a intentar (configuración predeterminada: 5 intentos, sin retardo, 100ms de separación).

- 14:00:11 — la standby se promueve, aceptando nuevas conexiones.

- 14:00:11 — API tier abre miles de nuevas conexiones de base de datos simultáneamente (cada réplica × cada solicitud concurrente × cada intento de repetición).

- 14:00:13 — la piscina de conexiones de la nueva primaria se agota; las nuevas conexiones se rechazan.

- 14:00:13-14:05:00 — las réplicas de API tier agotan las piscinas de conexiones, arrojan excepciones, se caen, se reinician, repiten.

- 14:05:00 — el operador detiene manualmente el tráfico de API tier; la base de datos se estabiliza.

- 14:10:00 — la restauración gradual del tráfico se completa. Interrupción total: ~10 minutos (en lugar de los esperados ~10 segundos).

SERVFAIL DNS: Dos Defectos Compensantes

Un Postmortem Real-Shape

Lo siguiente es una versión desinfectada de un incidente real. Los nombres de los proveedores se han cambiado, las IP se han anonimizado; la forma, la cronología y las lecciones son reales.

Resumen

El sitio example.com devolvió SERVFAIL desde todos los resolvers DNS públicos durante aproximadamente 3-4 horas. Las otras 46 zonas en el mismo servidor DNS no fueron afectadas. Causa raíz: dos defectos compensantes.

1. Vendor A (un proveedor secundario de DNS) agregó una nueva IP de sincronización interna que no estaba en la lista de permitidos allow-axfr-ips de la primaria.

2. La zona example.com tenía un conflicto de CNAME de años de antigüedad (RFC-violating) (demo.example.com tenía registros CNAME y MX/TXT en la misma etiqueta) que causó que Vendor A rechazara la zona en una AXFR recién.

Cronología (UTC)

- ~15:00 — Vendor A agrega la nueva IP de sincronización 198.51.100.42 a su infraestructura

- 15:02 — first AXFR-out denied for 198.51.100.42 appears in primary DNS logs (no alerting on this signal)

- ~18:00 — SOA expire window reached; Vendor A drops example.com zone from cache

- ~18:30 — SERVFAIL detected externally

- ~19:45 — root cause identified

- 20:00 — 198.51.100.42 added to allow-axfr-ips; primary restarted

- 20:05 — NOTIFY sent; AXFR iniciado; zona AÚN SERVFAIL (conflicto de CNAME)

- 20:07 — check-zone revela 1 error: conflicto de CNAME en demo.example.com

- 20:09 — CNAME reemplazado con registro A; verificación de la zona limpia (0 errores)

- 20:10 — NOTIFY enviado; AXFR completa; Vendor A comienza a servir la zona

- 20:11 — dig @8.8.8.8 example.com A devuelve la dirección IP correcta — RESUELTO

¿Solo example.com?

Las 47 zonas comparten la misma DNS primaria. El bloque de IPs de AXFR afectó a todas las zonas. Pero solo example.com tenía el conflicto de CNAME y solo example.com necesitaba una AXFR fresca en el momento en que se aplicó el denegar. Las otras zonas ya se habían actualizado antes del denegar o aún no lo necesitaban.

Defecto latente

El conflicto de CNAME en demo.example.com existía desde hace años. Funcionaba porque el primario servía la zona desde su base de datos (tolerante con las violaciones de RFC) y Vendor A estaba sirviendo datos cachéados de antes de que se introdujera la violación. Cuando Vendor A eliminó su caché y necesitó datos frescos, la violación surgió.

Desencadenante

Vendor A agregó silenciosamente una nueva IP de sincronización. La lista de permitidos del primario no la incluía. AXFR denegado. Tres horas después (SOA expire), Vendor A eliminó la zona. El defecto latente surgió cuando el sistema intentó recuperarse.

Escribir Acciones Inocentes

Inocente: Dirigir a los Sistemas, No a las Personas

Una acción inocente del sistema nombra algo que el sistema debería hacer de manera diferente, no algo que una persona debería hacer de manera diferente. 'Entrenar al operador' es culpable. 'Agregue una comprobación automática que detecte esto antes de desplegar' es inocente.

Las buenas acciones inocentes se agrupan en tres dimensiones:

- Prevención: hacer que la cosa mala sea más difícil o imposible

- Detección: notarla más pronto si sucede

- Recuperación: limitar el daño cuando sucede

Cada artículo debería nombrar (1) el cambio específico en el sistema, (2) un equipo de propietario y (3) la dimensión a la que sirve.

Compartimentos que se hunden sin el barco

Prestado de la ingeniería naval

Los barcos llevan tabiques estancos: muros verticales que dividen la quilla en compartimentos. Un compartimento puede inundarse sin hundir el barco; otro puede fallar sin afectar al resto.

Los sistemas distribuidos prestan la misma palabra y la misma idea.

Patrón de tabique estanco: aaislar recursos por dependencia. Un servicio que llama a tres APIs downstream utiliza tres piscinas de conexiones separadas, tres presupuestos de hilos separados, tres presupuestos de reintento. Una API downstream lenta o fallando no puede consumir los recursos asignados para los otros dos.

Sin tabiques estancos: una dependencia lenta agota la piscina de hilos compartida; las llamadas a otras dependencias bloquean esperando hilos; el servicio entero se vuelve inoperativo.

Con tabiques estancos: una dependencia lenta agota su propia piscina; las llamadas a ella fallan rápidamente; las llamadas a otras dependencias continúan normalmente; el radio de explosión se mantiene limitado a la dependencia fallante.

Interruptores de circuito

Patrón de interruptor de circuito: un envoltorio estatal alrededor de una dependencia downstream que registra la tasa de fallas. Tres estados:

- Cerrado (normal): las llamadas pasan. Fallos contados.

- Abierto (trippado): pasado un umbral de fallas (digamos, el 50% de fallas en los últimos 30 segundos), el interruptor se abre. Las llamadas fallan inmediatamente sin intentar la dependencia. Ahorra al llamador de gastar trabajo; ahorra a la dependencia de recibir carga mientras está enferma.

- Casi abierto (prueba): después de un período de enfriamiento, el interruptor permite una pequeña fracción de llamadas. Si tienen éxito, cierra de nuevo a normal. Si fallan, se abre de nuevo para otro período de enfriamiento.

La clave: el interruptor de circuito previene el esfuerzo desperdiciado durante períodos de incuestionablemente enfermo, y da a la downstream una oportunidad de recuperarse sin carga continua.

Los tabiques estancos limitan el radio de explosión. Los interruptores de circuito impiden que la explosión se sostenga por sí misma.

Limitar el radio de explosión

Su servicio API llama a cuatro servicios downstream: Service de Usuario, Service de Recomendación, Service de Notificación y un API de Pagos de terceros. El equipo ha oído que 'el Service de Recomendación ha estado un poco inestable' y quiere asegurarse de que cuando falla, el resto del sistema se mantenga saludable.

Hoy en día el servicio utiliza una sola piscina de hilos compartidos de 200 hilos y una piscina de conexiones HTTP compartida. Los cuatro downstream compiten por estos recursos. No hay interruptores de circuito.

Diseñar una Revisión de Modos de Fallo

Síntesis

Has aprendido a detectar SPOFs mediante inspección, reconocer patrones de fallo en cadena, separar el disparador del defecto latente al leer un postmortem, escribir acciones sin culpa en prevención / detección / recuperación y limitar el alcance del fallo con bulkeley + interruptores de circuito + degradación graciosa.

Aplica todos los cinco.

Tu equipo está lanzando un nuevo service search.example.com que depende de tres servicios downstream: un índice de búsqueda principal (index.example.com), un service de análisis (analytics.example.com) y un service de recomendaciones (recs.example.com). El equipo quiere que lideres una 'revisión de modos de fallo' antes del lanzamiento.

Dónde Continúa Este Curso

Dónde Continúa Este Curso

Ahora puedes detectar un SPOF, reconocer una cascada, leer un postmortem de manera productiva, escribir acciones sin culpa y limitar el alcance del fallo por diseño.

La última lección en este curso (cs_distsys_observability_and_capacity) enseña qué medir para descubrir cuándo hay un problema antes de que los usuarios lo hagan. Verificaciones de salud, puntos de extremo de versión, las cuatro señales doradas en una capa de proxy y cómo las decisiones de capacidad de sobrepaso se relacionan con los datos observados.

Lección complementaria: geometry_of_failure_modes_and_blast_radius deriva la centralidad de entretenimiento (qué nodo de gráfico es la botella) y el corte mínimo (el límite en el radio de explosión).

Bien hecho. Adelante.