├── .gitattributes ├── .editorconfig ├── .github └── workflows │ └── lint.yml ├── contributing.md ├── .gitignore ├── code-of-conduct.md ├── LICENSE └── README.md /.gitattributes: -------------------------------------------------------------------------------- 1 | * text=auto 2 | -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | root = true 2 | 3 | [*] 4 | indent_style = tab 5 | end_of_line = lf 6 | charset = utf-8 7 | trim_trailing_whitespace = true 8 | insert_final_newline = true 9 | -------------------------------------------------------------------------------- /.github/workflows/lint.yml: -------------------------------------------------------------------------------- 1 | name: Lint 2 | 3 | on: 4 | push: 5 | branches: [master] 6 | pull_request: 7 | types: [opened, synchronize] 8 | 9 | jobs: 10 | awesome_bot: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v3 14 | - uses: ruby/setup-ruby@v1 15 | with: 16 | ruby-version: 2.6 17 | - name: Install awesome_bot 18 | run: gem install awesome_bot 19 | - name: Run awesome_bot 20 | run: awesome_bot README.md --allow-redirect --allow-dupe --allow-timeout --set-timeout 60 --skip-save-results --allow 429 21 | 22 | awesome_lint: 23 | name: Run awesome linter 24 | runs-on: ubuntu-latest 25 | steps: 26 | - uses: actions/checkout@v3 27 | with: 28 | fetch-depth: 0 29 | - uses: actions/setup-node@v2 30 | with: 31 | node-version: '14' 32 | - run: npx awesome-lint 33 | -------------------------------------------------------------------------------- /contributing.md: -------------------------------------------------------------------------------- 1 | # Contribution Guidelines 2 | 3 | Please note that this project is released with a 4 | [Contributor Code of Conduct](code-of-conduct.md). By participating in this 5 | project you agree to abide by its terms. 6 | 7 | --- 8 | 9 | Ensure your pull request adheres to the following guidelines: 10 | 11 | - Make sure you take care of this 12 | - And this as well 13 | - And don't forget to check this 14 | 15 | Thank you for your suggestions! 16 | 17 | 18 | ## Updating your PR 19 | 20 | A lot of times, making a PR adhere to the standards above can be difficult. 21 | If the maintainers notice anything that we'd like changed, we'll ask you to 22 | edit your PR before we merge it. There's no need to open a new PR, just edit 23 | the existing one. If you're not sure how to do that, 24 | [here is a guide](https://github.com/RichardLitt/knowledge/blob/master/github/amending-a-commit-guide.md) 25 | on the different ways you can update your PR so that we can merge it. 26 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | # Created by https://www.toptal.com/developers/gitignore/api/linux,macos,windows 3 | # Edit at https://www.toptal.com/developers/gitignore?templates=linux,macos,windows 4 | 5 | ### Linux ### 6 | *~ 7 | 8 | # temporary files which can be created if a process still has a handle open of a deleted file 9 | .fuse_hidden* 10 | 11 | # KDE directory preferences 12 | .directory 13 | 14 | # Linux trash folder which might appear on any partition or disk 15 | .Trash-* 16 | 17 | # .nfs files are created when an open file is removed but is still being accessed 18 | .nfs* 19 | 20 | ### macOS ### 21 | # General 22 | .DS_Store 23 | .AppleDouble 24 | .LSOverride 25 | 26 | # Icon must end with two \r 27 | Icon 28 | 29 | 30 | # Thumbnails 31 | ._* 32 | 33 | # Files that might appear in the root of a volume 34 | .DocumentRevisions-V100 35 | .fseventsd 36 | .Spotlight-V100 37 | .TemporaryItems 38 | .Trashes 39 | .VolumeIcon.icns 40 | .com.apple.timemachine.donotpresent 41 | 42 | # Directories potentially created on remote AFP share 43 | .AppleDB 44 | .AppleDesktop 45 | Network Trash Folder 46 | Temporary Items 47 | .apdisk 48 | 49 | ### Windows ### 50 | # Windows thumbnail cache files 51 | Thumbs.db 52 | Thumbs.db:encryptable 53 | ehthumbs.db 54 | ehthumbs_vista.db 55 | 56 | # Dump file 57 | *.stackdump 58 | 59 | # Folder config file 60 | [Dd]esktop.ini 61 | 62 | # Recycle Bin used on file shares 63 | $RECYCLE.BIN/ 64 | 65 | # Windows Installer files 66 | *.cab 67 | *.msi 68 | *.msix 69 | *.msm 70 | *.msp 71 | 72 | # Windows shortcuts 73 | *.lnk 74 | 75 | # End of https://www.toptal.com/developers/gitignore/api/linux,macos,windows 76 | -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, gender identity and expression, level of experience, 9 | nationality, personal appearance, race, religion, or sexual identity and 10 | orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at adrian.novegil@gmail.com. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at [http://contributor-covenant.org/version/1/4][version] 72 | 73 | [homepage]: http://contributor-covenant.org 74 | [version]: http://contributor-covenant.org/version/1/4/ 75 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | CC0 1.0 Universal 2 | 3 | Statement of Purpose 4 | 5 | The laws of most jurisdictions throughout the world automatically confer 6 | exclusive Copyright and Related Rights (defined below) upon the creator and 7 | subsequent owner(s) (each and all, an "owner") of an original work of 8 | authorship and/or a database (each, a "Work"). 9 | 10 | Certain owners wish to permanently relinquish those rights to a Work for the 11 | purpose of contributing to a commons of creative, cultural and scientific 12 | works ("Commons") that the public can reliably and without fear of later 13 | claims of infringement build upon, modify, incorporate in other works, reuse 14 | and redistribute as freely as possible in any form whatsoever and for any 15 | purposes, including without limitation commercial purposes. These owners may 16 | contribute to the Commons to promote the ideal of a free culture and the 17 | further production of creative, cultural and scientific works, or to gain 18 | reputation or greater distribution for their Work in part through the use and 19 | efforts of others. 20 | 21 | For these and/or other purposes and motivations, and without any expectation 22 | of additional consideration or compensation, the person associating CC0 with a 23 | Work (the "Affirmer"), to the extent that he or she is an owner of Copyright 24 | and Related Rights in the Work, voluntarily elects to apply CC0 to the Work 25 | and publicly distribute the Work under its terms, with knowledge of his or her 26 | Copyright and Related Rights in the Work and the meaning and intended legal 27 | effect of CC0 on those rights. 28 | 29 | 1. Copyright and Related Rights. A Work made available under CC0 may be 30 | protected by copyright and related or neighboring rights ("Copyright and 31 | Related Rights"). Copyright and Related Rights include, but are not limited 32 | to, the following: 33 | 34 | i. the right to reproduce, adapt, distribute, perform, display, communicate, 35 | and translate a Work; 36 | 37 | ii. moral rights retained by the original author(s) and/or performer(s); 38 | 39 | iii. publicity and privacy rights pertaining to a person's image or likeness 40 | depicted in a Work; 41 | 42 | iv. rights protecting against unfair competition in regards to a Work, 43 | subject to the limitations in paragraph 4(a), below; 44 | 45 | v. rights protecting the extraction, dissemination, use and reuse of data in 46 | a Work; 47 | 48 | vi. database rights (such as those arising under Directive 96/9/EC of the 49 | European Parliament and of the Council of 11 March 1996 on the legal 50 | protection of databases, and under any national implementation thereof, 51 | including any amended or successor version of such directive); and 52 | 53 | vii. other similar, equivalent or corresponding rights throughout the world 54 | based on applicable law or treaty, and any national implementations thereof. 55 | 56 | 2. Waiver. To the greatest extent permitted by, but not in contravention of, 57 | applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and 58 | unconditionally waives, abandons, and surrenders all of Affirmer's Copyright 59 | and Related Rights and associated claims and causes of action, whether now 60 | known or unknown (including existing as well as future claims and causes of 61 | action), in the Work (i) in all territories worldwide, (ii) for the maximum 62 | duration provided by applicable law or treaty (including future time 63 | extensions), (iii) in any current or future medium and for any number of 64 | copies, and (iv) for any purpose whatsoever, including without limitation 65 | commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes 66 | the Waiver for the benefit of each member of the public at large and to the 67 | detriment of Affirmer's heirs and successors, fully intending that such Waiver 68 | shall not be subject to revocation, rescission, cancellation, termination, or 69 | any other legal or equitable action to disrupt the quiet enjoyment of the Work 70 | by the public as contemplated by Affirmer's express Statement of Purpose. 71 | 72 | 3. Public License Fallback. Should any part of the Waiver for any reason be 73 | judged legally invalid or ineffective under applicable law, then the Waiver 74 | shall be preserved to the maximum extent permitted taking into account 75 | Affirmer's express Statement of Purpose. In addition, to the extent the Waiver 76 | is so judged Affirmer hereby grants to each affected person a royalty-free, 77 | non transferable, non sublicensable, non exclusive, irrevocable and 78 | unconditional license to exercise Affirmer's Copyright and Related Rights in 79 | the Work (i) in all territories worldwide, (ii) for the maximum duration 80 | provided by applicable law or treaty (including future time extensions), (iii) 81 | in any current or future medium and for any number of copies, and (iv) for any 82 | purpose whatsoever, including without limitation commercial, advertising or 83 | promotional purposes (the "License"). The License shall be deemed effective as 84 | of the date CC0 was applied by Affirmer to the Work. Should any part of the 85 | License for any reason be judged legally invalid or ineffective under 86 | applicable law, such partial invalidity or ineffectiveness shall not 87 | invalidate the remainder of the License, and in such case Affirmer hereby 88 | affirms that he or she will not (i) exercise any of his or her remaining 89 | Copyright and Related Rights in the Work or (ii) assert any associated claims 90 | and causes of action with respect to the Work, in either case contrary to 91 | Affirmer's express Statement of Purpose. 92 | 93 | 4. Limitations and Disclaimers. 94 | 95 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 96 | surrendered, licensed or otherwise affected by this document. 97 | 98 | b. Affirmer offers the Work as-is and makes no representations or warranties 99 | of any kind concerning the Work, express, implied, statutory or otherwise, 100 | including without limitation warranties of title, merchantability, fitness 101 | for a particular purpose, non infringement, or the absence of latent or 102 | other defects, accuracy, or the present or absence of errors, whether or not 103 | discoverable, all to the greatest extent permissible under applicable law. 104 | 105 | c. Affirmer disclaims responsibility for clearing rights of other persons 106 | that may apply to the Work or any use thereof, including without limitation 107 | any person's Copyright and Related Rights in the Work. Further, Affirmer 108 | disclaims responsibility for obtaining any necessary consents, permissions 109 | or other rights required for any use of the Work. 110 | 111 | d. Affirmer understands and acknowledges that Creative Commons is not a 112 | party to this document and has no duty or obligation with respect to this 113 | CC0 or use of the Work. 114 | 115 | For more information, please see 116 | 117 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Awesome Chaos Engineering [![Awesome](https://awesome.re/badge.svg)](https://awesome.re) 2 | 3 | Testing in production (TiP) is gaining steam as an accepted practice in DevOps and testing communities, but no amount of preproduction QA testing can foresee all the possible scenarios in your real production deployment. 4 | 5 | The prevailing wisdom is that you will see failures in production; the only question is whether you'll be surprised by them or inflict them intentionally to test system resilience and learn from the experience. 6 | 7 | The latter approach is chaos engineering. 8 | 9 | > To understand all this knowledge is very important have a good background in Chaos Engineering, containers, fault injection, monitoring and observability. 10 | 11 | ## Contents 12 | 13 | - [0. Introduction](#0-introduction) 14 | - [1. Chaos in Practice](#1-chaos-in-practice) 15 | - [2. Principles of Chaos Engineering](#2-principles-of-chaos-engineering) 16 | - [3. Fault Injection](#3-fault-injection) 17 | - [4. Observability](#4-observability) 18 | - [5. Incident Management Tool](#5-incident-management-tool) 19 | - [6. Cost of SEVs](#6-cost-of-sevs) 20 | - [7. Chaos As A Sevice](#7-chaos-as-a-sevice) 21 | - [8. Gamedays](#8-gamedays) 22 | - [9. Forums and Groups](#9-forums-and-groups) 23 | - [10. References](#10-references) 24 | - [11. License](#11-license) 25 | - [12. Contributing](#12-contributing) 26 | 27 | ## 0. Introduction 28 | 29 | __Chaos engineering__ is defined as "the discipline of experimenting on a system in order to build confidence in the system's capability to withstand turbulent conditions in production" (Principles of Chaos Engineering, http://principlesofchaos.org/). 30 | 31 | In other words, it's a software testing method focusing on finding evidence of problems before they are experienced by users. 32 | 33 | It's a common misconception that chaos engineering is only about randomly breaking things in production. It's not. Although running experiments in production is a unique part of chaos engineering (more on that later), it's about much more than that—anything that helps us be confident the system can withstand turbulence. 34 | 35 | > IMPORTANT!: Chaos engineering is not just about randomly breaking things ;-) 36 | 37 | It interfaces with site reliability engineering (SRE), application and systems performance analysis, and other forms of testing. 38 | 39 | Practicing chaos engineering can help you prepare for failure, and by doing that, learn to build better systems, improve existing ones, and make the world a safer place. 40 | 41 | ### Motivations for chaos engineering 42 | 43 | There are at least three good reasons to implement chaos engineering: 44 | 45 | - Determining risk and cost and setting service-level indicators, objectives, and agreements 46 | - Testing a system (often complex and distributed) as a whole 47 | - Finding emergent properties you were unaware of 48 | 49 | ## 1. Chaos in Practice 50 | 51 | To specifically address the uncertainty of distributed systems at scale, Chaos Engineering can be thought of as the facilitation of experiments to uncover systemic weaknesses. These experiments follow four steps: 52 | 53 | - Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior. 54 | - Hypothesize that this steady state will continue in both the control group and the experimental group. 55 | - Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc. 56 | - Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group. 57 | 58 | The harder it is to disrupt the steady state, the more confidence we have in the behavior of the system. If a weakness is uncovered, we now have a target for improvement before that behavior manifests in the system at large. 59 | 60 | ## 2. Principles of Chaos Engineering 61 | 62 | A chaos experiment is defined as the following five points by the Principles of chaos engineering 63 | 64 | - Build a Hypothesis around Steady State Behavior 65 | - Vary Real-world Events 66 | - Run Experiments in Production 67 | - Automate Experiments to Run Continuously 68 | - Minimize Blast Radius 69 | 70 | More details in the following link ;-) 71 | 72 | - [PRINCIPLES OF CHAOS ENGINEERING](https://principlesofchaos.org/) 73 | 74 | ## 3. Fault Injection 75 | 76 | ### Generic Tools 77 | 78 | - [The Simian Army](https://github.com/Netflix/SimianArmy) - A suite of tools for keeping your cloud operating in top form. 79 | - [Chaos Monkey](https://github.com/Netflix/chaosmonkey) - A resiliency tool that helps applications tolerate random instance failures. 80 | - [Chaos Toolkit](https://github.com/chaostoolkit/chaostoolkit) - A chaos engineering toolkit to help you build confidence in your software system. 81 | - [Chaos Toolkit Turbulence](https://github.com/tmobile/chaostoolkit-turbulence) - This is an extension for Chaos Toolkit which adds support for Turbulence attacks. 82 | - [Monarch](https://github.com/tmobile/monarch) - This is a series of tools for Chaos Toolkit. 83 | - [Muxy](https://github.com/mefellows/muxy/) - A chaos testing tool for simulating a real-world distributed system failures. 84 | - [Chaos Blade](https://github.com/chaosblade-io/chaosblade) - Chaosblade is an experimental tool that follows the principles of Chaos Engineering and is used to simulate common fault scenarios, helping to improve the recoverability of faulty systems and the fault tolerance of faults. 85 | - [Cthulhu](https://github.com/xmatters/cthulhu-chaos-testing) - Chaos Engineering tool that helps evaluating the resiliency of microservice systems simulating various disaster scenarios against a target infrastructure in a data-driven manner. 86 | - [Namazu](https://github.com/osrg/namazu) - Programmable fuzzy scheduler for testing distributed systems. 87 | - [Chaos Scimmia](https://github.com/joshuamckenty/chaos-scimmia) - Chaos Engineering for Redis. 88 | - [HavocLeopard](https://github.com/jonfast565/HavocLeopard) - A set of simple chaos engineering apps that can be used to royally screw up your on-prem servers. 89 | - [Arcdata](https://github.com/redcross/arcdata) - Open source incident management and volunteer scheduling application for Red Cross Disaster Services. 90 | - [AWS Chaos Scripts](https://github.com/adhorn/aws-chaos-scripts) - Collection of python scripts to run failure injection on AWS infrastructure. 91 | - [Simoorg](https://github.com/LinkedInAttic/simoorg/tree/master) - Simoorg is linkedin’s very own failure inducer framework, It was designed to be easy to extend and most of the important components are pluggable. 92 | 93 | ### CPU's 94 | 95 | - [Cpu Troll](https://github.com/TrollScripts/cpu-troll) - Dedicated to raising CPU latency by the requested percentage and timespan. 96 | 97 | ### Memory 98 | 99 | - [totalChaos](https://github.com/Rayan25062011/totalChaos) - This will overload ram, start moving opened windows everywhere, if the user enter CTRL+ALT+DEL it will put infinite command prompts. 100 | 101 | ### File system 102 | 103 | ### Disk 104 | 105 | ### Networking 106 | 107 | - [Toxiproxy](https://github.com/Shopify/toxiproxy) - A TCP proxy to simulate network and system conditions for chaos and resiliency testing. 108 | - [Comcast](https://github.com/tylertreat/comcast) - A tool designed to simulate common network problems like latency, bandwidth restrictions, and dropped/reordered/corrupted packets. 109 | - [Chaos HTTP Proxy](https://github.com/bouncestorage/chaos-http-proxy) - Introduce failures into HTTP requests via a proxy server. 110 | 111 | ### Security 112 | 113 | - [Infection Monkey](https://github.com/guardicore/monkey) - Open source security tool for testing a data center's resiliency to perimeter breaches and internal server infection. The Monkey uses various methods to self propagate across a data center and reports success to a centralized Monkey Island server. 114 | - [ChaoSlingr](https://github.com/Optum/ChaoSlingr) - Introducing Security Chaos Engineering. ChaoSlingr focuses primarily on the experimentation on AWS Infrastructure to proactively instrument system security failure through experimentation. 115 | - [Mitigant](https://www.mitigant.io/) - Security chaos engineering for cloud cyber resilience. 116 | 117 | ### Languages 118 | 119 | #### Compilation time 120 | 121 | - [ChaosCat](https://github.com/Torvaney/chaoscat) - Chaos engineering for Pull Requests - Taking a not-even-good joke a bit too far. 122 | 123 | #### Runtime 124 | 125 | - [Byteman](https://byteman.jboss.org/) - A Swiss Army Knife for Byte Code Manipulation. 126 | - [Byte-Monkey](https://github.com/mrwilson/byte-monkey) - Bytecode-level fault injection for the JVM. It works by instrumenting application code on the fly to deliberately introduce faults like exceptions and latency. 127 | - [Perses](https://github.com/nicolasmanic/perses) - A project to cause (controlled) destruction to a JVM application. 128 | - [Wiremock](http://wiremock.org/) - API mocking (Service Virtualization) which enables modeling real world faults and delays. 129 | - [MockLab](http://get.mocklab.io/) - API mocking (Service Virtualization) as a service which enables modeling real world faults and delays. 130 | - [Flaw](https://github.com/GaruGaru/flaw) - Inject failures on api calls for local chaos engineering. 131 | - [Havoc](https://github.com/bchavez/Havoc) - Havoc is a collection of dangerous code that wreck havoc in .NET applications and the operating system for chaos-engineering. 132 | - [Utilities for frontend chaos engineering](https://github.com/jchiatt/chaos) - Utilities for frontend chaos engineering. 133 | - [CHAOS GOPHER](https://github.com/chaostesting/chaosgopher) - A collection of unix style tools in GO to do chaos engineering or testing. 134 | - [Chaos Monkey for Spring Boot](https://codecentric.github.io/chaos-monkey-spring-boot/) - Injects latencies, exceptions, and terminations into Spring Boot applications. 135 | - [React Chaos](https://github.com/jchiatt/react-chaos) - Chaos Engineering for your React apps. 136 | - [Vue Chaos](https://github.com/aviadhahami/vue-chaos) - A simple (yet chaotic) component to introduce chaos in your Vue app. 137 | - [Chaos QoaLa](https://github.com/oslabs-beta/ChaosQoaLa) - ChaosQoaLa is a chaos engineering tool for injecting failure into JavaScript backed GraphQL end points. 138 | - [Chaos Reverse-engineering](https://github.com/pcoppens/chaos-re) - Chaos engineering approach by Reverse-engineering. 139 | - [Fault](https://github.com/lingrino/go-fault) - The fault package provides go http middleware that makes it easy to inject faults into your service. 140 | - [GORM SQLChaos](https://github.com/u2386/gorm-sqlchaos) - GORM SQLChaos manipulates DML at program runtime based on gorm callbacks 141 | - [Chaos Frontend Toolkit](https://chaos-frontend-toolkit.web.app/) - A set of tools to break your web apps and, in doing so, find ways to improve them. 142 | 143 | ### Database 144 | 145 | - [RedFI](https://github.com/openfip/redfi) - RedFI acts as a proxy between the client and Redis with the capability of injecting faults on the fly, based on the rules given by you. 146 | 147 | ### Virtual Machine 148 | 149 | - [ChaosMachine](https://github.com/KTH/royal-chaos/tree/master/chaosmachine) - Tool to do chaos engineering at the application level in the JVM. 150 | - [TripleAgent](https://github.com/KTH/royal-chaos/tree/master/tripleagent) - System for fault injection for Java applications. . 151 | 152 | ### Containers & Orchestrators 153 | 154 | - [ChaosOrca](https://github.com/KTH/royal-chaos/tree/master/chaosorca) - Tool for doing Chaos Engineering on containers by perturbing system calls for processes inside containers. 155 | - [POBS](https://github.com/KTH/royal-chaos/tree/master/pobs) - Automatic Observability and Chaos for Dockerized Java Applications. 156 | - [Pumba](https://github.com/gaia-adm/pumba) - Chaos testing and network emulation for Docker containers (and clusters). 157 | - [Blockade](https://github.com/worstcase/blockade) - Docker-based utility for testing network failures and partitions in distributed applications. 158 | - [Chaos Engineering for Docker](https://github.com/cloudchaos/docker) - Chaos Engineering for Docker. 159 | - [Chaos Engineering with Docker EE](https://github.com/sameerkasi200x/docker-chaos-engineering) - Chaos Engineering with Docker EE. 160 | - [Chaos Util](https://github.com/abnamrocoesd/chaos-util) - Docker image with utilities for Chaos Engineering. 161 | - [Drax](https://github.com/dcos-labs/drax) - DC/OS Resilience Automated Xenodiagnosis tool. It helps to test DC/OS deployments by applying a Chaos Monkey-inspired, proactive and invasive testing approach. 162 | - [Pod-Reaper](https://github.com/target/pod-reaper) - A rules based pod killing container. Pod-Reaper was designed to kill pods that meet specific conditions that can be used for Chaos testing in Kubernetes. 163 | - [Chaoskube](https://github.com/linki/chaoskube) - ChaosKube periodically kills random pods in your Kubernetes cluster. 164 | - [Litmus](https://github.com/litmuschaos/litmus) - Framework for Kubernetes environments that enables users to run test suites, capture logs, generate reports and perform chaos tests. 165 | - [Chaos Operator](https://github.com/litmuschaos/chaos-operator) - Chaos engineering via kubernetes operator. 166 | - [Kube Entropy](https://github.com/alexlokshin/kube-entropy) - A little chaos engineering application for kubernetes resilience testing. 167 | - [kubernetes-chaos-lab](https://github.com/matthewbrahms/kubernetes-chaos-lab) - A brief guide to setting up your first chaos engineering lab on Kubernetes!. 168 | - [Chaos Mesh](https://github.com/pingcap/chaos-mesh) - A Chaos Engineering Platform for Kubernetes. 169 | 170 | ### Hypervisors 171 | 172 | - [VMware Mangle](https://vmware.github.io/mangle/) - Orchestrating Chaos Engineering. 173 | - [Turbulence](https://github.com/cppforlife/turbulence-release) - Tool focused on BOSH environments capable of stressing VMs, manipulating network traffic, and more. It is very simmilar to Gremlin. 174 | - [Chaos Lemur](https://github.com/strepsirrhini-army/chaos-lemur) - This project is a self-hostable application to randomly destroy virtual machines in a BOSH-managed environment. 175 | 176 | ### Kernel & Operating System 177 | 178 | ### Cloud 179 | 180 | - [Chaos Engine](https://github.com/ThalesGroup/chaos-engine) - Chaos Engine is an application for creating random Chaos Events in cloud applications to test resiliency. 181 | 182 | #### Private Cloud 183 | 184 | - [Glooshot](https://github.com/solo-io/glooshot) - Chaos engineering framework to help you Immunize your service mesh. 185 | - [kube-monkey](https://github.com/asobti/kube-monkey) - An implementation of Netflix's Chaos Monkey for Kubernetes clusters. 186 | - [Powerful Seal](https://github.com/bloomberg/powerfulseal) - PowerfulSeal adds chaos to your Kubernetes clusters, so that you can detect problems in your systems as early as possible. It kills targeted pods and takes VMs up and down. 187 | - [KubeInvaders](https://github.com/lucky-sideburn/KubeInvaders) - Gamfied Chaos engineering tool for Kubernetes Clusters. 188 | - [Kube DOOM](https://github.com/storax/kubedoom) - The next level of chaos engineering is here! Kill pods inside your Kubernetes cluster by shooting them in Doom. 189 | - [GomJabbar](https://github.com/outbrain/GomJabbar) - ChaosMonkey for your private cloud. 190 | - [kubethanos](https://github.com/berkay-dincer/kubethanos) - kubethanos kills half of your pods randomly to engineer chaos in your preferred environment, gives you the opportunity to see how your system behaves under failures. 191 | - [krkn](https://github.com/redhat-chaos/krkn) - Chaos and resiliency testing tool for Kubernetes and OpenShift. 192 | - [kube-burner](https://github.com/cloud-bulldozer/kube-burner) - Kube-burner is a Kubernetes performance and scale test orchestration toolset. 193 | - [Chaos Controller](https://github.com/DataDog/chaos-controller) - The Chaos Controller is a Kubernetes controller with which you can inject various systemic failures, at scale, and without caring about the implementation details of your Kubernetes infrastructure. 194 | 195 | #### Amazon AWS 196 | 197 | - [Testing Amazon Aurora Using Fault Injection Queries](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/AuroraMySQL.Managing.html#AuroraMySQL.Managing.FaultInjectionQueries) - Testing Amazon Aurora Using Fault Injection Queries. 198 | - [Chaos SSM Documents](https://github.com/adhorn/chaos-ssm-documents) - Collection of AWS SSM Documents to perform Chaos Engineering experiments. 199 | - [failure-lambda](https://github.com/gunnargrosch/failure-lambda) - failure-lambda is a small Node module for injecting failure into AWS Lambda. 200 | - [chaos_lambda](https://github.com/adhorn/aws-lambda-chaos-injection) - chaos_lambda is a small library injecting chaos into AWS Lambda. 201 | - [AWSSSMChaosRunner](https://github.com/amzn/awsssmchaosrunner) - AWSSSMChaosRunner is a library which simplifies failure injection testing and chaos engineering for EC2 and ECS (with EC2 launch type). 202 | 203 | #### Azure Cloud 204 | 205 | - [Azure Fault Analysis Service](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-testability-overview) 206 | - [Include controlled Chaos in Service Fabric clusters](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-controlled-chaos) - Include controlled Chaos in Service Fabric clusters. 207 | - [chaos-dingo](https://github.com/jmspring/chaos-dingo) - Monkey and Lemur are taken, so Chaos Dingo it is. This is a tool to mess with Azure services using the Azure NodeJS SDK. 208 | 209 | - [Chaos Lambda](https://github.com/bbc/chaos-lambda) - Randomly terminate ASG instances during business hours. 210 | 211 | #### Google Cloud Platform 212 | 213 | - [Chaos Engineering on Google Cloud Platform](https://github.com/cloudchaos/google-cloud-platform) - Chaos Engineering on Google Cloud Platform. 214 | 215 | ### Examples Projects 216 | 217 | - [A Chaos Engineering Bootcamp](https://github.com/tammybutow/chaosengineeringbootcamp) - A Chaos Engineering Bootcamp. 218 | - [HW4](https://github.com/kbalakr/Chaos-Engineering---DevOps-Demo) - Express servers were used to implement service topologies. 219 | - [Serverless Chaos Engineering Demo](https://github.com/gunnargrosch/serverless-chaos-demo) - This example demonstrates how to use Adrian Hornsby's Failure Injection Layer to perform chaos engineering experiments on a serverless environment. 220 | - [Chaos Engineeing Demo](https://github.com/fazdevils/chaos-engineeing-demo) - Simple project demonstrating chaos engineering with Chaos Monkey and Resiliance4J. 221 | - [Chaos Engineering Demo](https://github.com/ericwyles/chaos-engineering-demo) - resilience4j + chaos toolkit + wiremock + chaos monkey for spring boot sample application. 222 | - [How to Create a Kubernetes Cluster on Ubuntu 16.04 with kudeadm and Weave Net](https://www.gremlin.com/community/tutorials/how-to-create-a-kubernetes-cluster-on-ubuntu-16-04-with-kudeadm-and-weave-net/) 223 | 224 | ## 4. Observability 225 | 226 | ### Specific tools 227 | 228 | ### General Use 229 | 230 | - [My Awesome Observability Repo ;-)](https://github.com/adriannovegil/awesome-observability) 231 | 232 | ## 5. Incident Management Tool 233 | 234 | - [Banjaxed](https://github.com/intercom-archive/banjaxed) - Open source incident management tool. 235 | 236 | ## 6. Cost of SEVs 237 | 238 | - [Availability Calculator](https://github.com/dastergon/availability-calculator) - Calculate how much downtime should be permitted in your SLA. 239 | 240 | ## 7. Chaos As A Sevice 241 | 242 | - [Gremlin Inc.](https://www.gremlin.com/) - Failure as a Service. 243 | - [Chaos Engineering Experiment Automation](https://chaostoolkit.org/) - Chaos Engineering Experiment Automation. 244 | - [Pystol.org](https://www.pystol.org/) - The cloud chaos engineering toolbox. 245 | - [Chaos Platform](https://github.com/chaostoolkit/chaosplatform) - Chaos Engineering Platform for Everyone. 246 | - [Chaos Hub](https://github.com/chaostoolkit/chaoshub-archive) - Chaos Hub stands on the shoulders of the Chaos Toolkit to provide a complete, user-friendly, platform to automate and collaborate on your Chaos Engineering and Resiliency efforts. 247 | - [steadybit](https://www.steadybit.com/) - Chaos Engineering platform that helps to proactively reduce downtime and provide visibility into systems to detect issues. 248 | - [Cavisson](https://www.cavisson.com/nethavoc-resilience-testing-solution/) - Chaos engineering platform. 249 | 250 | ## 8. Gamedays 251 | 252 | - [Target: What is a Gameday?](https://tech.target.com/2019/05/09/chaos-engineering-at-Target.html) - Chaos Gamedays experience by Target. 253 | - [Codecentric: Chaos Engineering Gamedays](https://blog.codecentric.de/en/2018/08/chaos-engineering-gameday/) - Chaos Gamedays by Codecentric. 254 | - [New Relic: How to run a Gameday?](https://blog.newrelic.com/engineering/how-to-run-a-game-day/) - Chaos Gamedays experience by New Relic. 255 | - [Dius: Gamedays resources](https://dius.com.au/resources/game-day/) - Resources for getting started with GameDay and Chaos Engineering. 256 | - [Gremlin: Gamedays](https://www.gremlin.com/gameday/) - Resources for getting started with GameDay and Chaos Engineering. 257 | - [Gremlin: Planning your own Chaos Day](https://www.gremlin.com/community/tutorials/planning-your-own-chaos-day/) - Example of a Gameday with DynamoDB by Gremlin. 258 | - [Gremlin: How to run a Gameday?](https://www.gremlin.com/community/tutorials/how-to-run-a-gameday/) - Methodology to run Gamedays according Gremlin. 259 | - [Gremlin DB: Breaking Dynamo DB](https://www.gremlin.com/community/tutorials/gremlin-gameday-breaking-dynamodb/) - Example of a Gameday with DynamoDB by Gremlin. 260 | - [Gremlin: Introduction to Gameday](https://www.gremlin.com/community/tutorials/introduction-to-gamedays/) - What is a Gameday according Gremlin. 261 | - [Gremlin: Inside Gremlin 2019 Gremlin Gamedays Roadmap](https://www.gremlin.com/community/tutorials/inside-gremlin-2019-gremlin-gamedays-roadmap/) - Chaos Gamedays experience by Gremlin. 262 | - [Gremlin: What I lerned running the Chaos Lab with Kafka](https://www.gremlin.com/community/tutorials/what-i-learned-running-the-chaos-lab-kafka-breaks/) - Example of a Gameday with Kafka by Gremlin. 263 | - [Chaos Toolkit: Chaos Engineering with Humans in the loop](https://medium.com/chaos-toolkit/chaos-engineering-with-humans-in-the-loop-f4854900b1eb) - Article about Chaos Gamedays. 264 | - [GooCardless: All fun and games until you start with Gamedays](https://gocardless.com/blog/game-days-at-gc/) - Article about Chaos Gamedays. 265 | - [InfoQ: Gamedays - Achieving Resilience through Chaos Engineering](https://www.infoq.com/presentations/gameday-chaos-engineering) - InfoQ Presentation with experiences about Chaos Gamedays. 266 | 267 | ## 9. Forums and Groups 268 | 269 | 270 | - [CNCF Chaos Engineering Working Group](https://groups.google.com/forum/#!forum/chaoseng-wg) 271 | - CNCF Chaos Engineering Working Group Slack: #chaosengineering (slack.cncf.io) 272 | - [CNCF Chaos Engineering Working Group GitHub](https://github.com/chaoseng/wg-chaoseng) 273 | - [Chaos Toolkit Slack Community](https://join.chaostoolkit.org) 274 | 275 | - [Chaos Community Google Group](https://groups.google.com/forum/#!forum/chaos-community) 276 | - [Chaos Engineering LinkedIn Group](https://www.linkedin.com/groups/7057761) 277 | - [Chaos Engineering Slack Community](https://gremlin.com/community) 278 | 279 | ## 10. References 280 | 281 | - https://kth.diva-portal.org/smash/get/diva2:1707948/SUMMARY01.pdf 282 | - https://github.com/dastergon/awesome-chaos-engineering 283 | - https://github.com/seeker89/chaos-engineering-book 284 | - [What is security chaos engineering and why is it important?](https://hub.packtpub.com/what-is-security-chaos-engineering-and-why-is-it-important/) 285 | - [Security Chaos Engineering: A new paradigm for cybersecurity](https://opensource.com/article/18/1/new-paradigm-cybersecurity) 286 | - [Injecting chaos experiments into security log pipelines](https://opensource.com/article/18/9/injecting-chaos-experiments-security-log-pipelines) 287 | - [Purple testing and chaos engineering in securityexperimentation](https://opensource.com/article/18/6/security-experimentation) 288 | - [A new approach to security instrumentation](https://opensource.com/article/18/4/new-approach-security-instrumentation) 289 | - https://blog.qaware.de/posts/chaos-engineering-the-status-quo/ 290 | - https://blog.qaware.de/posts/chaos-engineering-chaostoolkit/ 291 | - https://github.com/chaoseng/wg-chaoseng/blob/master/WHITEPAPER.md 292 | - https://docs.google.com/document/d/1BeeJZIyReCFNLJQrZjwA4KMlUJelxFFEv3IwED16lHE/edit?ts=5ace0eab#heading=h.ephtflhfpd1d 293 | - https://techbeacon.com/app-dev-testing/chaos-engineering-testing-34-tools-tutorials 294 | - https://www.techrepublic.com/article/chaos-engineering-a-cheat-sheet/ 295 | - https://medium.com/capital-one-tech/4-real-world-scenarios-that-read-like-chaos-engineering-experiments-8dbf40c5f247 296 | - https://thenewstack.io/gremlins-tammy-butow-on-the-business-side-of-chaos-engineering/ 297 | - https://learnk8s.io/blog/kubernetes-chaos-engineering-lessons-learned 298 | - https://gocardless.com/blog/game-days-at-gc/ 299 | - https://engineering.grab.com/chaos-engineering 300 | - https://blog.newrelic.com/engineering/chaos-engineering-explained/ 301 | - https://slack.engineering/disasterpiece-theater-slacks-process-for-approachable-chaos-engineering-3434422afb54 302 | - https://www.usenix.org/system/files/osdi18-veeraraghavan.pdf 303 | - https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf 304 | - https://people.ucsc.edu/~palvaro/fit-ldfi.pdf 305 | - https://landing.google.com/sre/book.html 306 | - http://the-cloud-book.com/ 307 | - https://www.infoq.com/minibooks/emag-chaos-engineering 308 | - https://www.pagerduty.com/blog/failure-fridays-four-years/ 309 | - https://www.slideshare.net/zgrinch/monkeys-lemurs-and-locusts-oh-my 310 | - https://softwareengineeringdaily.com/2018/02/02/chaos-engineering-with-kolton-andrus/ 311 | - https://blog.codeship.com/embracing-the-chaos-of-chaos-engineering/ 312 | - https://sharpend.io/chaos-monkey-for-fun-and-profit/ 313 | - https://queue.acm.org/detail.cfm?id=2353017 314 | - https://dl.acm.org/citation.cfm?id=3177123.3158134 315 | - https://dl.acm.org/citation.cfm?id=2723711 316 | - https://azure.microsoft.com/en-us/blog/inside-azure-search-chaos-engineering/ 317 | - https://devops.com/netflix-the-simian-army-and-the-culture-of-freedom-and-responsibility/ 318 | - http://www.oreilly.com/webops-perf/free/chaos-engineering.csp 319 | - http://www.oreilly.com/webops-perf/free/antifragile-systems-and-teams.csp 320 | - http://shop.oreilly.com/product/0636920251897.do 321 | - https://www.gremlin.com/community/tutorials/chaos-engineering-the-history-principles-and-practice/ 322 | - https://www.gremlin.com/blog/the-discipline-of-chaos-engineering/ 323 | - http://kth.diva-portal.org/smash/get/diva2:1366436/FULLTEXT01.pdf 324 | - https://arxiv.org/pdf/1907.13039.pdf 325 | - https://arxiv.org/abs/1404.3056 326 | - https://arxiv.org/abs/1702.05843 327 | - https://arxiv.org/abs/1702.05849 328 | - https://arxiv.org/abs/1805.05246 329 | - https://arxiv.org/abs/1812.10706 330 | - https://medium.com/@bbideep/why-should-chaos-be-part-of-your-distributed-systems-engineering-5bcb21497660 331 | - https://medium.com/@njones_18523/chaos-engineering-traps-e3486c526059 332 | - https://medium.com/@adhorn/chaos-engineering-ab0cc9fbd12a 333 | - https://medium.com/netflix-techblog/fit-failure-injection-testing-35d8e2a9bb2 334 | - https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116 335 | - https://medium.com/netflix-techblog/automated-failure-testing-86c1b8bc841f 336 | - https://medium.com/netflix-techblog/chaos-engineering-upgraded-878d341f15fa 337 | - https://medium.com/netflix-techblog/chap-chaos-automation-platform-53e6d528371f 338 | - https://medium.com/@crochefolle/how-to-convince-your-boss-to-make-them-say-yes-to-chaos-engineering-796ba119bd7 339 | - https://medium.com/chaosiq/cloud-native-and-chaos-engineering-20842ee2fa8a 340 | - https://www.wired.com/story/netflix-ddos-attack/ 341 | - https://github.com/gremlin/chaos-engineering-tools 342 | - https://github.com/greenlearner01/Chaos-Engineering/blob/master/Chaos-Engineering.md 343 | 344 | ## 11. License 345 | 346 | [![CC0](https://mirrors.creativecommons.org/presskit/buttons/88x31/svg/cc-zero.svg)](https://creativecommons.org/publicdomain/zero/1.0) 347 | 348 | ## 12. Contributing 349 | 350 | Contributions welcome! Read the [contribution guidelines](contributing.md) first. 351 | 352 | Thank you! 353 | --------------------------------------------------------------------------------