Operational resilience: simulating the outage before it happens
Operational resilience simulation runs infrastructure failures — an availability-zone outage, a database failover, a cooling failure, a traffic surge — against a live model of your environment to see what degrades, what cascades, how many people and customers are affected, and what it costs per hour. It uses the same twin and the same financial model as cyber-attack simulation, so an outage and a breach are priced on one scale and compete fairly for the same budget.
Security teams and infrastructure teams are usually measured on different things, buy different tools and present to the board in different meetings. Yet the thing they are both protecting is identical: the services the business runs on, and the revenue those services carry. A ransomware incident and a failed storage array both end in the same place — an outage with a cost per hour.
Resilience simulation starts from that shared endpoint. Instead of modeling the attacker, it models the failure, and asks the same questions: what else goes down, how fast do we recover, and what does it cost while we do.
Failure propagates along dependencies
A single host failing rarely matters. What matters is what depended on it. A model that knows the dependency graph — this service reads from that database, which replicates to that replica, which lives on those nodes, in that zone — can propagate a failure realistically: with delays, with redundancy absorbing some of the shock, with degradation before outright failure.
That is where single points of failure come from. Not from a checklist, but from running the failure and noticing which assets, when they fall, take a disproportionate share of the estate with them.
Scenarios worth running
The useful library is small and concrete. Each scenario is a story your operations team already worries about:
- Availability-zone outage — a cloud zone goes dark; do services re-route, and what browns out while they do?
- Database failover drill — the primary fails; how long until the replica is promoted and connection pools recover?
- Traffic surge — five times normal load at the edge; where does saturation appear first and does autoscaling keep up?
- Cooling or power failure on-prem — hosts thermal-throttle; which tier-1 workloads degrade and in what order?
- Vendor or SaaS outage — a third party you depend on disappears for a day.
Pricing the outage
Every service in the model carries its monthly revenue, its operating cost and its customers. Propagate a failure and the twin can total what is impaired: revenue at risk per hour of outage, committed cost still being paid, customers affected, employees who cannot work. Add response and recovery labor, SLA penalties and vendor credits and you have an incident cost — the same figure cyber simulation produces, built the same way.
That shared unit is the point. When an infrastructure lead asks for a second storage array and a security lead asks for network segmentation, the board can finally compare the two: this much value-at-risk removed, for this much spend.
After the run
A simulation should leave you with a short list, not a long log. Which single points of failure it exposed. Where redundancy was assumed and turned out not to exist. A resilience grade you can compare with last quarter's. And an explicit recommendation per weakness, so the run turns into work rather than a slide.
How Onek.ai simulates resilience
Onek.ai runs operational and cyber scenarios through the same engine against the same twin, so the after-action report and the dollar figure come out in one format whatever went wrong.
Available today
- A scenario library spanning operational failures (AZ outage, database failover, traffic surge, cooling failure) and cyber attacks, run from the Digital Twin with live propagation along dependencies.
- Live blast radius during a run: impaired assets, affected users by department, service accounts touched, and value-at-risk per hour updating as the failure spreads.
- After-action analysis with single points of failure, weaknesses, a resilience grade and a recommendation per finding.
- A probabilistic lab that runs ensembles of up to four scenarios at once and reports P50 / P90 loss, recovery and containment distributions.
- A technology-adoption simulator for the opposite question: what does introducing a new system do to resilience, cost and risk?
On the roadmap
- Scheduled, continuous resilience runs with trend reporting on the resilience grade.
Frequently asked questions
- How is this different from a disaster-recovery test?
- A DR test exercises your recovery procedure on real systems, usually once or twice a year and usually for one scenario. Resilience simulation runs many failures against a model as often as you like, before you commit to a DR plan, and tells you what the test is likely to find. It complements the real test; it does not replace it.
- Why price an outage in the same dollars as a breach?
- Because the business pays for both from the same budget and suffers both as lost revenue, idle staff and unhappy customers. One scale lets the board compare a security investment with an infrastructure investment honestly, instead of each team arguing from its own metrics.
- What is a single point of failure?
- An asset whose failure takes down a disproportionate share of what depends on it, because there is no redundant path around it. Simulation finds them by running failures and measuring the blast radius of each, rather than by relying on an architecture diagram that may be out of date.
Related platform capabilities
Learn the concepts