再谈系统 Monitoring 和 Alerting

工程师有时侯也是侦探。...





题图：Tru by Emilia Dziubak

上一篇提到我之前做搜索，后来转而做了支付。有读者留言问：为什么选择支付而不是搜索？其实当时的选择并不是觉得一个领域比另一个领域更有意思，而是当时的机遇恰恰给了我一个在支付方向发展的更好的机会。

无论哪个领域，做到一定程度，都会有很多很有意思的问题。逐年的积累也会带给你看待问题的思路和解决问题的经验。这样，在系统设计时，你能有个更好的全局感；解决问题时，能有更清晰的思路；遇到异常时，会有更高的敏感度；实现时，也能有更有效的执行力。

现在的方向很多，不同的方向锻炼出来的思维方式和技能集也不尽相同。比如我有很多朋友做增长（Growth），这在很多时候就需要快速迭代、采集和分析有效数据，还需要有比较好的产品的 Sense。很多朋友做 Search、做 Risk，很多时候就需要建模、调参，机器学习使用的也会比较多。有一些做底层 Infrastructure（比如 Storage，Data 或 Event Pipeline）就会比较注重 Scalability 和 Reliability 等。

而支付呢？做到一定规模后需要考虑 Scale 的问题，而最基本最关键的还是保证事务的一致性、正确性、和可审计性。打个简单的比方。房客 A 想在 Airbnb 上预订房东 B 的房子。这样我们需要从房客 A 收钱，经过一段时间再转账给房东 B。说起来简单，不过是两笔交易，但这中间可能和需要发生的东西就太多了：A 和 B 可能是不同货币，需要进行汇率换算；A 可能使用两种或以上支付方式，比如一半用 Credit 付、一半用信用卡付，而这两笔可能失败，或者一笔成功一笔失败；可能某一步的第三方支付延时过长，实际交易成功却丢失了回执；可能需要保留一部分租赁税上交政府；可能房客下完订单后又希望改变预定的天数，这样需要追加一部分付费或者 Refund 交易的一部分…… 而每个公司的支付都要做结算，怎样保证每一笔现金流和转账都按一定的方式有记录，能够重现整个交易发生的场景。怎样保证任何的交易错误都能及时被发现等等。

所以支付说白了，就是各种各样奇葩的场景，怎样能做到系统的处理不会导致任何错误，并且能记录下足够的信息任何时候都能还原实际发生的事件。除了一些比较 Domain Specific 的支付知识，支付一个很重要的需求，就是系统对任何想得到的想不到的、有可能发生的情况都能正确的处理。

每年到了最后几个月，支付的一个重头戏就是为审计做准备，说白了，就是各种对账。前一段时间，大家都是做开发，最近，按照组里的小朋友们的说法，就是每天都像侦探一样在 “破案”。系统里的帐一批批、一笔笔地对，确保每一笔订单的收、支、现金流都是 “有案可查”，都是正确的。

而受益于我们整个 Monitoring 和 Alerting 系统已经做的相当完善，每一笔账的追踪就成为可能。有一些是放之四海而皆准的方案，不妨拿来说说。

Syslog 或 Kibana Log：也就是系统的日志，之前《白话 IT 之浅谈 ELK 日志系统》略有提及。这样，哪笔订单执行过哪些函数，留下的 Food Print 就可以搜索。缺点有二：一是 Kibana Log 在 ELK 系统中通常只能查到最近几十天或一个月的，定期 Archive，不能方便地查询历史所有的信息。而是没有办法很好的做 Analysis。

Hive 或者 DB Persisted Event：可以做比较详尽的 Event Tracking。这个根据不同的使用场景可以做的特别 Powerful。但是需要搭建比较完善的 Event Pipeline 和 Processing System。量大以后 Scalability 的处理也很重要。对工程师的要求比较高，尤其是在 Infrastructure 方面。

Datadog：可以记录一些系统的 Statistic。打个比方。对一个 Charge 函数。可以入口的时候设一个计数器，出口的时候为成功的 Charge 和失败的 Charge 各设一个计数器。这样就可以用图表追踪 Charge 成功的 Rate。并且可以进一步设置一个 Alert，当这个 Rate 低于 99.9% 的时候就 Fire Alarm。Datadog 还可以做一些很细致的统计、画图和警报。很多公司都有大屏幕用 Datadog 实时 Monitor 系统的核心 Metrics。

Sentry 和 NewRelic：主要是实时 Track 系统的 Error 和异常。对一些 API 或者 Client、Server Error 进行 Aggregation。很多公司 Oncall 必不可少的监测手段。

基于机器学习或者数学模型建立的 Alert 系统：比如之前《公司里的 Data Scientist（数据科学家）》一文中提过的我们建立的一个异常监测系统就属于这一类。

基于 DB Trigger 的 Auditing Trail：记录所有的 DB 改动，可以还原所有数据库写操作的历史。

有了以上这些工具和系统，几乎任何一种情况都能让工程师的 “侦察” 工作变得更轻松简单。

很多公司一开始的时候没有 Setup 好这样一些基本框架，就会丢失很多有价值的数据和记录。这样后面真的需要信息的时候就没有办法再找回来了。因此，设立一套完善的 Monitoring 系统，虽然对产品没有直接的好处，但从长远来看，是极为重要的。

    关注 嘀嗒嘀嗒