Ingeniería del caos

Capítulo 4. El teatro de obras de desastre de Slack

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Richard Crowley

¿Cómo te introduces en la Ingeniería del Caos si tu equipo y tus herramientas no han nacido con ella? Puede parecer una tarea abrumadora e insuperable adaptar el caos a sistemas diseñados con la mentalidad de que los ordenadores pueden y deben durar mucho tiempo. Los sistemas complejos nacidos con esta mentalidad tienden a adaptarse menos a la transitoriedad extrema de los ordenadores subyacentes que sus sucesores nativos de la nube. Estos sistemas probablemente funcionan muy bien en condiciones óptimas, pero se degradan rápidamente y a veces de forma catastrófica en caso de fallo.

Puede que seas el orgulloso propietario de uno de esos sistemas. No se diseñó para dar cabida al caos, pero te guste o no, el caos está llegando a medida que aumenta su escala y el desarrollo continuo le pide que haga más cosas, más rápido y de forma más fiable. No hay tiempo para reescribirlo: el sistema ya está bajo presión. Aplicar nuevas prácticas de Ingeniería del Caos a sistemas antiguos puede empeorar la situación. Necesitas una estrategia diferente.

Este capítulo describe una estrategia para probar de forma segura y sistemática sistemas complejos que no se diseñaron necesariamente con la Ingeniería del Caos en mente, introduciendo fallos y particiones de red de forma meditada y controlada. Se trata de un proceso, no de automatización, que ayuda a tu equipo a comprender cómo es vulnerable tu software, motiva mejoras y valida que los sistemas toleren los fallos que puedes anticipar. Este proceso se utiliza activamente en Slack desde principios de 2018. A través de más de veinte ejercicios, ha descubierto vulnerabilidades, ha demostrado la seguridad de sistemas nuevos y antiguos, y ha afectado a las hojas de ruta de muchos equipos de ingeniería.

El primer paso, sin embargo, es asegurarse de que los sistemas en cuestión están preparados, incluso teóricamente, para tolerar los tipos de fallos que esperas que encuentren.

Retroadaptar el caos

Las herramientas y técnicas que puedes utilizar para hacer que un sistema sea más tolerante a fallos son las mismas que puedes utilizar para modernizarlo, hacerlo nativo de la nube, hacerlo más fiable o hacerlo más altamente disponible. Repasemos.

Patrones de diseño comunes en sistemas antiguos

Los sistemas existentes en, sobre todo los más antiguos, tienen más probabilidades que los nuevos sistemas que se construyen hoy en día de asumir que los ordenadores individuales duran mucho tiempo. Esta simple suposición es la base de muchos sistemas intolerantes a los fallos. Hicimos esta suposición en una época en la que había que evitar los ordenadores de repuesto -era un despilfarro- y ha perdurado en el diseño de nuestros sistemas desde entonces.

Cuando los ordenadores eran escasos, lo más probable era que se aprovisionaran con un sistema operativo y todos los adornos aproximadamente una vez, poco después de comprarlos, y se actualizaran en su lugar a lo largo de su vida útil. El proceso de aprovisionamiento podía estar muy automatizado, sobre todo si aparecían muchos ordenadores en el muelle de carga a la vez, pero iniciar ese proceso era probablemente manual. En instalaciones más pequeñas, no era raro que mucho más de ese proceso de aprovisionamiento fuera manual.

La conmutación por error también era comúnmente una acción manual llevada a cabo por un humano que juzgaba que era la respuesta adecuada a algún fallo o desviación de las operaciones normales. En los sistemas especialmente antiguos, el periodo entre el fallo y la conmutación por error era una interrupción infligida a los clientes. Se pensaba que la conmutación por error era poco frecuente, por lo que la automatización y, en algunos casos, incluso la documentación y la formación no merecían obviamente la pena.

Copia de seguridad y restauración es otra área en la que los sistemas existentes pueden ir a la zaga del estado de la técnica. Como aspecto positivo, es casi seguro que se hacen copias de seguridad. Sin embargo, no es tan seguro que esas copias de seguridad puedan restaurarse o que puedan restaurarse rápidamente. Al igual que en el caso de la conmutación por error, la restauración a partir de una copia de seguridad fue en su día un acontecimiento poco frecuente para el que no valía la pena la automatización.

Aceptamos más fácilmente el impacto potencial de sucesos improbables: ¡quizá nunca lleguen a ocurrir! Los sistemas existentes construidos para aceptar estos riesgos lo pasan mal cuando el índice de fallos aumenta con la escala o cuando el impacto se vuelve menos aceptable para la empresa.

Para completar, quiero tratar brevemente el tema de los monolitos. No hay un umbral preciso que un sistema cruce y se convierta en un monolito: es relativo. Los sistemas monolíticos no son intrínsecamente más o menos tolerantes a fallos que las arquitecturas orientadas a servicios. Sin embargo, puede que sean más difíciles de adaptar debido a su enorme superficie, a la dificultad de introducir cambios graduales y a la dificultad de limitar el radio de explosión de los fallos. Puede que decidas romper tu monolito, puede que no. La tolerancia a los fallos es alcanzable por ambas vías.

Patrones de diseño comunes en los sistemas más recientes

