天哪！ 凌晨3点，您看到了一个奇妙的梦，突然间，钟声响了。 这个星期你值班，显然发生了什么事。 一个自动化系统正在呼吁找出问题所在。 这是管理现代计算机系统的重要点，但让我们看看如何使人们更方便地进行通知。
熟悉几十年来我在各种监视团队中担任的职责所产生的监视哲学。 它在很大程度上受到了Rob Sevashchuk的“ 我的预警哲学” （包括Google SRE书中的内容）和John Alspo的《 Alertations for Alert Design》一书的影响。
Kelly Dunn ， Aridzhit Mukheryi和Maxim Petazzoni-感谢您在编辑帖子时的帮助。
什么是案例？
我决定提出一个漂亮的首字母缩写词，例如Brendan Gregg的USE 方法或Tom Wilkie的RED方法 。 我将此称为CASE方法 。 他介绍了使用自动监视时需要注意的四点：
如果您使用CASE，则会以无动于衷的态度对待通知，并且不要在晚上唤醒人们。 应该定期评估监测的效用和有效性。 当一个人收到通知时，他将有更好的心理模型和更多的自信。
为了更容易记住，假设您需要一个CASE（也就是说，一个案例，原因是解释者的注释 ）来证明每个警报的合理性。 太阳镜
那为什么是全部呢？
责任可能是一种折磨 。 由于许多原因。 而且，CASE不会消除所有问题。 但是到了晚上，您会从更好的通知中醒来。 此方法涵盖了各种组织过程，这些过程也将对此有所帮助。
RED和USE方法的优点在于，在它们的帮助下，我们不仅知道如何工作，而且彼此之间也使用相同的语言。 我希望使用CASE方法可以更轻松地讨论保护我们的系统的通知，但不要给同事们带来麻烦。
最重要的是，您需要在组织中创建一种文化，在这种文化中，对待通知的态度会保持冷漠。 在这种情况下，可能会创建通知，但事实并非如此，它们以后不会失去价值。 我们为什么设置此通知？ 它的标准是否已在很久以前修订过？ 使用CASE，可以回答这些问题。
重上下文-上下文绑定
凌晨3点不是阅读包含大量流行词的消息的最佳时间。 为了有效响应，您需要信息。 理想情况下，这应该是有关特定问题的信息，可以立即清除其上下文，并且您需要配置通知，以便有可能。 这些是来自NORD循环的 “观察”和“方向”。 花时间在此设置上不是很可惜，因为不断分散人们的注意力更加昂贵。 让我们互相尊重。
问题有很多根源。 特别是鬼。
如何帮助服务员？ 值班人员首先看到通知，因此他根据通知建立所有假设。 然后，他查看说明和仪表板，但是是否始终有特定通知上的信息，而不仅仅是一般信息？ Alspo建议“考虑如何解释通知或对其进行响应”（幻灯片29） 1 。 良好的通知将重点放在话务员上，而不仅仅是在阈值上进行配置。
因此，以下是改善通知上下文的想法：
- 向用户展示一些有用且专门创建的内容，而不仅仅是普通说明或仪表板。 以前，我和他们使用仪表板进行调查，并针对特定的通知进行配置。 如果已知问题，这将有所帮助，并且只会在其他情况下造成混淆。 在这里，您需要找到一个平衡点。
- 告诉我们有关通知的历史记录：是新的吗？ 它经常起作用吗？ 是季节性的吗？
- 显示系统状态的最新更改。 最近有什么变化吗？ （例如，部署或启用/禁用功能。）
- 显示这种关系并提供有关心智模型的信息：系统的依存关系应该清晰可见，最好带有可操作性的指示。
- 快速将用户与团队联系起来：他看到了当前事件吗？还是可以找出公司中还有谁收到了通知？ 事件管理程序是否已激活？
理想情况下，事件管理程序提供有关在调查事件时如何改善通知上下文的提示。 总有事情要做！
可行-实用价值
服务员应该响应通知吗？ 如果什么也不需要做或者不清楚要做什么，为什么要唤醒您？ 有必要避免通知值班并且不需要采取行动。
怎么办 你需要什么
以前，当系统简单且团队规模较小时，我们将监视设置为始终保持最新状态。 如果服务随后发生故障，则通知堆上的负载会增加，这将为我们提供上下文。 在很大程度上，这样的通知只会造成混乱，因为我们的系统始终在严重程度不同的降级状态下工作。 这很快会导致通知引起疲劳 ，当然还会导致敏感性下降。 因此，服务员会忽略甚至过滤此类通知，并且不会始终根据需要对其进行响应。 不要落入这个陷阱！ 不要连续配置所有通知，因此以后可以通过邮件将其发送到某个Godforsaken文件夹。
具有实际价值的通知如下所示：
- 通知需要采取行动，而不仅仅是报告新闻。
- 此操作很难自动化或有风险。 如果该动作可以自动化，则采取行动并使其自动化，停止缠扰他人！
- 该通知包含服务级别协议 （SLA）或目标恢复时间 （RTO）形式的紧急建议。 然后，服务员可以使用组织中的事件管理程序。
我想澄清一下：我并不是说通知应该仅针对API的最重要的SLO（服务级别目标，服务级别目标）发出。 SLO监控始终是零碎的，并且需要对所有服务使用相同的方法。 很显然，您将跟踪付款给您的客户最重要的SLO。 但是，还需要监视SLO基础结构，例如数据库。 很快，您将不得不与内部客户打交道并提供支持。 等等广告无限。
基于症状-关注症状
无论您是否喜欢，都可以在分布式系统（Kavaj） 2中工作 。 结果，您使用不同的策略来隔离服务并保护它们免受故障影响（Trainor等）3。 而且，尽管长时间进行垃圾收集或对数据库进行周到的查询表明存在问题，但是如果用户在不久的将来没有问题，也无需急于修复它们。
这些是重要的信号，它们可能具有实用价值，但是，如果它们不干扰用户，则不必急于分散服务员的注意力。 基于原因的通知是我们关于系统故障的心理模型的快照。 跟踪重要症状比尝试列出所有可能的故障原因要好。
为了使通知具有实用价值，请关注对用户很重要的性能指标 。 Evashchuk将此称为“用户监视”。 请记住，这种理念需要在整个组织中应用。 如果服务在基础结构中的某个地方存在紧急问题，则适当的团队将处理这些问题。 保护系统免受此类故障是一个完全独立的问题（Trainer等人，关于使关键依赖性最小化的策略的一节） 3 。
症状不那么不稳定
理查德·库克回忆说，在复杂的系统中，存在许多缺陷，缺点和问题4 。 试图列出所有可能的原因-西西弗劳。 您尝试描述问题，并且问题一直在变化。 Cindy Sridharan认为“系统不必每秒都处于完美状态”，最好使用更人性化的方法（ “ Distributed Systems Observability” ，7） 5 。
避免事件通知
通常，将原因通知配置为更正事件。 这些关于发生的事实的有限通知会产生一种虚假的信心，因为每次系统提出新的破解方法时，都会产生错误的信心。
不要被原因通知所迷惑。 想得更好：
- 为什么基于症状的通知没有注意到问题？
- 改善用户环境是否有用？
- 如何改进监视工具以便更快地诊断并且不累积有关发生的情况的通知？
诊断监视工具仅在将其作为从症状转变为解决方案的方式时才有用。 没有这些反馈，您只会被关于过去失败的迟来的通知和图表所淹没，而对未来的失败一言不发。 对于组织而言，这是从防御到进攻的绝佳机会。 开发人员和产品经理将拥有相同的期望和明确的目标。 案例-CASE（：wink :)-每个通知都清楚。
基于中等容忍度的通知
有时，根据原因，我们的系统几乎在通知方面无可奈何。 有时服务员会很清楚症状可能会导致故障，这意味着它具有实用价值。 也许您只是不确定发生了什么，并且正在设置有关再保险的通知。 希望在更改系统以解决性能下降问题之前暂时需要执行此操作。
处理此类情况时，请注意其他CASE组件。 如果这是暂时的，则并不意味着您无法用头脑思考。
评估-评分
系统中的任何更改（新代码，新基础架构，任何新内容）都会扩大故障范围（Cook，3）。 4此通知是否仍按预期运行？ 清晰，相关的心理系统模型和对某些通知的反应经验，以支持预防方法 ，是学习型组织的关键特征。 系统中的缺陷在不断发展，我们必须跟上它们。
您需要不断评估每个通知的质量，以便它们按预期工作。 尊敬的领导人！ 如果您帮助他们设置此过程，对您的团队将更加容易！ 以下是一些评估思路：
- 使用混乱的工程 ， 游戏日或其他通知测试方法。 团队无需使用重量级的事件管理系统即可自行完成此操作！
- 在事件管理程序中包括所有事件通知的数据收集。 标记有用，有害，不合适，难以理解等。将其用作反馈。
- 正确的通知很少，并且要仔细检查。 确保所有链接正常工作，指向正确的上下文，依此类推。
- 如果通知从不触发或触发得太频繁，则说明有问题。 修理或取出它。 当心过度的被动或活动！
- 设置通知的过期时间戳。 如果到期日期已过，请使用CASE方法评估通知并更新时间戳。 定期检查保质期，如带食物。
- 简化改进通知的过程。 使用代码形式的监视并将通知存储在Git存储库中。 池请求有助于吸引团队，您将拥有过去通知的历史记录。 您将不再害怕更改通知或征求那些负责人的许可。
- 设置反馈通知（即使只是Google表单） ，以使值班人员将通知标记为无用或侵入式。 在通知本身中嵌入链接或号召性用语，并定期检查反馈。
- 在团队中设定规则-让服务员工作以简化工作量少的工作。 让您之后的一切都比以前更好。
结论
我相信CASE方法可以帮助开发人员和组织讨论设置和发送自动通知的过程。 一个开发人员可以开始使用CASE方法评估通知，然后整个组织将与其他开发人员，管理和事件管理程序一起加入该通知程序，以使通知保持良好状态。 为此，不需要特殊的工具或复杂的过程。
整个行业应在值班时考虑人为因素，而又不损害一流的客户服务。 所有这些工具和实践都可以而且应该加以改进。 我希望CASE方法可以对此有所帮助。
享受增强的通知！
