熟悉的场景：

运营：你们系统出问题啦！

技术：不可能出问题吧？没有什么发布和上线啊，要不给个信息来排查一下呢？

一个小时候后......

运营：查出什么问题了吗？

技术：还没有，系统多，层级深，需要拉通了查。

运营：能不能尽快，客户已经抱怨多次啦。

不管是谁充当其中的角色，都会一次次崩溃掉，特别是非工作日，技术及相关人员不在线，这中间消耗的是客户的耐心和信任，相关人员也会被消耗在这样的日常工作中，久而久之，也会让人产生不良的情绪，影响整个团队的效率。

问题是时代的声音，更是需求的声音。善于发现业务中的问题、提出问题、直面问题、研究问题、回答问题，积极推动问题的解决，是一个技术人员的分内之事、应尽之责，更是其价值体现。

整套系统是一个复杂的工程，是由基础网络、服务器、数据库及各种中间件，业务系统及各种资源渠道等组成，谁也不能保障哪里不出问题。因此迫切需要有效的体系（工具）和手段来解决这些，这就是当初很坚定的来做监控体系的背景。

现在技术领域里面开源的也有一些监控系统，各有各的优点，但都很难找到适合我们自身业务的那款，所以我们当初针对已有的系统做了分析与对比，最终选择了自建方式。这里就谈一下业务监控体系应该如何落地，这中间应该注意什么。

我们的支付体系建设在经历多年的时间，由最初的单体架构，逐步演变为分布式架构，再到现在的微服务架构。随着业务的发展，体系架构还在不断迭代过程中，在其可扩展和高可用等方面已具备相当好的优势，同时体系结构也演变的较为复杂，层级相对较深，还要支撑各种各样的产品场景。这就会带来另外一个问题：如何排查问题？

而作为技术来说，最重要的工作之一，那就是日常支撑，每天都在处理各种各样的疑难杂症，当时技术中心为解放大部分程序员的日常运维工作，特别成立了“服务台”这个组织。专人处理这些日常问题。

这就是采用了牺牲小部分高素质程序员的产出能力，去解决整体日常的技术运维。而每次投诉咨询都是一个数据从头到尾的排查，效率相当低下，时间一久这些人也形成了自己的经验和套路，日常工作就成了繁重的体力劳动，久而久之大家也对其失去了动力，导致无以为继。总的来说投入的成本何其高，产出的效率还达不到要求，何况人才会流失，难以培养。不难看出，这其中最大的痛点就是我们没有相应的业务监控体系。

如何尝试搭建这样的监控体系，开启了我们的业务监控建设之路。

1.建设目标要清晰

◆实时反映系统的健康状况，可预警；

◆掌握系统的峰值及压力，及相关资源的消耗与承载情况，报警且能有效自动处理与恢复；

◆能够做到业务及产品场景下的有效监控，掌握业务运行情况，能够及时发现业务异常，并根据业务异常识别告警级别和触发应急处理机制；

◆对系统问题能够早发现和快速定位，尽量智能化处理和规避风险性问题；

◆透过监控里的重要指标，能够推动体系结构的迭代优化，建设合理的技术运维监控产品，降低运营、技术等相关角色的沟通成本，减少技术在运营支撑上的投入成本。

服务对象的定位，受益者会涉及到运营、技术、运维等，以及管理者，能够满足不同所需，不同的受益者都会有它特有的需求。

监控不是一个独立（封闭）的体系，它提供的指标数据以及分析结果，可以促进相关领域的迭代，甚至不同部门的协作进行整站的改进和完善。

2.以业务为主导方向，而非技术

监控的目的是服务前端业务，是以解决问题为导向，问题才是需求的声音。以技术主导做的一些基础技术服务体系，很难与业务契合的很好，因为一开始就不清楚使用对象是谁，又解决谁的问题，可能更谈不上可用性，及用户体验。