Por el contrario, es probable que los sistemas que se diseñan hoy en día asuman que los ordenadores individuales van y vienen con frecuencia. Hay muchas consecuencias de esta nueva mentalidad, pero quizá la más importante sea que los sistemas se están diseñando para funcionar en n ordenadores simultáneamente y para seguir funcionando cuando uno falle y sólo queden n - 1.

Comprobaciones de salud que son lo suficientemente profundas como para detectar problemas, pero lo suficientemente superficiales como para evitar fallos en cascada de las dependencias de un servicio desempeñan un papel crítico. Retiran del servicio los ordenadores que fallan y, en muchos casos, inician automáticamente su sustitución.

Instancia reemplazo -los proveedores de servicios en la nube suelen llamar instancias a los ordenadores individuales- es una potente estrategia empleada por los sistemas modernos. Permite la tolerancia a fallos que acabo de describir, así como patrones operativos estables como la implementación azul-verde. Y dentro de los sistemas que almacenan datos, la sustitución de instancias proporciona capacidad y motivación para comprobar automática y frecuentemente que las copias de seguridad pueden restaurarse.

Una vez más, quiero subrayar que el hecho de que un sistema sea más monolítico no impide que aproveche estos patrones de diseño. Sin embargo, es una opción arquitectónica de probada eficacia exponer una nueva funcionalidad como un servicio que coopera con un monolito existente.

Llegar a la tolerancia básica a fallos

Los experimentos de Chaos deben ejecutarse en producción (además de en entornos de desarrollo y ensayo) y debes poder afirmar con seguridad que el impacto en los clientes será insignificante, si es que hay alguno. Éstos son algunos cambios de gran calado que puedes hacer si alguno de los sistemas que manejas se alinea con los patrones de diseño habituales en sistemas antiguos.

Primero y ante todo, mantén capacidad de reserva en línea. Tener al menos un ordenador extra durante el funcionamiento normal es el principio de la tolerancia a fallos (y cubre más tipos de fallos de hardware que el RAID, que sólo cubre los discos duros, o la degradación gradual a nivel de aplicación, que puede no ser posible en tu aplicación concreta). Utiliza esa capacidad de reserva para atender las solicitudes que lleguen mientras uno o varios ordenadores funcionan mal.

Una vez que dispongas de capacidad de reserva, estudia cómo retirar automáticamente del servicio los ordenadores que funcionen mal (antes de sumergirte en la Ingeniería del Caos). Pero no te detengas en la retirada automática. Continúa con la sustitución automática. Aquí, la nube ofrece algunas ventajas claras. Es fácil (y divertido) dejarse llevar optimizando el aprovisionamiento de instancias, pero una implementación básica de autoescalado que sustituya las instancias a medida que se terminan para mantener constante el número total será adecuada para la mayoría de los sistemas. La sustitución automática de instancias debe ser fiable. Las instancias de sustitución deben entrar en servicio en un tiempo inferior al tiempo medio entre fallos.

Algunos sistemas, especialmente los que almacenan datos, pueden diferenciar entre un líder y muchos seguidores. Es fácil (y divertido) dejarse llevar por la elección del líder y el consenso, pero aquí también es probable que baste con una implementación que simplemente mantenga las acciones humanas fuera de la ruta crítica. La introducción en de la conmutación por error automatizada es el momento perfecto para auditar las políticas de tiempo de espera y reintentos en los servicios dependientes. Deberías buscar tiempos de espera cortos pero razonables, que sean lo suficientemente largos para permitir que se complete la conmutación por error automatizada, y reintentos que retrocedan exponencialmente con un poco de fluctuación.

Los ejercicios de mesa, en los que tu equipo repasa los detalles del comportamiento esperado de un sistema en presencia de algún fallo, son útiles para convenceros de que un sistema está preparado. Sin embargo, esta confianza académica dista mucho de ser suficiente en un sistema complejo. La única forma de ganarse la verdadera confianza es incitar al fallo en producción. El resto de este capítulo presenta el proceso de Slack para hacerlo con seguridad.

Teatro Disasterpiece

Yo llamo a este proceso Teatro de Piezas de Desastre. Cuando compites con otras valiosas preocupaciones por el tiempo de tus colegas ingenieros y les pides que cambien su forma de desarrollar y utilizar sistemas de software, una marca memorable realmente ayuda. Disasterpiece Theater se introdujo por primera vez como un foro sobre el tema del fallo de los sistemas. Se trata de una serie continua de ejercicios en los que nos reunimos y provocamos a propósito el fallo de una parte de Slack.

Objetivos

Cada ejercicio del Teatro de la Pieza de Desastre es un poco diferente, desenterrando diferentes trucos de nuestro pasado, reavivando diferentes miedos y asumiendo diferentes riesgos. Todos ellos, sin embargo, pueden reconducirse a los mismos objetivos fundamentales.

Fuera de los devotos más extremistas del software que sólo falla, la mayoría de los sistemas se implementan más a menudo de lo que falla su infraestructura subyacente de red y servidores. Cuando diseñamos un ejercicio de Teatro de Desastres, prestamos mucha atención a la fidelidad con que el entorno de desarrollo coincide con el entorno de producción. Es importante que todos los cambios de software puedan probarse en el entorno de desarrollo, pero es fundamental que los fallos puedan practicarse allí. Las ventajas de que el Teatro de Desastres obligue a rectificar las desviaciones reportan dividendos en cada ejecución del conjunto de pruebas y en cada ciclo de implementación.

