Nota. traducir: Este artículo continúa una gran serie de artículos del evangelista de la tecnología de AWS, Adrian Hornsby, quien se propone explicar de una manera sencilla y clara la importancia de la experimentación para mitigar las consecuencias de las fallas en los sistemas de TI.
"Si no preparas un plan, entonces planeas fracasar". - Benjamin Franklin
В En esta serie de artículos, presenté el concepto de ingeniería del caos y expliqué cómo ayuda a encontrar y corregir fallas en el sistema antes de que provoquen fallas de producción. También se analizó cómo la ingeniería del caos promueve un cambio cultural positivo dentro de las organizaciones.
Al final de la primera parte, prometí hablar sobre "herramientas y métodos para introducir fallas en los sistemas". Por desgracia, mi cabeza tenía sus propios planes al respecto, y en este artículo intentaré responder la pregunta más popular que surge entre las personas que quieren adentrarse en la ingeniería del caos: ¿Qué romper primero?
¡Gran pregunta! Sin embargo, no parece estar particularmente molesto por este panda...
¡No te metas con el panda del caos!
Respuesta corta: Apunte a servicios críticos a lo largo de la ruta de solicitud.
Respuesta más larga pero más clara.: Para entender por dónde empezar a experimentar con el caos, preste atención a tres áreas:
- Mirar historial de accidentes e identificar patrones;
- Decidir por dependencias críticas;
- Utilice el llamado efecto de exceso de confianza.
Es gracioso, pero esta parte podría llamarse fácilmente "Un viaje hacia el autodescubrimiento y la iluminación". En él empezaremos a “tocar” con algunos instrumentos interesantes.
1. La respuesta está en el pasado
Si recuerdas, en la primera parte introduje el concepto de Corrección de Errores (COE), un método mediante el cual analizamos nuestros errores (errores en tecnología, proceso u organización) para comprender sus causas y prevenirlos. recurrencia en el futuro. En general, aquí es donde deberías empezar.
“Para entender el presente es necesario conocer el pasado”. —Carl Sagan
Mira el historial de fallas, etiquétalos en COE o postmortems y clasifícalos. Identifique patrones comunes que a menudo generan problemas y, para cada COE, hágase la siguiente pregunta:
"¿Esto podría haberse predicho y, por lo tanto, evitado mediante la inyección de fallas?"
Recuerdo un fracaso al principio de mi carrera. Podría haberse evitado fácilmente si hubiéramos llevado a cabo un par de sencillos experimentos de caos:
En condiciones normales, las instancias de backend responden a las comprobaciones de estado de ). ELB utiliza estas comprobaciones para redirigir solicitudes a instancias en buen estado. Cuando resulta que una instancia "no está en buen estado", ELB deja de enviarle solicitudes. Un día, después de una exitosa campaña de marketing, el volumen de tráfico aumentó y los backends comenzaron a responder a los controles de estado más lentamente de lo habitual. Hay que decir que estos controles sanitarios fueron , es decir, se comprobó el estado de las dependencias.
Sin embargo, todo estuvo bien por un tiempo.
Luego, ya en condiciones bastante estresantes, una de las instancias comenzó a ejecutar una tarea cron ETL regular y no crítica. La combinación de alto tráfico y cronjob impulsó la utilización de la CPU a casi el 100%. La sobrecarga de la CPU ralentizó aún más las respuestas a las comprobaciones de estado, hasta el punto de que ELB decidió que la instancia estaba experimentando problemas de rendimiento. Como era de esperar, el equilibrador dejó de distribuirle tráfico, lo que, a su vez, provocó un aumento en la carga en las instancias restantes del grupo.
De repente, todas las demás instancias también comenzaron a fallar el control de salud.
Iniciar una nueva instancia requirió descargar e instalar paquetes y tomó mucho más tiempo que el ELB para deshabilitarlos, uno por uno, en el grupo de escalado automático. Está claro que pronto todo el proceso llegó a un punto crítico y la aplicación falló.
Entonces entendimos para siempre los siguientes puntos:
- La instalación del software al crear una nueva instancia lleva mucho tiempo; es mejor dar preferencia al enfoque inmutable y .
- En situaciones complejas, las respuestas a los controles de salud y a los ELB deberían tener prioridad; lo último que se quiere es complicar la vida en los casos restantes.
- El almacenamiento en caché local de los controles de salud ayuda mucho (incluso durante unos segundos).
- En una situación difícil, no ejecute tareas cron ni otros procesos no críticos; guarde recursos para las tareas más importantes.
- Al realizar el escalado automático, utilice instancias más pequeñas. Es mejor un grupo de 10 ejemplares pequeños que un grupo de 4 grandes; Si una instancia falla, en el primer caso el 10% del tráfico se distribuirá en 9 puntos, en el segundo, el 25% del tráfico en tres puntos.
Por lo tanto, ¿Podría haberse previsto esto y, por lo tanto, haberse evitado al introducir el problema?
Sí, y de varias maneras.
Primero, simulando un uso elevado de la CPU utilizando herramientas como o :
❯ stress-ng --matrix 1 -t 60s
estresante
En segundo lugar, al sobrecargar la instancia con y otras utilidades similares:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Los experimentos son relativamente simples, pero pueden proporcionar buenos elementos de reflexión sin tener que pasar por el estrés de un fracaso real.
Sino no te detengas allí. Intente reproducir el bloqueo en un entorno de prueba y verifique su respuesta a la pregunta "¿Se podría haber previsto y, por tanto, evitado introduciendo un fallo?" Este es un mini experimento de caos dentro de un experimento de caos para probar suposiciones, pero comenzando con un fracaso.
¿Fue un sueño o realmente sucedió?
Así que estudie la historia de los fracasos, analice COE, etiquételos y clasifíquelos por “radio de impacto” (o más exactamente, la cantidad de clientes afectados) y luego busque patrones. Pregúntese si esto podría haberse predicho y evitado al presentar el problema. Comprueba tu respuesta.
Luego cambie a los patrones más comunes con el rango más amplio.
2. Construya un mapa de dependencia
Tómese un momento para pensar en su solicitud. ¿Existe un mapa claro de sus dependencias? ¿Sabes qué impacto tendrán si hay una falla?
Si no está muy familiarizado con el código de su aplicación o si se ha vuelto muy grande, puede resultar difícil comprender qué hace el código y cuáles son sus dependencias. Comprender estas dependencias y su posible impacto en la aplicación y los usuarios es fundamental para saber por dónde empezar con la ingeniería del caos: el punto de partida es el componente con el mayor radio de impacto.
Identificar y documentar dependencias se llama "construyendo un mapa de dependencia» (mapeo de dependencia). Por lo general, esto se hace para aplicaciones con una base de código grande utilizando herramientas de creación de perfiles de código. (perfil de código) e instrumentación (instrumentación). También puede crear un mapa monitoreando el tráfico de la red.
Sin embargo, no todas las dependencias son iguales (lo que complica aún más el proceso). Alguno crítico, otro - secundario (al menos en teoría, ya que los bloqueos suelen ocurrir debido a problemas con dependencias que no se consideraban críticas).
Sin dependencias críticas, el servicio no puede funcionar. Dependencias no críticas "no debería» para influir en el servicio en caso de caída. Para comprender las dependencias, debe tener una comprensión clara de las API utilizadas por su aplicación. Esto puede ser mucho más difícil de lo que parece, al menos para aplicaciones grandes.
Comience revisando todas las API. Resalta lo más significativo y critico... Llevar dependencias desde el repositorio de código, compruébalo registros de conexión, luego ver documentación (por supuesto, si existe; de lo contrario, todavía tienesоproblemas mayores). Utilice las herramientas para perfilado y seguimiento, filtrar llamadas externas.
Puedes utilizar programas como netstat - una utilidad de línea de comando que muestra una lista de todas las conexiones de red (sockets activos) en el sistema. Por ejemplo, para enumerar todas las conexiones actuales, escriba:
❯ netstat -a | more
En AWS puedes usar (registros de flujo) VPC es un método que le permite recopilar información sobre el tráfico IP que va hacia o desde las interfaces de red en una VPC. Estos registros también pueden ayudar con otras tareas, por ejemplo, encontrar una respuesta a la pregunta de por qué cierto tráfico no llega a la instancia.
También puedes usar . X-Ray le permite obtener imágenes detalladas y "definitivas" (de extremo a extremo) descripción general de las solicitudes a medida que se mueven a través de la aplicación y también crea un mapa de los componentes subyacentes de la aplicación. Muy conveniente si necesita identificar dependencias.
Consola de rayos X de AWS
Un mapa de dependencia de la red es sólo una solución parcial. Sí, muestra qué aplicación se comunica con cuál, pero existen otras dependencias.
Muchas aplicaciones usan DNS para conectarse a dependencias, mientras que otras pueden usar el descubrimiento de servicios o incluso direcciones IP codificadas en archivos de configuración (p. ej. /etc/hosts).
Por ejemplo, puedes crear a través de iptables y ver qué se rompe. Para hacer esto, ingrese el siguiente comando:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Agujero negro DNS
Si el /etc/hosts u otros archivos de configuración, encontrarás direcciones IP de las que no sabes nada (sí, desafortunadamente, esto también sucede), puedes acudir al rescate nuevamente iptables. Digamos que descubriste 8.8.8.8 y no sé que esta es la dirección del servidor DNS público de Google. Mediante el uso iptables Puede bloquear el tráfico entrante y saliente a esta dirección usando los siguientes comandos:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Cerrar acceso
La primera regla elimina todos los paquetes del DNS público de Google: ping Funciona, pero los paquetes no se devuelven. La segunda regla descarta todos los paquetes que se originan en su sistema hacia el DNS público de Google, en respuesta a ping obtenemos Operación no permitida.
Nota: en este caso particular sería mejor usar whois 8.8.8.8, pero esto es sólo un ejemplo.
Podemos profundizar aún más en la madriguera del conejo, porque todo lo que utiliza TCP y UDP en realidad también depende de IP. En la mayoría de los casos, la IP está vinculada a ARP. No te olvides de los cortafuegos...
Si tomas la pastilla roja, te quedarás en el País de las Maravillas y te mostraré hasta qué punto llega la madriguera del conejo".
Un enfoque más radical es desconectar Coches uno por uno y ve qué está roto... conviértete en un "mono del caos". Por supuesto, muchos sistemas de producción no están diseñados para un ataque de fuerza bruta de este tipo, pero al menos se puede probar en un entorno de prueba.
Elaborar un mapa de dependencia suele ser una tarea muy larga. Recientemente hablé con un cliente que pasó casi 2 años desarrollando una herramienta que genera semiautomáticamente mapas de dependencia para cientos de microservicios y comandos.
El resultado, sin embargo, es sumamente interesante y útil. Aprenderá mucho sobre su sistema, sus dependencias y operaciones. Una vez más, tenga paciencia: lo que más importa es el viaje en sí.
3. Cuidado con el exceso de confianza
"Quien sueña qué, cree en ello". - Demóstenes
Alguna vez has oído hablar de efecto de exceso de confianza?
Según Wikipedia, el efecto de exceso de confianza es "un sesgo cognitivo en el que la confianza de una persona en sus acciones y decisiones es significativamente mayor que la precisión objetiva de esos juicios, especialmente cuando el nivel de confianza es relativamente alto".
Basado en el instinto y la experiencia...
En mi experiencia, esta distorsión es una gran pista de por dónde empezar con la ingeniería del caos.
Cuidado con el operador demasiado confiado:
Charlie: "Esta cosa no se ha caído en cinco años, ¡todo está bien!"
Crash: "Espera... ¡Estaré allí pronto!"
El sesgo como consecuencia del exceso de confianza es algo insidioso e incluso peligroso debido a los diversos factores que influyen en él. Esto es especialmente cierto cuando los miembros del equipo han puesto todo su corazón en una tecnología o han dedicado mucho tiempo a “arreglarla”.
Resumiendo
La búsqueda de un punto de partida para la ingeniería del caos siempre produce más resultados de los esperados, y los equipos que empiezan a romper cosas demasiado rápido pierden de vista la esencia más global e interesante de (caos-)ingeniería - aplicación creativa metodos cientificos и evidencia empírica para el diseño, desarrollo, operación, mantenimiento y mejora de sistemas (software).
Con esto concluye la segunda parte. Por favor escriba reseñas, comparta opiniones o simplemente aplauda . En la siguiente parte yo realmente Consideraré herramientas y métodos para introducir fallas en los sistemas. ¡Hasta!
PD del traductor
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com