In part 4-4, I continued the description of the initial set of configuration changes that should be made before starting performance testing. I described the following key activities that are input into the initial set of configuration changes:

1. Use the “funnel” configuration
2. Ensure the configuration is coherent
3. Document all clients

In this post, I will describe key resiliency related inputs into the initial set of configuration changes. I personally think resiliency is different from performance. However, many IT professionals do not distinguish between two. Having said that, since we are talking about the initial set of configuration changes, I believe it is important to talk about resiliency related changes that can be included in the initial set of configuration. Perhaps, I will write a dedicated series of blog posts on the resiliency engineering subject later.

If you ask yourself any of the following questions:

1. What happens if I have a slowdown, a failure, or any abnormal event to a particular resource of my solution?
2. What is the expected service level agreement (SLA) of my solution under this failure scenario?
3. What is the expected behavior of my solution?

Then, the answer would be another question: What changes do I need to make to my solution configuration so that my solution provides the expected SLA?

For each failure, an abnormal event, or a slowdown in any resource, it is important to consider the following:

1. The likelihood of that happening
2. How would I simulate that failure, abnormal event or a slowdown during performance/resiliency testing?
3. What will happen to all the resources in my solution?
4. What is the cost and benefit of addressing such a failure, slowdown or an abnormal event?
5. How do I configure the various resources of my solution as a result of a failure, slowdown, or an abnormal event?

Evidently, to answer these questions, it is really important to understand the solution in a great depth. More importantly, it is often impossible to nail down the full set of configuration changes that must be made without running performance and resiliency tests.

In the next blog post, I will describe resiliency related guidance that should be followed when making the initial set of configuration changes.