The Pragmatic Engineer recap 从史上最大 outage 里码农可以学到什么

Root cause：并不是之前网上盛传的 null bytes，是 configuration update 引发了逻辑错误造成 unhandled error

修复过程很慢因为 IT 得手动进入 windows 安全模式并删除肇事文件。随后个人开发者和微软都释出了自动修复工具可以加快修复过程，两天之后 CrowdStrike 表示也在测试新的快速修复手段。

谁该负责？

CrowdStrike，显而易见。但随之而来的问题是：
1. 更新被测试了吗，怎么测试的？
2. 有被员工 dogfood 吗？
3. 有 canary rollout 吗？因为更新本身被认为是“content”而不是“business logic”，它们可能真的 YOLO 了。（这事儿我工作这些年也碰到过不少了，包括 Amazon 的 Sev 0 和特别有名的 Facebook 全系 down 了一整天的 incident）
4. CrowdStrike 是否认为 binary（”content”）files 无法影响 kernel level？
5. 是否忽略过之前类似的 outage？

Microsoft/Windows？在 Mac 上，类似的安全软件只在用户层运行，为什么 windows 允许在 kernel 层？这就引发了第三个罪魁祸首：

政策法规：WSJ 从 Microsoft 得到答复，因为 2009 年微软同意欧盟给安全软件与 Windows 操作系统一样的 access。但这源于 2006 年微软试图使 Windows Vista 更安全。

最后，码农可以从此次事件学到的事：
- 量化所有地方软件 crash 可能造成的影响
- 重新审视代码是如何被部署到 production 的
- Canary/staged rollout
- 把 Configuration 也像代码一样对待（像前面说的一样，光亲眼目睹就看到过两次业界龙头全球范围内的 outage 是这个原因了）
- Dependency/vendors 能未经审核推出什么样的更新？
- Outage 不是一个人的错

#coding #newsletter #tech #Microsoft #导读 #career