Ingeniería del caos, incidentes y aprendizaje sin culpas

Practicar el fallo a propósito

Todo lo visto hasta ahora en este capítulo es una promesa sobre cómo se comportará el sistema cuando algo vaya mal: los timeouts saltarán, los circuit breakers se abrirán, se descartará carga, las réplicas tomarán el relevo, las alertas llegarán a alguien que sabe qué hacer. El Capítulo 2 advirtió de que un failover que nunca se ha ejercitado suele fallar cuando por fin se necesita (Sección 2.5). Esta sección trata de convertir esas promesas en evidencia, y de cómo las organizaciones responden a los fallos que ocurren de todos modos y aprenden de ellos.

Dos prácticas van juntas. Antes de los fallos, la ingeniería del caos y los game days provocan deliberadamente fallos pequeños y controlados para encontrar debilidades y formar a las personas. Después de los fallos, la gestión de incidentes limita los daños y las revisiones posteriores al incidente sin culpas convierten cada incidente en una mejora duradera. Ambas se basan en la misma convicción: los sistemas complejos siempre están parcialmente rotos, y la resiliencia viene de descubrir cómo, pronto y de forma segura.

Ingeniería del caos

La ingeniería del caos nació de la migración de Netflix desde sus propios centros de datos a Amazon Web Services, que empezó tras una grave corrupción de una base de datos en 2008. Las instancias individuales en la nube podían desaparecer en cualquier momento, así que Netflix creó Chaos Monkey, una herramienta que terminaba aleatoriamente instancias de producción en horario laboral, cuando los ingenieros estaban en sus puestos para detectar y corregir cualquier problema resultante. Netflix la describió, junto con una familia de herramientas relacionadas llamada Simian Army, en una entrada de blog de julio de 2011. Herramientas posteriores fueron más allá: Chaos Kong simulaba la pérdida de una región entera de AWS evacuando su tráfico.

Ingenieros de Netflix y otros pusieron después por escrito la disciplina como los Principios de la Ingeniería del Caos (principlesofchaos.org, revisados por última vez en 2019), que la definen como experimentar con un sistema para ganar confianza en su capacidad de resistir condiciones turbulentas en producción. La palabra clave es experimentar: la ingeniería del caos no consiste en romper cosas al azar para ver qué pasa, sino en aplicar el método científico a la resiliencia. Los principios enumeran cinco prácticas:

Formula una hipótesis en torno al comportamiento en estado estable. Elige un resultado medible que indique un funcionamiento normal, como los pedidos realizados por minuto o el SLI del proceso de pago, en lugar de métricas internas como la CPU. La hipótesis de estado estable predice que ese resultado se mantendrá dentro de unos límites mientras se inyecta el fallo. Varía los eventos del mundo real. Inyecta los fallos que ocurren de verdad: instancias que mueren, una dependencia que se ralentiza, pérdida de paquetes, un disco lleno, un certificado caducado, desfase de relojes, un pico de tráfico. Ejecuta los experimentos en producción. Solo producción tiene el tráfico, los datos y la configuración reales. Automatiza los experimentos para que se ejecuten de forma continua. Un experimento puntual demuestra la resiliencia una vez; los sistemas cambian a diario. Minimiza el radio de impacto (blast radius). Empieza por el experimento más pequeño que pueda enseñar algo (una instancia, un pequeño porcentaje del tráfico) y ten preparado un interruptor para cancelarlo.

Ejecutar experimentos en producción es el principio más debatido. Sus defensores argumentan que los entornos de staging difieren en tráfico, datos, escala y configuración, así que solo los experimentos en producción revelan las debilidades reales, y que un experimento pequeño y controlado a las 15:00 es mucho más amable con los usuarios que el mismo fallo llegando sin control a las 03:00. Los críticos señalan que muchas organizaciones carecen de la observabilidad, la automatización y la confianza organizativa necesarias para hacerlo con seguridad. El consenso práctico es una progresión: empezar en un entorno de staging, después ejecutar en producción con un radio de impacto diminuto y condiciones de cancelación automáticas ligadas a los SLO, y ampliar solo a medida que crece la confianza. Nunca empieces con un sistema que ya sabes que es frágil; corrige primero las debilidades conocidas, porque un experimento cuyo resultado puedes predecir no enseña nada.

