有方法可以衡量系统的功能

rmamin

如果您遇到故障可能导致数据更改或类似情况的情况，我通常会谨慎行事并保持手动状态，因为如果我有一个自动化脚本，如果我发现一些包含三个的合流文档几年前说运行这个脚本，我倾向于对该脚本有百分百的信心并执行它。正确的。然而，如果这是四年前记录的一系列手动步骤，我会说，我需要在这里进行一些验证。正确的？让我简单介绍一下这个过程并与一些人交谈。有时，当我们设计流程时，强制这种思维过程是值得的，对吧？你必须考虑人类的组成部分以及他们将如何表现。有时值得让这个过程变得更麻烦一点，迫使人们思考我现在应该这样做吗？

德鲁：是否有其他方法可以通过监控系统和测量事物来确定哪些 电报号码数据 内容应该自动化？我的意思是，我认为 DevOps 和仪表板是其中之一，漂亮的图表。我确信这些仪表板不仅仅是看起来漂亮，但拥有漂亮的仪表板总是好的。是否以帮助您做出此类决策？

杰夫：绝对地。这就涉及到摄像头的指标部分，对吧，我们在系统中跟踪哪些内容以了解它们是否高效运行？指标的常见陷阱之一是我们寻找错误而不是验证成功。这是两种截然不同的做法，对吧？因此，某些东西可以流经系统，不一定会出错，但不一定会按照应有的方式完成整个过程。因此，如果我们将一条消息放入消息队列中，应该有一个相应的指标，表示“该消息已被检索并处理”，对吗？如果不是，那么你很快就会出现不平衡，系统将无法按其应有的方式运行。我认为我们可以使用指标来理解不同的事情，当我们进入这些糟糕的状态时，这些事情应该自动化。



杰夫正确的因为很多时候这是一个非常简单的步骤，需要采取清理工作，对吗？对于已经操作了一段时间的人来说，磁盘空间警报，每个人都知道。哦，我们已经装满了光盘。哦，我们忘记了现在是月底，计费运行并且计费总是填满日志。然后 VAR 日志会消耗所有磁盘空间，因此我们需要运行日志轮转。正确的？如果你愿意的话，你可以在凌晨三点醒来。但如果我们知道这就是行为，我们的指标应该能够为我们提供线索。我们可以简单地自动化日志旋转命令，对吧？哦，我们已经达到了这个阈值，执行日志旋转命令。让我们看看警报是否清除。如果是的话，继续生活。如果没有，那么也许我们会叫醒某人，对吧。

杰夫：您在基础设施自动化中也会看到更多这种情况，对吧，就像，“嘿，我们每秒的请求是否达到了理论最大值。也许我们需要扩展集群。也许我们需要向负载均衡器池添加三个或四个节点。” 我们可以做到这一点，而不需要有人干预。我们可以只查看这些指标并采取该行动，然后在基础设施低于特定阈值时收缩该基础设施，但您必须拥有这些指标，并且必须将这些挂钩纳入您的监控环境才能做到这一点。这就是对话的整个指标部分的用武之地。