# The single points of failure you don't know about · Stilla > A service is redundant on paper. In reality it may hang on a single switch, storage array or hypervisor. URL: https://stilla.eywo.digital/en/blog/single-points-of-failure/ Language: en Last updated: 2026-10-25 [← Back to the blog](https://stilla.eywo.digital/en/blog/) Resilience18 June 2026Updated 25 October 20263 min readEywo team # The single points of failure you don't know about A service is redundant on paper. In reality it may hang on a single switch, storage array or hypervisor. Here is how to find those weak spots before they find you. 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: 1. **Record redundancy explicitly.** Which items stand in for each other and form a redundant group. 2. **Look for SPOFs continuously, not once a year.** Every infrastructure change can alter the answer. 3. **Test resilience with simulation.** Ask what happens when a specific component fails. 4. **Carry redundancy into maintenance.** Patch redundant nodes one after another so the service stays up. ## How Stilla handles it Stilla 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. **Stilla Standard** For organisations that want a reliable CMDB and managed ITSM processes. [Compare editions →](https://stilla.eywo.digital/en/editions/) ## More articles [CMDB·25 October 2026 ### The virtual network in the CMDB: from port group to leaf switch Between a virtual machine and the physical network sits a layer most CMDBs do not see – virtual switches, port groups and host uplinks. Yet this is exactly where it is decided which services a network change will touch. Standard3 min read](https://stilla.eywo.digital/en/blog/virtual-network-in-the-cmdb/)[Governance·25 October 2026 ### NIS2 and DORA: what operations must be able to evidence Both regulations ask the same question – do you know which services an outage hits, who is responsible for them and what changed when? Without a reliable dependency map, the answers are assembled by hand, often under time pressure. Standard3 min read](https://stilla.eywo.digital/en/blog/nis2-dora-evidence/)[Rollout·15 October 2026 ### Rolling out ITSM without a six-month project Introducing a new ITSM tool does not have to mean months of workshops and consultants. Start with one area, bring over the data you already keep in Excel, and check readiness before you go live. Standard3 min read](https://stilla.eywo.digital/en/blog/itsm-without-half-year-project/)