Hoy las herramientas están ampliamente disponibles: los proveedores de nube ofrecen inyección de fallos gestionada (AWS Fault Injection Service, Azure Chaos Studio), Chaos Mesh y LitmusChaos son proyectos de código abierto de la CNCF para Kubernetes, y plataformas comerciales como Gremlin ofrecen bibliotecas de ataques con controles de seguridad. Los service meshes y los proxies pueden inyectar latencia y errores en un porcentaje de las llamadas sin tocar el código de la aplicación. Las herramientas son la parte fácil; lo difícil es elegir hipótesis significativas y actuar según los resultados.

Game days

Un game day (día de juego) es un ejercicio planificado en el que un equipo provoca o simula deliberadamente un fallo importante y practica la respuesta. Jesse Robbins popularizó esta práctica en Amazon, donde, según se cuenta, su cargo era Master of Disaster. Google organiza grandes ejercicios de pruebas de recuperación ante desastres (Disaster Recovery Testing, DiRT), y su libro de SRE describe la Wheel of Misfortune (rueda de la desgracia), un juego de rol en el que los ingenieros de guardia trabajan sobre un incidente pasado mientras un director de juego revela lo que habría mostrado la monitorización.

Los game days ponen a prueba algo más que el software. Comprueban si las alertas llegan a las personas adecuadas, si las personas tienen el acceso que necesitan a las 03:00, si los runbooks están al día, si el procedimiento de failover funciona de verdad, si las copias de seguridad se restauran y si el plan de comunicación llega a los clientes. Un game day típico de la plataforma de reparto de comida podría hacer failover de la base de datos de pedidos a su réplica en espera durante una tarde tranquila, con todo el turno de guardia observando, un facilitador que introduce sorpresas (la persona que conoce el runbook está de vacaciones) y un observador que anota cada retraso y cada confusión para la revisión posterior. Antes de una gran salida a la venta de entradas, el mismo equipo podría ensayar la pérdida del proveedor de pagos y el cambio al proveedor de respaldo en plena venta.

Gestión de incidentes

Un incidente es un evento no planificado que interrumpe un servicio, o amenaza con interrumpirlo, y necesita una respuesta coordinada. La gestión de incidentes es la práctica de llevar esa respuesta de forma que sea rápida, tranquila y bien comunicada. La mayor parte de la práctica moderna toma prestado del Incident Command System (sistema de mando de incidentes), desarrollado en California en la década de 1970 para la respuesta a los incendios forestales y adaptado al software en el capítulo sobre gestión de incidentes del libro de SRE de Google.

La idea central es la separación de roles. El coordinador del incidente (incident commander) es el dueño del incidente: fija prioridades, asigna roles, toma decisiones y mantiene la visión de conjunto, y deliberadamente no depura, porque un coordinador enterrado en un archivo de log no está coordinando. El responsable de operaciones y los intervinientes diagnostican y mitigan. El responsable de comunicaciones es la única voz hacia todos los que están fuera de la respuesta: los equipos de soporte, los directivos y los clientes, a través de la página de estado, con actualizaciones a la frecuencia prometida incluso cuando no hay nada nuevo. Un escriba registra la cronología, las decisiones y las hipótesis. En una empresa pequeña una persona puede ocupar varios roles, pero los roles deberían nombrarse igualmente. Los roles se traspasan de forma explícita cuando cambian los turnos.

Varios hábitos marcan la diferencia. Declara los incidentes pronto y sin complicaciones: es mejor desactivar una falsa alarma que descubrir al cabo de una hora que tres equipos han estado depurando el mismo problema por separado. Clasifica cada incidente con un nivel de gravedad definido por el impacto en los usuarios, no por la causa, para que todo el mundo sepa a quién llamar y con qué amplitud comunicar. Mitiga antes de diagnosticar: primero revierte el último despliegue, haz failover, desactiva el feature flag o descarta carga, y averigua el porqué después. Usa un solo canal del incidente. Y recuerda las obligaciones externas: puede que haya que notificar una violación de datos personales a la autoridad de control en un plazo de 72 horas según el RGPD (GDPR), por lo que los incidentes de seguridad siguen el proceso relacionado de la Sección 8.8.

Revisiones posteriores al incidente sin culpas

Después del incidente llega la parte más valiosa: el aprendizaje. Una revisión posterior al incidente (a menudo llamada postmortem) reconstruye lo que ocurrió, por qué tuvo sentido para las personas implicadas en ese momento y qué va a cambiar. El capítulo sobre la cultura de los postmortems del libro de SRE de Google establece las expectativas: un registro escrito de cada incidente significativo, que cubra el impacto, la cronología, las causas contribuyentes y las acciones de seguimiento, que se revise y se comparta, y que se escriba sin culpas.