Más obviamente, un objetivo principal cuando incitamos fallos controlados es descubrir vulnerabilidades en nuestros sistemas de producción. La planificación que conllevan estos ejercicios ayuda a mitigar (aunque nunca del todo) el riesgo de que cualquier vulnerabilidad desconocida se convierta en una cascada que afecte a los clientes. Buscamos vulnerabilidades de disponibilidad, corrección, controlabilidad, observabilidad y seguridad.

Disasterpiece Theater es una serie continua de ejercicios. Cuando un ejercicio descubre una vulnerabilidad, planeamos volver a ejecutarlo para verificar que los esfuerzos de corrección han sido eficaces, del mismo modo que se vuelve a ejecutar el conjunto de pruebas de un programa para confirmar que se ha corregido un error que provocó el fallo de una prueba. En términos más generales, los ejercicios validan los diseños de los sistemas y las suposiciones que contienen. Con el tiempo, un sistema complejo evoluciona y puede invalidar inadvertidamente una suposición hecha hace tiempo en una parte dependiente del sistema. Por ejemplo, el tiempo de espera que un servicio impone a las peticiones a una dependencia puede no ser suficiente una vez que esa dependencia se despliega en varias regiones de la nube. El crecimiento organizativo y del sistema disminuye la precisión del modelo del sistema de cualquier individuo (según el informe STELLA); cada vez es menos probable que esos individuos conozcan siquiera todos los supuestos realizados en el diseño del sistema. Validar periódicamente la tolerancia a fallos ayuda a la organización a asegurarse de que sus suposiciones se mantienen.

Contra los objetivos

Así pues, el Teatro de Desastres pretende promover la paridad entre los entornos de desarrollo y de producción, motivar mejoras en la fiabilidad y demostrar la tolerancia a fallos de un sistema. También me parece útil ser explícito sobre lo que no debe ser un proceso o una herramienta.

Una talla no sirve para todos pero, para Slack, decidí que debían planificarse y ejecutarse ejercicios de Teatro de Desastres para minimizar la posibilidad de provocar un incidente de producción. Slack es un servicio utilizado por empresas grandes y pequeñas para llevar a cabo sus negocios; es fundamental que el servicio esté ahí para ellos todo el tiempo. Dicho de manera más formal, Slack no tiene suficiente presupuesto para errores como para aceptar un impacto grave o prolongado en el cliente como resultado de uno de estos ejercicios planificados. Puede que tenga más presupuesto para errores o tolerancia al riesgo y, si los maneja con eficacia, acabe aprendiendo más, más rápidamente, gracias a los ejercicios que le permiten planificar.

La durabilidad de los datos es aún más prioritaria. Eso no quiere decir que los sistemas de almacenamiento no se vean afectados por este proceso. Más bien, significa simplemente que los planes y las contingencias de esos planes deben garantizar que los datos nunca se pierdan irrecuperablemente. Esto puede influir en las técnicas utilizadas para incitar al fallo o motivar el mantenimiento de una réplica extra en reserva o la realización manual de una copia de seguridad durante el ejercicio. Sea cual sea el beneficio del Teatro de Desastres, no merece la pena perder los datos de un cliente.

El Teatro de Fracasos no es exploratorio. Cuando se introduce un pequeño fallo donde no se ha experimentado ninguno (o muy pocos) antes, la planificación es clave. Debes tener una hipótesis detallada y creíble sobre lo que ocurrirá antes de incitar el fracaso. Reunir a todos los expertos y humanos interesados en la misma sala o en la misma videoconferencia ayuda a atemperar el caos, educa a más ingenieros en los detalles de los sistemas que se van a ejercitar y difunde el conocimiento del propio programa de Teatro de Desastres. La siguiente sección describe detalladamente el proceso desde la idea hasta el resultado.

El proceso

Todo ejercicio de Teatro de Piezas de Desastre comienza con una idea. O quizá, para ser más exactos, de una preocupación. Puede provenir del autor y antiguo propietario de un sistema, de un descubrimiento realizado durante un trabajo no relacionado, como seguimiento de una autopsia... en realidad, de cualquier parte. Armado con esta preocupación y la ayuda de uno o más expertos en el sistema en cuestión, un anfitrión experimentado nos guía a todos a través del proceso.

Preparación

Tú y tus coanfitriones debéis reuniros en la misma sala o en la misma videoconferencia para preparar el ejercicio. Mi lista de comprobación original del Teatro de Desastres sugiere lo siguiente, cada uno de los cuales describiré en detalle:

1. Decide el servidor o servicio que se hará fallar, el modo de fallo y la estrategia para simular ese modo de fallo.

2. Examina el servidor o servicio en dev y prod; ten en cuenta tu confianza en nuestra capacidad para simular el fallo en dev.

3. Identifica alertas, cuadros de mando, registros y métricas que, según tu hipótesis, detectarán el fallo; si no existe ninguno, considera la posibilidad de incitar el fallo de todos modos y trabajar hacia atrás en la detección.

4. Identifica las redundancias y los remedios automatizados que deberían mitigar el impacto del fallo y los libros de ejecución que pueden ser necesarios para responder.

5. Invita al acto a todas las personas relevantes, especialmente a las que vayan a estar de guardia en ese momento, y anuncia el ejercicio en #disasterpiece-theater (un canal del propio Slack).

He descubierto que la mayoría de las veces una hora juntos es suficiente para empezar y la preparación final puede realizarse de forma asíncrona. (Sí, utilizamos Slack para esto).

