<blockquote>
  <p>One Server to rule them all, One Server to find them,<br>
  One Server to bring them all and in the outage bind them</p>
</blockquote>

<p>You, Sauron, forged this One Server, in the Darkness of <strike>Mount Doom</strike> your Datacenter in a desire to rule All applications.<br>
Hopefully the Fellowship of Devops did unite to tell you:</p>

<p><a href="https://i.sstatic.net/OAT4s.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/OAT4s.jpg" alt="Gandalf - You shall PAAS"></a></p>

<p>After a long fight, <strike>Frodo</strike> the Chaos Monkey has been able to melt your One Server and bring freedom to all applications, driving you to the way of reproducible Servers at the same time.</p>

<p>Credits:</p>

<ul>
<li><a href="https://en.wikipedia.org/wiki/The_Lord_of_the_Rings" rel="nofollow noreferrer">Lord Of the Rings</a> of J.R.R. Tolkien </li>
<li>Picture taken from <a href="https://fr.slideshare.net/quentinadam/the-end-of-server-management-hosting-have-to-become-a-commodity-keynote-devoxx-fr-2015" rel="nofollow noreferrer">CleverCloud presentation</a></li>
</ul>

CC BY-SA 3.0
2017-03-28T10:04:34.727Z
2017-03-28T12:14:11.477Z
2017-03-28T12:14:11.477Z
Tensibai
<p>Some additions to your own answer to this question ...</p>
<h3>Additional monkeys</h3>
<p>The article about &quot;<a href="http://acutest.co.uk/blog/chaos-monkey" rel="noreferrer">How chaos boosts performance</a>&quot; describes a few more of these monkeys, i.e.:</p>
<blockquote>
<ul>
<li><strong>10-18 Monkey</strong>: finds configuration and run time problems in instances that serve customers in multiple regions.</li>
<li><strong>Chaos Kong</strong>: simulates an outage of an Amazon region.</li>
</ul>
</blockquote>
<p>Remark: The same article also mentions &quot;Chaos Gorilla: simulates an outage of an Amazon availability zone&quot;, though it could well be that this has been renamed now to &quot;Chaos Kong: simulates an outage of an Amazon region&quot; ... Talking about <em>Chaos</em>! I couldn't find any confirmation/docu on that so far, at least there does not seem to be an issue for it in the <a href="https://github.com/Netflix/SimianArmy/issues" rel="noreferrer">issue queue</a>. An undocumented change might have made it to production on github ... Gggggggrrrrrreat!</p>
<h3>Setup and use your own Monkeys.</h3>
<p>Head over to github to <a href="https://github.com/Netflix/SimianArmy/wiki" rel="noreferrer">get in touch with the Simian Army</a> (same link as the very first link in your own answer). Here is a quote of what you'll find there:</p>
<blockquote>
<p>Simian Army consists of services (Monkeys) in the cloud for generating various kinds of failures, detecting abnormal conditions, and testing our ability to survive them. The goal is to keep our cloud safe, secure, and highly available. More details can be found at <a href="http://techblog.netflix.com/2011/07/netflix-simian-army.html" rel="noreferrer">this blog</a>.</p>
<p>Currently the simians include <a href="https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey" rel="noreferrer">Chaos Monkey</a>, <a href="https://github.com/Netflix/SimianArmy/wiki/Janitor-Home" rel="noreferrer">Janitor Monkey</a>, and <a href="https://github.com/Netflix/SimianArmy/wiki/Conformity-Home" rel="noreferrer">Conformity Monkey</a>.</p>
<p>Refer to the <a href="https://github.com/Netflix/SimianArmy/wiki/Quick-Start-Guide" rel="noreferrer">Quick start guide</a> to get started setting up and using the Monkeys.</p>
</blockquote>
<p>You can even <a href="https://github.com/Netflix/SimianArmy/wiki/Configuration" rel="noreferrer">configure</a> the monkyes, so that they fit your business needs.</p>
<p>If you dig deep enough within those Github links (i.e within the <a href="https://github.com/Netflix/SimianArmy/wiki/Support" rel="noreferrer">Support</a> link), you'll also find a link to join the <a href="http://groups.google.com/group/simianarmy-users" rel="noreferrer">SimianArmy Google Group</a>.</p>