La entrada de John Allspaw de 2012 Blameless PostMortems and a Just Culture, escrita cuando dirigía las operaciones técnicas de Etsy, explica por qué una cultura sin culpas (blameless) es práctica y no simplemente amable. Los ingenieros que esperan un castigo dejan de dar cuentas completas de lo que vieron e hicieron, así que la organización pierde exactamente la información que necesita para evitar el siguiente incidente. Allspaw se apoya en la ciencia de la seguridad, incluido el trabajo de Sidney Dekker sobre la cultura justa, y en la idea de las segundas historias: la primera historia dice un ingeniero ejecutó el comando equivocado; la segunda pregunta por qué era tan fácil ejecutar ese comando, por qué la herramienta no avisó, por qué el procedimiento parecía razonable bajo la presión del tiempo, y encuentra condiciones que también atraparán a la siguiente persona. Sin culpas no significa sin responsabilidad: se sigue esperando que las personas den cuentas completas, y la organización es responsable de corregir las condiciones.

Las buenas revisiones evitan el sesgo retrospectivo (el resultado no era evidente en ese momento), los contrafácticos (debería haber, no logró) y la búsqueda de una única causa raíz. El breve artículo de Richard Cook How Complex Systems Fail (1998) sostiene que los fallos graves en los sistemas complejos necesitan que se alineen varios defectos, así que no hay una única causa raíz, solo factores contribuyentes. Una cadena de cinco porqués que termina en error humano se ha detenido demasiado pronto. Anota también lo que salió bien: la pericia y la improvisación que limitaron los daños forman parte de cómo el sistema se mantiene realmente en pie, y son invisibles a menos que alguien las registre.

Aprender de los incidentes, y los límites del MTTR

Las organizaciones quieren, como es natural, una cifra que muestre si la respuesta a incidentes está mejorando, y el tiempo medio de recuperación (MTTR) es el candidato habitual. El Capítulo 2 usó el MTTR en A = MTBF / (MTBF + MTTR), donde tiene sentido para un único componente con fallos repetibles. Como métrica organizativa sobre muchos incidentes distintos es mucho más débil. Las duraciones de los incidentes están muy sesgadas: la mayoría son cortos y unos pocos son muy largos, así que la media está dominada por un puñado de valores atípicos. Los análisis de Courtney Nash de miles de informes públicos de incidentes en la Verica Open Incident Database (informes VOID desde 2021) encontraron exactamente este sesgo, y un informe de Google de 2021 de Štěpán Davidovič, Incident Metrics in SRE, usó simulaciones para mostrar que, con un número realista de incidentes, los cambios en el MTTR son sobre todo ruido y no pueden mostrar de forma fiable si una mejora funcionó.

Mejores señales son el impacto en los SLO y en los presupuestos de errores (que ponderan los incidentes según lo que notaron los usuarios), los temas recurrentes en las revisiones (el mismo tipo de cambio de configuración causando problemas tres veces), los cuasi incidentes, la rapidez con que se detectan los incidentes, la frecuencia con que las revisiones dan lugar a cambios del sistema completados y la evidencia cualitativa, como si los ingenieros encuentran útiles las revisiones. Muchas organizaciones publican las revisiones internamente en una biblioteca con búsqueda y celebran reuniones periódicas de revisión de incidentes, para que la lección de un equipo llegue a los demás.

Acciones que cambian de verdad el sistema

Una revisión vale solo por los cambios que produce. Las acciones difieren mucho en solidez. Las más sólidas son las que eliminan el peligro (borrar el comando peligroso, hacer imposible el estado inseguro), después las salvaguardas que impiden que el error se propague (validación de la configuración, despliegues escalonados y canarios, límites de tasa a los cambios, rollback automático ante el consumo del SLO), y después una detección y una mitigación más rápidas (una nueva alerta de SLO, un runbook probado, un failover automatizado). Las más débiles son la formación, la documentación y los recordatorios. Tener más cuidado no es una acción; no cambia nada de las condiciones que encontrará la siguiente persona.

Cada acción necesita un responsable, una prioridad y una fecha límite, y debe vivir en el backlog normal del equipo y no en un documento olvidado. La política de presupuesto de errores de la Sección 9.5 aporta la palanca: un incidente que consumió una gran parte del presupuesto hace que sus correcciones tengan prioridad sobre las funcionalidades. Mantén la lista corta; cinco acciones completadas valen más que veinte abiertas. Cuando una acción cambia la arquitectura, como añadir un bulkhead o eliminar una dependencia síncrona, regístrala en un registro de decisiones de arquitectura que cite el incidente, y enlaza los runbooks (manuales de operaciones) correspondientes desde las alertas que saltarán la próxima vez.