CrowdStrike事故席卷全球，每位CIO应当从中吸取的六条教训

无论是出于吃瓜还是甩锅的心态，CrowdStrike宕机事故的余波都已经基本散去。然而，从中吸取教训、把握最重要的IT影响才是意义所在。

2000年初，相较于IT世界针对千年虫问题做出前所未有的高效响应，事后评估工作却可以说是一塌糊涂。全球各地的意见领袖似乎急于找人背锅，甚至宣称千年虫问题就是IT部门为了扩大技术预算、强调自身重要性而制造的一场骗局。

找到了宣泄对象的人们都很开心，无知且盲目的热情被鼓动起来，之后就是时间推移、事件平息，再转向下一个所谓的“罪魁祸首”。

这一次的CrowdStrike也成了类似的众矢之的。无论是确实负有责任的CrowdStrike本身，还是作为实际爆发事故场景的Windows缔造者微软，世界各地的意见领袖们再次投入大量时间、精力跟专业知识（存疑），选择对相关当事方破口大骂，而不是以系统化的视角深入分析整个来龙去脉。

但首先需要承认：无论这次事故看起来波及范围多广、后果多严重，西南航空都丝毫没有受到CrowdStrike漏洞的影响——因为他们的服务器运行的是Windows 3.1。于是问题来了：对于一个需要支持成千上万最终用户的业务网络，到底是哪个选项更有可能造成系统故障——包含bug的CrowdStrike Falcon更新，还是Windows 3.1本身？大家当然可以给出自己的答案。实际上西南航空的行为类似于在发动机中使用胶带加锡纸，倒也不是不行，但风险也随时可能来临。

遗憾的是，有时候说服那些患有偏执症的企业高管们就是这么困难——在很多人看来，IT部门申请的生命周期管理资金就类似于当初的千年虫bug修复，完全就是在骗吃骗喝。

我的个人观点也很明确：在AI驱动网络攻击的新时代，最糟糕的决策就是把容忍过时当成一项策略。

相反，任何指望按老办法行事的决策者，都应该牢牢记住此番CrowdStrike的遭遇。

教训一：CrowdStrike宕机事故不仅仅源自技术缺陷

没错，微软确实向CrowdStrike授予了内核访问权限，而苹果和大多数Linux变体不会这么做，因此导致问题的直接因素似乎就是CrowdStrike Falcon糟糕的版本更新。但这并不代表微软的懒惰和草率，而是因为欧盟监管机构坚持要求软件巨头这么做。

欧盟监管机构这样坚持，也不代表他们就是一群高高在上的笨蛋。他们的目标是确保欧洲操作系统市场能够保持公平竞争。这是一场没有真正坏人的角力，而角力也不一定就有赢家。正因为如此，我们才生活在地上、而非完美无瑕的天国。

教训二：非要找个人骂？那就骂“红皇后”吧

CrowdStrike是一家从事网络安全业务的公司。跟大多数网络安全提供商一样，他们发现自己陷入到了“红皇后困境”当中。就如同爱丽丝梦游仙境中的这位经典反派，他们必须全力以赴才能保证自己仍然存续、不被替代。

没错，这些厂商都面临着无情的竞争压力，需要加快发布更新、更复杂的应对措施来解决好更新、更复杂的安全威胁。

这也是系统性问题的另一种典型表现。像CrowdStrike这样的网络安全提供商必须以超越审慎态度的节奏快速部署内容更新、补丁和版本，而“更快”往往意味着“测试不充分”。

于是这些提供商都陷入了红皇后困境，他们要么根据恶意攻击者的行动节奏迅速交付新的防御方案，哪怕冒着补丁或者内容更新中存在缺陷的风险；要么放弃保护客户免受新型恶意软件的侵害，导致受众处于危险当中。

很明显，新型恶意软件迭代的速度越快，网络安全提供商就越可能无法察觉自己内容更新、补丁和版本中的代码缺陷。

身为CIO，我们自己也无法免受红皇后困境的影响。IT部门一直承受着快速交付的压力，也没有人会支持什么放慢速度以降低风险这套“狗屁理论”。

这就叫进退两难，好在我们还有DevOps。

教训三：我们需要仔细、认真地研究一下DevOps

DevOps不只是要消灭用户验收测试，更主张将持续集成/持续交付（CI/CD）设定为“最佳实践”。然而，还是有太多所谓的DevOps支持者在用部署代替交付——二者的区别在于，交付意味着创建可发布的版本并进一步保证其质量，而部署仅仅是将其落地至生产环境。

教训四：边界正愈发模糊

曾几何时，软件当中同样存在漏洞。曾几何时，世界上同样存在恶意软件。但现如今，漏洞和恶意软件危害之间的唯一区别，就在于作者的意图——其造成的后果已经几无差异。

教训五：万全准备方为正途

那些在CrowdStrike bug面前能够维持住弹性和可恢复性的企业之所以做得到这点，是因为他们已经为勒索软件攻击及其他恢复情况做好了准备。至于准备是否万全，很大程度上是由一家企业的CIO所决定。

教训六：用数据说话，以权衡为本

这一切也让我们再次回归每位CIO都必须面临的核心挑战——确保公司当中的高管团队接受IT行业这种“一切出于权衡、万事皆须妥协”的本质。CrowdStrike事故就是个很好的研究案例，我们可以用它来强调IT权衡的重要意义。而前面提到的在速度跟风险之间做出选择的红皇后困境，往往会成为开启对话的良好起点。

当然，大家也可以借助数据分析之力，为IT部门需要应对的关键权衡设置正确的管控指标。