前言
线上运行监控主要是靠四点，第一：编码阶段的业务指标，第二：业务数据看板，第三：线上日志巡检。第四：业务反馈。前面三点都是提前去发现和预防严重的问题。如果到第四点业务开始反馈，问题就比较滞后，这也是我们为什么将第四点放置最后，我们尽量减少这种case。
报警监控
这一项主要是结合前面编程阶段和测试发布阶段一起的内容，正常业务指标在发布完上线后立即进行阀值的设置，有一些Exception的报警监控直接加上阀值就好，当然还有一部分监控需要在线上运行一、二天才能看到有效的阀值。咱们也不能遗漏，定期对阀值进行修改，保证线上报警指标的有效性，不遗漏不泛滥才是我们真正的目标，每一个报警值都是有它特定的价值。保证工程师在收到报警之后不会有任何的懈怠，都当成第一要务处理。
业务数据可视化看板
业务数据可视化是对报警监控的一个补充，曾出现某些case，订单在某某功能上线后呈现下降趋势，但是线上没有报任何异常，这个时候需要对数据进行一个周期性对比，分析数据的准确性。找出形成下降趋势的原因。这种类似的原因比较多，例如搜索排序对房屋漏出的影响。我们供应链系统针对房屋系统、商户系统、CRM销售系统分别做了不同的业务数据可视化看板，房屋基础信息的访问频率、每日平台商户上房率、API上房率、商户日活、商户实拍订单数据……等。这些指标都存在周期可比性。当出现大幅的波动是需要详细排查。
线上日志巡检
如果前面两步做得非常到位，可能第三步暂且不需要了。线上日志巡检：部分系统上线后将日志的定位非常不明确，经常一堆正常业务中夹杂着大量的Exception 和 Error。导致发布和线上日志巡检的时候很容易出现误区。所以这项工作一定是必须有，但是周期可以调整。如果项目前期的各个上线都做得非常到位，线上日志也很干净，所有 warn 、Exception、Error的地方区分得很清楚。保障了日志的赶紧程度。后期可以适当把日志巡检周期拉长，一周一次、一月一次。
业务反馈
最后一点，业务或用户反馈的问题，一般都需要经过PM、QA 的验证才能到DEV手中，如果出现大面积的业务异常，这时DEV一定是第一时间着手去解决的，当成线上故障进行处理。优先解决线上问题。当出现个别的房屋或者门店时，也需要彻底排查问题点，对线上进行快速的修复
总结
线上运行监控是系统稳定和高可用的最后一道保障，如果要做到99.99%这里面的四点缺一不可。项目组员必须提高自身的认知和编码能力。每一个开发都需要覆盖到以上四个点，才是一个合格的开发。
网友评论