客户分享了他们的方法，包括警报关联、事件丰富、工单管理以及事件后分析的重要性。
译自 Best Practices for Responding to a Major Outage，作者 Joel McKelvey。
自 Crowdstrike 故障导致数百万系统瘫痪以来，无数文章都写了关于故障原因、影响以及公司在服务中断期间产生的成本。
几乎每家大型公司都有一些主机因 CrowdStrike Falcon 软件的错误更新而离线。我们 BigPanda 的客户也不例外。7 月 19 日，UTC 时间 04:00 到 07:00（EDT 时间 8-11 a.m.），我们的系统记录了共享事件的增加，峰值达到正常水平的 290%，表明我们的客户群中发生了重大事件。此次故障影响了全球 850 万台基于 Microsoft Windows 的主机。
面对 CrowdStrike 故障 的巨大规模，IT 团队不得不发挥创意，以加快响应和恢复时间。我们的客户与我们分享了他们的方法，包括警报关联、事件丰富、高容量票证管理以及事件后分析的重要性。
在错误更新期间，数千台主机离线。警报不仅来自受影响的系统，还来自相关系统，并且在线系统因此承受了额外的负载。这使得响应团队面临着警报噪音的洪流，以及在噪音中筛选出有关正在发生的事情的相关且可操作的信息的挑战。
之前部署了强大的警报关联的 IT 团队最适合将“主机未报告”和相关服务警报的洪流关联成更少、更清晰的事件。警报过滤和关联对于管理请求量、提供关键数据以及帮助团队有效地优先处理和解决问题至关重要。
响应 团队随后面临着识别哪些事件 与 CrowdStrike 更新相关，哪些事件无关的挑战。由于与故障相关的 事件数量，存在其他问题在混乱中被忽略的风险。
团队需要用重要信息丰富事件，例如自动生成的标题、事件摘要以及最重要的疑似根本原因。这使响应者能够立即识别哪些事件相关并适当地解决它们。重要的是，即使其他事件威胁到运营团队，与 CrowdStrike 无关的事件仍然可见且可操作。
一旦 确定了恢复受影响系统的步骤，您需要一个显示故障的主机汇总列表。这是通过结合基于丰富标签搜索事件和分析（例如监控影响概述、深入特定工具以及识别可操作的事件趋势）来实现的。
在故障期间，这对响应者来说至关重要，可以帮助他们恢复和重启服务器，并节省了确定最终影响范围的时间。
在这里，强大的关联也发挥了作用，显著减少了创建的票证数量，并消除了大量浪费的精力。那些使用集成工作流自动化从相关事件中自动创建票证的人拥有最佳体验，票证会及时路由到正确的团队（并创建包含正确上下文以加快修复的票证）。
该事件还充当了当前 IT 基础设施的压力测试，证明整个运营流程中的系统能够处理票证数量的巨大激增。在系统超负荷的情况下，团队正在故障后努力提高可扩展性和弹性。在面对故障时，使用事件中的发现重新评估您的关联模式，并以使下次故障更容易处理的方式改进它们。
对故障的常见反应是在故障后进行额外的见解和报告，例如关于平均修复时间 (MTTx) 和工具效率的报告。团队需要将来自不同工作流的数据整合到一个行业特定的仪表板中，简化识别差距、合理化工具和优化工作流的过程。
精明的客户继续使用这些工具来收集和定制所需的数据和报告，以评估停机事件的最终影响。
来自全球客户和 ITOps 团队的反馈突出了在管理此类大规模中断时做好准备和适应的重要性。这次停机事件促使许多人重新评估和增强其运营系统，以确保在未来中断事件中具有更高的可扩展性。我们需要优先考虑事件响应策略并实施强大的监控系统，以减轻未来重大类似 Crowdstrike 停机事件的影响。从这次经历中获得的集体知识将有助于在各行各业建立更强大、更具适应性的 IT 基础设施。