警报引起的辛劳

对于所有DevOps团队而言，辛苦的工作是一件令人担忧的事情。 辛劳产生的原因很多。 这使它成为一个非常棘手的问题，几乎不可能完全消除。 因此，团队必须解决的最佳策略是尽可能地减少他们。 在这篇文章中，我们讨论了由于不良的警报和传呼习惯而导致的辛劳管理的一些基础知识。

辛劳源于工程师在执行通常可以自动化或避免的任务上花费的精力。 一般而言，在一段时间内觉得不必要的工程任务会造成最大的负担。 Google SRE本书将Toil定义为可以“手​​动，重复，可自动化，战术，没有持久价值并且随着服务的增长呈线性扩展”的任务。

让我们看一个例子，说明不良的警报实践如何为采用DevOps实践的团队带来辛劳。

假设您正在使用AWS在生产上运行Web应用程序。 您具有标准设置。 还有一个确定何时应扩展或扩展Auto Scaling组的扩展策略。但是，如果未正确设置扩展策略怎么办？ 如果选择了错误的阈值怎么办？ 这就是为您的团队发挥作用的方式……

• 您的主机将发出有关CPU /内存耗尽的警报。
• 越来越多的5xx响应将触发Cloudwatch的警报
• Pingdom检查将开始报告加载时间增加或响应失败，并向您发送警报
• 应用程序日志将开始记录更多错误。 任何日志监视都将基于此开始发出警报。
• 增加的日志也可能触发磁盘I / O警报。

可能会触发许多其他警报。 尽管所有这些都代表问题，但这里的根本问题是糟糕的扩展策略。

并非总能获得根本原因的警报。 但是，这并不是让工程师不知所措的借口。 这种情况也说明了上下文切换，警报设置成本以及响应和诊断成本如何快速增加。 警报所依据的信号不佳是此问题的核心。

这是我们在构建Plumbr时要解决的问题之一。 Plumbr在应用程序监视和实际用户监视的交叉点工作。 因为Plumbr基于从实际使用中收集的数据，所以它最准确地反映了用户与Web应用程序交互时的体验。

需要更好地将重要警报与出现的嘈杂警报区分开。 因此，警报信号的重要来源是使用来自应用程序实际使用的数据。 实际的用户监视将重点放在用户和使用上，而不是系统级行为上。 这形成了更客观的警报基础。 没有人可以否认，如果用户受到的影响超出一定水平，工程师必须记下笔记并开始调查修补程序。 根本原因是数据库问题，CPU配置，PaaS上的扩展策略还是第三方基础结构故障–如果用户受到不利影响，则可以合理地提醒工程师。

您的团队还可以使用真实的用户监视数据为警报和传呼提供更好的基础。 立即开始免费的Plumbr试用 。 免费享受我们为期14天的完整功能集。

PS：不可能在一个文档中解释有关劳动的所有内容。 但是，我们关心工程师能够专注于重要的事情。 我们已经 发布了一份白皮书，该白皮书 更深入地讨论了劳动问题。 对于更多的视觉学习者，我们还在此 点播网络研讨会上 发布了此信息 。 干杯!

翻译自: https://www.javacodegeeks.com/2019/08/toil-arising-alerting.html