这是一个创建于 90 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 。
很好奇你觉得哪点最不可思议或者最严重呢？😯
21 条回复 • 2024-08-12 22:07:54 +08:00
 |
1
k9982874 90 天前 via Android  12
但凡自己公司内装上用一下，也不会出这么大问题
|
 |
4
littlejackyxu 89 天前
所以也不自测一下？
|
 |
5
talk3745 89 天前
估计内部都 agile 了，integration test 和 system test 都被砍了
|
 |
6
shijingshijing 89 天前
@talk3745 其实是测试全部外包到印度，主管技术开发的两大负责人 Head of Product 和 Head of Engineering 都是三哥，外包的测试主要精力都放在怎么造测试报告，整各种 paperwork 来符合流程，出问题就是很自然的事情。
|
 |
7
qiyilai 89 天前
本质上还是人口减少相应的聪明人也少了，蠢人去干聪明人岗位就 gg
|
 |
8
timeisweapon 89 天前
不懂这个行业，uat 、fat 、灰度这些环节一个都没有么
|
 |
9
supuwoerc 89 天前
@shijingshijing 哈哈哈，想起来个梗：三哥为了让单元测试通过就改单元测试的 expect
|
 |
10
fengpan567 89 天前
都没有灰度测试的吗
|
 |
11
LieEar 89 天前
别说灰度测试这种高级东西了，最基本的公司内部找几台 win 系统 PC 测试安装都没有。
草台班子 |
 |
12
ZZ74 89 天前
站在一个程序员的角度看，说到底还是程序员自己没有用心写代码。自己写的代码该怎么样会怎么样应该心里很清楚。
|
 |
13
Leviathann 89 天前
npe ？
|
 |
14
lichdkimba 89 天前
所以补救措施是啥？ 10 美元咖啡券？
|
 |
15
cyp0633 89 天前
@lichdkimba 是 mitigation ，指的不是赔偿
|
 |
16
slack 89 天前
很多开源项目也是这样，运行也不运行一下就发布正式版本，结果发布了一个根本不能正常使用的版本，然后又匆匆发布追加更新。
|
 |
17
proxytoworld 89 天前
@slack 开源的没收钱，crowdstrike 是付费的，不一样
|
 |
18
cybort 89 天前 via Android
@proxytoworld 钱也不是直接打给干活的人的，说不定还不如兴趣项目上心。
|
|
19
proxytoworld 89 天前
@cybort 你真的工作过吗
|
 |
20
wangofjian 89 天前
HN 上讨论了软件工程的责任问题蛮有意思的 https://news.ycombinator.com/item?id=41217037
没人保证写的程序没有 bug ，但是如何判断这个 bug 是主观故意还是客观现象，也没有机制能保证执行了 XXX 就一定没问题。不过 CrowdStrike 这个错误太离谱了，完全草台班子 |
Select Language