微信公众号也要实现监控的框架

你有多少次在事后分析会议上发现，其实你的监控系统早就标识出了潜在的可扩展性和可用性问题发生的迹象？也许监控系统触发了数据库上的空间报警，但没有得到响应，也许是几个服务的CPU使用率都超出阈值了。也许你启用了监控系统中对响应时间的监控功能，而且在过去几个月中可以看到调用某个特定服务的时间在缓慢增加。你也许会问自己，“怎么这些居然都没有得到注意”？

XX 您有多少次在事后分析会议上发现您的监控系统长期以来已经发现潜在的可扩展性和可用性问题的迹象？也许监控系统在数据库上触发了空间警报，但没有得到响应，可能是多个服务的CPU使用率超过了阈值。也许您已启用监控系统中响应时间的监控，并且在过去几个月中您可以看到调用特定服务的时间正在缓慢增加。你可能会问自己，“你为什么不被人注意？”也许您甚至告诉您的团队您的疑虑，但答案可能是监控系统在系统中提供了太多错误消息或噪音。太多了。也许运营团队的负责人也可能会说他已经申请了几个月，希望有资金来取代现有的监控系统，或者有时间和灵活性来重新实施当前的系统。他可能会说，“如果我们能够摆脱一些噪音，那么我的团队将会更好地睡觉并解决我们面临的真正问题。”我们听到了无数的理由要求建立新的和更好的监控系统，尽管有时它们是合理的，但我们相信它们的结果通常会损害股东的价值。真正的问题通常是监控系统不能满足公司的需求，但监控方法是错误的。运营团队可能已经确认需要监控，但这通常是错误的。虽然有必要解决“为什么我们没有及早找到它”的问题，但我们必须采用这种能够监控的架构设计原则，但这还不足以解决我们所有的监控问题或所有监控需求。我们需要规划我们的监测计划，并随着时间的推移而改进。在开发软件的部分之前，敏捷的软件开发方法不知道所有要求。要解决这个问题，我们必须有一个敏捷和渐进的发展理念，这同样适用于我们的监控平台和系统。我们提出的渐进方法可以回答三个问题，即故障列表和问题描述。 在我们提出的监测计划的渐进模型中，我们要问的第一个问题是“有问题吗？”具体来说，我们感兴趣的是确定系统是否表现不正确。通常我们真正想问的是客户是否会遇到或将遇到的问题。根据我们的经验，许多公司将完全绕过这个非常重要的问题，迫不及待地投资于下一期的“无人探索”，“哪里有问题”或更糟，“什么问题”。在监控过程中，绕过软件自定义

