Skip to main content

Resilience - The Modern Uptime Trinity

Terry Critchley

Some years ago, the computer systems' key focus was on performance and many articles, products and efforts were evident in this area. A few years later, the emphasis moved to high availability (HA) of hardware and software and all the other machinations they entail. Today the focus is on (cyber)security.

Read Dr. Terry Critchley's full paper on Resilience

These discrete environments' boundaries have now blurred under the heading of resilience. The main components of resilience are:

1. Normal high availability (HA) design, redundancy etc. plus normal recovery from non-critical outages. This applies to hardware and software. Human factors ("fat finger" syndrome and deliberate malice), are extremely common causes of failure.

2. Cybersecurity breaches of all kinds. No hard system failures here but leaving a compromised system online is dangerous. This area has spawned the phrase cybersecurity resilience.

3. Disaster Recovery (DR), a discipline not in evidence, for example, in May 2017 when Wannacry struck the UK NHS (National Health Service).

You can't choose which of the three bases you cover; it's all or nothing and in the "any-2-from-3" choice, disaster beckons. It would be like trying to build then sit on a two-legged stool.

In boxing, resilience in simple terms means the ability to recover from a punch (normal recovery) or knock down (disaster recovery). However, it has connotations beyond just that, inasmuch as the boxer must prepare himself via tough training, a fight plan and coaching to avoid the knockdown and, should it happen, he should be fit enough to recover and re-join the fray quickly enough to beat the 10 second count; financial penalties in our world.

When is an Outage Not an Outage?

This is a valid question to ask if you understand service level agreements (SLAs). SLAs specify what properties the service should offer aside from a "system availability clause." These requirements usually include response times, hours of service schedule (not the same as availability) at various points in the calendar, for example, high volume activity periods such as major holidays, product promotions, year-end processing and so on.

Many people think of a system outage as complete failure — a knockout using our earlier analogy. In reality, a system not performing as expected and defined in a Service Level Agreement (SLA) will often lead users to consider the system as ‘down' since it is not doing what it is supposed to do and impedes their work.

This leads to the concept of a logical outage(a forced standing count in boxing) where physically everything is in working order but the service provided is not acceptable for some reason. These reasons vary, depending at what stage the applications have reached but they are many.

Resilience Areas

Resilience in bare terms means the ability to recover from a knock down, to use the boxing analogy once more. However, it has connotations beyond just that inasmuch as the boxer must prepare himself by tough training and coaching to avoid the knockdown and, should it happen, he should be fit enough to recover, get to his feet and continue fighting. The information technology (IT) scenario this involves, among other things:

■ "Fitness" through rigorous system design, implementation and monitoring.

■ Normal backup and recovery after outages or data loss.

■ Cybersecurity tools and techniques.

■ Disaster Recovery (DR) when the primary system(s) is totally unable to function for whatever reason and workload must be located and accessed from facilities — system and accommodation (often forgotten) — elsewhere.

■ Spanning the resilience ecosphere are the monitoring, management and analysis methods to turn data into information to support the resilience aims of a company and improve it. If you can't measure it, you can't manage it.

Figure 1 is a simple representation of resilience and the main thing to remember is that it is not a pick and choose exercise; you have to do them all to close the loop between the three contributing areas of resilience planning and recovery activities.


Figure 1: Resilience Components

Security(cybersecurity) is a new threat which the business world has to be aware of and take action on, not following the Mark Twain dictum: "Everybody is talking about the weather, nobody is doing anything about it."

The key factor is covering all the ‘resilience' bases at a level matching the business's needs. It is not a "chose any n from M" menu type of choice; it is all or nothing for optimum resilience.

To stretch a point a little, I think that resilience will be enhanced by recognizing the "trinity" aspect of the factors affecting resilience and should operate as such, even in virtual team mode across the individual teams involved. This needs some thought but a "war room" mentality might be appropriate.

The three areas considered in parallel (P) make for a more resilient system than different teams treating them in isolation as serial or siloed activities (S). Another downside of S is that it requires three sets of change management activities.

Conclusion

Like any major activity, the results of any resilience plan need review and corrective action taken. This requires an environment where parameters relating to resilience are measurable, recorded, reviewed and acted upon; it is not simply a monitoring activity since monitoring is passive, management is active and proactive.

Management = Monitoring + Analysis + Review + Action

This is a big subject which few understand in size or complexity but it has to be tackled.

Resilience is hard. If you think that throwing suitable, trendy products at the resilience design is the answer, you are deluding yourself. As Sir Winston Churchill said, in paraphrase; "All I can offer is blood, sweat and tears."

Hot Topics

The Latest

In MEAN TIME TO INSIGHT Episode 24, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses network observability tool sprawl ... 

