近日，微软全球宕机事件引发业界关注和思考。由于国外一家终端安全公司Crowdstrike软件更新，导致了微软Windows系统大面积蓝屏死机。一些欧美机场、医院、媒体与银行由于Windows系统崩溃，陷入瘫痪状态，不仅诸多企业运营受阻，人们的衣食住行也受到影响。
造成本次蓝屏事件的原因，是因为“CSAgent.sys”加载和解析使用存在错误设定的“C-00000291*.sys”文件所致。根据Crowdstrike的官网提供的解决方案，用户可以尝试以下操作进行恢复：
1. 使用安全模式或恢复模式进入操作系统
2. 进入 C:\Windows\System32\drivers\CrowdStrike 目录
3. 找到所有匹配“C-00000291*.sys”的文件，并将其删除
4. 正常启动主机
或者直接重命名以下文件夹：“C:\Windows\system32\drivers\CrowdStrike
事实上，目前许多企业办公场景和生产场景都会使用这样的第三方软件，由于安全问题和三方软件功能迭代，办公电脑和服务器需要不断地安装更新。由于对于三方软件缺乏技术上的深入了解，运维人员往往很难定位到是三方软件的问题，只能面对着蓝屏电脑、崩溃的服务器一头雾水。
此次事件中，阿里云上也有部分用户受到波及。通过对故障情况分析和梳理，以及基于云的特性和能力，阿里云对云上客户在应对此类故障的应急处理方面，可以提供怎样的帮助？
首先，阿里云ECS实例具备自助排查能力，可以帮助企业客户快速定位三方软件问题，及时地定位问题根因。对于一些已知的问题，知识库会给出修复方案，解决企业因为缺乏专业排查工具而定位难的问题。
（ECS控制台自助问题排查）
（ECS实例问题排查定位的事件分析根因）
其次，云上用户还可通过系统运维管理服务，如阿里云的OOS，对受损机器进行批量操作，从而迅速止血，用户可在执行模板窗口选择要修复的ECS实例等参数，就可以一键对受损的实例进行批量修复。
整个自动化修复流程不仅大大减少了用户的修复时间，并且由于在模板中固化了修复流程，能够保证修复效果，避免手动修复过程中执行错误的情况。
本次事件也给各大厂商在安全产品的设计、研发、测试、以及变更的流程上一定启示。
比如，从产品设计角度，厂商应当有节制地使用驱动方案。目前阿里云在只有涉及到实时防御和拦截的功能才必须要基于驱动方案实现，其他所有的功能都是基于应用层设计，这样可在设计阶段就保证不会将风险不断扩大。
再如，从变更发布角度讲，提前规划好灰度流程与回滚方案。阿里云在设计此类安全产品时候，会根据最小粒度即单机进行灰度。对于机器规模庞大且整体变更周期很长的情况，会采用阶梯式的灰度发布，即逐个区域分批次发布，每批次发布机器数量、范围逐步增加，最终达到一个相对平稳的发布数量批次完成全网发布。
总的来说，此类故障难以完全避免，对于云厂商来说也需要不断提升自身在设计、研发、变更上的控制能力，优先保障系统稳定，且对系统稳定性做持续的投入、建设和优化，来降低故障风险。
对于云上产品用户来说，要利用好云平台提供的原生能力，在出现故障时进行规避和恢复，尽可能降低运维成本。对于三方产品的引入和部署，应当有充分的调研和评估，避免引入不受控的风险。
