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

你有多少次在事后分析会议上发现，其实你的监控系统早就标识出了潜在的可扩展性和可用性问题发生的迹象?也许监控系统触发了数据库上的空间报警，但没有得到响应，也许是几个服务的CPU使用率都超出阈值了。也许你启用了监控系统中对响应时间的监控功能，而且在过去几个月中可以看到调用某个特定服务的时间在缓慢增加。你也许会问自己，“怎么这些居然都没有得到注意”?
 
也许你甚至把自己的担心告诉了你的团队，但得到的答案可能是监控系统给出的错误信息太多，或者系统中的噪音太多了。也许运营团队的主管还可能会说，他已经申请几个月了，希望有资金来替换当前的监控系统，或者希望有时间和灵活度来重新实现当前的系统。他可能会说，“如果我们能够剔除-些噪音，那么我的团队会睡得好些，并且能够解决我们面对的真正问题”。我们已经听到过无数要求新的更好的监控系统的理由，虽然有时它们是正当的，但我们相信通常它们的结果还是损害了股东价值。真正的问题通常不是监控系统不能满足公司的需求，而在于监控的方法是错误的。运营团队可能证实了对监控的需求，但往往搞错了方向。


 
虽然要解决“为什么我们没能及早发现它”这个问题，必须采用设计为能够监控的这条架构设计原则，但它并不足以解决我们所有的监控问题或者所有的监控需求。我们需要规划我们的监控方案，并且还会随着时间的推移而改善它。敏捷软件开发方法在开发一段软件之前， 是不知道所有需求的。要解决这个问题，就要具有敏捷和渐进的开发理念，这一点同样适用于我们的监控平台和系统。我们提出的这种渐进的方法可以回答三个问题，列出的故障和问题的描述。
 
在我们提出的监控方案的渐进模型中，我们要问的第一个问题是“有问题吗”。具体说来，我们感兴趣的是确定系统是否行为不正确，通常我们真正要问的是这里是否有客户会经历或者将要经历的问题。根据我们的经验，许多公司都会完全绕过这个非常重要的问题，迫不及待地投入到对下一个问题的毫无指导的探索中，即“哪里有问题”，或者更糟的，“什么问题”。
 
在监控过程中，绕过“有问题吗”或者更恰当的“客户在经历的是什么问题”，都假设了你知道什么系统会以什么方式引发什么问题。但遗憾的是，实际并非总是如此。事实上，我们有许多客户都浪费了大量的人力来查找问题的根源，却不曾真正理解问题究竟是什么。你一定曾上过这样的课程，它们只是把分析问题或者解决问题的方法-股脑地星现出来。但关键在于，在你确 切理解了要解决的是什么问题之前，不要试图开始解决问题或者进行任何分析。这一点同样适用于举行会议一通常 会议都需要有一个议题和目标，或产品营销一在尝试为某 个市场需求开发效地判断出问题的原因，我们必须知道这里存在一一个问题以及问题表现为什么样子。产品或服务之前，我们首先要确认目标人群。这一一点对监控系统和应用也是如此一如果 要想有
 
如果构建的系统不能回答第.个问题 “有问题吗”，这就会导致两个新的问题。第一个问题是，我们的团队总是在追踪假警报，然后就会过早地把总是出现的警报作为噪音处理掉。这样久而久之，对于那些看来不是大问题的警报，我们就会停止调查，这就使得我们的系统不那么有用了。最终，我们会习惯性地忽略-些警报，无论它们重要与否。
 
这种习惯性忽略警报会引发第二个问题，也是更加恶劣的问题，即由客户通知我们发生问题了。客户一定不希望自己是那个告诉你你的系统或产品有问题的人，尤其当你是像应用服务提供商(ASP)或软件即服务(SaaS) 提供商这样的托管方案提供者时。客户期望的是，他们告诉你的东西，你都已经知道了，并且你正在修复他们所经历的问题。但遗憾的是，由于我们没有花费时间来构建一个告诉我们这里有问题的系统，所有通常怒不可遏的客户是我们得到我们有问题的第一指示。能够回答第一个问题“有问题吗”的系统，通常是关注客户的系统，它们会像客户那样与我们的平台进行交互。它们还可以是内置在我们平台上的诊断服务，与前面提到的统计过程控制示例相似。
 
在渐进模式中，要回答的下一个问题是“哪里有问题”。现在我们已经构建了一个系统，能够确切地告诉我们，在我们的系统中出现了问题，在理想状况下，还能告诉我们这个问题与哪个或哪些业务指标相关。现在我们需要做的是隔离问题。这种类型的系统通常广泛收集各种类型的信息，能够给我们提供一段时间内资源的使用情况。在理想状况下，它们是图形化的，甚至还可能利用了我们前面提到的统计过程控制图。也许它们还能提供个友好的用户 界面，给我们一一副热图，说明我们的系统中有哪些区域或部分的行为与我们的预期不符。这种类型的系统能够真正帮助我们迅速找出应该把力气花在哪里来隔离问题，或者造成故障的根本原因是什么。
 
