There's exist a class of software that when put to use, generates more failures than successes. In fact failure mode is the default, successes are the anomalies.
A tell tale sign would be connected components/services that are not in your control. If your software talks to third party APIs, it pay to expect them to fail spectacularly.
This sounds like a good place to seek antifragility.
Towards that got me interested in the quality debuggability. To anticipate failures require surfacing them. Doing it right amounts to a crime scene leaving detectives copious amount of clues so clear the murder mystery solves itself.
That means taking extra steps in our code to leave breadcrumbs of what took place, how it happened, why, etc. Commom techniques are logs and stack trace.
The interesting question is how to execute these in a way that cuts debugging time by order of magnitude.
Log is merely the vehicle for raw error data. What goes in there and how we extract them is a matter of design.
This design is highly contextual. And that tells me we'll find principles and heuristics that make debugging-engineering an art form.