"When we had our last discussion, when we talked about failure, we had several topics that we could have gone deeper on and it was suggested that we actually go and do that. So here we are. And one of the things that came to mind based on our previous conversation when we last talked about failure is how do we get the failures that occur and the information about those failures that occur back into the architecture?"
"But like anything the proximate cause is not necessarily the real cause because there are many things happening. The classic example, of course, is the airline pilot flips the wrong switch and bad things happen to the airplane. That's not necessarily the fault of the pilot because he may have gotten the wrong information from the dashboard. The switches may have been poorly designed."
More than three decades of experience building distributed systems and high-performing teams include roles at Oracle, Tumbleweed Communications, eBay, Google, Stitch Fix, and Thrive Market. Failures and postmortems must feed back into architecture to prevent recurrence. SRE postmortems often identify proximate causes, but proximate causes can mask deeper design, interface, information, and assumption failures. Poor dashboard information, confusing controls, or unrealistic operational assumptions can turn operator actions into system failures. Effective architectural learning requires tracing incidents beyond immediate errors to underlying systemic issues such as UI design, component interactions, and assumption validation.
Read at InfoQ
Unable to calculate read time
Collection
[
|
...
]