Thank Goodness For Contingency Plans (TGFCP)

Today is the first time since the Crowdstrike outage that any of my windows devices have touched the internet so before going to bed I thought I'd post a follow-up...Hope it is interesting enough for a full read.

It's Always Something . . . . Roseanna Roseannadanna

The ever evolving online security environment can be wearisome. This outage exaggerates the feeling because it seems one of our allies is becoming complacent...which damages their credibility.
The catch phrase of Roseanna Roseannadanna may be as close as humans can get to knowing an absolute truth. Which highlights the importance that the most reasonable assessment of an event like this is whether the cause(s) and our response trend toward utopian or dystopian (altruistic or narcissistic prosocial or antisocial constructive or destructive).
Back in the 1980's & 90's contingencies to prevent and/or mitigate events like this were deeply ingrained in our methodology. If this outage had not been prevented, its impact would have been so minor that the only press it might have received would have been in trade journals. The priorities must have changed and reliability suffered. This decrease in reliability and increase in risk to the people served by these systems is likely caused in large part by the highest paid, most influential members of the responsible organization(s). They make the decisions that create the environmental pressures that lead to pushing the profit margin based efficiency envelope ever farther at the expense of reliability. They do it to justify next year's Raise despite already being paid exponentially more than the folks who have to try to keep the systems working.
Two concepts that came immediately to mind were maintaining two boot-able images which is simpler and more affordable than it first sounds. And a scaled roll-out. Install the update on a trucking company and cargo airline's systems before installing it on passenger service systems. Install it on medical supply systems before installing on systems that directly affect patient services. Technology is not a living entity. It can't decide to cause incidents like this. It is only as good or bad, helpful or harmful as the people managing it make it. Most of the responsibility is at the very top of the management structure and that is where the greatest disconnect exists.
Quite literally somebody who gets paid tens or hundreds of millions of dollars per year got an accountant or actuary to look at the historical data. Then they crunched the numbers to show that mass implementations like this would be more profitable than maintaining more effective quality assurance...at least in the short term...let somebody else make their billions pretending to relearn historical lessons.
Maybe a speed limit analogy would be helpful. It is dangerous, inappropriate and unnecessary to travel at freeway speeds all the time. Delivery vehicles don't do it (or at least shouldn't). This was a delivery that crashed (and a crash made worse) because of excessive and inappropriate speed. Hopefully the response will focus more on making processes more robust and better able to cope with human mistakes (which is a predictable fact of life).
I have read a few follow-up/related articles over the past week, but none of them revealed much about corrective measures other than one in The Times India indicating that Microsoft was considering barring Kernel access to all outside Aps.

BTW AARP
The automated email sent to me with the subject: "Did you get the answer you needed?", IMHO, contributes to the problem. It contains an embedded link, and neither the original post nor the 1 subsequent post were Q&A oriented. Your email amounted clutter that makes the problem more tiresome. It contributes to the mess of incoming emails the scammers use to try to hide themselves.