A veces, la preocupación que inspiró todo el ejercicio es lo suficientemente específica como para que ya sepas con precisión el fallo que vas a provocar, como hacer que un proceso pase sus comprobaciones de salud pero, sin embargo, no responda a las peticiones. Otras veces, hay muchas formas de lograr el fallo deseado y todas son sutilmente diferentes. Normalmente, el modo de fallo más fácil de incitar, reparar y tolerar es la detención de un proceso. Luego está la finalización de instancias (especialmente si estás en la nube), que puede ser conveniente si se sustituyen automáticamente. Utilizar iptables(8) para simular que se desenchufa el cable de red de un ordenador es un modo de fallo bastante seguro que se diferencia de la detención de procesos y (a veces) de la finalización de instancias porque los fallos se manifiestan como tiempos de espera en lugar de ECONNREFUSED. Y luego puedes adentrarte en el interminable y a veces aterrador mundo de las particiones de red parciales e incluso asimétricas, que normalmente pueden simularse con iptables(8).

Además, está la cuestión de en qué parte del sistema se aplica una de estas técnicas. Los ordenadores individuales son un buen comienzo, pero considera la posibilidad de ir subiendo hasta llegar a bastidores enteros, filas, centros de datos, zonas de disponibilidad o incluso regiones. Los fallos más grandes pueden ayudarnos a descubrir las limitaciones de capacidad y el acoplamiento estrecho entre sistemas. Considera la posibilidad de introducir el fallo entre los equilibradores de carga y los servidores de aplicaciones, entre algunos servidores de aplicaciones (pero no todos) y sus bases de datos de respaldo, etc. Deberías salir de este paso con pasos muy concretos que dar o, mejor aún, comandos que ejecutar.

A continuación, asegúrate de que te basas en lo que es realmente posible ejercitar con seguridad. Examina detenida y desapasionadamente tu entorno de desarrollo para determinar si el fallo que quieres introducir puede realmente introducirse allí. Considera también si hay (o puede haber) suficiente tráfico en tu entorno de desarrollo para detectar el fallo y experimentar cualquier efecto negativo potencial como el agotamiento de recursos en un servicio dependiente con tiempos de espera mal configurados, en instancias restantes del servicio degradado o en sistemas relacionados como el descubrimiento de servicios o la agregación de registros.

Imagina por un momento que tu entorno de desarrollo tolera bien el fallo. ¿Te da eso confianza para provocar el mismo fallo en tu entorno de producción? Si no es así, plantéate abortar el ejercicio e invertir en tu entorno de desarrollo. Si es así, ¡buen trabajo por tener un entorno de desarrollo que inspira confianza! Ahora dedica un momento a formalizar esa confianza. Identifica todas las alertas que esperas que se activen cuando incites este fallo, todos los cuadros de mando, registros y/o métricas que hipotetizas que detectarán el fallo más los que hipotetizas que se mantendrán estables. Piensa en esto un poco como "cebar" tu proceso de respuesta a incidentes. No piensas necesitarlo, pero es una contingencia que merece la pena para asegurarte de que el tiempo de detección y el tiempo de montaje sean cero en caso de que el ejercicio no salga según lo previsto. Espero que, la mayoría de las veces, necesites en cambio estos registros y métricas para confirmar tu hipótesis.

Pero, ¿cuál es esa hipótesis? Tómate un tiempo para escribir exactamente lo que tú y tus compañeros esperáis que ocurra. Adopta varias perspectivas. Considera el funcionamiento de las comprobaciones de estado, los equilibradores de carga y el descubrimiento de servicios en torno al fallo. Piensa en el destino de las solicitudes que se interrumpen por el fallo, así como en las que llegan poco después. ¿Cómo se entera del fallo un programa solicitante? ¿Cuánto tiempo tarda? ¿Alguno de esos programas reintenta sus peticiones? Si es así, ¿con qué agresividad? ¿La combinación de estos tiempos de espera y reintentos hará que algo se acerque al punto de agotamiento de los recursos? Ahora amplía tu modelo de la situación para incluir a los humanos y anota cualquier punto en el que la intervención humana pueda ser necesaria o deseable. Identifica cualquier libro de ejecución o documentación que pueda ser necesario. (Esto también sirve para "preparar" el proceso de respuesta a incidentes.) Por último, intenta cuantificar el impacto en el cliente que esperas y confirma que es lo suficientemente mínimo como para proceder.

Concluye tu preparación elaborando la logística del ejercicio. Recomiendo programar al menos tres horas en una gran sala de conferencias. Según mi experiencia, es raro que se utilicen realmente las tres horas, pero sería una distracción tener que desplazarse durante un ejercicio que no va según lo previsto. Si hay participantes a distancia, utiliza un sistema de videoconferencia con un buen micrófono que capte toda la sala. Convoca a los copresentadores, a todos los demás expertos en el sistema que se está ejercitando y sus clientes, a cualquiera que esté de guardia y a cualquiera que quiera aprender. Estos ejercicios cuestan horas humanas, lo que subraya la importancia de una preparación minuciosa. Ahora que estás preparado, es el momento del Teatro de la Pieza de Desastre.

El Ejercicio

