The service has two application servers and a clustered database, and on the architecture diagram it looks safe. Then one day a single network device fails and the whole service goes dark. The post-incident review reveals that both application servers were running on the same hypervisor, or that both database instances were attached to the same storage array. Redundancy existed in one layer only.
Discoveries like this are uncomfortable for everyone. The service owner believed they were protected. The operations team may have suspected the weak spot but had no way to prove it. And the people who fought the incident at night are left asking why nobody saw it coming.
Why single points of failure stay hidden
A single point of failure (SPOF) is rarely a design mistake. It is usually the result of gradual drift. Infrastructure changes, virtual machines move, capacity is reallocated. What was separated at go-live can end up on the same hardware months later.
- Redundancy is assessed one layer at a time. The application team sees two servers, the virtualisation team sees spare capacity, and nobody sees the whole chain.
- Diagrams capture intent, not reality. They show how things were meant to be, not where systems have moved since.
- Resilience reviews are one-off exercises. They happen at design time or during an audit, not continuously.
- Maintenance exposes weaknesses too late. If both nodes of a redundant pair are patched at the same time, the service goes down even though it is formally redundant.
A better way to think about resilience
Service resilience is a property of the whole dependency chain, not of individual components. It therefore has to be assessed at the service level, across all layers at once. We recommend:
- Record redundancy explicitly. Which items stand in for each other and form a redundant group.
- Look for SPOFs continuously, not once a year. Every infrastructure change can alter the answer.
- Test resilience with simulation. Ask what happens when a specific component fails.
- Carry redundancy into maintenance. Patch redundant nodes one after another so the service stays up.
How Eywo Stratum handles it
Eywo Stratum works with a layered dependency map, from business services through applications, databases and servers down to hypervisors, storage and network. On that basis it can:
- record redundant groups, meaning items that stand in for one another,
- identify single points of failure, the components whose failure hits a service regardless of redundancy elsewhere in the chain,
- assess service resilience and show where a service is protected and where it is not,
- simulate the failure of a selected component and show the affected services and applications.
Knowledge of redundancy also shapes maintenance. Changes can be carried out item by item in a rolling fashion, so the nodes of a redundant group are never taken down together. In the Business edition, the patch agreement with the service owner supports rolling patching of redundant nodes: one node is updated and verified before the next one follows. The service stays available even during routine maintenance.
The service owner no longer has to trust a diagram. They see the current state, derived from the CMDB, and know what their service actually depends on.
Conclusion
Single points of failure do not appear overnight, and a one-off review will not make them disappear. You can only find them by looking at a service as a whole, across every layer, with a view that stays current. Uncomfortable night-time discoveries then become ordinary items on the work plan, fixed calmly and during business hours.
Redundant groups, single-point-of-failure analysis and outage simulation are part of the Standard edition; rolling patching of redundant nodes as part of patch management comes with the Business edition.
Eywo Stratum Standard
For organisations that want a reliable CMDB and managed ITSM processes.