我的妻子很友好地回顾了我正在写的一篇关于事件响应的文章，并提出了一个相关的话题，我无法融入那篇文章，但非常吸引人：公司应该如何应对一小群变得挑剔的工程师几乎所有事件的响应者？
这发生在许多公司，通常是这样的：一些长期任职的工程师，他们恰好拥有所有关键系统的显式访问凭据和使用它们的隐式权限，帮助响应几乎所有事件。随着时间的推移，这些人的负担越来越重，因为很少有人获得知识并访问凭证，以便在他们不可用时做出响应。快进到未来，这些关键响应者之一离开公司，这给其余关键响应者带来了更多负担。越来越多的人离开，最终公司迎来了一个痛苦的时代，需要重新学习如何有效地应对事件。
经常看到这种情况发生，在大多数情况下，您可以通过以下方式解决此问题：
- 您通常可以立即识别担任此角色的个人，而无需进行任何扩展分析
- 当他们没有明确待命时，要求频繁响应者的响应较少。他们仍然可以观看，但至少要等待十到二十分钟才能做出响应，只要事件不会对用户造成太严重的影响
- 要求待命人员在升级到关键响应者时进行更多研究
- 作为关键响应者参与的事件响应的一部分，要求他们记录他们如何响应并使用该文档训练更广泛的待命轮换
- 对于在几次培训课程后文档无法弥补差距的任何工具或系统，优先设计可以以更简单的方式缓解的东西
- 这种行为会传播开来，特别是对于一部分新员工，他们会复制这种行为（出现在每个事件中），而关键响应者并不知道他们在响应时是否有价值。这些人在他们的模拟尝试中制造了很多噪音，你应该立即给他们反馈。如果你不这样做，很难在这个问题上取得进展
- 促进和奖励那些在没有他们在场的情况下成功进行随叫随到轮换的高级人员。停止奖励必须亲自出现以领导事件响应的高级人员
- 教育公司内的其他领导者，以同样奖励那些建立有弹性的待命轮换而不是英雄主义的人
十有八九，应该能解决问题。
有时你会遇到与其他领导者价值观不一致的情况，在这种情况下，进展将是缓慢而痛苦的。非常简单但非常痛苦的方法是等到几个关键响应者退出，这将证明你的观点。更困难但不那么痛苦的路径是构建数据来支持您的案例。例如，自动记录谁在哪些事件中处于活动状态（例如，在 Slack/Teams/其他中记录事件响应渠道），将其与用户影响/平均缓解时间等相关联，并建立一个过度依赖让你当它们不存在时，效率会降低，例如，这种方法会产生无法补偿的公司风险。它很慢，但数据总会教给你一些有趣的东西，尽管它很少会教给你你最初预期的东西。0