Steve Loughran:"If you read the thread, a lot of people are upset. What's going
on? they demand; fix it! they say. I sympathise with their point of
view, but I don't agree with it. AWS can't say what's going on, not
until they know. They can't fix it until after that. I've been on
the receiving end of these 'fix it now' crises, and having lots of
people on the phone doesn't help you find the problem any faster.
So well done to the AWS team to (a) fixing it fairly quickly and
(b) having so many users that the outage got such publicity!"
Lister's law: "people under time pressure don't think faster". I agree with Steve. And within Steve's point is a general anti-pattern of trying to go faster and introduce more stress when you're in the weeds. But that's SOP. The most important thing seems to be to design a system that can be fixed in place when bad things happen. That means a lot of things that aren't normally considered part of software "design" - build management, release management, issue tracking, testing, configuration, deployment, rollbacks, logistics, cross-departmental processes, SLAs, findable documents and stacktraces. I really hope Steve writes a continuous deployment book.
Previous Topic
