可控的服务的构成

最近出现过几例现网问题，促使自己在考虑一个好的后台服务的标准是什么？最重要的又是什么？
以前总觉得后台服务嘛，要稳定，可靠，性能好。也就是作为一个后台运行的服务器，要能在7*24的状态下，稳定运行，不宕机；另外作为一个好的后台服务，性能也能重要，我们的目标是为海量用户提供服务。
看起来够屌逼了吧？但是这其实只是完成了最基本的部分，且看下面个问题：
你的服务上线有段时间了，老大问你，你负责的这个服务最近运行的怎样，服务状态是否正常？
这个时候，你会想，我的服务运行了这么久了，也好像没出啥问题。但是仔细再一想，问题就来了，服务状态是否正常应该怎么去界定，怎么衡量呢？
这里就不绕弯子了，直接说干货吧。先撇开具体的业务，从通用角度来说，一个服务是否正常应该从服务端全流程监控数据来判断。
1）接收的前端请求个数，包量，流量是多少。这意味着什么呢？意味着你作为一个后端服务，在还没有做任何处理之前，接收到的原始请求的量。
2）你的服务处理了多少请求，处理的结果中，正常的数量，异常的数量各自有多少，如果有异常，那么异常细分场景的监控数据也要收集分类统计。这个环节的数据，是真正对你的服务质量的衡定。
3）如果你的服务还向后端其他服务器发起了请求，这时候，还要监控网后端发出的请求和后端其他服务器返回的响应数量。这里意味着你对中间服务的质量有了数据上的判定
4）就是你的服务往前端的返回的响应数据了。大部分常规服务都是有请求，有应答的。这里的数据主要看看请求经过你的服务处理后，响应数据是否和请求数据能对上。
经过这4个步骤的数据监控，这时候如果你看了这些数据。而且请求量和你处理的量基本一致，你处理中的结果都是正常的，没有异常，最后你的响应数据量也和请求量基本一致的话。那你就可以拍着胸脯说，我的服务质量都正常，心里是有底气的，因为你的全流程监控数据支撑了你的信心。
当然，上面也只是从通用角度做了分析。如果你的业务逻辑特殊且复杂的话，你还要多增加业务上的监控数据。只有全程的监控数据都有的情况下，你开发的服务才算是可控的。即使在运行过程中，出现了问题，你也能马上通过监控数据的变化发现问题所在，也就是说有数据在，你也不怕出问题了。问题一出马上能知道，这也算是everything in control！
由此可见，可控的服务构成是由全流程上的监控数据构成的，抓住业务的关键流程，采集好监控数据，就能做到一切尽在掌控！