支付系统监控实践

Author: Hu, Elvin

摘要

        监控（Monitor）对服务（Service）的重要性不言而喻。一个配置了有效以及可靠的监控的系统，就像拥有不间断雷达和卫星跟踪保护的民航飞机一样， 让人放心，在关键时刻亦能最大程度的发出警报并减少灾难带来的后果。

        智能判断样本是否超越警戒线不是一件容易的事情。漏报和过多的误报都不可取。而样本通常由用户行为产生，且不符合严格的解析规律，这对阀值的设置造成很大困难。为了解决这个问题，我们采用观察变化率的方法，把不可解析的样本曲线转换成可解析的曲线，从而简化分析和判断过程，有效地捕捉突发异常事件，并降低误报率。

        本文以eBay的支付流程为例，介绍我们的系统监控实践。

一．简介

        eBay依靠 PayPal作为支付平台，而Payment系统处于eBay在线网站和PayPal之间。简单来看就是这个样子：

        我们负责开发和维护就是其中的“Payment”部分。通常与钱相关的系统都比较重要，稳定性要求也相对比较高。所以 Payment 这条线必须保持时刻畅通以保障终端用户的支付体验。一旦发生了系统问题我们必须在第一时间知道并予以解决，同时把对用户的影响降低到最小。这一切都仰仗对其的监控能力。

二． 目标

        一个合格有效的监控，在具有定性感知错误的能力外还要能定量的回答：什么时间（when），在哪一个环节（where），出了什么错（what）。

        When（实时）：实时性可理解为灾难发生到被感知的延迟时间 。这个时间当然是越短约好。但是出于对资源的考虑，对不同功能的系统，实时性的要求不完全一样。目前我们对Payment定义的实时为5分钟延迟。

        Where（定位）：下游系统被理解为上游系统的依赖（Dependency），所以PayPal是Payment 的依赖，Payment又是Checkout的依赖。当支付无法完成的时候，有可能是Payment本身出了问题，也有可能是PayPal出了问题。迅速的定位是解决问题的关键。

        通常的做法是对自己监控，同时对下游做监控，因为当别人问起来的时候，我们就可以告诉他Payment有没有问题，是否是由于PayPal不Work而导致的，等等。常常被忽略的是对上游系统的监控，作为身在同一个战壕里的战友，Checkout 出了状况Payment也有责任及时感知并通知，毕竟都是对用户体验的影响。

        What（症结）：也理解为Root Cause。有可能是数据库连接失败，有可能是HTTPS证书过期，有可能是集群中一台机器掉线，等等。监控系统给出的信息量越多越能帮助我们找到这个Root Cause，从而更迅速的解决问题。

        另外还有两点，也非常重要。

        多重保护：最好有两套或更多不同监控机制，互相参考，互为备份，以防其中一个出现失误。

        误报率：保险起见通常监控会比较保守，宁可错报也不能漏报。但是可以想象如果一个监控频繁地发出报警，就变相形成了一个 Spam。会让人麻木，同时淹没真正有效的报警。所以误报率需要尽可能的低。