I think if this is kind of missing the point. I don't believe these things are fundamentally incompatible but I do believe there is a big element that's missing

I think if this is kind of missing the point. I don't believe these things are fundamentally incompatible but I do believe there is a big element that's missing from this when we talk about reliability. This is simply looking at a bit of code that is doing things that potentially could have unknown outcomes because the way it has to hook in to do its job. Fair enough there is always risks in doing things like that and anyone can make mistakes that have led to catastrophic failures. The real problem isn't that a mistake was made or a series of mistakes were made that allowed this code to be released. The real problem is that when it was released it apparently functioned more like a virus or a worm infecting and crashing everything along its way. So it appears crowdstrike is nothing but a massive botnet. This is where the problem lies because vast numbers of systems went down and remained down for a long periods of time. So apparently the best practice that people were taught was to not try and isolate the scope of any rollout or deployment of something new. Put it on everywhere all at once and YOLO seems to be the fundamental guiding policy from crowdstrike that was blindly followed by their customers. Having been in IT long enough anyone knows this is an idiotic practice. This is the kind of mistakes only a junior admin would make. So either we have a junior admins running vast amounts of core IT infrastructure around the globe or we have idiots defining policies without technical guidance and understanding how things really work. Auto updates let's check that box off our policy without thinking how do we do this in a safe way to mitigate issues. Simply staging something like this so it's deployed in line with a company's redundancy model means that you can have a security and reliability. Because you don't need to look at the reliability of an individual system those will always have problems even if it comes down to simple capacitors burning out. It's about reliability of your service as the whole and this is where the failure really was. I blame the IT administrators as much as I do crowdstrike. For allowing these kind of policies to be put in place for allowing this kind of thing to happen. If this was rolled out in a manner consistent with their redundancy strategy they would have seen that they lost some redundant systems and known to halt what's going on. Before you say but blah blah blah zero day we have to account for that. If crowd strike is your only way to account for a zero day you have lost already. Security is a multi-layered approach such that a zero day shouldn't cause this kind of panic because you have multiple layers protecting you against a zero day. And you can still deploy an update in line with your redundancy model.