Trato de hacer de cada ejercicio una especie de espectáculo para dar a conocer al máximo Disasterpiece Theater en toda la empresa. Este programa compite por el tiempo de la gente; es muy importante que todos comprendan que dedicar tiempo a Disasterpiece Theater da como resultado un sistema más fiable con un entorno de desarrollo que inspira más confianza.

En debes designar a una persona que tome notas. (Yo he desempeñado históricamente este papel durante los ejercicios de Teatro de Piezas de Desastre de Slack, pero no hay razón para que no puedas decidirlo de otro modo). Recomiendo que tomen notas en un canal de chat o en algún medio similar que marque la hora de cada mensaje automáticamente. Nosotros tomamos notas en el canal #disasterpiece-theater del propio Slack.

Si en algún momento del ejercicio te das cuenta de que te desvías incómodamente del plan o te encuentras con impactos imprevistos en el cliente, aborta. Aprende lo que puedas, reagrúpate y vuelve a intentarlo otro día. Puedes aprender mucho sin cruzar el umbral de la respuesta a incidentes.

Mi lista de comprobación original de para el Teatro de la Pieza de Desastre continúa en el propio ejercicio y, al igual que con la lista de comprobación de la preparación, describiré cada paso detalladamente:

1. Asegúrate de que todo el mundo se siente cómodo siendo grabado y, si es así, empieza a grabar la videoconferencia si es posible.

2. Revisa la preparación y modifícala si es necesario.

3. Anuncia el ejercicio de desarrollo en #ops (un canal del propio Slack donde discutimos los cambios e incidencias de producción).

4. Incita el fallo en dev. Anota la hora.

5. Recibe alertas e inspecciona paneles, registros y métricas. Observa el momento en que proporcionan pruebas definitivas del fallo.

6. Si procede, da tiempo a que se activen las correcciones automáticas. Anota la hora a la que lo hacen.

7. Si es necesario, sigue los runbooks para restablecer el servicio en dev. Anota el tiempo y las desviaciones necesarias.

8. Toma la decisión de proceder o no a la picana. Si no, anuncia el visto bueno en #ops, informa y detente. Si es positiva, adelante.

9. Anuncia el ejercicio prod en #ops.

10. Incita el fallo en prod. Anota la hora.

11. Recibe alertas e inspecciona paneles, registros y métricas. Observa el momento en que proporcionan pruebas definitivas del fallo.

12. Si procede, da tiempo a que se activen las correcciones automáticas. Anota la hora a la que lo hacen.

13. Si es necesario, sigue los runbooks para restablecer el servicio en prod. Anota el tiempo y las desviaciones necesarias.

14. Anuncia el visto bueno en #ops.

15. Informe.

16. Si la hay, distribuye la grabación cuando esté disponible.

Me gusta tener una grabación de audio del ejercicio para consultarla en caso de que algo importante no se capte o no se capte con claridad en las notas tomadas en tiempo real. Sin embargo, es importante asegurarse de que todos los participantes están de acuerdo con que se les grabe. Quita esto de en medio primero y, si es posible, empieza a grabar.

Comienza con una revisión exhaustiva del plan. Es probable que sea la primera vez que algunos de los participantes lo conozcan. Sus perspectivas únicas pueden mejorar el plan. Incorpora sus comentarios, especialmente cuando hagan que el ejercicio sea más seguro o los resultados más significativos. Publicamos los planes con antelación en documentos compartidos y los actualizamos con estos cambios. Pero ten cuidado con desviarte demasiado del plan por capricho, ya que esto puede convertir un ejercicio seguro y bien planificado en una carrera de obstáculos.

Cuando se ratifique el plan, anuncia el ejercicio en un lugar muy público, como un canal de chat donde se esperan actualizaciones sobre las operaciones del sistema, una lista de correo de toda la ingeniería o similar. Este primer anuncio debe decir que el ejercicio comienza en el entorno de desarrollo e indicar a los espectadores que lo sigan allí. Consulta el Ejemplo 4-1 para ver el aspecto de un anuncio típico en Slack.

Ejemplo 4-1. Un típico anuncio inicial de Teatro de Desastres en Slack

Richard Crowley 9:50 AM El #disasterpiece-theater está encendido de nuevo y estamos a punto de desenchufar casi todos los cables de red de 1/4 de los servidores del canal en dev. Sigue la evolución en el canal o espera mi anuncio aquí cuando pasemos a prod.

Ahora para el momento de la verdad (en el entorno de desarrollo, al menos). Uno de tus coanfitriones debe ejecutar el comando preparado para provocar el fallo. Tu anotador debe anotar la hora.

Éste es el momento de que todos los participantes (excepto el anotador) entren en acción. Recoge pruebas del fallo, la recuperación y el impacto en los sistemas adyacentes. Confirma o desconfirma todos los detalles de tu hipótesis. Anota específicamente cuánto tardan las reparaciones automatizadas y qué experimentaron tus clientes en el ínterin. Y si tienes que intervenir para restablecer el servicio, toma notas especialmente detalladas de tus acciones y las de tus compañeros. En todo momento, asegúrate de que el que toma las notas puede capturar tus observaciones y publicar capturas de pantalla de los gráficos que estás examinando.