在确定方向的同时，我们的大体思路也初步形成，基于事后慢慢向事前转变，在实现目标后，将转身由事中去把握事前，这中间就是一个质的转变，由被动转为主动，就需要大量的信息做支撑（信息的采集—>信息的清洗—>信息的加工—>信息的编排—>信息的有效利用）,不同的阶段会有对应的技术选型，但把握一个原则，不过度设计，规避简单事情复杂化。

3.初心很重要

知道发生了问题（预警），快速定位（哪里发生），自动处理与恢复（解决方式），这个就是当初我们简单勾勒出来的愿景。这个也是在整个过程中，不管人员或资源上发生了那些变化，有了什么冲突，或者我们的想法上有了什么更好的idea，尽量用有效的资源来做有效的事，而且是有意义的事情。

一直到现在，我们都会用初心这样的方式，来让我们走进现实，把复杂的事情简单化，从实际出发解决我们最本质的问题，当一个个迫切待解决的问题都被消灭了，那强大的监控体系自然而然也就被迭代出来了。

4.选择适合自己的方式

从一开始我们选择了敏捷的模式来落地这个体系建设。万事开头难，但要开好头，一直坚持下来，更考验团队的毅力和有效执行力。

我们把当初构思的监控体系的蓝图勾勒出来后，就切分成了不同的目标（阶段），而把看得清楚想得明白，且立竿见影的那部分作为第一个迭代周期，通过快速的迭代实现，验证我们的设想，同时又可以调整后面不同阶段的目标和规划，就这样一个一个迭代周而复始，不断的打磨，在对偏离的那部分进行下一个迭代周期修复。虽然有试错的场景在里面，但也不会对我们资源造成浪费，这个也取决于迭代周期和交付成果的合理设计。

从最初的金融域，到全站，再到具体业务场景，我们也是在变化中不断的去实践，围绕着初心去构建和迭代。透过这样的实践形成的模式与意识，可以运用于其它地方，可以很好的推进相关工作的开展，以及把控风险，最终实现预期目标。

5.意义所在

要做这件事的意义可以罗列很多，结合公司目前的研发资源情况，在这里，我想说的有以下几点：

◆把人的精力从低级、繁杂的日常中释放出来，去做有意义的事情，从而达到增效和降低成本的目的；

◆在跨界的领域里面让小伙伴成长，能够把握体系结构，扩展自身的广度；

◆改变我们的视角，从点走出来，站在线、面、体上，同时主动的思考和捕捉问题；

◆弥补体系的不足，有效控制风险；

◆解决掉对角色（人）或岗的依赖，不可能百分百做到，结合自身做到最大程度上的缓解。

最开始的时候，我们选择了最重要的金融域，也是我们最为熟悉的业务产品之一，包括对金融渠道的掌握程度，这也是我们从一开始就能够取得成功的地方，也从最初的时候就激发了小伙伴的动力，让大家看到了可行性，和实现了目标与价值，得到认可。

这中间对金融的各种异常和异动都做了详细的定位，通过拦截、异步、尝试、探测等方式，结合预警和自动处理，尽量不影响业务，特别是反向路由做到重路由，也是小伙伴在实践中想到的最佳的解法渠道异常的最为有效的方式之一，省去了运营和技术岗上人力的投入。

拥抱变化，主动的接纳，基于这样的态度来面对监控体系建设，可能不是人人都能看到的事情，但确实是很有意义的事情。所以对人的选择也很重要，不但要有兴趣，对技术和业务有相当的熟悉度，且需要有全局的思维和角度，耐得住乏味的工作，自驱力要强，才能保障这样的体系不断的持续迭代，才能输出适合企业自身的监控体系，给整个支付体系保驾护航。

在这条路上，没有终点，我们一直在路上。随着业务和体系的不断演变，未来还有未知的领域等着我们，唯有加紧当下的脚步，才能跟得上变化，与时俱进，好的东西永远都是在不断演变中进化出来的。