在继续我们的介绍之前，我们要暂停一下， 说明如果一个系统绕过了“有问题吗”这个问题而直接问“哪里有问题”，会发生什么情况。如前所述，这种状况太常见了。也许你有一个运营中心，其中有无数的显示器、刻度表和图表，甚至你还可能实现了我们前面提到的热图系统。如果没有首先知道这里发生了一个客户问题，那么你的团队可能就会执行一个日常的完整检查流程，查看每个在某一时间段稍微 呈现红色的子系统。也许只需几分钟就能确认这只不过是个异常的硬盘使用事件，于是运营团队可能会放松使这个子系统变红的运营定义的阈值。当客户支持中心总是收到用户不能登录系统的电话时，他们首先会假设这只是属于日常的登录失败，但在连续10分钟都接到这样的电话后，客户支持中心就会联系运营中心，让他们关注这个问题了。
 
事实上，在我们处理硬盘使用报告时，在热图系统中，CPU的使用情况和登录服务的用户连接都变红了。现在，与客户有关的事件几乎已经发生15分钟了，而我们还没开始诊断操作。如果我们的监控系统能够报告与客户交易相关的问题，那么我们就能在解决其他不直接影响客户体验的问题之前，先解决登录失败的故障。在这个例子中，一个能够显示出某种类型的交易随着时间而减少的监控方案会告诉我们可能发生了问题(登录失败)，那么运营团队就会查看系统中的监控警报，从而找出发生问题的地方，如登录服务的CPU使用警报。
 
在我们的渐进监控模型中，最后一个要回答的问题是“什么问题”。注意，我们已经从确认这里有一个故障，前进到了隔离发生故障的区域，现在要进人识别问题的阶段了，即我们要迅速找出引发系统中问题的根本原因。从我们确认有事情发生了，到确定引发故障的根本原因，中间会发生两件事情。一件事情是， 当我们从第-一个问题深人到第三个问题的过程中，我们需要收集的数据量增长了。要确认是否有事情或者有地方出问题了，我们只需少量的数据即可。但要从我们可能遇到的各种问题中找出“什么问题”的答案，我们就需要收集大量时间段内的所有数据。另一一件事情是，我们会自然地把我们关注的范围从“有事情发生了”缩小到“我已经发现发生了什么”。这两件事情的规模会互相影响要想使这个问题的答案越具体，我们确定这个答案需要收集的数据就越多。
 
要想能够确切地回答所有问题，我们需要很多数据。问题本身，可能只需非常少部分的数据就能回答，但为了得到这个答案，我们必须收集所有可能发生的问题的数据。你发现这会造成的问题了吗?如果我们没有一个足够智能的系统可以确定是否有问题，那么我们就要为提示潜在问题的数条警报信息都分配人手，渐渐地，组织就会忽略这些警报。较好的方法是构建一个系统，对有影响的事件或即将发生的事件发出警报，然后以此作为触发器，指导我们找出根本原因。“什么问题”通常是比“哪里有问题”更深一层的问题。这里甚至可以更加细致地使用统计过程控制来帮助我们找出根本原因。假设我们有足够的空间和资源，那么也许我们可以绘制一段时间内我们应用的每个功能的运行曲线。我们可以拿最近24小时的数据与上-一周的数据进行对比，也可以拿上一周的数据与上个月的数据进行对比。我们可以不必保留每个调用的所有交易记录，而只需汇总段时间内的交易数据，以便进行对比即可。我们可以按照错误类型对比一天之中某个时间或者周之中某一 天的每个服务的错误率。这里，我们看的是构成服务的函数、 方法和对象，而不是服务本身的操作。如前所述，这需要很多数据，但对于我们所遇到的几乎任何问题，由此我们都能确切地回答出问题是什么。
 
通常，我们可以把这三个问题简单地划分为三种监控类型或者监控方法。监控少量的用户体验或实时业务指标，通常就可以回答“有问题吗”。利用系统级的监控指标通常就可以回答“哪里有问题”。而利用我们专有的系统记录和收集数据就可以解决“什么问题”。
 
上述方法是种系统化的方法，因为它促使我们在尝试微信网站制作监控平台或产品中的一切之前，先构建一.此系统来识别问题。我们并不是说在回答了“有问题吗”这个问题之前，绝对不能做任何与回答“哪里有问题”和“什么问题”有关的工作，而是说要把我们的主要精力首先集中在回答第-个问题上。由于“哪里有问题”在许多平台上都很容易实现，所以把你的初始工作的20%投人到这个问题上就能得到很大的回报，而至少要把50%的工作都用来确保你知道并且能够回答“有问题吗”这个问题。通常“什么问题”这个比较难回答，你需要认真思考你的专有系统的设计和部署。