CC BY-SA 3.0
2017-03-23T15:54:19.747Z
Chaos Kong was renamed to Chaos Gorilla, I think or the other way around.
Jiri Klouda
CC BY-SA 3.0
2017-03-23T16:45:12.493Z
@JiriKlouda you seem to confirm what I was starting to wonder about. Which is why I'd added my remark in my answer now also.
Pierre.Vriens
CC BY-SA 3.0
2017-03-22T22:28:01.367Z
2017-03-23T16:40:24.670Z
2020-06-18T08:28:10.803Z
Pierre.Vriens
<p><strong>TL;DR</strong>: <a href="https://github.com/netflix/chaosmonkey" rel="nofollow noreferrer">Chaos Monkey</a> was <a href="http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html" rel="nofollow noreferrer">developed in 2010</a> at <a href="http://techblog.netflix.com/2011/07/netflix-simian-army.html" rel="nofollow noreferrer">Netflix</a> and <a href="http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html" rel="nofollow noreferrer">released into wild in 2012</a> is part of the <a href="https://github.com/Netflix/SimianArmy/blob/95ceab2ca15c1600feffb4e90e58c3c4f64a610f/assets/SimianArmy.png" rel="nofollow noreferrer">Simian Army</a>, wildly popular among <a href="https://groups.google.com/forum/#!forum/simianarmy-users" rel="nofollow noreferrer">devoted followers</a>. Built on <a href="http://principlesofchaos.org" rel="nofollow noreferrer">principles of chaos</a> engineering, the army increases resiliency to failure by injecting constant failure to the system.</p>
<h2>Concept</h2>
<p>Chaos Monkey was developed specifically for AWS where it will randomly kill instances within an Auto Scaling Group. It is meant to run during the business hours when engineers are alert and can quickly react to discovered failures.</p>
<h2>Simian Army</h2>
<p>Members of the army would <em>sow chaos</em> through other means:</p>
<ul>
<li><p>Latency Monkey will introduce random delays to services.</p>
</li>
<li><p>Chaos Gorilla (Kong) will simulate outage of entire availability zone.</p>
</li>
</ul>
<p>Other Monkeys are <em>helpful</em> and remove the weak members of the herd:</p>
<ul>
<li><p>Conformity Monkey shuts down instances not following best practices.</p>
</li>
<li><p>Security Monkey looks for known security vulnerabilities in configuration and services.</p>
</li>
<li><p>Doctor Monkey shuts down unhealthy instances not conforming to certain metrics.</p>
</li>
<li><p>Janitor Monkey looks for unused resources to reclaim.</p>
</li>
</ul>
<h2>Failure is Inevitable</h2>
<p>Failure in the System is inevitable, <a href="https://blog.codinghorror.com/working-with-the-chaos-monkey/" rel="nofollow noreferrer">something will always go wrong</a>. You might not be able to choose what, but you can try to choose when. By introducing small errors throughout the day, you ensure that your engineers are present. By killing non-conforming services quickly, you ensure that failures happen often before deployment. By making the environment more adversarial, you ensure that it will be the developers who run into issues long before any service makes its way into production. Failures will be quickly apparent in integration phase of new services with the old ones, but that is ok, because the old production services are already resilient.</p>
<h2>Cattle not Pets</h2>
<p>Everyone <a href="https://news.ycombinator.com/item?id=7311704" rel="nofollow noreferrer">will tell you</a> lately: Do not treat your <a href="http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/" rel="nofollow noreferrer">servers as pets</a>. There is a power in numbers and any single point of failure will bring down the system. No matter how well you can tune and optimize your server, no matter how beefy hardware you can get, how much it can handle, it will never be a match for herd of small scalable instances. Chaos Monkey encourages you to think about removing all points of failure, because sooner or later, the Monkey will come! Everyone fails and even the Amazon S3 had an <a href="https://aws.amazon.com/message/41926/" rel="nofollow noreferrer">unpredictable outage</a>.</p>
<h2>Anti-Fragile</h2>
<p>So what is the theory and why does it work? <a href="https://en.wikipedia.org/wiki/Nassim_Nicholas_Taleb" rel="nofollow noreferrer">Nassim Nicholas Taleb</a> in his book <a href="https://en.wikipedia.org/wiki/Antifragile" rel="nofollow noreferrer">Antifragile</a> describes a concept where living self-aware systems, will benefit from a small levels of randomness and actually become better in face of adversity. This is similar to annealing.</p>
<p>He does also describe an evolutionary way, where <em>fragility of parts</em> in a system is <em>transferring into antifragility of the whole</em>. The transfer occurs on two levels:</p>
<ol>
<li><p>By a small random variations - <em>developers making changes</em> - the most fit for the environment will survive and propagate - <em>pass tests and get deployed</em>. <strong>Standard Development Life Cycle</strong>.</p>
</li>
<li><p>By failure of parts not capable to withstand a larger level of randomness in the environment, the remaining parts that were able to withstand it compose a system that is as a whole better able to deal with changing environment than before. This is essentially <strong>Chaos Monkey</strong>.</p>
</li>
</ol>
<p>Larger levels of randomness can be withstood using the second approach.</p>

