The best way to keep people from eating shit on-call is to make technology that is failure-resistant. Most software today is not designed to resist failure, and

The best way to keep people from eating shit on-call is to make technology that is failure-resistant. Most software today is not designed to resist failure, and most operations are not designed to resist failure. But it could get better. For example: a trend in recent years was static site generators. You can still find the internet littered with websites that return only errors due to SQL servers breaking long ago. But those static sites, as long as they don't depend on some other precarious tech, will keep working as long as someone's paying the bills. No security patches needed, no logs filling up disks. The servers could still go down, but it won't be your code's fault, so you shouldn't get a call. The majority of failure risk today comes down to security and mutable state. Both of them are easier when the tech is read-only. For security, you can reduce your attack surface until no reasonable attack would work. For mutable state, you have a couple options. First, all changes to both code and data should be versioned and immutable with a working rollback mechanism. Second, never allow a change without verification, and rollback should happen immediately if verification fails. Third, do not depend on technology whose state can or does mutate regularly. Fourth, do not depend on technology that will stop operating once resource limits are exceeded. And fifth, never build something if you can buy it. (The latter has to do with investment in robustness. If you have to build an entire car, you will never have enough time or money or expertise to design a better brake system/suspension system/muffler/etc as someone who specializes in manufacturing just that one part) Another positive solidarity take would be for everyone to stop taking jobs where 24/7 is a requirement. How do you do this? Before signing a contract, require that they put in language that says you will not be required to work outside of normal business hours. If you're a developer, have it say explicitly that you will only be required to maintain application code and not maintain servers. If they balk, don't take the job. Have a lawyer look it over. This doesn't stop the company from firing you in at-will employment states if you pull out the contract one day, so it's better to just walk if they challenge putting it in writing. Some industries just do not expect their users to be 24/7. And a final note: if you are a developer, please don't just wing your app's design in terms of how it will work in production. Don't let the ops person take care of running it for you, and also don't try to figure it out by yourself. Put your brain together with the brain of somebody who specializes in system architecture and operations - at the start of your project, not the end. Design your app along with this other brain, to work in tandem with a very robust system architecture. And then as you build your app, ask the other brain to review it periodically and give you feedback. In terms of car analogies, this is like asking a mechanic for feedback on the parts you are designing. They've seen what fails when and why, what's painful to maintain and what isn't, what's expensive and what's not. I promise you this will result in fewer calls.