12 comments

[ 2.8 ms ] story [ 38.9 ms ] thread
I've been trying to implement and apply these principals at my $job. It's so helpful to have an intro guide published with all the supplemental reading. I'm going to send this around to all my teams.
Is it specific enough to give them direction?
I love small concise mini-syllabi’s like this. Just give me the big papers and set some context.
Readers beware -- this particular taxonomy of robustness vs resilience is not a pervasive or even common one. Often these terms are used completely synonymously. And often they are used with different subtleties that distinguish them.

For example, some distinguish between the two terms in that robustness refers more to staying functional in the face of failures, where resilience refers more to the capability to work around failures (neither having anything to do in particular with whether the unknowns were unknown).

The blog post author says that this taxonomy come straight from David woods, so there's no problem. Just keep in mind that most people don't use these terms in this particular way.

> Readers beware -- this particular taxonomy of robustness vs resilience is not a pervasive or even common one. Often these terms are used completely synonymously. And often they are used with different subtleties that distinguish them.

> For example, some distinguish between the two terms in that robustness refers more to staying functional in the face of failures, where resilience refers more to the capability to work around failures (neither having anything to do in particular with whether the unknowns were unknown).

> The blog post author says that this taxonomy come straight from David woods, so there's no problem. Just keep in mind that most people don't use these terms in this particular way.

Can you go into more detail with specific examples between the two that highlight the differences? "Working around failures" and "staying functional in the face of failures" sound borderline synonymous to me, so I'm curious how that plays out in practice.

> "Working around failures" and "staying functional in the face of failures" sound borderline synonymous to me

One is going around the iceberg, the other is ensuring the Titanic can sail on with a couple of huge holes in it's hull.

If the Titanic does not hit the iceberg, it does not enter a failure mode. That doesn't sound like "working around failures" but "avoiding failure" which seems very different.
The team I work on at AWS wrote a paper on this https://d1.awsstatic.com/whitepapers/architecture/AWS-Reliab... covers concepts such as Recovery Oriented Computing (ROC) etc