“有问题吗？”或者更合适的“客户体验是什么”假设您知道什么系统会导致问题。但不幸的是，情况并非总是如此。事实上，我们的许多客户浪费了大量人力来找到问题的根本原因，但还没有真正理解问题所在。你必须去过这样的课程，它们只是一种分析问题或解决问题的方法 - 大脑和星星。但重点是，在您真正了解您要解决的问题之前，不要尝试解决问题或进行任何分析。这也适用于会议。人们通常需要一个主题和目标，或者产品营销试图找出市场需求的问题。我们必须知道存在问题和表现。它看起来像什么。在我们提供产品或服务之前，我们必须首先确认目标人群。监控系统和应用程序也是如此。如果你想要一个不回答第一个问题的系统，“有问题吗？”，这会导致两个新问题。第一个问题是我们的团队总是跟踪误报，然后过早地将永远在线的警报作为噪声处理。随着时间的推移，对于那些似乎不是大问题的警告，我们将停止调查，这使我们的系统不那么有用。最后，我们会习惯性地忽略 - 一些警报，无论它们是否重要。这种习惯性的无知警报引发了第二个也是更严重的问题，即客户告诉我们出了问题。客户不能希望成为告诉您系统或产品出现问题的人，特别是如果您是应用服务提供商（ASP）或软件即服务（SaaS）提供商等托管解决方案提供商。客户期望的是他们告诉您的，您已经知道的，并且您正在解决他们遇到的问题。但不幸的是，由于我们没有花时间建立一个告诉我们这里存在问题的系统，所有常见的沮丧客户都是我们遇到问题的第一个迹象。 回答第一个问题的系统，“有问题吗？”通常是一个专注于客户的系统，他们像客户一样与我们的平台互动。它们也可以是我们平台内置的诊断服务，类似于前面提到的统计过程控制示例。在渐进模式中，接下来要回答的问题是“哪里有问题”。既然我们已经构建了一个系统来告诉我们系统中究竟发生了什么，在理想情况下，我们可以告诉我们哪个业务指标与问题相关。现在我们需要做的是隔离问题。这种类型的系统通常收集各种类型的信息，并随着时间的推移为我们提供对资源的访问。理想情况下，它们是图形化的，甚至可以利用我们前面提到的统计过程控制图。也许它们还提供友好的用户界面，为我们提供热图，显示我们系统的哪些区域或部分与我们的期望不一致。这种类型的系统可以真正帮助我们快速找到我们应该在哪里花费我们的力量来隔离问题或者什么是失败的根本原因。在继续我们的介绍之前，我们必须暂停以显示如果系统绕过“是否存在问题？”这一问题会发生什么？并询问“哪里有问题”。如前所述，这种情况太常见了。也许你有一个拥有无数显示器，秤和图表的操作中心，你甚至可以实现我们前面提到的热图系统。如果您没有首先知道客户问题已经发生，那么您的团队可能会执行每日完整检查过程，以查看在特定时间稍微偏红的每个子系统。可能只需几分钟即可确认这只是一个异常的硬盘使用事件，因此运营团队可能会放松将子系统变为红色的操作定义的阈值。 当客户支持中心始终接收无法登录系统的用户的呼叫时，他们首先假设这只是每天登录失败，但是在连续10分钟接到这样的呼叫后，客户支持中心将联系运营中心。让他们关注这个问题。实际上，当我们处理硬盘使用情况报告时，热量图系统中的CPU使用率和登录服务的用户连接变为红色。现在，与客户相关的事件几乎发生了15分钟，我们还没有开始诊断。如果我们的监控系统能够报告与客户交易相关的问题，那么我们可以在解决其他不直接影响客户体验的问题之前解决登录失败的失败。在此示例中，显示特定类型的事务随时间减少的监视计划将告诉我们可能已发生问题（登录失败），然后操作团队将查看系统中的监视警报以查明发生了。问题是登录服务的CPU使用警报。在我们的渐进式监控模型中，最后一个要回答的问题是“什么问题”。请注意，我们已确认此处存在故障，并且已移至发生故障的区域。现在我们必须进入识别问题的阶段，也就是说，我们需要快速找到系统中问题的根本原因。从我们确认事情发生的那一刻起，确定失败的根本原因，中间会发生两件事。有一点是，当我们从第一个问题转移到第三个问题时，我们需要收集的数据量会增加。为了确认是否发生了某些事情或者出现了什么问题，我们只需要少量数据。但是要从我们可能遇到的各种问题中找到“什么问题”的答案，我们需要收集大量时间段的所有数据。另一件事是我们自然会将注意力从“发生的事情”缩小到“我发现了发生的事情”。这两件事的大小会相互影响。为了更具体地回答这个问题，我们将确定收集此答案所需的更多数据。为了能够准确回答所有问题，我们需要大量数据。 问题本身可以用非常少的数据来回答，但为了得到这个答案，我们必须收集所有可能问题的数据。你有没有发现这个问题？如果我们没有足够聪明的系统来确定是否存在问题，那么我们必须为潜在的警告分配一些警报。渐渐地，该组织忽视了它们。更好的方法是构建一个警报有影响或即将发生的事件的系统，并将其用作引导我们完成根本原因的触发器。 “什么问题”通常是比“存在问题的地方”更深层次的问题。甚至可以更详细地使用统计过程控制来帮助我们找到根本原因。假设我们有足够的空间和资源，那么我们可以绘制我们应用的每个函数的运行曲线一段时间。我们可以将过去24小时的数据与前一周的数据进行比较，或者我们可以将前一周的数据与上个月的数据进行比较。我们只需总结一段时间内的交易数据进行比较，而不是保留每次调用的所有交易。我们可以根据错误的类型比较每个特定时间或一周中某天的每个服务的错误率。在这里，我们将查看构成服务的函数，方法和对象，而不是服务本身的操作。如前所述，这需要大量数据，但对于我们遇到的几乎任何问题，我们都可以准确回答问题所在。通常，我们可以简单地将这三个问题分为三种类型的监测或监测方法。通过监控少量用户体验或实时业务指标，您通常可以回答“是否存在问题？”使用系统级监控指标，您通常可以回答“存在问题的位置”。并使用我们的专有系统来记录和收集数据可以解决“什么问题”。上面的方法是一种系统的方法，因为它提示我们在尝试微信网站之前构建一个系统来识别问题，以便在监控平台或产品中制作所有内容。 在回答“有问题吗？”这个问题之前，我们并没有这么说，我们绝不能做任何与回答“哪里有问题”和“什么问题”有关的事情，而是把我们的主要精力集中在回答第一个问题上。 - 一个问题。由于“在有问题的地方”很容易在许多平台上实施，因此将20％的初始工作放在这个问题上可以获得很大回报，并且至少有50％的工作是为了确保您知道并且可以回答“有问题吗？”通常“什么问题”更难回答，您需要认真考虑专有系统的设计和部署。