En este momento, tu entorno de desarrollo debería haber vuelto a un estado estable. Haz balance. Si tus reparaciones automatizadas no detectaron el fallo o funcionaron mal de algún modo, probablemente debas detenerte aquí. Si el fallo fue demasiado perceptible para los clientes (independientemente de cómo lo extrapoles de tu entorno de desarrollo) o fue perceptible durante demasiado tiempo, puedes decidir detenerte aquí. Si evalúas el riesgo y decides abortar, anúncialo donde anunciaste el comienzo del ejercicio. Mira el Ejemplo 4-2 para ver cómo es una retirada de este tipo en Slack.

Ejemplo 4-2. Un anuncio abortado de Disasterpiece Theater en Slack

Richard Crowley 11:22 AM El Teatro de la Obra de Desastre ha terminado por hoy sin llegar a la picana.

Cuando el ejercicio en tu entorno de desarrollo va según lo previsto, puedes anunciar que el ejercicio pasa a tu entorno de producción. Consulta el Ejemplo 4-3 para ver cómo es un anuncio típico en Slack.

Ejemplo 4-3. Un anuncio típico cuando el Teatro Disasterpiece pasa a prod

Richard Crowley 10:10 AM #disasterpiece-theater hizo dos rondas en dev y ha terminado allí. Ahora pasamos a prod. Espera que se redistribuyan un montón de canales en el anillo del Servidor de Canales en un futuro próximo. Volveré a publicar cuando todo esté claro.

Éste es el verdadero momento de la verdad. Toda la preparación y el ejercicio en el entorno de desarrollo te han conducido a este momento en el que uno de tus coanfitriones debe provocar el fallo en el entorno de producción utilizando los pasos o el comando preparados con antelación. Esto no te parecerá nada durante algunos ejercicios y será realmente aterrador durante otros. Toma nota de estas sensaciones: te están indicando dónde reside el riesgo en tus sistemas.

Una vez más, es hora de que todos los participantes (excepto el que toma notas) entren en acción reuniendo pruebas del fallo, la recuperación y el impacto en los sistemas adyacentes. Las pruebas suelen ser mucho más interesantes esta vez, con el tráfico real de clientes en juego. Confirma o desconfirma tu hipótesis en producción. Observa cómo responde el sistema al fallo, anotando el momento en que observas una reparación automatizada. Y, por supuesto, si tienes que intervenir para restablecer el servicio, hazlo con rapidez y decisión: ¡tus clientes cuentan contigo! También en este caso, asegúrate de que el anotador capta tus observaciones y publica capturas de pantalla de los gráficos que estás examinando.

Cuando tu entorno de producción haya vuelto a su estado estable, da el visto bueno en el mismo lugar en el que anunciaste el ejercicio en tu entorno de desarrollo y la transición a tu entorno de producción. Si puedes hacer algún comentario preliminar sobre el éxito del ejercicio, estupendo, pero como mínimo el anuncio mantiene a los compañeros de equipo que hacen cambios en producción al corriente de la situación.

Antes de que todos los participantes se dispersen a los vientos, tómate un tiempo para hacer algo de sentido inmediato. Es decir, tómate tiempo para comprender o al menos documentar cualquier ambigüedad persistente sobre el ejercicio.

Sesión informativa

Poco después del ejercicio, cuando los recuerdos aún están frescos y son de alta fidelidad, me gusta resumir el ejercicio -sólo los hechos- para un público amplio. Ayuda a formar una narrativa en torno al resumen que explique por qué es importante el modo de fallo que se ejercita, cómo los sistemas toleraron (o no) el fallo y qué significa eso para los clientes y la empresa. También sirve para reforzar ante el resto de la empresa por qué es tan importante hacer estos ejercicios. Mi lista de comprobación original del Teatro de Desastres ofrece las siguientes indicaciones:

• ¿Cuál fue el tiempo de detección y el tiempo de recuperación?

• ¿Se ha dado cuenta algún usuario? ¿Cómo lo sabemos? ¿Cómo podemos conseguir que "no"?

• ¿Qué tenían que hacer los humanos que deberían haber hecho los ordenadores?

• ¿Dónde estamos ciegos?

• ¿En qué se equivocan nuestros cuadros de mando y documentos?

• ¿Qué necesitamos practicar más a menudo?

• ¿Qué tendrían que hacer los ingenieros de guardia si esto ocurriera inesperadamente?

Capturamos las respuestas a estas preguntas en Slack o en un documento resumen compartido en Slack. Más recientemente, también hemos empezado a grabar el audio de los ejercicios y a archivarlos para la posteridad.

Tras el resumen, el anfitrión ofrece conclusiones y recomendaciones en nombre del ejercicio. Tu trabajo, como anfitrión del ejercicio, es sacar esas conclusiones y hacer esas recomendaciones al servicio de la fiabilidad del sistema y de la calidad del entorno de desarrollo, basándote en las pruebas presentadas desapasionadamente en el resumen. Estas recomendaciones adquieren una importancia elevada cuando el ejercicio no se desarrolla según lo previsto. Si incluso las mentes más expertas entendían el sistema de forma incorrecta o incompleta antes del ejercicio, es probable que todos los demás estén aún más equivocados. Esta es tu oportunidad para mejorar la comprensión de todos.

El debriefing y sus resultados ofrecen otra oportunidad de influir en tu organización educando a más gente sobre los tipos de fallos que pueden ocurrir en producción y las técnicas que utiliza tu organización para tolerarlos. De hecho, este beneficio es notablemente similar a uno de los beneficios de publicar internamente postmortems detallados de incidentes.

Cómo ha evolucionado el proceso

