Nota perev. : Nos complace compartir la traducción del maravilloso material del evangelista de tecnología senior de AWS - Adrian Hornsby. En palabras simples, explica la importancia de los experimentos diseñados para mitigar las consecuencias de fallas en los sistemas de TI. ¿Probablemente ya escuchaste sobre Chaos Monkey (o incluso usaste soluciones similares)? Hoy, los enfoques para la creación de tales herramientas y su implementación en un contexto más amplio se llevan a cabo como parte de una actividad llamada ingeniería del caos. Lea más sobre esto en este artículo.
"Pero detrás de toda esta belleza yace el caos y la locura". - paredes de curtidor
Bomberos Estos especialistas altamente calificados arriesgan sus vidas todos los días, luchando contra el fuego. ¿Sabes que antes de convertirte en bombero, debes pasar al menos 600 horas entrenando? Y esto es solo el comienzo. Según los informes, los bomberos entrenan hasta el 80% de su tiempo de trabajo.
Por qué
Cuando un bombero lucha con fuego real, necesita una
intuición adecuada. Para desarrollarlo, debes entrenar hora tras hora, día tras día. Como dicen, la práctica hace maravillas.
“Parece como si penetraran la esencia misma del fuego; tales análogos del Dr. Phil para la llama ". - Combatir incendios forestales con computadoras e intuición
Nota perev. : Phillip Calvin "Phil" McGraw es un psicólogo, escritor y presentador estadounidense del popular programa de televisión "Doctor Phil", en el que el presentador ofrece a sus participantes soluciones a sus problemas.Érase una vez en Seattle
A principios de la década de 2000,
Jesse Robbins , quien ocupó un puesto oficial en Amazon con el nombre oficial
Master of Disaster , creó y dirigió el programa GameDay. Se basó en su experiencia como bombero. GameDay fue diseñado para probar, educar y preparar varios sistemas, software y personas de Amazon para posibles situaciones de crisis.
Justo cuando los bomberos desarrollan la intuición para combatir incendios, Jesse estaba a punto de ayudar a su equipo a desarrollar la intuición para contrarrestar eventos catastróficos a gran escala.
"GameDay: creando resiliencia a través de la destrucción" - Jesse RobbinsGameDay fue diseñado para aumentar la resistencia del sitio minorista de Amazon mediante la introducción deliberada de errores en los sistemas de misión crítica.
GameDay comenzó con una serie de anuncios para toda la compañía de que se había planeado una alarma de entrenamiento, a veces a gran escala, por ejemplo, desactivando un centro de datos completo. Los detalles sobre el cierre planificado se proporcionaron al mínimo, y el equipo recibió varios meses para prepararse. El objetivo principal del ejercicio era verificar si el personal puede hacer frente a la crisis local y eliminar rápidamente sus consecuencias.
Durante estos ejercicios, se utilizaron herramientas y procesos especiales, como monitoreo, alertas y llamadas urgentes, para analizar e identificar errores en los procedimientos de respuesta a incidentes. Al final resultó que, GameDay revela perfectamente los problemas arquitectónicos clásicos. A veces también era posible detectar los llamados "defectos ocultos", problemas manifestados debido a los detalles del incidente. Por ejemplo, los sistemas de gestión de incidentes críticos para el proceso de recuperación fallaron debido a efectos secundarios inesperados causados por un problema provocado por el hombre.
A medida que la compañía creció, el radio teórico de derrota de GameDay se expandió. Al final, estos ejercicios se detuvieron: el daño potencial a la empresa se volvió demasiado grande si algo salía mal. Desde entonces, el programa se ha degenerado en una serie de experimentos comerciales dispares y sin impacto para capacitar al personal en situaciones de crisis. No entraré en los detalles de los experimentos en este artículo, pero lo haré en el futuro. Esta vez quiero discutir la importante idea subyacente en GameDay: la
ingeniería de resiliencia , también conocida como
ingeniería del caos .
Subida del mono
Probablemente hayas oído hablar de Netflix, el proveedor de contenido de video en línea. Netflix comenzó a pasar de su propio centro de datos a AWS Cloud en agosto de 2008. Este paso fue causado por daños graves en la base de datos, debido a que la entrega de DVD se retrasó por tres días (sí, Netflix comenzó enviando películas por correo ordinario). La migración a la nube se asoció con la necesidad de soportar cargas de transmisión mucho más altas, así como el deseo de abandonar la arquitectura monolítica y pasar a microservicios que son fáciles de escalar dependiendo de la cantidad de usuarios y el tamaño del equipo de ingeniería. La parte del usuario del servicio de transmisión se trasladó primero a AWS, entre 2010 y 2011, seguido de TI corporativa y todas las demás estructuras. El propio centro de datos de Netflix cerró en 2016. La compañía mide la accesibilidad como una proporción del número de intentos exitosos de lanzar una película con el número total, y no como una simple comparación del tiempo de actividad y el tiempo de inactividad, y trata de alcanzar una cifra de 0.9999 en cada región trimestralmente (a menudo tiene éxito). La arquitectura global de Netflix abarca tres regiones de AWS. Por lo tanto, en caso de problemas en una de las regiones, la empresa tiene la capacidad de redirigir a los usuarios a otros.
Repito una de mis citas favoritas:
“El fracaso es inevitable; eventualmente, cualquier sistema se bloqueará con el tiempo ". - Werner Vogels
De hecho, las fallas en los sistemas distribuidos, especialmente los de gran escala, son inevitables incluso en la nube. Sin embargo, la nube de AWS y sus primitivas de redundancia, en particular, el
principio de las zonas de acceso múltiple en las que está construida, permite a cualquiera diseñar servicios altamente confiables.
Utilizando los principios de redundancia y
degradación elegante , Netflix
logró sobrevivir a las fallas sin afectar a los usuarios finales.
Desde el principio, Netflix se adhirió a los principios arquitectónicos más estrictos. Una de las primeras aplicaciones que implementaron en AWS fue su
Chaos Monkey , para admitir microservicios sin estado de escala automática. En otras palabras, cualquier instancia se puede detener y reemplazar automáticamente sin ninguna pérdida de estado. Chaos Monkey asegura que nadie viole este principio.
Nota perev. : Por cierto, para Kubernetes hay un análogo llamado mono-kube , cuyo desarrollo parece haberse detenido en marzo de este año.Netflix tiene una regla más, que establece la distribución de cada servicio en tres zonas de disponibilidad. Debería continuar funcionando si solo dos de ellos están disponibles. Para garantizar que se cumpla esta regla,
Chaos Gorilla desactiva las zonas de disponibilidad. Más globalmente,
Chaos Kong puede deshabilitar toda la región de AWS para confirmar que todos los usuarios de Netflix pueden recibir servicios de cualquiera de las tres regiones. Y hacen estas pruebas a gran escala cada pocas semanas en producción para asegurarse de que nada escapa a la atención.
Finalmente, Netflix también desarrolló las
herramientas más enfocadas de
Chaos Testing para ayudar a detectar problemas con microservicios y arquitectura de almacenamiento. Puede obtener más información sobre estas técnicas en el libro Chaos Engineering, que recomiendo a cualquier persona interesada en este tema.
"Al realizar experimentos de forma regular que imitan las interrupciones regionales, pudimos identificar varios defectos sistémicos y eliminarlos en una etapa temprana". - Blog de Netflix
Hoy, los principios de la ingeniería del caos están
formalizados ; se les da la siguiente definición:
"La ingeniería del caos es un enfoque que implica realizar experimentos en un sistema de producción para garantizar su capacidad de soportar diversas interferencias que ocurren durante la operación". - principiosofchaos.org
Sin embargo, en un
discurso en AWS re: Invent 2018 sobre ingeniería del caos,
Adrian Cockcroft , un ex creador de la arquitectura de la nube de Netflix, que ayudó a la compañía a cambiar completamente a la infraestructura de la nube, introdujo una definición alternativa de ingeniería del caos. En mi opinión, es más preciso y está bien establecido:
"La ingeniería del caos es un experimento diseñado para mitigar las consecuencias de las fallas".
De hecho, sabemos que los accidentes ocurren todo el tiempo. Con la respuesta correcta, no deberían afectar a los usuarios finales. El objetivo principal de la ingeniería del caos es detectar problemas que no se resuelven correctamente.
Prerrequisitos para crear caos
Antes de embarcarse en la ingeniería del caos, asegúrese de hacer todo el trabajo necesario para garantizar la sostenibilidad en todos los niveles de la organización. Crear sistemas tolerantes a fallas no se trata solo de software. Comienza en el nivel de
infraestructura , se extiende a la
red y los datos , afecta la estructura de las
aplicaciones y, en última instancia, abarca a las
personas y la cultura . En el pasado, escribí mucho sobre modelos de estabilidad y fallas (
aquí ,
aquí ,
aquí y
aquí ) y no me enfocaré en esto ahora, pero no puedo hacerlo sin un pequeño recordatorio.
Algunos elementos obligatorios antes de introducir el caos en el sistema (la lista no es exhaustiva)Etapas de la ingeniería del caos
Es importante comprender que la esencia de la ingeniería del caos
NO es dejar que los monos se suelten y dejar que destruyan todo en una fila, sin ningún propósito. El objetivo de esta disciplina es destruir algunos elementos del sistema en un entorno controlado a través de experimentos bien planificados para verificar si su aplicación puede soportar condiciones turbulentas.
Para hacer esto, debe seguir el proceso formalizado claramente definido que se muestra en la figura a continuación. Con él, puede pasar de comprender el estado estable de su sistema a formular una hipótesis, probarla y, finalmente, analizar la experiencia adquirida durante el experimento y aumentar la estabilidad del propio sistema.
Etapas de la ingeniería del caos1. condición estable
Uno de los elementos más importantes de la ingeniería del caos es comprender el comportamiento de un sistema en condiciones normales.
Por qué Es simple: después de la introducción de la falla artificial, debe asegurarse de que el sistema haya vuelto a un estado estable bien estudiado y que el experimento ya no interfiera con su comportamiento normal.
El punto clave aquí es que debe centrarse no en los atributos internos del sistema (procesador, memoria, etc.), sino en monitorear las señales de salida medibles que conectan el rendimiento con la experiencia del usuario. Para que estas señales de salida estén en un estado estable, el comportamiento observado del sistema debe tener un patrón predecible, pero debe cambiar significativamente cuando se produce un mal funcionamiento en el sistema.
Teniendo en cuenta la
definición de ingeniería del caos propuesta anteriormente por Adrian Cockcroft, este estado estable cambia cuando una falla fuera de control causa un problema inesperado y señala que el experimento del caos debería interrumpirse.
Como ejemplo de condiciones estables, citemos la experiencia de Amazon. La compañía utiliza el número de pedidos como una de las métricas de una condición estable y por una buena razón. En 2007, Greg Linden, quien trabajó anteriormente en Amazon, habló sobre cómo, como parte de un experimento utilizando el método de
prueba A / B, trató de reducir el tiempo de carga de las páginas en el sitio en incrementos de 100 ms y descubrió que incluso se producen retrasos leves a una seria caída en los ingresos. Con un aumento en el tiempo de carga de 100 ms, el número de pedidos (y, por lo tanto, las ventas) disminuyó en un 1%. Es por eso que el número de pedidos es un excelente candidato para métricas estables.
Netflix usa una métrica del lado del servidor asociada con el inicio de la reproducción: la cantidad de clics en el botón de reproducción. Notaron una regularidad en el comportamiento del indicador SPS (inicio por segundo) y sus fluctuaciones significativas en caso de fallas del sistema. La métrica se llama "Pulse of Netflix" (
Pulse of Netflix ).
El número de pedidos en el caso de Amazon y Netflix Pulse son excelentes barómetros de estabilidad, ya que combinan la experiencia del usuario y las métricas operativas en un indicador único, medible y altamente predecible.
Mide, mide y vuelve a medir
No hace falta decir que si no puede registrar correctamente el rendimiento del sistema, no podrá monitorear los cambios en un estado estable (o incluso detectarlos). Preste especial atención a eliminar todos los parámetros / indicadores, de la red, el hardware y terminar con la aplicación y las personas. Dibuje gráficos de estas medidas, incluso si no cambian con el tiempo. Se sorprenderá al descubrir correlaciones de las que no era consciente.
"Haga que sea lo más fácil posible para los ingenieros acceder a los datos que pueden contar o traducir en forma gráfica". - Ian Malpass
2. Hipótesis
Habiendo tratado con un estado estable, podemos proceder a formular una hipótesis.
- ¿Qué pasa si el mecanismo de recomendación se detiene?
- ¿Qué pasa si cae el balanceador de carga?
- ¿Qué pasa si el almacenamiento en caché se cae?
- ¿Qué pasa si el retraso aumenta en 300 ms?
- ¿Qué pasa si la base maestra falla?
Por supuesto, solo se debe elegir una hipótesis y no es necesario complicarla innecesariamente. Comience pequeño. Me gusta comenzar con la hipótesis del personal. ¿Has oído hablar del
factor bus ? El factor bus es una medida de riesgo asociada con el hecho de que el conocimiento no se distribuye de manera uniforme entre los miembros del equipo. Le permite calcular el número mínimo de participantes, después de una pérdida repentina de la cual el proyecto se detendrá debido a la falta de conocimiento o experiencia.
Muchas compañías tienen expertos técnicos cuya desaparición repentina ("atropellada por un autobús") tendrá un efecto devastador tanto en el proyecto como en el equipo. Identifique a estas personas y realice experimentos de caos con su participación: por ejemplo, quíteles las computadoras y envíelas a casa por un día, y luego observe los resultados (a menudo caóticos).
¡Haga el problema común a todos!
Involucre a
todo el equipo en el desarrollo de una hipótesis. Deje que todos participen en la lluvia de ideas: el propietario del producto, el gerente técnico, los desarrolladores, diseñadores, arquitectos, etc. Todos los que están conectados de una forma u otra con el producto.
En primer lugar, pídales a todos que escriban su propia respuesta a la pregunta "¿Qué pasaría si ...?" en un pedazo de papel Verá que, en la mayoría de los casos, todos tendrán su propia respuesta, y comprenderá que alguna parte del equipo todavía no ha pensado en ese problema en absoluto.
Deténgase en este punto y discuta por qué los miembros del equipo tienen una visión diferente del comportamiento del producto en el caso de "¿Qué pasa si ...?". Regrese a sus especificaciones y asegúrese de que todos entiendan correctamente el posible desarrollo de eventos.
Tomemos, por ejemplo, el sitio minorista de Amazon mencionado. ¿Qué sucede si el servicio Comprar por categoría deja de cargarse en la página principal?
¿Debo devolver un error 404? ¿Vale la pena cargar la página, dejando un espacio vacío como en la captura de pantalla a continuación?
¿Vale la pena sacrificar parte de la funcionalidad y, por ejemplo, dejar que la página se expanda y oculte el error?
Y esto solo está en el lado de la interfaz de usuario. ¿Qué debería pasar en el backend? ¿Deben enviarse alertas? ¿Debería un servicio fallido continuar recibiendo solicitudes cada vez que el usuario carga la página de inicio, o el backend debe cortarla por completo?
Y el último. ¡No formule una hipótesis, que se sabe de antemano que romperá la leña! Experimente con partes del sistema que, en su opinión, son estables; en última instancia, este es el punto central del experimento.3. Diseña y ejecuta un experimento
- Elige una hipótesis;
- Definir el alcance del experimento;
- Definir los indicadores relacionados a medir;
- Notificar a la organización.
Hoy, muchas personas, así como los
principios del sitio web de
Chaos , están promoviendo la idea de la ingeniería del caos en la producción. Aunque este debería ser el objetivo final, la mayoría de las organizaciones tienen miedo de este enfoque, por lo que no debe comenzar con él.
Para mí, la ingeniería del caos no es solo la destrucción de varios elementos de los sistemas de producción. Este es un viaje Un viaje al mundo del conocimiento, inextricablemente vinculado con actividades como la destrucción de sistemas en un entorno controlado, cualquier entorno, ya sea un entorno de desarrollo local, beta, puesta en escena o producción. Destrucción a través de experimentos bien diseñados para generar confianza en la capacidad de su aplicación para tolerar condiciones turbulentas. "
Crear confianza " es un punto clave en este caso, ya que es un precursor de los cambios culturales necesarios para la implementación exitosa de la ingeniería del caos y la práctica de mejorar la confiabilidad en su empresa.
Honestamente, la mayoría de los equipos aprenderán mucho rompiendo cosas incluso en un entorno que no sea de producción. Simplemente intente hacer que
docker stop database de
docker stop database en su entorno local y vea si puede resolver este problema sin consecuencias. Alta probabilidad de que no.
Detención de la base de datos: ejemploComience con poco y gradualmente desarrolle confianza en su equipo y organización. Se le informará que "el tráfico de producción real es la única forma de capturar de manera confiable el comportamiento del sistema". Escucha, sonríe y continúa haciendo lentamente lo que estás haciendo. Lo peor que puede hacer es aplicar la ingeniería del caos a la producción y fallar miserablemente. Después de eso, nadie confiará en ti, y te verás obligado a olvidarte de los "monos del caos" para siempre.
Gane credibilidad primero. Muestre a las organizaciones y colegas que sabe lo que está haciendo. Conviértete en bombero y aprende sobre la llama tanto como sea posible antes de pasar a entrenar con fuego vivo. Gana credibilidad. ¿Recuerdas la
historia de la tortuga y la liebre ? La carrera siempre la gana un jugador lento y paciente.
Uno de los puntos más importantes durante el experimento es comprender el posible
radio de daño del mal funcionamiento que está introduciendo y minimizarlo. Hágase las siguientes preguntas:
- ¿Cuántos clientes se verán afectados por el experimento?
- ¿Qué funcionalidad sufrirá?
- ¿Qué lugares se verán afectados?
Piense en un "botón de parada de emergencia" o en una forma de terminar inmediatamente un experimento y volver a un estado estable lo antes posible. Me gusta realizar experimentos usando el llamado. Lanzamientos "canarios". Esta técnica reduce el riesgo de falla cuando se lanzan nuevas versiones de una aplicación en producción al implementar gradualmente los cambios en un pequeño subconjunto de usuarios y luego se extienden lentamente por toda la infraestructura y todos los usuarios. Me encantan los lanzamientos de canarios simplemente porque satisfacen el principio de una
infraestructura fija , y el experimento en sí es bastante fácil de detener.
Un ejemplo de un lanzamiento de canario basado en DNS para experimentos de caosTenga cuidado con los experimentos que cambian el estado de la aplicación (caché o base de datos) o aquellos que no se pueden revertir (fácilmente o en principio).
Es curioso que Adrian Cockcroft me haya dicho que una de las razones por las que Netflix comenzó a usar las bases de datos NoSQL fue la falta de esquemas para cambios o retrocesos en ellas, por lo que es mucho más fácil actualizar gradualmente o corregir registros individuales con datos (es decir, son más amigable con la ingeniería del caos).
4. Observa y aprende
Para aprender algo nuevo y monitorear el progreso del experimento, debe poder realizar un seguimiento del rendimiento del sistema. Como se mencionó anteriormente, ¡preste la máxima atención a todo tipo de métricas y parámetros! Luego cuantifique los resultados y siempre, ¡siempre! - Tenga en cuenta el tiempo hasta que aparezcan los primeros signos de un problema. En mi historia, ha sucedido en repetidas ocasiones que los sistemas de advertencia se negaron y fueron los primeros en informar el problema a los clientes en Twitter ... créanme, no querrán estar en esta situación, así que utilicen experimentos de caos para verificar sus sistemas de monitoreo y advertencia.
- ¿Hora de descubrir?
- ¿Es hora de alertar e iniciar una acción activa?
- ¿Hora de aviso público?
- ¿Tiempo de pérdida parcial de funcionalidad?
- ¿La duración del período de autocuración?
- ¿Tiempo de recuperación total o parcial?
- ¿Es hora de poner fin a la crisis y volver a un estado estable?
Recuerde que no hay una sola causa aislada de falla. Los accidentes mayores son siempre el resultado de varias fallas pequeñas que se acumulan y conducen a una crisis a gran escala.
¡Realice un análisis detallado postmortem para cada experimento!En AWS, prestamos gran atención al análisis de fallas detectadas y a comprender las causas que causaron la prevención de problemas similares en el futuro. Todas las conclusiones y resultados del experimento se resumen en un documento llamado Corrección de errores (COE). COE nos permite aprender de nuestros errores, ya sean defectuosos en tecnología, procesos o incluso organización. Utilizamos este mecanismo para eliminar las causas de las averías y el desarrollo continuo.
La clave del éxito en este proceso es la apertura y la transparencia con respecto a lo que salió mal. Uno de los principios más importantes al escribir un buen COE es ser imparcial y evitar mencionar a personas específicas. Esto a menudo es difícil en un entorno que no fomenta ese comportamiento y no permite el fracaso. Amazon utiliza una colección de
Principios de
liderazgo para promover este comportamiento; por ejemplo,
la autocrítica, un enfoque analítico, el compromiso con los estándares más altos y la responsabilidad son componentes clave del proceso de COE y la excelencia operativa en general.
El informe COE tiene cinco secciones principales:
- ¿Qué pasó (orden cronológico)?
- ¿Cuál fue el impacto en los clientes?
- ¿Por qué ocurrió el error? ( Cinco "¿por qué?" )
- Que aprendimos
- ¿Cómo prevenir esto en el futuro?
Es más difícil responder a estas preguntas de lo que parece a primera vista, ya que debe asegurarse de que cada momento incomprensible / desconocido se estudie cuidadosamente.
Con el fin de convertir el mecanismo de COE en un proceso completo, realizamos constantes controles en forma de reuniones semanales con un análisis obligatorio de las métricas operativas. Además, los principales expertos técnicos realizan revisiones métricas semanales con todo el personal de AWS.
5. ¡Corregir y mejorar!
La lección principal aquí es
, en primer lugar, eliminar los problemas identificados durante los experimentos de caos, asignándoles una prioridad más alta que el desarrollo de nuevas funciones . Involucre a la alta gerencia en este proceso y preséntele la idea de que solucionar los problemas actuales es mucho más importante que desarrollar una nueva funcionalidad.
Una vez, con la ayuda de un experimento de caos, ayudé a un cliente a identificar problemas críticos de estabilidad, pero debido a la presión del departamento de ventas, se redujo la prioridad de la solución, y todos los esfuerzos se dirigieron a introducir algo nuevo que es "extremadamente importante" para los clientes. Dos semanas después, un tiempo de inactividad de 16 horas obligó a la compañía a abordar los mismos problemas que identificamos durante el experimento del caos. Solo las pérdidas fueron mucho mayores.
Los beneficios de la ingeniería del caos
Hay muchas ventajas Destacaré dos, en mi opinión, los más importantes:
En primer lugar, la ingeniería del caos ayuda a resolver problemas desconocidos en el sistema y a solucionarlos antes de que provoquen un fallo de producción, por ejemplo, a las 3 a.m.del domingo. Es decir,
aumenta la resistencia al choque y, de hecho, la calidad del sueño .
En segundo lugar, los experimentos de caos realizados de manera eficiente siempre causan cambios más extensos (principalmente culturales) de lo previsto. Quizás el más importante de estos es la evolución natural a una
cultura " no culpable" , cuando la pregunta "¿Por qué hiciste esto?" se convierte en "¿Cómo podemos evitar esto en el futuro?". Como resultado, el equipo se vuelve más feliz, más eficiente, más interesado y exitoso.
¡Y esto es maravilloso!Sobre esto, la primera parte llega a su fin. Espero que lo hayas disfrutado. Escribe comentarios, comparte opiniones o simplemente aplaude en
Medium . En la siguiente parte, analizaré las herramientas y técnicas para introducir fallas del sistema. Hasta que ... ¡chao!
Para aquellos que estén ansiosos por familiarizarse con la segunda parte, ofrezco mi presentación sobre el tema de la ingeniería del caos en el NDC en Oslo. En él, hablo de muchas de mis herramientas favoritas:
PD del traductor
La segunda parte del artículo en inglés ya apareció y también la traduciremos si vemos suficiente interés por parte de los lectores de Habré a este material. ¡Los comentarios relevantes sobre el artículo son bienvenidos! ACTUALIZADO (3 de septiembre): también se
publica una traducción de la segunda parte.
ACTUALIZADO (19 de diciembre): La
traducción de la tercera parte está disponible.
Lea también en nuestro blog: