- \n
- Power Outages<\/span>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n
\n - \n
- Unexpected surge in user traffic<\/span>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
\n \n - \n
- Natural Disasters<\/span>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n
\n - \n
- Cyber-attacks like <\/span>DDoS<\/span><\/i>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
\n \n - \n
- Hardware Complications<\/span>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n
\n - \n
- Exhausted Resource\u00a0<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
(low memory, high CPU, low bandwidth etc)<\/span><\/i>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
We cannot control or avoid failures in distributed systems. However, we can control the impact radius of the failure and optimize the time to recover and restore the systems. This can be achieved only by exercising as many failures as possible in the test lab, thus achieving confidence in the system\u2019s resilience.<\/p>\n
Why Chaos Engineering?<\/h2>\n
Chaos Engineering is the discipline of experimenting with distributed systems to build confidence in the system\u2019s capability to withstand turbulent conditions in production. Chaos Testing is the deliberate injection of faults or failures into your infrastructure in a controlled manner to test the system\u2019s ability to respond during a failure. This is an effective method to practice, prepare, and prevent or minimize downtime and outages before they occur.<\/p>\n
Chaos testing is one of the effective ways<\/a> to validate a system\u2019s resilience by running failure experiments or fault injections.<\/p>\n
What is an Experiment?<\/h2>\n
An experiment is a planned fault injection in a controlled manner. Experiments vary based on the architecture of the systems under test. However, in a distributed system and microservices architecture deployed on the cloud, below are the most common fault injections that must be exercised.<\/p>\n
- \n
- Shutdown<\/strong> the compute engines randomly in an availability zone (or data center)<\/li>\n
- Outage<\/strong> of an entire region or availability zone.<\/li>\n
- Resource<\/strong> exhaustion: High CPU, Low Memory, Heavy Disk Usage<\/li>\n
- Data<\/strong> Service Failure – Partially deleting a stream of records\/messages across multiple instances to recreate a database-dependent issue.<\/li>\n
- Network<\/strong> – Inject latency between services for a select percentage of traffic over a predetermined period.<\/li>\n
- Code insertion<\/strong>: Adding instructions to the target program and allowing fault injection to occur prior to certain instructions.<\/li>\n<\/ul>\n
Principles of Chaos Testing<\/strong><\/p>\n
![\"Principles](\"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/principles-of-chaos-testing-555x80.png\")
<\/p>\n- \n
- Define the system\u2019s normal behavior:<\/strong> The steady state can be defined as some measurable output like overall throughput, error rates, or the latency of a system that indicates normal behavior. The system\u2019s normal behavior is believed to be acceptable behavior and unexpected behavior. The normal state of the system should be considered the steady state.<\/li>\n
- Hypothesize about the steady state:<\/strong> The hypothesis defined here will be believed to be the expected output of the experiment. The hypothesis of the experiments should be in line with the objective of Chaos engineering: \u201cthe events injected into the system will not result in a change from the steady state of the target system.<\/em>\u201d<\/li>\n
- Design and run experiments:<\/strong> Identify all the possible failure scenarios in the infrastructure, design failure experiments and run them in a controlled manner, and ensure there is a backout plan for every failure experiment. If a back-out plan is unknown, identify the path to systems recovery and record<\/a> the procedures during the recovery.<\/li>\n
- Analyse Test Results:<\/strong> Verify if the hypothesis was correct or if there was a change to the system\u2019s expected steady-state behavior. Identity, whether there was any impact on the service continuity user experience<\/a>, and whether the service is resilient to the failures injected.<\/li>\n<\/ol>\n
Test tools comparison<\/strong><\/p>\n
![\"Test](\"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/Test-tools-comparison-530x300.png\")
<\/strong><\/p>\nBest Practises<\/h2>\n
Smaller blast radius:<\/strong> Begin with small experiments to know the unknowns and learn about them. Scale-out the experiments only when we gain confidence. Start with a single compute engine, a container, or a microservice to reduce the potential side effects.<\/p>\n
Test tool selection:<\/strong> Perform<\/strong><\/a> a study of the test tools available<\/strong>. Compare the available features and the time and effort required to build your tools. We recommend not picking tools that perform random experiments as it would become difficult to measure the outcome. Use the test tools that perform thoughtful, planned, controlled, safe, and secure experiments.<\/p>\n
Exercise first in the Lower environment:<\/strong> get confidence in the tests, start with staging or development environment. Once the tests in these environments<\/a> are complete, move up to production.<\/p>\n
Roll Back & Abort planning:<\/strong> ensure effective<\/a> planning is exercised to abort any experiment immediately and revert the system or service back to its normal state. If an experiment causes a severe outage, track it carefully and do an analysis to avoid it happening again. If these plans are void or cannot be run, exercise effective root cause analysis to learn further about the outage.<\/p>\n
Path to achieve maturity of Chaos Testing:<\/strong><\/p>\n
![\"maturity](\"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/Path-to-achieve-maturity-of-Chaos-Testing-555x261.png\")
<\/strong><\/p>\nConclusion<\/h2>\n
No system is safe from failure or outage. Cloud infrastructure platforms cannot be over-trusted. Every major Cloud infra reported at least one outage in each quarter. We cannot control the failures or outages. You can only control the impact on your customers, employees, partners, and reputation by exercising failures as often as possible in the test<\/a> lab, thus identifying the path to your systems’ recovery.<\/p>\n
Enterprises building distributed systems must exercise Chaos engineering as part of their resilience strategy. Running Chaos tests in a continuous manner is one of several things that you can do to improve the resiliency of your applications and infrastructure.<\/p>\n
Cigniti has built a dedicated Performance Testing<\/a> CoE that provides solutions around performance testing & engineering for our global clients. We focus on performing in-depth analysis<\/a> at the component level, dynamic profiling, capacity evaluation, testing, and reporting to help isolate bottlenecks and provide appropriate recommendations.<\/p>\n
Schedule a discussion with our Chaos Engineering<\/a> and Testing experts to learn more about Chaos Engineering and testing tools for cloud deployment.<\/p>\n
Join us for a Fireside Chat on October 12th, 2023, where we’ll be accompanied by Northern Trust and Gremlin to discuss the art of Building Resilient Digital Systems Through Chaos Engineering<\/a>. Embrace orchestrated chaos, foster resilience, and be part of our insightful Chaos Engineering Fireside Chat dialogue<\/a>.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Modern systems are built on a large scale and operated in a distributed manner. With scale comes complexity, and there are so many ways these large-scale distributed systems can fail. Modern systems built on cloud technologies and microservices architecture have a lot of dependencies on the internet, infrastructure, and services that you do not have […]<\/p>\n","protected":false},"author":20,"featured_media":16812,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4043],"tags":[3265,3264,4042,1297,305,498,1481],"ppma_author":[4041],"class_list":["post-16797","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-chaos-engineering","tag-chaos-engineering","tag-chaos-testing","tag-chaos-testing-tools","tag-network-penetration-testing","tag-penetration-testing","tag-security-testing","tag-security-testing-services"],"authors":[{"term_id":4041,"user_id":0,"is_guest":1,"slug":"jitendra-nath-lella","display_name":"Jitendra Nath Lella","avatar_url":{"url":"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/Jitendra-Nath-Lella.jpg","url2x":"https:\/\/www.cigniti.com\/blog\/wp-content\/uploads\/Jitendra-Nath-Lella.jpg"},"user_url":"","last_name":"","first_name":"","job_title":"","description":"Jitendra Nath Lella is a Senior Architect at Cigniti Technologies and is Certified Chaos Engineering practitioner. He is into the practice of Non-Functional testing for over 17 years. He is specialized in building & implementing test strategy\u2019s for organizations that build \/ migrate data centres on to the cloud. Also, his expertise is into simulating heavy user load tests of more than 200K users."}],"_links":{"self":[{"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/posts\/16797"}],"collection":[{"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/comments?post=16797"}],"version-history":[{"count":0,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/posts\/16797\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/media\/16812"}],"wp:attachment":[{"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/media?parent=16797"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/categories?post=16797"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/tags?post=16797"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.cigniti.com\/blog\/wp-json\/wp\/v2\/ppma_author?post=16797"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Hypothesize about the steady state:<\/strong> The hypothesis defined here will be believed to be the expected output of the experiment. The hypothesis of the experiments should be in line with the objective of Chaos engineering: \u201cthe events injected into the system will not result in a change from the steady state of the target system.<\/em>\u201d<\/li>\n
- Outage<\/strong> of an entire region or availability zone.<\/li>\n
- Shutdown<\/strong> the compute engines randomly in an availability zone (or data center)<\/li>\n
- Exhausted Resource\u00a0<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
- Hardware Complications<\/span>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n
- Cyber-attacks like <\/span>DDoS<\/span><\/i>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
- Natural Disasters<\/span>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n
- Unexpected surge in user traffic<\/span>\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n