CC BY-SA 3.0
2017-03-22T21:43:44.583Z
"Failure is Inevitable" - great mantram!
wogsland
CC BY-SA 3.0
2017-08-01T21:11:01.633Z
Upvoted because you mentioned Nassim Taleb.  Super smart guy, and his ideas can be applied to basically anything.
maplebird
CC BY-SA 4.0
2017-03-21T06:04:27.830Z
2022-08-22T21:03:27.560Z
2022-08-22T21:03:27.560Z
Jiri Klouda
<p>I had a perfect server, it was so pretty and rock solid and so I named it Petra. It was perfect in every way, everything was configured and tuned just right, it had perfect 100% service record and 753 days of uptime. I've spent a lot of time and effort making sure it run so well. No other server in the company had been this good. But last night this evil monster crashed my server for no reason. </p>

<p><a href="https://i.sstatic.net/DC6C1.png" rel="noreferrer"><img src="https://i.sstatic.net/DC6C1.png" alt="Chaos Monkey"></a></p>

<p>Of course I was notified at 2am and it took me until morning to get it up and running and everything configured and tuned up, but I'm afraid it is not going to be as good as before. It might take weeks before it is back to it's former glory. Now my uptime is gone, I don't have even measly three 9s and who knows what this will do to my reputation. Who is this Chaos Monkey and why did he do that to my server and why is he trying to ruin me?  </p>

CC BY-SA 3.0
2017-03-21T08:06:50.347Z
There needs to be a badge for funniest question :)
Richard Slater
CC BY-SA 3.0
2017-03-26T21:18:33.913Z
Single server?  What's that?  Why would you base your business on a unique work of art instead of a commodity that is easily scaled and replaced when it inevitably fails or goes off lease?
No Refunds No Returns
CC BY-SA 3.0
2017-04-02T04:40:34.503Z
Do we really consider this a good question to pre-seed the site with?  Are we expecting engineers to install, configure, and run Chaos Monkey, then forget what it is, but discover that it's running on their network and ask on Stack Exchange rather than visiting the official website?  There are so many steps there that are implausible.
Xiong Chiamiov
CC BY-SA 3.0
2017-04-02T05:55:11.843Z
Obviously, it is not a real question. It was a joke to sort of portray the top of the field sysadmin of old, who's simply been outpaced by the industry. But your criticism assumes that there is a single person or even a single team taking care of the infrastructure. Quite often in large companies the existing infrastructure and teams are left in place even while they are being replaced. It is quite plausible that a new team started with new infrastructure and installation of Chaos Monkey and the old fart simply got hit at a time when it was after initial success deployed company wide.
Jiri Klouda
CC BY-SA 3.0
2017-04-15T15:08:05.170Z
@immibis answer to that is in the comment above yours.
Jiri Klouda
<amazon-web-services><process><automation><servers><sysadmin>
Who is this Chaos Monkey and why did he crash my server?
Jiri Klouda
# Who is this Chaos Monkey and why did he crash my server?

(Asked by: username_0 on 2017-03-21)

I had a perfect server, it was so pretty and rock solid and so I named it Petra. It was perfect in every way, everything was configured and tuned just right, it had perfect 100% service record and 753 days of uptime. I've spent a lot of time and effort making sure it run so well. No other server in the company had been this good. But last night this evil monster crashed my server for no reason.