In cloud-native systems, scaling is often as simple as moving a slider. For on-premise databases, the stakes are different. Over-provisioning hardware is expensive. Under-provisioning leads to performance bottlenecks that are difficult to fix once the equipment is in the rack ...

When most people think about cybersecurity, they picture firewalls, encryption, and access controls — technical tools designed to protect systems and data. But beneath the technology lies a deeper set of principles about trust, decision-making, and resilience ... The best leaders don't eliminate risk. They manage it intelligently. And in many ways, cybersecurity offers a surprisingly useful playbook for doing exactly that ...

Many organizations assumed their infrastructure strategy was settled. It had been implemented, optimized and built into long-term plans. Recent changes in technology and vendor consolidation are forcing a second look. Cloud outages and licensing changes have exposed how much dependency exists on a small number of platforms. As a result, organizations are reevaluating whether those decisions still hold up under current conditions ...

Edge AI is strategically embedded in core IT and infrastructure spending across industries, according to the 2026 Edge AI Survey from ZEDEDA. The research shows that 83% of C-suite and IT executive respondents say edge AI is important to their core business strategy ...

As AI adoption accelerates, operational complexity — not model intelligence — is becoming the primary barrier to reliable AI at scale, according to the State of AI Engineering 2026 from Datadog ... The report highlights a compounding complexity challenge as AI systems scale ... Around 5% of AI model requests fail in production, with nearly 60% of those failures caused by capacity limits ...

For years, production operations teams have treated alert fatigue as a quality-of-life problem: something that makes on-call rotations miserable but isn't considered a direct contributor to outages. That framing doesn't capture how these systems fail, and we now have data to show why. More importantly, it's now clear alert fatigue is a symptom of a deeper issue: production systems have outgrown the current operational approaches ...

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on." Most enterprise leaders don't expect that to be the experience ...

Ask any senior SRE or platform engineer what keeps them up at night, and the answer probably isn't the monitoring tool — it's the data feeding it. The proliferation of APM, observability, and AIOps platforms has created a telemetry sprawl problem that most teams manage reactively rather than architect proactively. Metrics are going to one platform. Traces routed somewhere else. Logs duplicated across multiple backends because nobody wants to be caught without them when something breaks. Every redundant stream costs money ...

80% of respondents agree that the IT role is shifting from operators to orchestrators, according to the 2026 IT Trends Report: The Human Side of Autonomous IT from SolarWinds ...

Resilience - The Modern Uptime Trinity

Terry Critchley

Some years ago, the computer systems' key focus was on performance and many articles, products and efforts were evident in this area. A few years later, the emphasis moved to high availability (HA) of hardware and software and all the other machinations they entail. Today the focus is on (cyber)security.

Read Dr. Terry Critchley's full paper on Resilience

These discrete environments' boundaries have now blurred under the heading of resilience. The main components of resilience are:

1. Normal high availability (HA) design, redundancy etc. plus normal recovery from non-critical outages. This applies to hardware and software. Human factors ("fat finger" syndrome and deliberate malice), are extremely common causes of failure.

2. Cybersecurity breaches of all kinds. No hard system failures here but leaving a compromised system online is dangerous. This area has spawned the phrase cybersecurity resilience.

3. Disaster Recovery (DR), a discipline not in evidence, for example, in May 2017 when Wannacry struck the UK NHS (National Health Service).

You can't choose which of the three bases you cover; it's all or nothing and in the "any-2-from-3" choice, disaster beckons. It would be like trying to build then sit on a two-legged stool.

In boxing, resilience in simple terms means the ability to recover from a punch (normal recovery) or knock down (disaster recovery). However, it has connotations beyond just that, inasmuch as the boxer must prepare himself via tough training, a fight plan and coaching to avoid the knockdown and, should it happen, he should be fit enough to recover and re-join the fray quickly enough to beat the 10 second count; financial penalties in our world.

When is an Outage Not an Outage?

This is a valid question to ask if you understand service level agreements (SLAs). SLAs specify what properties the service should offer aside from a "system availability clause." These requirements usually include response times, hours of service schedule (not the same as availability) at various points in the calendar, for example, high volume activity periods such as major holidays, product promotions, year-end processing and so on.

Many people think of a system outage as complete failure — a knockout using our earlier analogy. In reality, a system not performing as expected and defined in a Service Level Agreement (SLA) will often lead users to consider the system as ‘down' since it is not doing what it is supposed to do and impedes their work.

This leads to the concept of a logical outage(a forced standing count in boxing) where physically everything is in working order but the service provided is not acceptable for some reason. These reasons vary, depending at what stage the applications have reached but they are many.

Resilience Areas

