安全事件一直是悬挂在每一个公司头顶的达摩克利斯之剑，时刻提醒着我们数字世界的脆弱与复杂。其中，CrowdStrike与Windows宕机事件，便是近年来引起广泛关注的一起网络安全风波，它不仅撼动了全球网络安全的神经，也再次凸显出在日益复杂的网络威胁面前，加强系统防御、提升应急响应能力的重要性。
CrowdStrike，作为全球知名的网络安全和技术服务提供商，以其先进的威胁情报和端点保护解决方案闻名于世，服务于众多政府机构及企业客户，守护着关键基础设施的安全。然而，即便是这样的行业巨擘，也难免遭遇前所未有的挑战。202X年，一场突如其来的Windows系统大规模宕机事件，将CrowdStrike推上了风口浪尖，引发了全球对于网络安全防护能力的深刻反思。
这次事件的起因错综复杂，初步分析指向了一种新型的、高度隐蔽的恶意软件攻击，该攻击利用了Windows操作系统中的一个未知漏洞（零日漏洞），迅速在全球范围内的计算机网络中蔓延开来。受影响的系统纷纷出现崩溃、数据丢失等严重后果，一时间，从政府机构到私营企业，无一不感受到了前所未有的恐慌和压力。
CrowdStrike作为事件响应的重要参与者，立即启动了最高级别的应急机制，与微软及其他安全厂商紧密合作，力求在最短时间内查明真相，遏制病毒传播，并协助用户恢复系统正常运行。此事件不仅是对CrowdStrike技术实力与应急处理能力的一次严峻考验，也是对全球网络安全生态协作与信息共享机制的一次实战演练。
本文将深入剖析CrowdStrike / Windows宕机事件的来龙去脉，探讨其背后的影响范围以及后续的应对措施，旨在为业界提供宝贵的经验教训，进一步推动网络安全防护技术的发展与进步。同时，我们也将审视这一事件对国际网络安全政策、企业安全策略乃至个人用户数据保护意识的长远影响，共同思考如何构建更加坚固的数字防线，以抵御未来可能发生的更复杂多变的网络攻击。
本文结构如下：
事件回顾：850万台Windows设备受到影响，涉及各行各业。
故障根因：对查找恶意进程的命名规则进行更新时，不知何故导致了CSAgent.sys进程试图向一个无效的内存地址写入数据，从而引发了操作系统崩溃。
非常缓慢的手动修复过程：停机四天后，恢复工作仍在进行，因为每一台受影响的机器和主机都需要手动修复。
谁该为此负责？显然是CrowdStrike公司，而且人们很容易认为微软也该承担部分责任。2009年出台的一项法规也可能起到了作用。
给软件工程师的建议：量化潜在影响、进行灰度发布/分阶段发布、配置即代码等。
事件回顾
2024年7月19日，有史以来由软件引发的最大规模全球性宕机事件席卷全球。航空公司、银行、超市、警察局、医院、电视台等对社会至关重要的企业所使用的数百万台Windows 10和11操作系统突然崩溃，并出现了令人恐惧的“蓝屏死机”，而且没有明显的修复方法，毫无疑问这是一次真正的全球性宕机事件；美国、欧洲、亚洲、南美洲和澳大利亚都受到了影响。
全球航空旅行陷入混乱，阿拉斯加州的紧急服务热线停止工作。在英国，天空新闻电视台无法播出节目，麦当劳不得不关闭部分日本门店，因为收银机无法使用。总共有数十万家企业和数百万人受到影响。与此同时，在一级方程式赛车界，梅赛德斯车队在匈牙利大奖赛期间遭遇了电脑故障。有趣的是，该车队的赞助商之一是CrowdStrike。以下是一些事故现场的照片：
纽约拉瓜迪亚机场的输送带式筛分装置，2024年7月19日。来源：维基百科
迪士尼巴黎乐园也受到了影响，员工们开始使用纸质打印件来显示游乐设施的等待时间。来源：《积分指南》
新西兰某超市的自助结账区（奥克兰）。来源：新西兰先驱报
CrowdStrike更新导致的Windows系统崩溃给CrowdStrike赞助的F1车队带来了问题。来源：BBC/Getty
我们知道，微软透露了这个数字（8.5million），后来也得到了CrowdStrike的确认。受影响最严重的可能是达美航空公司，在三天内约有三分之一的航班（5000架）被取消。即使在第四天，达美航空公司在恢复运营时也不得不取消另外1000架航班，并要为受影响的乘客提供现金退款。
故障根因
在运行CrowdStrike软件的Windows电脑开始崩溃几个小时后，该公司发布了更新信息：
CrowdStrike正在积极协助受到Windows主机最近一次内容更新中缺陷影响的客户。Mac和Linux主机未受影响。该问题已被发现并隔离，并已部署了修复程序。可以确认的是这并非一起网络攻击。
发生的事情是该公司一次性向所有客户推送了一个“内容”文件（二进制文件），这导致操作系统崩溃。但这是怎么发生的呢？由于事故仍在进行中，一些开发人员试图还原事故发生的情况。以下是帕特里克·沃德利（Patrick Wardle）提供的细节：
1. 导致Windows系统崩溃的进程名为“CSAgent.sys”。
2. 导致崩溃的指令是汇编指令“mov r9d， [r8]”。该指令将r8地址中的字节移动到r9d中。问题在于r8是一个未映射的地址（无效），因此进程崩溃了！
3. 这起事故是由名为“CSAgent.sys”的进程读取CrowdStrike向所有客户端推送的名为“C-00000291-*.sys”（其中“*”可以有其他字符）的新“内容”文件时发生的。与此文件的解析有关的某个环节出了问题。
一天后，CrowdStrike分享了更多细节：
4. 更新的目的是检测恶意命名的管道。CrowdStrike的Falcon产品会观察机器或网络上进程之间的通信方式，以试图确定恶意活动。此次更新增加了一个新的规则文件，用于过滤可疑命名的管道。在Windows世界中，命名管道是一种“用于服务器和一个或多个管道客户端之间通信的命名、单向或全双工管道”。这些管道可用于进程间通信（两个进程相互通信；例如，进程之间感知文件或通过网络通信）。命名管道是操作系统中用于进程间通信的常见概念：Unix也使用这个概念。
5. 发布了一个新的配置文件，其中包含了新的规则/命名。CrowdStrike将定义行为规则的配置文件（例如用于标记可疑命名管道的名称）称为“通道文件”。它们将所有这些通道文件存储在C：\Windows\System32\drivers\CrowdStrike\的位置。这些文件是编号文件，命名管道的规则位于编号291的位置。因此，所有以“C-00000291-*.sys”命名模式的文件都是该类别的规则。
CrowdStrike在更新中发布了一个新的命名文件。
6. 一次未处理的错误导致进程和操作系统崩溃。虽然我很想知道这个错误的详细情况，但CrowdStrike只提供了一个非常简短的概述。
“配置更新触发了一个逻辑错误，导致操作系统崩溃。这与通道文件291或其他任何通道文件中包含的空字节无关。”
因此，在某种程度上，解析这些新的命名规则导致产生了一个试图将内存位置移动到无效位置的汇编级指令。这就是导致Windows设备在各地崩溃的原因。
缓慢的手动修复
解决此次故障比以往任何时候都要复杂得多，因为简单的回滚操作并不足以解决问题。IT人员必须亲自访问每一台机器：
事件发生后几小时，CrowdStrike为想要解除封锁的IT管理员和开发人员提供了缓解措施。这些措施包括：
恢复过程可能需要一台拥有删除有问题文件权限的机器上的本地管理员。这些步骤非常专业，普通用户很难完成恢复工作：因此，大多数公司都是由IT人员手动修复每台机器。此外，许多地方的所有Windows笔记本电脑都受到了影响。一位IT管理员分享了这项工作的一个片段，他在周末上传了一张1200台2000台笔记本电脑需要修复的照片，理想情况下！
作为软件工程师，当我们看到一个高度依赖人工的过程时，我们的第一反应往往是能否自动化它，或者用更聪明的方法来加快进程。有850万台机器需要重置，显然手动操作会耗费大量时间。因此，独立开发者和微软也介入了：
iOS开发人员和Windows爱好者亚当·德马西（Adam Demasi）在第二天创建了Unistrike工具。经过一些额外的设置后，您可以创建一个USB棒，将其插入每台受影响的机器，以更快地进行恢复。
故障发生后的第二天，微软也发布了类似的恢复工具。
两天后，CrowdStrike宣布他们正在为客户测试一种新的、更快的恢复技术。
在停机事件发生四天后，仍有850万台受到影响的Windows设备尚未得到修复。事实证明，大规模崩溃的操作系统比应用程序更难大规模恢复，因为可以向客户端（移动和桌面应用程序）或服务器端（服务、后端应用程序和Web应用程序）发送补丁来修复应用程序。
谁该负责？
有趣的是，新闻最初将此次事件报道为“微软宕机”或“Windows宕机”，这与事实有些出入。那么，谁“拥有”了有史以来最大的软件故障呢？
CrowdStrike
显然，大部分责任在于CrowdStrike。目前我们只能猜测哪些环节被跳过了，或者没有得到充分的处理。希望在公开的“事故分析报告”中能了解更多信息。与此同时，CrowdStrike应该问（而且很可能已经在问）以下问题：1. 黑客是如何绕过CrowdStrike的安全措施的？2. CrowdStrike是否及时发现了入侵行为？3. CrowdStrike是否采取了有效的措施来阻止入侵行为？4. CrowdStrike是否对入侵行为进行了充分的调查和分析？5. CrowdStrike是否向客户提供了足够的信息和支持，以帮助他们应对入侵行为？6. CrowdStrike是否从这次事件中吸取了教训，并采取了相应的措施来防止类似事件再次发生？
2. 这个变更是否经过测试？是如何测试的？这个配置文件（C-00000291-*.sys）在手动和自动化场景下是否经过测试？如果是，测试是如何通过的？为什么生产环境中会出现崩溃？只有CrowdStrike才能回答的一个更有趣的问题是：这些配置文件是否以自动化方式进行了测试？确实进行了吗？我们知道测试环境永远无法完全模拟生产环境，因此预期会有未经检测的漏洞进入测试环节。
3. 这些配置变更是否已经在内部进行了测试？这些变更是否在向公众发布之前首先在CrowdStrike员工中进行了部署？如果是，是否有一些CrowdStrike员工也遇到了操作系统崩溃的问题？如果是，那么为什么还要继续部署？如果已经进行了内部测试，但没有员工的机器出现崩溃，那么有趣的问题是：为什么不会呢？
4. 有没有进行“金丝雀发布”？我们在《Shipping to Production》一文中讨论了“金丝雀测试”这一话题。
“Canarying”源自“canary in the coal mine”这一短语。在20世纪初，矿工们会把笼子里的金丝雀带到地下矿井中。金丝雀对有毒气体的耐受力比人类低，因此，如果金丝雀停止鸣叫或昏厥，就意味着有毒气体的存在，矿工们需要撤离。
今天，“金丝雀测试”意味着将代码变更分发给更小比例的用户群体，然后监控这一部署的健康信号，以寻找是否有什么地方出了问题。一种常见的实现“金丝雀测试”的方法是使用负载均衡器将流量路由到新代码的版本，或者将新代码的版本部署到单个节点上。
金丝雀发布是分阶段发布策略的一个子集。
“分阶段发布意味着逐步发布变更，在每个阶段评估结果后再继续。分阶段发布通常会定义要获得变更功能的用户比例，或者该功能应该在何区域发布，或者两者都有。”
分阶段实施计划如下所示：
第一阶段：在新西兰（一个较小的市场，用于验证变更）进行10%的部署。
第二阶段：在新西兰进行50%的部署
第三阶段：新西兰全面推广
第四阶段：全球范围内逐步推出10%的服务
第五阶段：全球范围内实现25%的覆盖率。
第六阶段：全球50%的部署
第七阶段：全球100%部署
在每个发布阶段之间，会设定一个发布可以继续的条件。通常定义为没有出现意料之外的退化情况，并且预期的业务指标变化已经得到观察。
CrowdStrike是否采用了这些方法，还是更倾向于“YOLO部署”，即一次性将配置文件推送给所有客户？目前我们还不清楚。
从应急响应通信来看，这次变更更像是一次“YOLO部署”(YOLO即You Only Live Once，意为“人生只有一次”，这里指未经充分准备就匆忙部署)，因为变更的文件被标记为“内容”，而不是“业务逻辑”。尽管该文件包含了如何检测命名管道的规则，但你可能会认为这是应该分阶段逐步部署的业务逻辑，而不是一次性全部部署！
5. CrowdStrike是否认为二进制文件（“内容”）无法破坏运行在内核级别的软件？在分发这些新配置文件时，可能没有采用常见的代码分发策略。CrowdStrike是否隐含或明确地认为这些“内容”文件不会导致进程崩溃？
CrowdStrike 的软件在 Windows 操作系统的内核层运行，这意味着其进程以操作系统的最高权限和访问权限运行。这意味着它可以导致整个系统崩溃，例如，通过破坏操作系统部分内存。CrowdStrike 以这种方式运行是必要的，以便监控操作系统中运行的所有进程，并发现威胁和漏洞。但这也意味着，即使是一个看似无害的内容文件更新！也可能导致系统崩溃。
6. 公司是否忽视了之前的类似故障？一位在公民技术实验室工作的黑客新闻评论者透露，几个月前，CrowdStrike的Linux系统也出现了类似的故障。这位开发者总结道：
早在2024年4月19日Crowdstrike对我们的生产Linux系统进行了同样的操作，从那以后我一直憋着想对此发泄一番。
简而言之，我们是一家公民技术实验室，因此在不同的基础设施上创建了多个不同的生产网站。我们使用企业提供的Crowdstrike进行安全防护。Crowdstrike在周五晚间推送了一个更新，与最新的Debian稳定版本不兼容。因此，我们像往常一样对Debian进行了打补丁，一切正常了一周，然后我们的所有服务器（包括多个网站和云主机）突然同时崩溃并无法启动。
当我们将一个硬盘连接到一台新机器上并查看日志时，Crowdstrike看起来像是罪魁祸首，于是我们手动将其删除。机器启动后，我们尝试重新安装它，但机器立即又崩溃了。好吧，让我们提交一份支持票单，让工程师接听电话。
Crowdstrike花了一天时间才做出回应，然后要求提供更多证据来证明这是他们的过错。他们一天后承认了这个漏洞，但几周后才给出了根因分析，而他们的分析没有涵盖我们的场景（我想是Debian稳定版运行版本n-1，这是一个受支持的配置）。在他们自己的事后分析中，并没有真正能够防止此类事件再次发生的能力：“我们随时都可以将软件推送到您的机器上，无论紧急与否，而不进行测试”似乎是这一模式的核心。
这些细节表明，CrowdStrike本应或确实知道其更新可能会（并且确实会）导致内核进程崩溃。如果是这样，显而易见的问题是，为什么这次宕机没有作为警告来调整更新发布流程，而不是仅仅改进测试？
公平地说，像CrowdStrike这样的公司拥有数百个工程团队，其中一个团队观察到系统宕机的信息不一定会迅速在整个组织中传播。然而，CrowdStrike的系统导致操作系统崩溃肯定是已知的漏洞，因为这是最明显的让客户的机器无法使用的方式，而该公司正是旨在保护客户的机器不受此类攻击。
微软
CrowdStrike为何能够在内核级别运行进程，从而导致操作系统崩溃？毕竟，苹果已经为MacOS做出了变更，以便在用户级别运行第三方软件，而不是内核级别。（引自《Electric Light》2021年）
多年来，苹果一直鼓励第三方开发者放弃内核扩展，转而使用在用户级而非内核级运行的等效功能。然而，只有在过去的一年左右的时间里，苹果才提供了足够的支持，使得这种做法成为可能。再加上M1 Mac必须降低安全级别才能加载第三方内核扩展的事实，几乎所有以前依赖内核扩展的软件和硬件现在都应该转向苹果的新替代方案，比如系统扩展。本文将解释这些变化对用户产生的影响。
因此在Mac上，相同的CrowdStrike进程将在用户空间运行，如果它崩溃了，也不会导致整个系统崩溃。
然而，在Windows和Linux系统上，防病毒软件和其他网络安全软件通常在内核级别运行，并且一直如此。那么，为什么微软没有效仿苹果的做法，禁止第三方进入内核空间呢？原来，2000年代的赛门铁克投诉以及欧盟法规起到了作用。
是监管制度的问题吗？
《华尔街日报》询问微软公司为何不将第三方软件（如CrowdStrike）限制为仅在用户空间运行，而不能在内核空间运行。微软的回应是：“我们相信，用户空间的隔离和保护措施已经足以保护用户免受恶意软件的攻击。将软件限制在用户空间运行，可能会影响其性能和功能，而这可能会给用户带来不便。因此，我们允许第三方软件在内核空间运行，以确保其功能不受限制，同时保护用户免受恶意软件的攻击。”
微软一位发言人表示，由于在收到投诉后与欧洲委员会达成了谅解，该公司无法像苹果那样在法律上将操作系统与外界隔离开来。2009年，微软同意向Windows的制造商提供与微软自身相同的访问权限，以便安全软件制造商能够更好地保护Windows系统。
讽刺的是，这一切要追溯到2006年，当时微软为了使Windows Vista的内核更加安全而采取了这些措施。以下是当时CIO.com的报道（下划线部分为我所加）：
如今，像赛门铁克这样的安全供应商正处于高度敏感的状态，因为他们已经开始与微软正面竞争，而微软在安全领域的一举一动都笼罩在进一步的反垄断行动的阴影之下。上周，欧盟竞争事务发言人乔纳森·托德警告称，如果微软不给安全供应商公平竞争的机会，市场可能会受到威胁。
赛门铁克和其他安全供应商不喜欢PatchGuard，因为它阻止他们访问Windows内核。他们说这将阻止他们提供像赛门铁克的“防篡改”技术这样的重要功能，该技术可防止恶意程序修改赛门铁克自己的软件。
桑贝特软件（Sunbelt Software）研发副总裁埃里克·赛茨（Eric Sites）表示，PatchGuard还将使安全供应商更难防范利用内核级漏洞的恶意软件。
微软拒绝接受本文的采访，但在上周接受IDG新闻采访时，一位微软高管表示，PatchGuard只是为了防止内核被滥用。
“我们认为，我们的产品中某些安全功能存在大量混淆……我们认为这些功能从根本上提高了安全性，”安全技术部门的高级产品经理斯蒂芬·图卢兹（Stephen Toulouse）说。“我们所做的是，将内核与攻击者隔离开来，因为目前存在的功能从未打算被任何人使用——无论是软件供应商还是攻击者。”
最后，赛门铁克和其他供应商胜出了。如果微软不打算在内核空间运行自己的安全软件，它就无法“禁止”其他安全供应商在该空间运行。因此，尽管微软在某种程度上对这次崩溃负有责任，但该公司在采取这些行动时别无选择，这些行动为问题的发生创造了条件！
不过，可能还是有办法的：如果微软将自己的安全解决方案（如Windows Defender）从内核空间移除，关闭对所有安全供应商的访问，包括它自己。这样做可能意味着对Windows安全堆栈进行足够大的重新架构。这也会限制第三方供应商解决方案的能力，任何此类变更都可能引发安全供应商的抗议和向监管机构的投诉。这与2006年Vista试图将供应商排除在内核空间之外时的投诉和升级情况并无不同。
软件工程师可以学习的经验
目前来看，以下是我们可以从这次事件中学到的一些经验教训：
量化软件在各处崩溃所产生的影响。
如果贵公司的产品在几个小时内完全崩溃，会发生什么情况？请忽略这种可能性微乎其微甚至不可能发生的事实——因为这种情况刚刚发生在CrowdStrike公司身上。如果这种情况发生了，会对贵公司和外部世界产生什么影响？例如：
如果亚马逊在全球范围内瘫痪几个小时，卖家会失去收入，而一部分消费者则可能无法获得必需品。亚马逊也会失去收入，并遭受声誉上的损失。
如果TikTok在全球范围内崩溃几个小时，品牌将无法投放广告，用户会感到漠不关心、略有不满或愤怒，因为他们无法使用这款社交平台。人们可能会产生各种荒谬的猜测，比如TikTok被屏蔽了，该公司将失去广告收入，用户会暂时转向Instagram Reels和Snap等替代品。
如果一家大型手机和互联网运营商出现故障，其影响将比上述两个事件加起来还要严重得多。企业将难以正常运营，紧急服务也可能受到影响。这种损害将是声誉上的、持久的，政府也可能会介入。去年11月，我们报道了澳大利亚一半的互联网断线14小时的情况。
这个练习很有帮助，因为它可以使人们了解停机可能造成的巨大损失。了解“影响范围”可以帮助获得对提高系统可靠性的支持，并加快检测和解决事故的速度。
回顾产品是如何发布到生产的
要将代码或资产变更发送给所有客户，需要做哪些事情？我们在《将代码发布到生产环境》一文中深入探讨了这一话题。简而言之，以下是将代码发送到生产环境的两种极端情况：CrowdStrike似乎选择了“YOLO”选项，为此付出了高昂的代价：
分阶段发布
如果你的软件在各个地方都频繁崩溃，其“破坏范围”大到足以导致失败无法接受，那么不要一次性将变更推送给所有客户！进行“金丝雀”测试或分阶段部署。
确实，对于用户数量较少、不产生收入或处于试验阶段的产品来说，采用灰度发布和分阶段发布等策略可能有些大材小用。设置灰度发布或分阶段发布需要投入一定的精力，也会减缓发布速度。但如果你的产品被大量用户使用，或者至关重要，那么这种发布策略是不可妥协的。以下是前谷歌Chrome工程师马克-安托万·鲁埃尔（Marc-Antoine Ruel）的看法：
从一开始，谷歌Chrome就有3个发布渠道以及每日构建版本：
卡纳里（夜夜）、开发版、测试版、稳定版。每一种都会扩大影响范围。
确实有出现过无法正常运行的版本。beta版本在一些不易察觉的地方出现了问题。这种发布策略减少了问题的影响范围。
最终结果：126个稳定版本！
配置即代码
前Twitch员工、高级工程师雅克·贝尼尔(Jacques Bernier)分享了亚马逊如何处理代码变更：
“亚马逊的构建和部署系统是我非常怀念的一个系统。它的功能非常强大，而且对所有的变更都一视同仁。它将代码、依赖项以及一直到操作系统和基础设施的所有内容都纳入同一条构建和部署流水线，流水线包含多个阶段。”
配置变更就是代码。基础设施变更就是代码变更。依赖更新就是代码变更。代码变更就是代码更改。它们都是一样的。
分阶段推出是减少影响范围的最佳方法之一。
依赖/供应商会“悄无声息”地推动哪些变化？
CrowdStrike破坏了大多数客户的业务，因为它在悄无声息地自动发送业务逻辑变更。即使客户想要“阻止”变更，或者仅允许在一小部分机器上首先执行更改，他们也无法做到。
这提醒我们，软件不仅可能因代码问题而出现故障，还可能因依赖项或供应商的问题而出现故障。因此，现在是考虑这些问题的好时机：
依赖项（库、框架）是如何更新的？是自动更新还是手动更新？这在使用可能自动更新依赖项的包管理器时尤其重要。
供应商依赖性——SDK（软件开发工具包）或API（应用程序接口）呢？你是负责进行变更的人，还是供应商在悄悄地进行变更？
列出所有可能受到第三方（目前）信任的“静默”变更影响的点。
事故不是某个人的过错
很容易把责任归咎于编写了有问题的代码的人；也许是缺乏经验的实习生，或者是心情不好的老资格工程师。但把责任归咎于个人是不对的。微软资深人士斯科特·汉塞尔曼（Scott Hanselman）总结了为什么大规模的失败绝不是一个人的过错（重点强调）：
“大家注意了，我编程已经有32年了。这种事情的发生就是组织上的失败。是的，有人写了一条糟糕的代码。有人可以使用‘git blame’功能来找出写代码的人，这真是太糟糕了。”
但是，这涉及到测试，包括Cl/CD（持续集成/持续部署）、A/B测试、有控制的发布、“哦，该死”按钮（用于回滚发布）、代码覆盖率、静态分析工具、代码审查、组织健康等等。
这总是一行代码的问题，但绝不是一个人的问题。暗示包容性政策导致了这个错误是一种简单的、片面的、种族主义的做法。工程是一项团队运动。包容性有助于打造优秀的团队。良好的工程实践有助于打造优秀的软件。无论检查代码的是何等人士，工程实践多次未能发现这个错误。
解决更大的系统性问题比检查空指针更重要。这并不是“学习C语言很难”的问题，更不是什么DEI（多元化、公平性和包容性）问题。
后话
大规模的宕机总是不好的，但其中一个好处是，它们迫使我们工程师思考：
我的公司是否也会发生类似的灾难性事件？如果是，原因是什么？
在我的情况下，会有什么影响呢？
我们应该采取哪些措施来避免成为下一个CrowdStrike呢？
现在是向领导层提出合理投资可靠性的时机。
CrowdStrike的宕机事件现已正式成为地球上有史以来最大的软件宕机事件，客户遭受了严重的财务和声誉损失。
CrowdStrike的财务损失目前尚未确定，但你可以假设它将是巨大的，因为一些企业将寻求赔偿损失。
对于CrowdStrike来说，名誉上的损失几乎是无法挽回的。直到几天前，该公司还是终端安全合规方面的行业标杆。但现在情况不再如此：该公司与有史以来最大的宕机事件联系在一起。在如此高调的失误之后，人们发现该公司在业务规则变更方面没有实施分阶段部署流程，这使得CrowdStrike的声誉受到了打击，需要很长时间才能恢复。
没有哪家公司愿意因为一次糟糕的部署而遭受这样的打击，但这已经发生了。如果你发现公司在发布流程（如测试、部署、监控和警报等）中存在漏洞，那么现在就是你将自己的担忧和建议提出来的时候了！与你的经理或跨级上司沟通；他们更有可能支持有助于生产系统具备弹性的建议。
CrowdStrike肯定会从中吸取教训，毫无疑问，其未来的发布流程将达到世界一流水平。祝愿那里的团队（以及所有受影响客户的团队）能够成功地缓解此次中断，并在 CrowdStrike 内部进行彻底的流程改革方面取得成功。
希望有更多公司效仿这一做法，让这一历史性事件最终成为科技行业的一次积极的学习经验。