[![Chaos Monkey](https://i.sstatic.net/DC6C1.png)](https://i.sstatic.net/DC6C1.png)

Of course I was notified at 2am and it took me until morning to get it up and running and everything configured and tuned up, but I'm afraid it is not going to be as good as before. It might take weeks before it is back to it's former glory. Now my uptime is gone, I don't have even measly three 9s and who knows what this will do to my reputation. Who is this Chaos Monkey and why did he do that to my server and why is he trying to ruin me?

**Tags:** amazon-web-services, process, automation, servers, sysadmin

> **Comments:**
> **username_1**: There needs to be a badge for funniest question :)  
> **username_2**: Single server?  What's that?  Why would you base your business on a unique work of art instead of a commodity that is easily scaled and replaced when it inevitably fails or goes off lease?  
> **username_3**: Do we really consider this a good question to pre-seed the site with?  Are we expecting engineers to install, configure, and run Chaos Monkey, then forget what it is, but discover that it's running on their network and ask on Stack Exchange rather than visiting the official website?  There are so many steps there that are implausible.  
> **username_0**: Obviously, it is not a real question. It was a joke to sort of portray the top of the field sysadmin of old, who's simply been outpaced by the industry. But your criticism assumes that there is a single person or even a single team taking care of the infrastructure. Quite often in large companies the existing infrastructure and teams are left in place even while they are being replaced. It is quite plausible that a new team started with new infrastructure and installation of Chaos Monkey and the old fart simply got hit at a time when it was after initial success deployed company wide.  
> **username_0**: @immibis answer to that is in the comment above yours.  

---

## 3 answers

### Answer by username_0 on 2017-03-21. Score: 39 | Accepted answer

**TL;DR**: [Chaos Monkey](https://github.com/netflix/chaosmonkey) was [developed in 2010](http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html) at [Netflix](http://techblog.netflix.com/2011/07/netflix-simian-army.html) and [released into wild in 2012](http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html) is part of the [Simian Army](https://github.com/Netflix/SimianArmy/blob/95ceab2ca15c1600feffb4e90e58c3c4f64a610f/assets/SimianArmy.png), wildly popular among [devoted followers](https://groups.google.com/forum/#!forum/simianarmy-users). Built on [principles of chaos](http://principlesofchaos.org) engineering, the army increases resiliency to failure by injecting constant failure to the system.

## Concept

Chaos Monkey was developed specifically for AWS where it will randomly kill instances within an Auto Scaling Group. It is meant to run during the business hours when engineers are alert and can quickly react to discovered failures.

## Simian Army

Members of the army would *sow chaos* through other means:

* Latency Monkey will introduce random delays to services.
* Chaos Gorilla (Kong) will simulate outage of entire availability zone.

Other Monkeys are *helpful* and remove the weak members of the herd:

* Conformity Monkey shuts down instances not following best practices.
* Security Monkey looks for known security vulnerabilities in configuration and services.
* Doctor Monkey shuts down unhealthy instances not conforming to certain metrics.
* Janitor Monkey looks for unused resources to reclaim.

## Failure is Inevitable

Failure in the System is inevitable, [something will always go wrong](https://blog.codinghorror.com/working-with-the-chaos-monkey/). You might not be able to choose what, but you can try to choose when. By introducing small errors throughout the day, you ensure that your engineers are present. By killing non-conforming services quickly, you ensure that failures happen often before deployment. By making the environment more adversarial, you ensure that it will be the developers who run into issues long before any service makes its way into production. Failures will be quickly apparent in integration phase of new services with the old ones, but that is ok, because the old production services are already resilient.

## Cattle not Pets

Everyone [will tell you](https://news.ycombinator.com/item?id=7311704) lately: Do not treat your [servers as pets](http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/). There is a power in numbers and any single point of failure will bring down the system. No matter how well you can tune and optimize your server, no matter how beefy hardware you can get, how much it can handle, it will never be a match for herd of small scalable instances. Chaos Monkey encourages you to think about removing all points of failure, because sooner or later, the Monkey will come! Everyone fails and even the Amazon S3 had an [unpredictable outage](https://aws.amazon.com/message/41926/).

## Anti-Fragile

So what is the theory and why does it work? [Nassim Nicholas Taleb](https://en.wikipedia.org/wiki/Nassim_Nicholas_Taleb) in his book [Antifragile](https://en.wikipedia.org/wiki/Antifragile) describes a concept where living self-aware systems, will benefit from a small levels of randomness and actually become better in face of adversity. This is similar to annealing.

He does also describe an evolutionary way, where *fragility of parts* in a system is *transferring into antifragility of the whole*. The transfer occurs on two levels:

1. By a small random variations - *developers making changes* - the most fit for the environment will survive and propagate - *pass tests and get deployed*. **Standard Development Life Cycle**.
2. By failure of parts not capable to withstand a larger level of randomness in the environment, the remaining parts that were able to withstand it compose a system that is as a whole better able to deal with changing environment than before. This is essentially **Chaos Monkey**.

Larger levels of randomness can be withstood using the second approach.

> **Comments:**
> **username_6**: "Failure is Inevitable" - great mantram!  
> **username_7**: Upvoted because you mentioned Nassim Taleb.  Super smart guy, and his ideas can be applied to basically anything.  

---

### Answer by username_5 on 2017-03-22. Score: 9

Some additions to your own answer to this question ...

### Additional monkeys

The article about "[How chaos boosts performance](http://acutest.co.uk/blog/chaos-monkey)" describes a few more of these monkeys, i.e.:

> * **10-18 Monkey**: finds configuration and run time problems in instances that serve customers in multiple regions.
> * **Chaos Kong**: simulates an outage of an Amazon region.

Remark: The same article also mentions "Chaos Gorilla: simulates an outage of an Amazon availability zone", though it could well be that this has been renamed now to "Chaos Kong: simulates an outage of an Amazon region" ... Talking about *Chaos*! I couldn't find any confirmation/docu on that so far, at least there does not seem to be an issue for it in the [issue queue](https://github.com/Netflix/SimianArmy/issues). An undocumented change might have made it to production on github ... Gggggggrrrrrreat!

### Setup and use your own Monkeys.

Head over to github to [get in touch with the Simian Army](https://github.com/Netflix/SimianArmy/wiki) (same link as the very first link in your own answer). Here is a quote of what you'll find there:

> Simian Army consists of services (Monkeys) in the cloud for generating various kinds of failures, detecting abnormal conditions, and testing our ability to survive them. The goal is to keep our cloud safe, secure, and highly available. More details can be found at [this blog](http://techblog.netflix.com/2011/07/netflix-simian-army.html).
>
> Currently the simians include [Chaos Monkey](https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey), [Janitor Monkey](https://github.com/Netflix/SimianArmy/wiki/Janitor-Home), and [Conformity Monkey](https://github.com/Netflix/SimianArmy/wiki/Conformity-Home).
>
> Refer to the [Quick start guide](https://github.com/Netflix/SimianArmy/wiki/Quick-Start-Guide) to get started setting up and using the Monkeys.

You can even [configure](https://github.com/Netflix/SimianArmy/wiki/Configuration) the monkyes, so that they fit your business needs.

If you dig deep enough within those Github links (i.e within the [Support](https://github.com/Netflix/SimianArmy/wiki/Support) link), you'll also find a link to join the [SimianArmy Google Group](http://groups.google.com/group/simianarmy-users).

> **Comments:**
> **username_0**: Chaos Kong was renamed to Chaos Gorilla, I think or the other way around.  
> **username_5**: @JiriKlouda you seem to confirm what I was starting to wonder about. Which is why I'd added my remark in my answer now also.  

---

### Answer by username_4 on 2017-03-28. Score: 3

> One Server to rule them all, One Server to find them,  
> One Server to bring them all and in the outage bind them

You, Sauron, forged this One Server, in the Darkness of Mount Doom your Datacenter in a desire to rule All applications.  
Hopefully the Fellowship of Devops did unite to tell you:

[![Gandalf - You shall PAAS](https://i.sstatic.net/OAT4s.jpg)](https://i.sstatic.net/OAT4s.jpg)

After a long fight, Frodo the Chaos Monkey has been able to melt your One Server and bring freedom to all applications, driving you to the way of reproducible Servers at the same time.

Credits:

* [Lord Of the Rings](https://en.wikipedia.org/wiki/The_Lord_of_the_Rings) of J.R.R. Tolkien
* Picture taken from [CleverCloud presentation](https://fr.slideshare.net/quentinadam/the-end-of-server-management-hosting-have-to-become-a-commodity-keynote-devoxx-fr-2015)


---