Resilience in bare terms means the ability to recover from a knock down, to use the boxing analogy once more. However, it has connotations beyond just that inasmuch as the boxer must prepare himself by tough training and coaching to avoid the knockdown and, should it happen, he should be fit enough to recover, get to his feet and continue fighting. The information technology (IT) scenario this involves, among other things:

■ "Fitness" through rigorous system design, implementation and monitoring.

■ Normal backup and recovery after outages or data loss.

■ Cybersecurity tools and techniques.

■ Disaster Recovery (DR) when the primary system(s) is totally unable to function for whatever reason and workload must be located and accessed from facilities — system and accommodation (often forgotten) — elsewhere.

■ Spanning the resilience ecosphere are the monitoring, management and analysis methods to turn data into information to support the resilience aims of a company and improve it. If you can't measure it, you can't manage it.

Figure 1 is a simple representation of resilience and the main thing to remember is that it is not a pick and choose exercise; you have to do them all to close the loop between the three contributing areas of resilience planning and recovery activities.


Figure 1: Resilience Components

Security(cybersecurity) is a new threat which the business world has to be aware of and take action on, not following the Mark Twain dictum: "Everybody is talking about the weather, nobody is doing anything about it."

The key factor is covering all the ‘resilience' bases at a level matching the business's needs. It is not a "chose any n from M" menu type of choice; it is all or nothing for optimum resilience.

To stretch a point a little, I think that resilience will be enhanced by recognizing the "trinity" aspect of the factors affecting resilience and should operate as such, even in virtual team mode across the individual teams involved. This needs some thought but a "war room" mentality might be appropriate.

The three areas considered in parallel (P) make for a more resilient system than different teams treating them in isolation as serial or siloed activities (S). Another downside of S is that it requires three sets of change management activities.

Conclusion

Like any major activity, the results of any resilience plan need review and corrective action taken. This requires an environment where parameters relating to resilience are measurable, recorded, reviewed and acted upon; it is not simply a monitoring activity since monitoring is passive, management is active and proactive.

Management = Monitoring + Analysis + Review + Action

This is a big subject which few understand in size or complexity but it has to be tackled.

Resilience is hard. If you think that throwing suitable, trendy products at the resilience design is the answer, you are deluding yourself. As Sir Winston Churchill said, in paraphrase; "All I can offer is blood, sweat and tears."

Hot Topics

The Latest

In MEAN TIME TO INSIGHT Episode 24, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses network observability tool sprawl ... 

In cloud-native systems, scaling is often as simple as moving a slider. For on-premise databases, the stakes are different. Over-provisioning hardware is expensive. Under-provisioning leads to performance bottlenecks that are difficult to fix once the equipment is in the rack ...

When most people think about cybersecurity, they picture firewalls, encryption, and access controls — technical tools designed to protect systems and data. But beneath the technology lies a deeper set of principles about trust, decision-making, and resilience ... The best leaders don't eliminate risk. They manage it intelligently. And in many ways, cybersecurity offers a surprisingly useful playbook for doing exactly that ...

Many organizations assumed their infrastructure strategy was settled. It had been implemented, optimized and built into long-term plans. Recent changes in technology and vendor consolidation are forcing a second look. Cloud outages and licensing changes have exposed how much dependency exists on a small number of platforms. As a result, organizations are reevaluating whether those decisions still hold up under current conditions ...

Edge AI is strategically embedded in core IT and infrastructure spending across industries, according to the 2026 Edge AI Survey from ZEDEDA. The research shows that 83% of C-suite and IT executive respondents say edge AI is important to their core business strategy ...

As AI adoption accelerates, operational complexity — not model intelligence — is becoming the primary barrier to reliable AI at scale, according to the State of AI Engineering 2026 from Datadog ... The report highlights a compounding complexity challenge as AI systems scale ... Around 5% of AI model requests fail in production, with nearly 60% of those failures caused by capacity limits ...

For years, production operations teams have treated alert fatigue as a quality-of-life problem: something that makes on-call rotations miserable but isn't considered a direct contributor to outages. That framing doesn't capture how these systems fail, and we now have data to show why. More importantly, it's now clear alert fatigue is a symptom of a deeper issue: production systems have outgrown the current operational approaches ...

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on." Most enterprise leaders don't expect that to be the experience ...

Ask any senior SRE or platform engineer what keeps them up at night, and the answer probably isn't the monitoring tool — it's the data feeding it. The proliferation of APM, observability, and AIOps platforms has created a telemetry sprawl problem that most teams manage reactively rather than architect proactively. Metrics are going to one platform. Traces routed somewhere else. Logs duplicated across multiple backends because nobody wants to be caught without them when something breaks. Every redundant stream costs money ...

80% of respondents agree that the IT role is shifting from operators to orchestrators, according to the 2026 IT Trends Report: The Human Side of Autonomous IT from SolarWinds ...