CrowdStrike的宕机事件大部分余波已消，但我们仍未充分认识到一些最为重要的IT影响。
回顾2000年初，在IT部门前所未有地成功应对Y2K问题之后，全球对事后总结进行了失败的处理。受困于寻找责任人的需求，来自世界各地的意见领袖们声称这是IT部门为膨胀技术预算和提高其重要性而制造的骗局。
世界对此欣然接受了这个替罪羊的说法，然后不明就里地嘲笑一番，接着转向下一个伪罪魁祸首。
现在轮到了CrowdStrike。各地的意见领袖们受困于寻找责任人的需求，而微软恰巧成了一个毫无防备的目标，坐在一个可疑的补丁堆上，全球的“专家”们不遗余力地开始甩锅，而不是构建对形势的系统性理解。
但在我们开始讨论之前：无论这个故事多么吸引人，西南航空似乎并未因CrowdStrike的漏洞而幸免，因为它的服务器运行在Windows 3.1系统上。再来一个简单的合理性测试：我们在讨论一个需要支持数万终端用户的网络。在这样一个必须扩展到如此规模的Windows 3.1网络中，系统故障的更可能原因是什么——是一个糟糕的CrowdStrike补丁，还是Windows 3.1本身？这有点像让西南航空用胶带和铝箔来支撑其发动机技术。也许你可以做到，但这同样容易导致坠机。
令人遗憾的是，不合理的推测并不能说服那些受确认偏误影响的商业高管，他们认为IT部门的生命周期管理资金请求就像Y2K漏洞修复工作一样是不必要的。
这只是我的意见：在一个充斥着AI驱动网络攻击的时代，最后一件你应该做的事就是将过时作为一种策略。
相反，你最好注意从CrowdStrike事件中学到的教训。
见解#1：CrowdStrike宕机不仅仅是一个技术缺陷
没错，微软允许访问其内核，而苹果和大多数Linux变体没有，这导致了问题补丁的出现，这并非是因为微软懒惰或决策草率，微软这么做是因为欧盟监管机构的要求。
欧盟监管机构并非愚蠢才做出这种要求，他们的目标是确保欧洲操作系统市场的公平竞争，这是一种权衡，结果却没有如愿，但正如所有的权衡一样，它们并不总是能带来好结果，这就是为什么它们被称为“权衡”而不是“十全十美”。
见解#2：想找人责备？责备红皇后吧
CrowdStrike从事的是网络安全业务。许多网络安全提供商，甚至可能是大多数，认识到他们被困在“红皇后策略”中。就像爱丽丝梦游仙境中的红皇后一样，他们必须拼命奔跑才能保持原地不动。
他们，即网络安全供应商，正面临着不断推出更复杂的应对措施以应对日益复杂的威胁的巨大压力。
这也是系统性问题的另一种表现形式。像CrowdStrike这样的网络安全供应商必须比审慎行事所需的时间更快地部署补丁和更新，而“更快”往往意味着“测试不足”。
供应商被困在红皇后效应中。他们可以选择按照不法分子的恶意软件发布节奏防御新威胁，冒着发布有缺陷补丁的风险，或者选择不防御新恶意软件，从而让他们的客户暴露在风险中。
新恶意软件发布的速度越快，网络安全供应商在补丁和更新中出现缺陷的可能性就越大。
作为CIO，你也无法免受红皇后效应的影响。IT部门一直承受着快速交付的压力，没有人愿意听到放慢节奏以降低风险是必要的。
这就是进退两难的局面。接下来，我们来谈谈DevOps。
见解#3：我们需要仔细审视DevOps
DevOps不仅仅是用户验收测试逐渐消亡的地方，它原本应该是“持续集成/持续交付（CI/CD）”的“最佳实践”所在，但太多的采用者将“交付”与“部署”混为一谈，而实际上，交付意味着创建可发布的版本以进行进一步的质量保证，而不是立即将其部署到生产环境中。
见解#4：界限已模糊
曾几何时，软件中存在漏洞，与此同时，也存在恶意软件，现在，漏洞与破坏性恶意软件之间的唯一区别就是作者的意图。
见解#5：准备就是一切
那些在CrowdStrike漏洞面前具有韧性和可恢复性的企业，之所以能够如此，是因为他们已经为勒索软件攻击和其他恢复情况做好了准备。
见解#6：向高层领导推广IT的权衡观念将带来回报
所有这些都将我们带回CIO必须克服的一个挑战，如果他们希望保留哪怕一丝理智：确保公司的高层领导团队理解IT工作中充满权衡的本质。CrowdStrike的混乱事件为你提供了一个案例研究，你可以用它来突出关键的IT权衡问题。红皇后困境——即速度与风险之间的选择——是一个很好的切入点。
然后，你可以寻求高层领导团队的帮助，为你自己的IT部门必须应对的一些关键权衡设定正确的平衡点。
