全球Windows蓝屏：甲乙双方都是草台班子
表：受到影响的行业领域、国家地区与相关机构
（来源：CrowdStrike导致大规模系统崩溃事件的技术分析[1]）
在我看来，这场事故是甲乙方两侧的共同责任 —— 乙方的问题在于：崩溃率如此之高的变更，为什么在没有灰度的情况下迅速发布到了全球？有没有做过灰度测试与验证？甲方的问题在于：盲目将自己的终端安全完全寄托在供应链的可靠性之上 —— 为什么能允许这样的变更联网实时推送到自己的电脑上而不加以控制？
控制爆炸半径是软件发布中的一条基本原则，而灰度发布则是软件发布中的基本操作。互联网行业中的许多应用会采用精细的灰度发布策略，比如从 1% 的流量开始滚动上量，一旦发现问题也能立刻回滚，避免一勺烩大翻车的出现。
数据库与操作系统变更同理，作为一个管理过大规模生产环境数据库集群的 DBA，我们在对数据库或者底层操作系统进行变更时，都会极为小心地采取灰度策略：首先在 Devbox 开发环境中测试变更，然后应用到预发/UAT/Staging环境中。跑几天没事后，开始针对生产环境发布：从一两套边缘业务开始，然后按照业务重要性划分的 A、B、C 三级，以及从库/主库的顺序与批次进行灰度变更。
某头部券商运维主管也在群里分享了金融行业的最佳实践 —— 直接网络隔离，禁止从互联网更新，买微软 ELA，在内网搭建补丁服务器，然后几万台终端/服务器从补丁服务器统一更新补丁和病毒库。灰度的方式是每个网点和分支机构/每个业务部门都选择一到两台组成灰度环境，跑一两天没事，进入大灰度环境跑满一周，最后的生产环境分成三波每天更新一次，完成整个发布。如果遇到紧急安全事件 —— 也会使用同样的灰度流程，只是把时间周期从一两周压缩到几个小时而已。
当然，有些乙方安全公司，安全出身的工程师会提出不同的看法：“安全行业不一样，我们要与病毒赶时间“，”病毒研究员发现最新的病毒，然后判断如何最快的全网防御”，“病毒来的时候，我的安全专家判断需要启用，跟你们打招呼来不及”，“蓝屏总好过数字资产丢失或者被人随意控制”。但对甲方来说，安全是一整个体系，配置灰度发布晚一点不是什么大不了的事情，然而集中批量崩溃这种惊吓则是让人难以接受的。
至少对于企业客户来说，更不更新，什么时候更新，这个利弊权衡应该是由甲方来做的，而不是乙方去拍脑袋决定。而放弃这一职责，无条件信任乙方供应商给你空中升级的甲方，也是草台班子。安全软件是合法的大规模肉鸡软件，即使用户以最大的善意信任供应商没有主观恶意，但在实践中也难以避免因为无心之失与愚蠢傲慢导致的灾难（比如这次蓝屏星期五）。
（美剧《太空部队》名梗：紧急任务遇到Microsoft强制更新）
如果你的系统真的重要，那么你应该假设任何单一供应商与组件都是不完全可靠的，并在此假设之上进行架构设计。如果你要给出信任，也应当在接受任何变更与更新前切记 —— Trust，But Verify。如果供应商不提供 Verify 这个选项，你应该在权力范围内果断 Say No。
我认为这次事件会极大利好 “本地优先软件” 的理念 —— 本地优先不是不更新，不变更，一个版本用到地老天荒，而是能够在无需联网的情况下，在你自己的电脑与服务器上持续运行。用户与供应商依然可以通过补丁服务器，与定期推送的方式升级功能，更新配置，但更新的时间点、方法、规模、策略都应当允许由用户自行指定，而不是由供应商越俎代庖替你决策。我认为这一点才是 “自主可控” 概念的真正实质。
在我们自己的开源 PostgreSQL RDS，数据库管控软件 Pigsty 中，也一直践行着本地优先的原则。每当我们发布一个新版本时，我们会对所有需要安装的软件及其依赖取一个快照，制作成离线软件安装包，让用户在没有互联网访问的环境下，无需容器也可以轻松完成高度确定性的安装。如果用户希望部署更多套数据库集群，他可以期待环境中的版本总是一致的 —— 这意味着，你可以随意移除或添加节点进行新陈代谢，让数据库服务跑到地老天荒。
如果您需要升级软件版本打补丁，将新版本软件包加入本地软件源，使用 Ansible 剧本批量更新即可。您可以选择用老旧 EOL 版本跑到地老天荒，也可以选择在第一时间发布就更新并尝鲜最新特性，您可以按照软件工程最佳实践依次灰度发布，但真想要糙猛快一把梭全量上也随意，我们提供默认的行为与实践的工具，但说到底，更不更新，这是用户的自由与选择。
物极必反，在 SaaS 与云服务盛行的当下，关键基础设施故障的单点风险与脆弱性愈加凸显。相信在本次事故后，本地优先软件的理念将会在未来得到更多的关注与实践。
References
[1] CrowdStrike导致大规模系统崩溃事件的技术分析: https://www.secrss.com/articles/68310[2] CrowdStrike官方故障复盘: https://www.crowdstrike.com/blog/falcon-update-for-windows-hosts-technical-details/