兹伊伊因！ 凌晨 3 点，你正在做美梦，突然接到电话。 你这周值班，显然发生了一些事情。 自动化系统会调用以找出问题所在。 这是管理现代计算机系统的一个重要方面，但让我们看看如何让通知更好地为人们服务。
熟悉我在不同监控团队的数十年职责中诞生的监控理念。 她很大程度上受到罗布·埃瓦什丘克（Rob Evashchuk）的真实圣经的影响 （我的通知哲学）包含在书中 ，以及约翰·阿尔斯波的书 （有关设置警报的注意事项）。
, и — 感谢您帮助编辑这篇文章。
什么是案例？
我决定想出一个漂亮的缩写，比如 или 。 我称之为 案例法。 他介绍了自动监控工作中需要注意的四点：
- （上下文绑定）
- （实用价值）
- （强调症状）
- （年级）
如果您使用 CASE，您会以健康的冷漠态度对待通知，并且不会在晚上吵醒人们。 应定期评估监测的有用性和有效性。 当一个人收到通知时，他们会有更好的思维模式和更多的信心。
为了更容易记住，想象一下你需要一个 CASE [即一个案例，一个理由 - 译者注] 来证明每个警报的合理性。 ：太阳镜：
而这一切又是为什么呢？
。 出于很多原因。 CASE 不会将它们全部消除。 但有了它，您将在晚上醒来时收到更好的通知。 该方法涵盖了对解决此问题也将有所帮助的各种组织流程。
RED 和 USE 方法的美妙之处在于，在它们的帮助下，我们不仅知道如何工作，而且彼此之间可以说相同的语言。 我希望 CASE 方法能够更轻松地讨论保护我们的系统但让我们的同事忙碌的通知。
关键是您需要在组织中创建一种文化，以健康的冷漠态度对待通知。 通知可以为特定目的而创建，但事实并非它们以后不会失去价值。 我们为什么要设置这个通知？ 其标准多久前修订过？ 有了CASE，这些问题都可以得到解答。
Context-Heavy - 上下文绑定
凌晨 3 点并不是阅读包含大量智能词汇的消息的最佳时间。 为了有效地做出反应，您需要信息。 理想情况下，这应该是有关特定问题的信息，其上下文立即清晰，并且应该配置通知以便实现这一点。 这就是“观察”和“定向” 。 花时间在这个设置上并不丢人，因为不断分散一个人的注意力甚至会更加昂贵。 让我们互相尊重吧。
问题有很多来源。 尤其是鬼。
我该如何帮助值班人员？ 值班人员首先看到的是一条通知，因此他根据通知建立了所有假设。 然后他查看说明和仪表板，但是否总是有特定通知的数据，而不仅仅是一般信息？ Alspaugh 建议“思考如何解释或回应通知”（幻灯片 29）。 好的通知应该集中在值班人员身上，而不仅仅是通过阈值配置。
因此，这里有一些关于如何改进通知上下文的想法：
- 向用户展示一些有用且专门创建的东西，而不仅仅是普通的说明或仪表板。 以前，我和这些人使用了为特定通知配置的调查仪表板。 如果问题已知，这会有所帮助，但只会让其他人感到困惑。 我们需要在这里找到一个平衡点。
- 请告诉我们该通知的历史记录：是新的吗？ 经常起作用吗？ 是季节性的吗？
- 显示系统状态的最近更改。 最近有什么变化吗？ （例如，部署或启用/禁用功能。）
- 显示关系并为心智模型提供信息：系统依赖性应该清晰可见，最好带有功能指示。
- 快速将用户与团队联系起来：他们能否看到正在发生的事件，或者他们能否找出公司中的其他人收到了通知？ 程序 活性？
理想情况下，事件管理计划将提供有关如何改进事件调查的通知上下文的建议。 总有一些事情需要努力！
可操作-实用价值
值班人员是否应该根据通知采取行动？ 如果你不需要做任何事或者不清楚该做什么，你为什么要叫醒他？ 您需要避免那些惹恼值班人员且不需要采取行动的通知。
我应该怎么办？ 你想要什么？
过去，当系统很简单、团队规模很小时，我们设置监控只是为了掌握最新情况。 如果服务随后出现故障，堆上的负载已增加的通知将为我们提供上下文。 从大规模来看，此类通知只会造成混乱，因为我们的系统始终在不同严重程度的降级状态下运行。 这很快导致 当然，还会失去敏感性。 因此，值班人员会忽略甚至过滤此类通知，并且并不总是根据需要做出回应。 不要落入这个陷阱！ 不要连续设置所有通知，然后通过电子邮件将它们发送到某个被遗弃的文件夹。
具有实用价值的通知如下所示：
- 通知需要采取行动，而不仅仅是报告新闻。
- 此操作很难实现自动化，或者存在风险。 如果一个动作可以自动化，那就自动化它，别再纠缠人了！
- 该通知包含以下形式的紧急建议 （SLA）或 （RTO）。 然后值班人员可以激活组织的事件管理程序。
我想澄清一下：我并不是说通知应该只针对 API 最重要的 SLO（服务级别目标）。 SLO 监控不断分散和划分，并且需要对所有服务采用相同的方法。 很明显，您将跟踪向您付款的客户最重要的 SLO。 但基础设施 SLO（例如数据库）也需要进行监控。 很快您将不得不与内部客户打交道并为他们提供支持。 如此下去，无止境。
基于症状——强调症状
无论你喜欢与否，你都在分布式系统中工作（Kavaj）。 因此，您可以使用不同的策略来隔离服务并防止它们出现故障（Trainor 等人）3。 尽管延迟的垃圾收集或停滞的数据库查询表明存在问题，但如果用户在不久的将来没有出现问题，则无需急于修复它们。
这些是重要的信号并且可能具有实用价值，但是如果它们不打扰用户，那么就不足以分散服务员的注意力。 基于原因的通知是我们关于系统故障的心理模型的快照。 跟踪重要的症状比尝试列出故障的所有可能原因更好。
为了使通知有意义，请关注 ，对用户很重要。 Evashchuk 称之为“对用户的监控”。 请记住，这一理念必须应用于整个组织。 如果某项服务在基础设施深处出现紧急问题，适当的团队将会处理这些问题。 保护系统免受此类故障的影响是完全不同的事情（Trainer 等人，有关最小化关键依赖性的策略的部分）.
症状并不多变
理查德·库克提醒我们，复杂的系统充满缺陷、缺点和问题。 试图列出所有可能的原因是一项西西弗斯式的任务。 你试图描述问题，但它们一直在变化。 Cindy Sridharan 认为“系统不必每秒都处于完美状态”，最好使用更人性化的方法（ （“监控分布式系统”），7）.
避免在事件发生后收到通知
通常，原因通知被配置为纠正事件。 这些关于所发生事件事实的有限通知会产生一种错误的安全感，因为系统每次都会想出新的破解方法。
不要被原因通知所愚弄。 最好这样想：
- 为什么基于症状的通知没有注意到问题？
- 改善用户的环境会有帮助吗？
- 如何改进监控工具以更快地做出诊断，而不是累积有关所发生事件的通知？
仅当您将诊断监控工具视为从症状转向解决方案的一种方式时，它们才会有所帮助。 如果没有这种反馈，您只会收到有关过去失败的最新通知和图表的轰炸，而不会收到有关未来失败的任何信息。 对于组织来说，这是从防御转向攻击的绝佳机会。 并且开发人员和产品经理会有相同的期望和明确的目标。 每个通知的情况 - CASE (:wink:) - 都很清楚。
基于原因的通知是可以容忍的
有时，我们的系统在基于原因的通知方面让我们别无选择。 有时值班人员很清楚，一个症状肯定会导致失败，因此具有实用价值。 也许您只是不确定发生了什么，因此为了安全起见而设置了通知。 希望此操作是暂时的，直到我们可以更改系统以解决性能问题为止。
处理这些情况时，请记住 CASE 的其他组成部分。 仅仅因为它是暂时的并不意味着你可以停止用头脑思考。
已评估-评估
对系统的任何更改（新代码、新基础设施、任何新事物）都会扩大故障范围（库克，3）。 此通知是否仍按预期工作？ 清晰且当前的系统心理模型以及响应某些支持通知的经验 - 这些是主要特征 。 系统中的缺陷在不断演变，我们必须跟上它们。
您需要不断评估每个通知的质量，以确保它们按预期工作。 尊敬的各位领导！ 如果您帮助您的团队建立此流程，那么对他们来说会更容易！ 以下是一些评估想法：
- 使用 , 或其他通知测试方法。 团队可以自己完成，无需依赖繁重的事件管理系统！
- 将所有与事件相关的通知的集合合并到您的事件管理计划中。 标记有用、有害、不适当、不清楚等。将它们用作反馈。
- 正确的通知很少被触发，并且经过仔细测试。 确保所有链接都有效，指向正确的上下文等。
- 如果通知从不触发或触发过于频繁，则说明存在问题。 修复它或删除它。 谨防过度被动或主动！
- 设置带有到期日期的通知时间戳。 如果过期日期已过期，请使用 CASE 方法评估通知并更新时间戳。 就像食物一样，定期检查保质期。
- 简化改进通知的过程。 使用监控作为代码并将通知存储在 Git 存储库中。 拉取请求有助于吸引团队并为您提供过去通知的历史记录。 您将不再害怕更改通知或征求负责人的许可。
- 设置通知反馈，即使很简单 ，以便值班人员将通知标记为无用或侵入性。 将链接或号召性用语嵌入到通知本身中，并定期查看您的反馈。
- 在团队里制定一条规则——工作少的时候就让值班的人干，简化值班。 愿你之后的一切都比之前好一点。
结论
我相信 CASE 方法可以帮助开发人员和组织讨论设置和发送自动通知。 一名开发人员可以开始使用 CASE 方法评估通知，然后整个组织将与其他开发人员、管理层和事件管理程序一起加入，以保持通知处于良好状态。 这不需要任何特殊工具或复杂的过程。
整个行业需要在值班时考虑人为因素，同时又不牺牲一流的客户服务。 所有这些工具和实践都可以而且应该得到改进。 我希望 CASE 方法能对此有所帮助。
享受改进的通知！
来源： habr.com