事件响应：“接下来的 16 分钟将变得更加激烈”

当他的电话在凌晨 2 点叫醒他时，运营工程师安迪·皮尔森 (Andy Pearson) 知道这是个坏消息。有一个主要的服务器问题，数百个客户端网站已关闭。自动监控检查在几秒钟内检测到中断，并呼叫值班工程师。这一次，皮尔逊坐在热门位置上。 Pearson 很快确认了这个问题的真实性，并将其上报给他的老板、技术主管 Lewis Carey。在五分钟内，凯里评估了情况并宣布了重大事件。经过精心排练的程序开始生效。电话会议开始；当凯里为每个人分配角色时，失眠的事件响应团队聚集在一起。凯里是事件指挥官，全面负责整个过程。关键是要有一个负责人。停机不是民主。你需要一个决策者。通常，这将是团队负责人，但随着时间的推移，您应该确保让每个人都坐在那把椅子上。总有一天，团队负责人不会在身边，任何人都应该有能力并有足够的信心来处理事件。 Pearson 是驱动程序，操作键盘并与团队共享他的屏幕。开发人员 Juan Kennaugh 是通讯员，负责向受影响的客户、项目经理和管理层提供状态更新。团队中的一个关键角色是记录，他记录发生的一切，做详细的笔记，捕获屏幕截图和日志条目以供以后分析，记录团队讨论的内容、他们尝试过的事情、结果和他们做出的决定。所有这些原始数据稍后将进行详细的事后审查，但就目前而言，事情发展得如此之快，以至于指定的记录管理员埃利奥特·埃文斯 (Elliott Evans) 正在努力记录它们。同时，系统专家 Rich Rawlings 被分配到研究员角色。当故障排除过程中出现问题时，罗林斯一直忙于寻找答案。该团队做的第一件事是运行由 Rawlings 创建的内部快照工具，该工具从出现故障的机器中捕获所有关键日志文件和状态信息。 “如果服务器完全脱机，我们现在需要保存所有内容，”Rawlings 解释说。 “这就像飞机的黑匣子记录器。当我们分析这些数据时，我们可能会找到关于问题所在的重要线索。”

这就像电影“阿波罗13号”。我们不想通过猜测使事情变得更糟。相反，我们一步一步地解决问题。团队查看结果并开始逐项检查故障排除清单。 “现在我们只是确定问题出在哪里，”凯里说。 “它是否在我们的领域——服务器、配置、代码？或者是第三方中断——网络、云托管、DNS？”看起来问题似乎与网络有关。即使在 Pearson 输入控制台窗口时，文本也会断断续续地出现，似乎挂了几秒钟然后又赶上了。该团队特意多花几分钟时间来验证对网络问题的怀疑。 “这就像电影‘阿波罗 13’”，凯里解释说。 “我们不想通过猜测使事情变得更糟。相反，我们一步一步地解决问题。”在像影响数百个客户的中断这样的高压情况下，人们很容易采取行动。但错误的行动可能比根本不采取行动更糟糕。 “我们不想做的是跳枪并做一些我们无法从中恢复的事情。例如，如果这是一起安全事件，那么从技术上讲，该服务器可能是犯罪现场。”在凯里的领导下，该团队以法医的精确度行动。 “好的，我们有 95% 的把握确定这是网络，”凯里对团队说道。 “我建议我们与 ISP 建立一个支持案例来解决这个问题，同时，让我们为新服务器启动自动构建，这样我们就可以将所有失败的站点迁移到它。对此大家都满意吗？”做出决定后，团队迅速行动。通讯主管肯诺向公司管理层通报进展情况，并就决议的最新预计到达时间向社交媒体和支持团队发出警报。 “我们的目标是在 15 分钟内恢复一切，不管怎样。如果 ISP 能够在那个时候修复网络，那太好了，但我们不会坐等他们：我们已经在构建替代服务器，”肯诺说。与此同时，Evans 正在联系 ISP 的支持部门，Pearson 正在启动一个新的云服务器，Rawlings 正在检查迁移网站的文档和程序，准备好一切运行，以免浪费一秒钟。 “您无法完全消除停机时间，”Pearson 说，“但您可以做的是尽快排除故障和解决问题。您可以自动化所有可以自动化的部分，对于不能自动化的部分，您可以构建一个程序，从而消除过程中的猜测。”该团队定期对这些程序进行演练，以便在警报解除时，每个人都知道该做什么以及何时该做什么。八分钟之内——正好在团队自行设定的最后期限内——团队监控仪表板上的灯开始变绿。站点正在一个接一个地自动迁移到新服务器，并恢复生机。 “我们运营的数百个站点中的每一个站点都有一个自动生成的监控检查，”凯里解释说。 “每一次检查都会逐分钟验证站点是否已启动、DNS 是否正确、SSL 证书是否有效、客户端是否可以登录，如果其中任何一项停止工作，我们会在几秒钟内收到警报。”

