Tus cinco primeros experimentos de caos, y los que van en preproducción

La forma habitual en que llega la ingeniería del caos es que alguien instala una herramienta de inyección de fallos, mata un pod en producción un miércoles por la tarde, tira el pago durante nueve minutos y la práctica queda prohibida dos años. La idea era correcta y la secuencia estaba mal.

La ingeniería del caos no es romper cosas a ver qué pasa. Es declarar qué crees que va a hacer el sistema y después comprobar si lo hace. Si no puedes escribir el comportamiento esperado de antemano, no estás ejecutando un experimento, estás provocando un incidente.

La forma de un experimento de verdad

Cuatro cosas, escritas antes de que se ejecute nada.

Una hipótesis en términos del estado estable. No "el sistema sobrevivirá". Algo medible: "si se termina uno de los tres pods de la API, la tasa de error se mantiene por debajo del 0,1 por ciento y la latencia del percentil noventa y nueve por debajo de cuatrocientos milisegundos". Necesitas una métrica de estado estable en la que ya confíes, y por eso esta práctica depende de tener antes objetivos de nivel de servicio.

Un radio de impacto. Un pod, una zona de disponibilidad, una dependencia, un uno por ciento del tráfico. Nunca "el clúster".

Una condición de parada y una forma de parar. Define el umbral de la métrica con el que abortas, y confirma que el mecanismo de aborto funciona antes de empezar. Un experimento que no puedes detener es una caída con papeleo.

Una predicción de qué vas a aprender en cualquiera de los dos casos. Si la hipótesis se sostiene, tienes evidencia. Si no, tienes un hallazgo con una reproducción.

Ejecuta primero en preproducción, y sé honesto con que los hallazgos de preproducción son más débiles: menos instancias, sin tráfico real, dependencias simuladas. La preproducción te dice si el mecanismo funciona. La producción te dice si funciona a escala. Pasa a producción solo después de que el mismo experimento haya salido limpio varias veces en preproducción, en horario laboral, con el equipo mirando y con la persona dueña del servicio presente.

Los cinco que siempre encuentran algo

1. Termina una instancia. Mata un solo pod, contenedor o máquina virtual de un servicio replicado. Estás probando si el reemplazo arranca antes de que se sature la capacidad restante, si las peticiones en vuelo se drenan o se pierden, y si el balanceador se entera pronto. El hallazgo clásico es un servicio con dos réplicas y una sonda de disponibilidad que pasa antes de que la aplicación pueda servir, así que el tráfico llega a un proceso que no está listo y la tasa de error se dispara quince segundos.

2. Añade latencia a una dependencia. Inyecta quinientos milisegundos de retraso en las llamadas a una base de datos, una caché o una API de terceros. Es el experimento más productivo de la lista porque destapa los tiempos de espera que faltan. El hallazgo común es un cliente sin ningún tiempo de espera, o con uno más largo que el de quien le llama, de modo que una dependencia lenta agota la reserva de conexiones y una dependencia degradada se convierte en una caída total. Los reintentos sin espera creciente lo convierten en una denegación de servicio autoinfligida.

3. Llena un disco. Escribe hasta que un volumen llegue al 95 por ciento en un nodo. Estás probando si la monitorización lo caza antes que la aplicación, y qué hace la aplicación cuando no puede escribir. Las librerías de registro que se bloquean al escribir son un descubrimiento frecuente y desagradable.

4. Pierde una zona de disponibilidad. Haz inalcanzables las instancias de una zona, o drena sus nodos. Estás probando si la capacidad de las zonas restantes es suficiente de verdad y no solo sobre el papel, si las cargas con estado ancladas a los volúmenes de esa zona pueden replanificarse, y si la conmutación de la base de datos ocurre y cuánto tarda. Es el experimento que más a menudo invalida una afirmación de multizona, y conecta directamente con la aritmética de la conmutación multirregión y lo que cuesta.

5. Caduca un certificado. En preproducción, pon un certificado a caducar o bloquea el camino de renovación. La caducidad de certificados causa una proporción sorprendente de las caídas reales, el modo de fallo es total y el camino de recuperación suele estar sin documentar porque funciona automáticamente hasta el día que no.

Los días de juego ganan a la automatización, al principio

El instinto después del primer experimento exitoso es automatizarlo de forma programada. Resístete un tiempo.

Un día de juego es una sesión programada en la que el equipo ejecuta un experimento junto, con alguien haciendo el papel de la guardia y trabajando solo a partir de las alertas y los runbooks. Enseña más que la automatización porque lo que se prueba no es solo el sistema sino la respuesta: si la alerta se disparó, si decía algo útil, si el runbook era exacto, si alguien sabía a quién escalar.

Casi todos los primeros días de juego descubren que la resiliencia técnica es mejor de lo esperado y el proceso humano es peor. La alerta cae en un canal que nadie vigila, el runbook referencia un panel al que cambiaron el nombre, el contacto de escalado se fue de la empresa. Nada de eso aparece en un experimento automático que comprueba una métrica.

Automatiza más tarde, cuando los experimentos hayan sido aburridos varias veces seguidas.

Ejecutarlo sin perder a la sala

• Anúncialo. El caos silencioso en producción destruye la confianza y produce una respuesta a incidente real, arruinándole la tarde a todo el mundo.
• Nunca durante un congelado, un lanzamiento o un pico. El valor del hallazgo no compensa el riesgo en plena campaña.
• Una variable cada vez. Dos fallos simultáneos te dan una historia interesante y ninguna causa atribuible.
• Anota el resultado también cuando no pasó nada. "Matamos un pod y no pasó nada" es la evidencia de que el diseño funciona, y es lo que gana el permiso para el siguiente experimento.
• Arregla lo que encuentres antes de ejecutar el siguiente. Un montón de hallazgos de caos sin acción convierte la práctica en teatro.

Herramientas, brevemente

Para Kubernetes, las opciones de la fundación cubren fallos de pod, de red y de estrés de forma declarativa como recursos personalizados, lo que significa que los experimentos viven en git y se revisan. Las nubes tienen sus propios servicios gestionados de inyección de fallos que alcanzan fallos a nivel de infraestructura, como la interrupción de una zona o el estrangulamiento de la API, que las herramientas dentro del clúster no alcanzan.

No necesitas nada de eso para empezar. Los tres primeros experimentos de la lista son un borrado de pod, una regla de sidecar o proxy que añade retraso, y un comando que escribe en disco. Compra herramienta cuando la versión manual haya demostrado la práctica, no antes.

Qué hacer esta semana

Elige tu servicio más importante y escribe una hipótesis sobre él, con un número: qué le pasa a la tasa de error y a la latencia si desaparece una instancia. Después comprueba si podrías medir eso hoy. Si no puedes, el hallazgo llegó antes que el experimento, y arreglar la medición es el primer trabajo. Hacemos el primer día de juego con el equipo durante la fase de resiliencia de un proyecto cloud.