蓝屏星期五：甲乙双方都是草台班子
最近，因为网络安全公司 CrowdStrike 发布的一个配置更新，全球范围内无数 Windows 电脑都陷入蓝屏死机状态，无数的混乱 —— 航司停飞，医院取消手术，超市、游乐园、各行各业歇业。
表：受到影响的行业领域、国家地区与相关机构（CrowdStrike导致大规模系统崩溃事件的技术分析）
| 涉及领域 | 相关机构 |
|---|---|
| 航空运输 | 美国、澳大利亚、英国、荷兰、印度、捷克、匈牙利、西班牙、中国香港、瑞士等部分航空公司出现航班延误或机场服务中断。美国达美航空、美国航空和忠实航空宣布停飞所有航班。 |
| 媒体通信 | 以色列邮政、法国电视频道TF1、TFX、LCI和Canal+Group网络、爱尔兰国家广播公司RTÉ、加拿大广播公司、沃丰达集团、电话和互联网服务提供商Bouygues Telecom等。 |
| 交通运输 | 澳大利亚货运列车运营商Aurizon、西日本旅客铁道公司、马来西亚铁路运营商KTMB、英国铁路公司、澳大利亚猎人线和南部高地线的区域列车等。 |
| 银行与****金融服务 | 加拿大皇家银行、加拿大道明银行、印度储备银行、印度国家银行、新加坡星展银行、巴西布拉德斯科银行、西太平洋银行、澳新银行、联邦银行、本迪戈银行等。 |
| 零售 | 德国连锁超市Tegut、部分麦当劳和星巴克、迪克体育用品公司、英国杂货连锁店Waitrose、新西兰的Foodstuffs和Woolworths超市等。 |
| 医疗服务 | 纪念斯隆凯特琳癌症中心、英国国家医疗服务体系、德国吕贝克和基尔的两家医院、北美部分医院等。 |
| …… | …… |
在这次事件中，有许多程序员在津津乐道哪个 sys 文件或者配置文件搞崩了系统 （CrowdStrike官方故障复盘），或者XX公司是草台班子云云 —— 做安全的乙方和甲方工程师撕成一片。但在我看来，这个问题根本不是一个技术问题，而是一个工程管理问题。重要的也不是指责谁是草台班子，而是我们能从中吸取什么教训？
在我看来，这场事故是甲乙方两侧的共同责任 —— 乙方的问题在于：崩溃率如此之高的变更，为什么在没有灰度的情况下迅速发布到了全球？有没有做过灰度测试与验证？甲方的问题在于：将自己的终端安全全部寄托于供应链的可靠之上，为什么能允许这样的变更联网实时推送到自己的电脑上而不加以控制？
控制爆炸半径是软件发布中的一条基本原则，而灰度发布则是软件发布中的基本操作。互联网行业中的许多应用会采用精细的灰度发布策略，比如从 1% 的流量开始滚动上量，一旦发现问题也能立刻回滚，避免一勺烩大翻车的出现。
数据库与操作系统变更同理，作为一个管理过大规模生产环境数据库集群的 DBA，我们在对数据库或者底层操作系统进行变更时，都会极为小心地采取灰度策略：首先在 Devbox 开发环境中测试变更，然后应用到预发/UAT/Staging环境中。跑几天没事后，开始针对生产环境发布：从一两套边缘业务开始，然后按照业务重要性划分的 A、B、C 三级，以及从库/主库的顺序与批次进行灰度变更。
某头部券商运维主管也在群里分享了金融行业的最佳实践 —— 直接网络隔离，禁止从互联网更新，买微软 ELA，在内网搭建补丁服务器，然后几万台终端/服务器从补丁服务器统一更新补丁和病毒库。灰度的方式是每个网点和分支机构/每个业务部门都选择一到两台组成灰度环境，跑一两天没事，进入大灰度环境跑满一周，最后的生产环境分成三波每天更新一次，完成整个发布。如果遇到紧急安全事件 —— 也会使用同样的灰度流程，只是把时间周期从一两周压缩到几个小时而已。
当然，有些乙方安全公司，安全出身的工程师会提出不同的看法：“安全行业不一样，我们要与病毒赶时间“，”病毒研究员发现最新的病毒，然后判断如何最快的全网防御”，“病毒来的时候，我的安全专家判断需要启用，跟你们打招呼来不及”，“蓝屏总好过数字资产丢失或者被人随意控制”。但对甲方来说，安全是一整个体系，配置灰度发布晚一点不是什么大不了的事情，然而集中批量崩溃这种惊吓则是让人难以接受的。
至少对于企业客户来说，更不更新，什么时候更新，这个利弊权衡应该是由甲方来做的，而不是乙方去拍脑袋决定。而放弃这一职责，无条件信任乙方供应商给你空中升级的甲方，也是草台班子。安全软件是合法的，大规模肉鸡软件，即使用户以最大的善意信任供应商没有主观恶意，但在实践中也难以避免因为无心之失与愚蠢傲慢导致的灾难（比如这次蓝屏星期五）。
（美剧《太空部队》名梗：紧急任务遇到Microsoft强制更新）
如果你的系统真的很重要，在接受任何变更与更新前请切记 —— Trust，But Verify。如果供应商不提供 Verify 这个选项，你应该在权力范围内果断 Say No。
我认为这次事件会极大利好 “本地优先软件” 的理念 —— 本地优先不是不更新，不变更，一个版本用到地老天荒，而是能够在无需联网的情况下，在你自己的电脑与服务器上持续运行。用户与供应商依然可以通过补丁服务器，与定期推送的方式升级功能，更新配置，但更新的时间点、方法、规模、策略都应当允许由用户自行指定，而不是由供应商越俎代庖替你决策。我认为这一点才是 “自主可控” 概念的真正实质。
在我们自己的开源 PostgreSQL RDS，数据库管控软件 Pigsty 中，也一直践行着本地优先的原则。每当我们发布一个新版本时，我们会对所有需要安装的软件及其依赖取一个快照，制作成离线软件安装包，让用户在没有互联网访问的环境下，无需容器也可以轻松完成高度确定性的安装。如果用户希望部署更多套数据库集群，他可以期待环境中的版本总是一致的 —— 这意味着，你可以随意移除或添加节点进行新陈代谢，让数据库服务跑到地老天荒。
如果您需要升级软件版本打补丁，将新版本软件包加入本地软件源，使用 Ansible 剧本批量更新即可。您可以选择用老旧 EOL 版本跑到地老天荒，也可以选择在第一时间发布就更新并尝鲜最新特性，您可以按照软件工程最佳实践依次灰度发布，但真想要糙猛快一把梭全量上也随意，我们只提供默认的行为与实践的工具，但说到底，这是用户的自由与选择。
俗话说，物极必反，在 SaaS 与云服务盛行的当下，关键基础设施故障的单点风险与脆弱性愈加凸显。相信在本次事故后，本地优先软件的理念将会在未来得到更多的关注与实践。