自动监控还记录所有站点的性能和正常运行时间，并将其报告给客户，以及公司 SRE 不断审查的汇总数据，以检查基础设施是否一切正常。随着最后一个红灯变回绿灯，凯莉开始结束这起事件。 “好吧，Comms，你能不能让大家知道我们已经备份了？记录，你都保存了吗？司机，研究人员，我们是否已经捕获了所有事后行动以备后用？伟大的。干得好，大家。事件在… 2.16 结束。回去睡觉，明早见。”但这不是回去睡觉的时间。事实上，现在是下午。并且没有停机时间；没有客户站点出现故障，即使是片刻。对于领先的英国数字机构 ThirtyThree 的技术团队来说，这只是另一种练习。 “我们称之为'比赛日'，”凯里解释说。 “这基本上是一个事件管理演习，但我们做的一切都与真实情况完全一样。监控是真实的，警报是真实的，行动是真实的。只有问题是假的。” “压力很大，”Pearson 事后评论道。 “每个人都在看着你，有很多噪音和混乱，十几件事同时发生……非常简单的事情突然变成了挑战。这就是为什么我们一直在练习；所以它变成了第二天性。”在事件管理的热潮中，数百名客户和潜在的数百万收入处于危险之中，所有注意力都集中在他们身上，凯里训练有素的团队没有错过任何一个节拍。每个开发人员轮流加入红队，设计和执行一个真实的中断场景，直到事件结束后才向其他人透露。 “你永远不知道会发生什么，”埃文斯说。 “上周，这是一个堵塞的数据库。还有一次是 DNS 中毒攻击。我们必须为任何事情做好准备。”该团队甚至处理了一个全面的安全事件，其中模拟恶意软件被上传到一个特别隔离的服务器。在这个练习中，由 Rawlings 扮演的“红队”模拟了一个网络问题，故意将额外的延迟注入服务器的网络堆栈。由于数据包被随机丢弃或超时，它会破坏与机器的连接，触发自动站点监控以发出警报，并开始模拟事件。

“比赛日练习非常有价值，”凯里解释说。 “首先，它将每个人聚集在一起。当你经历过与某人发生重大事件的火灾时，你会对他们产生新的尊重。其次，我们每次这样做都在学习新事物。之后我们会进行详细的汇报，其中我们会查看哪些有效，哪些无效，以及下次我们可以做得更好。”通常，团队会吸取经验教训，这有助于防止真正的停机时间。 “比赛日练习是在安全环境中测试您的系统和程序的一种方式。这就像测试到破坏，只有没有破坏。你可以搞砸，没有人会死。但是当你搞砸了，你可以弄清楚你做错了什么，下次做得更好。哦，程序说转储数据库，但如果你这样做，它实际上崩溃了？伟大的。我们可以修复程序，或者想出另一种方法来转储数据库。好在我们在真实事件发生之前就发现了这一点。”模拟停机时间可节省实际停机时间。 “弄清楚比赛日的场景本身就很有用，”皮尔森指出。 “我们看着系统说，好吧，如果它坏了会怎样？我们能做些什么呢？有时答案是，事实证明我们真的无法在事件期间足够快地解决这个问题。因此，相反，我们提前进行了一些工程设计以确保它不会发生，或者设计一个程序来获得更快的解决方案。我们现在运行的每个比赛日都可以防止未来发生十多起真实事件。”比赛日让 ThirtyThree 在拥挤的市场中获得了真正的优势。 “这不仅仅是技术方面的问题，”凯里说。 “如果没有合适的人来运行，尖端的基础设施是没有用的。我们不断训练自己作为一个团队一起工作，独立思考，领导，做出决定，并在压力下进行良好的沟通。比赛日是其中的重要组成部分。”您的系统越可靠，真实事件发生的频率就越低，因此您越需要练习它们。 “有时几个月过去了都不会出现严重的问题，所以当它们真的发生时，没有人记得该怎么做。” “自动化是一件了不起的事情，但自动化程度越高，您就越不需要了解系统的工作原理，包括细节。”航空公司飞行员知道这一点，即使现代飞机基本上可以自己飞行，飞行员仍然会定期手动着陆和起飞，并在模拟器中练习应急程序。这是让您的技能保持敏锐并保持最新知识的最佳方式。第一次保持简短。为您将要做的事情制定一个基本计划：这是您的事件处理程序的初稿。如果您已经有了这样的程序，这可能是您第一次真正以团队的形式运行它。

随着团队的练习越来越多，将角色分配给其他成员，例如通讯员、司机和研究员。对于长时间的事件，您需要每隔一两个小时轮换这些角色，以便人们可以休息一下，并且您可以获得一双新的眼睛。但是对于您的第一次事件，一个小时就足够了。事实上，计划让团队休息一天。第二天早上做汇报，那时肾上腺素已经消耗殆尽，每个人都有时间反思。除非您参与其中，否则很难传达事件的压力有多大，即使是游戏日模拟也会给每个人带来真正的压力。在某些方面，这就是比赛日练习的真正价值。 “一旦你完成了几天的比赛，一切就会容易得多，”凯里说。 “任何球队在危机中最不需要的就是额外的压力。我们事先消除了所有压力，所以当真正的事件发生时，我们可以冷静地专注于做我们需要做的事情。”如果您还没有与您的团队进行定期的事件管理练习，也许是时候开始了。或者下次你的电话在凌晨 2 点响起时，它可能是真的。