Teatro de Piezas de Desastre se concibió inicialmente como un complemento del proceso de respuesta a incidentes e incluso como un foro para practicar la respuesta a incidentes. Las primeras listas de ejercicios potenciales incluían bastantes fallos que ya entonces se sabía que requerían la intervención humana. Esto era, al menos teóricamente, aceptable, porque esos modos de fallo eran también del tipo que se basaba en suposiciones que podían haber quedado invalidadas a medida que evolucionaba el entorno.

Más de un año después, Slack nunca ha llevado a cabo un ejercicio de Teatro de Desastres en el que se haya previsto que fuera necesaria la intervención humana, aunque ha habido casos en los que, no obstante, ha sido necesaria la intervención humana. En su lugar, hemos desarrollado otro programa para practicar la respuesta a incidentes: Almuerzo de Gestión de Incidentes. Es un juego en el que un grupo de personas intenta alimentarse siguiendo el proceso de respuesta a incidentes. Periódicamente sacan cartas que introducen bolas curvas como cierres repentinos de restaurantes, alergias y comedores quisquillosos. Gracias a esta práctica y a la formación que la precede, Disasterpiece Theater ya no necesita llenar este vacío.

El Teatro de Piezas de Desastre también ha evolucionado en otros aspectos. Las primeras iteraciones se centraban totalmente en los resultados y dejaban sobre la mesa muchas oportunidades educativas. Los debriefings y, especialmente, los resúmenes escritos, las conclusiones y las recomendaciones se introdujeron específicamente por su valor educativo. Del mismo modo, la reciente introducción de las grabaciones permite a los futuros observadores profundizar más de lo que pueden hacerlo sólo con el resumen y el historial del chat.

Puede ser difícil para un participante remoto en una videoconferencia seguir a quien está hablando, y más aún si no puede ver el vídeo porque alguien está compartiendo su pantalla. Por eso empecé Disasterpiece Theater desaconsejando compartir la pantalla. Por otro lado, puede ser increíblemente potente ver todos juntos el mismo gráfico. Sigo buscando el equilibrio adecuado entre la pantalla compartida y el vídeo que cree la mejor experiencia para los participantes remotos.

Por último, mi lista de comprobación original del Teatro de Desastres incitaba a los hosts a idear peticiones sintéticas que pudieran hacer en un bucle cerrado para visualizar el fallo y la tolerancia. Esta práctica nunca resultó tan útil como un panel de control bien elaborado que abarcara la tasa de solicitudes y errores, un histograma de latencia, etc. He eliminado esta indicación de la lista de comprobación en Slack para agilizar el proceso.

Desde luego, no serán las últimas evoluciones de este proceso en Slack. Si adoptas un proceso similar en tu empresa, presta atención a lo que te resulte incómodo para suavizarlo y a quién no está obteniendo valor para hacer el proceso más inclusivo.

Conseguir el apoyo de la dirección

Una vez que vuelvas a , la clave es una narración. Podrías empezar con un recurso retórico: "Hola, Director Técnico y Vicepresidente de Ingeniería. ¿No os gustaría saber lo bien que tolera nuestro sistema los fallos del maestro de la base de datos, las particiones de la red y los fallos de alimentación?". Pinta un cuadro que incluya algunas incógnitas.

Y luego trae la incómoda verdad. La única forma de entender cómo afronta un sistema un fallo en producción es tener un fallo en producción. Debo admitir aquí que esto fue increíblemente fácil de vender a los ejecutivos de Slack, que ya creían que esto era cierto.

En general, sin embargo, cualquier ejecutivo responsable necesitará ver pruebas de que estás gestionando los riesgos de forma eficaz y adecuada. El proceso de Teatro de Desastres está diseñado específicamente para cumplir este requisito. Haz hincapié en que estos ejercicios se planifican y controlan meticulosamente para maximizar el aprendizaje y minimizar (o, mejor aún, eliminar) el impacto en el cliente.

A continuación, planifica tu primer ejercicio y muestra algunos resultados como los de la siguiente sección.

Resultados

He dirigido docenas de ejercicios de Teatro de Desastres en Slack. La mayoría de ellos han ido más o menos según lo previsto, ampliando nuestra confianza en los sistemas existentes y probando el correcto funcionamiento de los nuevos. Algunos, sin embargo, han identificado graves vulnerabilidades en la disponibilidad o corrección de Slack y nos han dado la oportunidad de solucionarlas antes de que afecten a los clientes.

Evitar la incoherencia de la caché

La primera vez que Disasterpiece Theater dirigió su atención a Memcached fue para demostrar en producción que la sustitución automática de instancias funcionaba correctamente. El ejercicio fue sencillo, optando por desconectar una instancia de Memcached de la red para observar cómo una instancia de repuesto ocupaba su lugar. A continuación, restauramos su conectividad de red y terminamos la instancia de reemplazo.

Durante nuestra revisión del plan reconocimos una vulnerabilidad en el algoritmo de sustitución de instancias y pronto confirmamos su existencia en el entorno de desarrollo. Tal y como se implementó originalmente, si una instancia pierde su arrendamiento sobre un rango de claves de caché y luego recupera ese mismo arrendamiento, no vacía sus entradas de caché. Sin embargo, en este caso, otra instancia había servido ese rango de claves de caché en el ínterin, lo que significaba que los datos de la instancia original se habían vuelto obsoletos y posiblemente incorrectos.

