Tenía un servidor perfecto, era tan bonito y sólido como una roca, así que lo llamé Petra. Fue perfecto en todos los sentidos, todo se configuró y ajustó a la perfección, tenía un registro perfecto del 100% de servicio y 753 días de tiempo de actividad. He pasado mucho tiempo y esfuerzo asegurándome de que funcione tan bien. Ningún otro servidor de la compañía había sido tan bueno. Pero anoche este monstruo malvado estrelló mi servidor sin ninguna razón.
Por supuesto, me notificaron a las 2 am y me llevó hasta la mañana ponerlo en funcionamiento y todo configurado y afinado, pero me temo que no va a ser tan bueno como antes. Pueden pasar semanas antes de que vuelva a su antigua gloria. Ahora mi tiempo de actividad se ha ido, ni siquiera tengo tres miserables y quién sabe qué hará esto con mi reputación. ¿Quién es este mono del caos y por qué le hizo eso a mi servidor y por qué está tratando de arruinarme?
fuente
Respuestas:
TL; DR : Chaos Monkey fue desarrollado en 2010 en Netflix y lanzado al mercado en 2012 es parte del Ejército Simian , muy popular entre los seguidores devotos . Basado en los principios de la ingeniería del caos , el ejército aumenta la resistencia al fracaso mediante la inyección constante de fallas en el sistema.
Concepto
Chaos Monkey fue desarrollado específicamente para AWS donde matará instancias al azar dentro de un Grupo de Auto Scaling. Está destinado a ejecutarse durante el horario comercial cuando los ingenieros están alertas y pueden reaccionar rápidamente ante fallas descubiertas.
Ejército simio
Los miembros del ejército sembrarían el caos por otros medios:
Latency Monkey introducirá demoras aleatorias a los servicios.
Chaos Gorilla (Kong) simulará la interrupción de toda la zona de disponibilidad.
Otros monos son útiles y eliminan a los miembros débiles de la manada:
Conformity Monkey cierra las instancias que no siguen las mejores prácticas.
Security Monkey busca vulnerabilidades de seguridad conocidas en la configuración y los servicios.
Doctor Monkey cierra instancias poco saludables que no se ajustan a ciertas métricas.
Janitor Monkey busca recursos no utilizados para reclamar.
El fracaso es inevitable
La falla en el Sistema es inevitable, algo siempre saldrá mal . Es posible que no pueda elegir qué, pero puede intentar elegir cuándo. Al introducir pequeños errores durante el día, se asegura de que sus ingenieros estén presentes. Al eliminar rápidamente los servicios no conformes, se asegura de que las fallas ocurran a menudo antes de la implementación. Al hacer que el entorno sea más adverso, se asegura de que serán los desarrolladores los que tengan problemas mucho antes de que cualquier servicio llegue a la producción. Las fallas serán rápidamente aparentes en la fase de integración de los nuevos servicios con los antiguos, pero eso está bien, porque los viejos servicios de producción ya son resistentes.
Ganado no mascotas
Todos te dirán últimamente: no trates a tus servidores como mascotas . Hay un poder en los números y cualquier punto único de falla derribará el sistema. No importa qué tan bien pueda sintonizar y optimizar su servidor, no importa cuán robusto sea el hardware que pueda obtener, cuánto pueda manejar, nunca será un rival para el rebaño de pequeñas instancias escalables. Chaos Monkey te anima a pensar en eliminar todos los puntos de falla, porque tarde o temprano, ¡llegará el mono! Todos fallan e incluso el Amazon S3 tuvo una interrupción impredecible .
Anti-frágil
Entonces, ¿cuál es la teoría y por qué funciona? Nassim Nicholas Taleb en su libro Antifragile describe un concepto en el que los sistemas vivos conscientes de sí mismos se beneficiarán de unos pequeños niveles de aleatoriedad y, de hecho, mejorarán frente a la adversidad. Esto es similar al recocido.
También describe una forma evolutiva, donde la fragilidad de las partes en un sistema se está transfiriendo a la antifragilidad del todo . La transferencia se produce en dos niveles:
Por pequeñas variaciones aleatorias, los desarrolladores que realizan cambios , los más adecuados para el medio ambiente sobrevivirán y se propagarán, pasarán las pruebas y se implementarán . Ciclo de vida de desarrollo estándar .
Al fallar las partes que no son capaces de soportar un mayor nivel de aleatoriedad en el entorno, las partes restantes que pudieron resistirlo componen un sistema que, en su conjunto, está en mejores condiciones para lidiar con el entorno cambiante que antes. Esto es esencialmente Chaos Monkey .
Se pueden soportar mayores niveles de aleatoriedad utilizando el segundo enfoque.
fuente
Algunas adiciones a su propia respuesta a esta pregunta ...
Monos adicionales
El artículo sobre " Cómo el caos aumenta el rendimiento " describe algunos más de estos monos, es decir:
Observación: El mismo artículo también menciona "Gorila del Caos: simula un corte de una zona de disponibilidad de Amazon", aunque bien podría ser que ahora se le haya cambiado el nombre a "Chaos Kong: simula un corte de una región del Amazonas" ... Caos ! No pude encontrar ninguna confirmación / documento sobre eso hasta ahora, al menos no parece haber un problema en la cola de problemas . Un cambio indocumentado podría haber llegado a producción en github ... ¡Gggggggrrrrrreat!
Configura y usa tus propios monos.
Dirígete a github para ponerte en contacto con el Ejército Simian (el mismo enlace que el primer enlace en tu propia respuesta). Aquí hay una cita de lo que encontrarás allí:
Incluso puede configurar los monkyes, para que se ajusten a las necesidades de su negocio.
Si profundiza lo suficiente dentro de esos enlaces de Github (es decir, dentro del enlace de Soporte ), también encontrará un enlace para unirse al Grupo de Google SimianArmy .
fuente
Usted, Sauron, forjó este servidor único, en la Oscuridad de
Mount Doom,su centro de datos con el deseo de gobernar todas las aplicaciones.Esperemos que la Comunidad de Devops se haya unido para decirte:
Después de una larga pelea,
Frodothe Chaos Monkey ha podido derretir su One Server y brindar libertad a todas las aplicaciones, conduciéndolo al mismo tiempo a servidores reproducibles.Créditos
fuente