如果你的工作已经是不止一天围绕着技术平台、技术系统、后台办公IT系统或者产品平台了，那么在最近发生的事故、故障或危机中，你很可能已经听到过这样的问题，“为什么我们没能及早发现它”。如果你和我们年纪相仿，或者比我们年纪还大，那么你可能早就记不清楚自己听到过多少次这种问题了。答案通常相当简单，这往往是因为一个服务、组件、应用或系统没有被监控或者监控不当而导致的。而这个答案的结尾常常还会加上一句，“这个问题再也不会发生了”。

如果你的工作已经是不止一天围绕着技术平台、技术系统、后台办公IT系统或者产品平台了，那么在最近发生的事故、故障或危机中，你很可能已经听到过这样的问题，“为什么我们没能及早发现它”。如果你和我们年纪相仿，或者比我们年纪还大，那么你可能早就记不清楚自己听到过多少次这种问题了。答案通常相当简单，这往往是因为一个服务、组件、应用或系统没有被监控或者监控不当而导致的。而这个答案的结尾常常还会加上一句，“这个问题再也不会发生了”。


 
即使这个问题再也不会发生了，虽然根据我们的经验，这个问题经常还是会再发生，但很可能还会出现相似的问题。于是同样的问题会被再次提出，可能还会执行事后分析流程，然后采取一一些行动“再次”来正确地监控这个服务。
 
虽然“为什么我们没能及早发现它”这个问题有一定的用途，但它不像些更好的问题那么有价值，例如“我们的流程中有哪些问题，造成了我们没有合适的监控方法来发现这些问题就启动了服务”。你也许认为这两个问题是相似的，但事实并非如此。第一个问题 “为什么我们没能及早发现它”指的是此时此刻的这个问题，它不无帮助，至少能驱动正确的行动，来解决我们刚遇到的这个故障。但另方面，第二个问题解决的是人员和流程的问题，正是它们才使得你在没有合适监控的情况下，经历了刚才发生的事件，或者其他类似的事件。如果你愿意，可以回想一下我们在第8章中讨论过的故障与问题的关系。一个问题会引发一个故障， 可能还与多个故障有关。我们提出的第-个问题解决是的故障，而不是问题。而我们提出的第一个问题，解决的就是问题。两个问题都应该被提出，但如果你只能提个问题，并且只能得到一个问题的答案， 那么我们认为，你应该修复的是问题，而不是故障。
 
我们认为，通过监控没有发现问题最常见的原因是，大多数系统都没有被设计为能够监控的。事实上，大多数系统都是先被设计实现了，然后才考虑监控的。通常，负责判断系统或应用是否工作正常的团队都不是定义系统行为或者设计它的团队。最常见的结果就是，对应用执行的监控手段是由不能判断应用是否执行正确的团队开发的。这样就会造成监控系统不能抓住关键的成功或失败指标，相对于公司内部对于监控系统能够在影响客户的关键问题出现之前就识别出它们的期望；这样的监控系统无疑注定会失败。
 
要注意，设计为能够监控的并不只意味着要理解如何正确地监控一个系统的成败与否。设计为能够监控的是要把监控功能构建在应用或系统内部的，而不是构建在它们周围。它不仅仅是要记录发生的故障，进一步识别故障的主题，甚至还可能从应用的角度自主提出潜在的问题或担心。所谓被设计为能够监控的系统，要能够评估所有服务的响应时间，当响应时间超出正常水平时，就要与某些人进行交互或者警示他们。这个系统可能还会评估一段时间内记录的错误的频率，如果这个频率发生了很大的变化，或者其中出现的错误改变了，它也会警示合适的人。采用一个统计过程控制图，从过去30个相似日期的相同时间段的数据中可以得到一个平均值，如果错误率或响应时间落在了这个平均值的标准差之外，就报警，这样就可以实现上述两种方式。这里，“相似”的日期可以是周一对周一，周六对周六。
 
当公司成功实现了设计为能够监控的这个架构设计原则后，他们就会开始问第三个问题。这个问题最好在实现系统之前就问，通常是在架构评审委员会( ARB)或联合应用设计(JAD)会议上提出。这个问题通常是“我们如何知道这个系统运行正常，又如何知道何时它表现糟糕呢”。对于第三个问题，正确的答案需要包括前面我们提到的统计过程控制方案中的元素。任何一个正确的答案，告诉我们的都不能只是应用日志中有错误出现了。记住，我们希望系统告诉我们的不只是系统行为与预期不符了，还要告诉我们系统行为何时出现异常。这是两件完全不同的事情。
 
要注意到，让运营团队开发套应用监控指标，只是查找SNMP告警，或者遍历日志以查找软件开发人员说明的重要字符串，这些虽然也是监控方法，但与我们上述的监控有很大的不同。我们所说的监控也不只是查看CPU使用情况、负载、内存使用情况等。当然，这并不是说这些指标不重要，但只是监控它们还不足以保证你的应用是健康的。
 
我们通过监控没有发现问题的次常见原因是，我们开发监控系统的方法与我们开发其他系统的方法不同。通常我们并不会设计我们的监控系统，也不会以一一种系统的发展方式来开发它。大多数情况下，我们都是依靠生产环境的故障和危机来使我们的监控系统变得成熟，而这种方法通常会无缘无故地给监控系统打个补丁。当被问到在监控什么时，我们很可能会给出所有典型的答案，从应用日志到系统资源的使用情况，甚至还会信誓旦旦地说，我们还监控了过去发生过的重大故障的各种迹象。我们几乎不会回答说，我们是按照设计和实现我们的平台或服务的那一套标准来开发我们的监控系统的。接下来我们将给出了一个框架，用于解决这个次常见的问题。