Lo solucionamos en el ejercicio vaciando manualmente la caché en el momento oportuno y luego, inmediatamente después del ejercicio, cambiamos el algoritmo y volvimos a probarlo. Sin este resultado, podríamos haber vivido sin saberlo con un pequeño riesgo de corrupción de la caché durante bastante tiempo.

Inténtalo, inténtalo de nuevo (por seguridad)

En a principios de 2019 planeamos una serie de diez ejercicios para demostrar la tolerancia de Slack a los fallos zonales y a las particiones de red en AWS. Uno de estos ejercicios se refería al Servidor de Canales, un sistema responsable de difundir los mensajes y metadatos recién enviados a todos los WebSockets de clientes Slack conectados. El objetivo era simplemente particionar el 25% de los Channel Server de la red para observar que se detectaban los fallos y se sustituían las instancias por repuestos.

El primer intento de crear esta partición de red no tuvo plenamente en cuenta la red superpuesta que proporciona un cifrado de tránsito transparente. En efecto, aislamos cada Servidor de Canal mucho más de lo previsto, creando una situación más cercana a desconectarlos de la red que a una partición de red. Nos detuvimos pronto para reagruparnos y conseguir la partición de red adecuada.

El segundo intento resultó prometedor, pero también se terminó antes de llegar a la producción. Sin embargo, este ejercicio ofreció un resultado positivo. Demostró que Consul era bastante hábil en el enrutamiento alrededor de las particiones de la red. Esto inspiró confianza, pero condenó este ejercicio porque ninguno de los Servidores de Canal falló realmente.

El tercer y último intento trajo consigo un arsenal completo de reglas iptables(8) y consiguió separar de la red el 25% de los servidores del Canal. Consul detectó rápidamente los fallos y se pusieron en marcha los sustitutos. Y lo que es más importante, la carga que esta reconfiguración automatizada masiva supuso para la API de Slack estaba muy por debajo de la capacidad de ese sistema. Al final de un largo camino, ¡todo fueron resultados positivos!

Imposibilidad Resultado

En también ha habido resultados negativos. Una vez, mientras respondíamos a un incidente, nos vimos obligados a hacer e implementar un cambio de código para efectuar un cambio de configuración porque el sistema que se pretendía utilizar para hacer ese cambio de configuración, un sistema desarrollado internamente llamado Confabulator, no funcionaba. Pensé que merecía la pena seguir investigando. Los mantenedores y yo planeamos un ejercicio para imitar directamente la situación que nos encontramos. Confabulador se separaría del servicio Slack, pero por lo demás se dejaría completamente intacto. A continuación, intentaríamos hacer un cambio de configuración que no funcionara.

Reprodujimos el error sin problemas y empezamos a rastrear nuestro código. No tardamos mucho en encontrar el problema. Los autores del sistema previeron la situación en la que el propio Slack estuviera caído y, por tanto, no pudiera validar el cambio de configuración propuesto; ofrecieron un modo de emergencia que se saltaba esa validación. Sin embargo, tanto el modo normal como el de emergencia intentaron publicar un aviso del cambio de configuración en un canal de Slack. No hubo tiempo de espera en esta acción, pero sí en la API de configuración general. Como resultado, incluso en modo de emergencia, la solicitud nunca podía llegar a realizar el cambio de configuración si el propio Slack estaba caído. Desde entonces, hemos realizado muchas mejoras en la implementación del código y la configuración, y hemos auditado las políticas de tiempo de espera y reintentos en estos sistemas críticos.

Conclusión

Los descubrimientos realizados durante estos ejercicios y las mejoras de la fiabilidad de Slack que inspiraron sólo fueron posibles porque Disasterpiece Theater nos proporcionó un proceso claro para probar la tolerancia a fallos de nuestros sistemas de producción.

Los ejercicios de Teatro de Fallos son fallos meticulosamente planificados que se introducen en el entorno de desarrollo y luego, si sale bien, en el entorno de producción por un grupo de expertos reunidos todos juntos. Ayudan a minimizar el riesgo inherente a las pruebas de tolerancia a fallos, sobre todo cuando se basan en suposiciones hechas hace mucho tiempo en sistemas antiguos que quizá no se diseñaron originalmente para ser tan tolerantes a fallos.

El proceso pretende motivar la inversión en entornos de desarrollo que se ajusten fielmente al entorno de producción e impulsar mejoras de fiabilidad en todos los sistemas complejos.

Tu organización y tus sistemas serán mejores con una cadencia regular de ejercicios de Teatro de Desastres. Tu confianza en que cuando algo funciona en el entorno de desarrollo también funcionará en el entorno de producción debería ser mayor. Deberías ser capaz de validar regularmente supuestos de hace mucho tiempo para evitar la putrefacción de bits. Y tu organización debería comprender mejor el riesgo, especialmente cuando se trata de sistemas que requieren la intervención humana para recuperarse de un fallo. Pero lo más importante es que el Teatro de la Pieza de Desastre debería ser una motivación convincente para que tu organización invierta en tolerancia a fallos.

Sobre el autor

Richard Crowley es ingeniero, líder de ingeniería y director de recuperación. Le interesan las herramientas operativas, los sistemas distribuidos y las realidades de la producción a escala. Tolera los ordenadores, le gustan las bicicletas, no es muy buen mantenedor de código abierto y vive en San Francisco con su mujer y sus hijos.