What you see is someone who is actually willing and able to learn from any mistakes during this outage, no matter how small. That degree of attention to detail is exactly what I would expect from Colin. Novelty accounts created with the express purpose of slinging crap however are the equivalent of heckling in a theater, they don't contribute and in this case seem to be motivated by malice.
I do tech DD for a living and pretty much every company could do better if and when something goes wrong, but rarely do companies extract the maximum of learnings from an outage. That is what should impress you rather than to perceive it as a negative.
Note that most companies don't make any information about outages public and note that if and when they do it is usually heavily manipulated to make them look good. Colin could have easily done the same thing and the fact that he didn't deserves your respect, not your scorn. Consider the fact that even the best make mistakes. I'm aware of a very big name company that lost a ton of customer data through an interesting series of mishaps that all started with a routine test and not a peep on their website or in the media. Tens of thousands of people and hundreds of customers affected. And yet, you probably would trust them with your data precisely because they are not as honest as Tarsnap.
There are multiple comments in the post-mortem about what should - in hindsight - have been done instead and I think it's fair to expect that those things -will- get done reasonably soon.
Pretty much all ops problems come down to the interaction of multiple mistakes that hadn't previously been an issue - GCP and AWS post-mortems tend to show exactly that, although usually with somewhat less detail.
So I'd expect that any equivalent service has a similar number of gremlins hiding in their infrastructure and procedures, and I'd suggest to anybody reading this that a 43 minute old account that was created just to post the comment I'm replying to is perhaps not the most reliable judge of competency or otherwise on the part of M. Percival.
> This post-mortem just lists mistake after mistake, but gives no indication as to what the maintainer will do to prevent this in the future.
Each to their own - I myself wouldn't expect that from a comprehensive "what didn't go smoothly" list such as this.
Clearly Colin is aware of every point listed and no doubt is already mentally dot pointing procedural changes and additional guard rails to ease recovery in future outages and to ensure no data is lost (which appears to be the primary goal here).
