CrowdStrike 发布了完整的事件分析以及公司采取的补救措施

Crowdstrike 发布了 12 页 PDF 的事件分析以及补救措施 Crowdstrike Incident Root Cause Analysis

事件原因其实很简单，在新部署的 CrowdStrike Falcon 传感器中，Content Interpreter 在实际只提供了 20 个值的情况下，试图访问一个不存在的第 21 个输入值，导致系统崩溃。

感觉分析里面的 6 个"FINDINGS AND MITIGATIONS"比较有意思。

FINDINGS AND MITIGATIONS

1. The number of fields in the IPC Template Type was not validated at sensor compile time

“Validate at compile time” 我的理解就是 unit tests 。这是所有测试的第一步，如果一个接口需要 21 个值，那么就应该有一个 unit test 如果提供了不是 21 个值的输入，要报错。这样每次编译的时候如果有这个 bug 就会直接编译失败。感觉程序员都不太喜欢写 unit tests （包括我自己），我有时候会很气愤，有人会单纯为了 coverage 写一些完全没有用的 unit tests ，而不是去检查是不是真的有逻辑错误。

2. A runtime array bounds check was missing for Content Interpreter input fields on Channel File 291

刷 leetcode 面试题大概都知道要考虑 corner case ，而访问没有 allocate 的内存区域是大忌，array bounds check 算一个很常见的要考虑的东西。

3. Template Type testing should cover a wider variety of matching criteria

文章说之前的测试都是用的正则表达式，所以没有发现 bug 。而解决方法提出来的是提高测试 coverage 。😂如果让我猜，用正则表达应该就是为了偷懒，虽然后文还有提到用正则表达是因为第 21 个数值可能性有很多种，但至少还是应该要有一个完整的输入做为测试例子。提高测试 coverage 应该指要真正 cover 更多实际运用中的 corner cases 。

4. The Content Validator contained a logic error

简单来说就是 Validator 本身逻辑有问题，有 bug 。

5. Template Instance validation should expand to include testing within the Content Interpreter

文章说 Validator 没有发现 input 数值不一样会导致系统崩溃，但没有提供细节为啥没有发现。我猜测是不管 Integration Test 还是 Canary 都没有做到 end to end 。整个测试并没有完全模仿客户的整个操作流程。

6. Template Instances should have staged deployment

这个是我太惊讶的地方了，整个 rollout 是全球一次性的。正常来说我们 release 新版本的时候都应该一个阶段一个阶段来发布。如果只有一个 Stage ，一旦有重大 bug ， Blast Radius 太大了。

感觉 CrowdStrike 本身也很难做，毕竟他的服务是防止系统被攻击，如果有新病毒或者新漏洞，客户肯定希望 CrowdStrike 能尽快发布新的补丁保护系统。

速度与风险的权衡，至少我认为 2-3 个阶段是必须的，不然风险太大。

CrowdStrike 针对这点提了一个有点新颖的观点，把 Staged Deployment 的责任交给客户，如果客户有一组机器用他们的服务，让客户决定什么时候，以多快的速度进行 deployment 。

很好奇你觉得哪点最不可思议或者最严重呢？😯