上周，CrowdStrike的错误更新导致全球范围内的Windows系统出现大规模蓝屏事件，造成巨大经济损失。
据估计，仅美国财富500强企业就面临54亿美元的损失，全球损失可能高达150亿美元。受此影响，CrowdStrike股价暴跌超过20%。
除了对CrowdStrike的质疑和谴责，开发者圈内还兴起了另一个话题：
”如果CrowdStrike改用Rust的话，全球850万PC是不是就不会蓝屏了？“
这次事件的起因竟是一个简单的null deref错误。尽管C++语言已经发展了数十年，拥有各种工具、linter、sanitizer、测试和同行评审机制，但仍然无法阻止此类错误的发生。
因此不少开发者认为，如果采用内存安全机制更完善的Rust语言，或许能够避免类似事件的发生。
然而，一位同样喜欢Rust的资深软件工程师Julio Merino，在理智地进行了一番全盘分析后得出结论：“就算是Rust，也救不了这次CrowdStrike的中断事故。”
我们来看看他怎么说。
首先，CrowdStrike官方将此次事件归咎于一次配置更新引发的逻辑错误，该错误导致部分系统崩溃。
具体来说，Falcon平台在解析配置文件时，由于代码逻辑缺陷，尝试访问了无效的内存地址，最终引发系统崩溃。
诚然，Rust的内存安全机制可以有效避免此类内存访问错误。然而，将此次事件仅仅归咎于内存安全问题，无异于“只见树木，不见森林”。
首先，内核崩溃的原因多种多样，内存错误只是其中之一。
死锁、系统调用处理程序错误、无限递归等等，都可能导致内核崩溃。Rust虽然可以最大程度减少内存错误和其他逻辑错误，但并不能完全杜绝所有潜在问题。
其次，即使Falcon不运行在内核空间，系统崩溃的风险依然存在。
Falcon作为终端安全系统，需要具备防篡改能力，以防止恶意软件和用户的恶意操作。如果将Falcon迁移至用户空间，并通过受控API与内核通信，则需要确保这些API同样具备防篡改能力。
否则，恶意软件或用户可以通过攻击这些API，间接地影响系统稳定性。
因此，仅仅依靠Rust的内存安全机制，并不能完全避免类似事件的发生。
更重要的是，此次事件的根本原因在于CrowdStrike的配置变更发布流程存在严重缺陷。
根据SRE原则，配置变更应该分阶段、渐进式地进行，并在每个阶段进行充分验证。
然而，CrowdStrike显然没有遵循这一原则，导致一个本应在测试阶段就被发现的错误配置被推送至全球用户，最终引发了大规模系统崩溃。
CrowdStrike最新发布的初步审查报告也证实了这一点，报告指出“测试和流程不完善”是导致此次事件的主要原因。
报告详细描述了从2月28日到7月19日期间，CrowdStrike多次发布更新，并在测试环节存在严重疏漏，最终导致了7月19日的全球宕机事件。
综上，CrowdStrike全球宕机事件的根本原因在于其部署流程的缺陷，而非简单的代码或技术问题。
-------
将Rust奉为解决此类问题的唯一答案，不仅无助于问题的解决，反而会加剧技术社区之间的分歧，不利于Rust的推广和普及。
我们应该认识到，任何技术都有其局限性，Rust也不是万能的。
与其盲目追捧，不如理性看待，将Rust作为提升软件安全性和可靠性的工具之一，并结合完善的流程和最佳实践，共同构建更加健壮的软件系统。
