技术与业务同行：我是如何在业务中成长的?

作者：慕扉

应用实时监控服务ARMS（Application Real-Time Monitoring Service）是一款应用性能管理（APM）产品，包含应用监控、Prometheus监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、App 等领域的性能管理，能帮助用户实现全栈式性能监控和端到端全链路追踪诊断，让应用运维从未如此轻松高效。

我主要负责阿里云ARMS前端监控平台，该业务更偏向于技术类产品。我想聊聊如何在业务中成长，期间也有困惑和迷茫，希望我的经历或者方式方法能给有类似情况的前端同学有所帮助。

我个人的成长主要分为三个阶段，分别是：

（1）监控领域初接触，建立自身监控知识体系
（2）业务痛点跟进，打造监控平台核心能力
（3）业务场景不断拓展，建立保障业务稳定体系

监控领域初接触，建立自身监控知识体系

最初业务面临的问题：业务上线之后，用户在实际访问时遇到错误，业务方无法快速感知；发生线上故障后，很多场景无法快速复现和排查原因等。基于业务的这些痛点，团队决定搭建前端监控平台来解决这些问题。

我是从Retcode2.0正式开始接触前端监控领域，面对一个新的领域，需要快速从0-1建立自身监控知识体系。这个过程是非常充实且充满挑战的，但当你完成这个阶段后会非常有成就感。面对未知和挑战，这里总结一下我认为比较重要的经验。

勇于打破自己的边界，拓展自己的技术栈

前端监控的整个体系简单总结一下：采集、日志存储、日志切分&计算、数据分析、告警，也就是工作不再局限于前端业务的开发工作，需要有Nginx服务运维能力、实时/离线分析能力、Node应用开发运维能力等等，所以我迈出了第一步，从前端->全栈的转变，让我整体熟悉并能把控前端监控从采集到最后告警诊断整个流程，在这个基础上让我后续能Cover整个监控平台。

Owner意识

对于负责的产品需要具备较强的Owner意识，把工作做大做强，服务好客户。每一个功能的开发、迭代、优化及创新，认真对待，保障每个环节做到最好。在这个过程中，我的角色也发生了改变，从最初的功能实现落地者到产品能力的主导技术方案的选型拍板者，这段时间的复盘让我不经意间意识到自己的这些变化。

以我自己的一个经历为例：最初日志服务器的部署是运维同学直接在机器上配置好，再提供服务。我接手后就遇到了一个比较大的问题：扩容。正常应用扩容是很简单的事情，通过PSP提交扩容申请单，可快速完成扩容。但当前Nginx日志服务没有基线配置，无法直接PSP扩容，只能手动配置。

对于扩容来说，当前的方案存在2个问题：

（1）手动配置扩容时间成本高
（2）无法有效保证所有机器上各类包的版本号一致。

为了解决这些问题，就需要了解Nginx日志服务的能力及运维相关的能力，通过与PE、后端同学讨论，最终决定采用Dokcer的形式解决当时扩容的问题，不仅提升了运维效率，也为后续海外业务支持打好了基础。
所以给到大家的建议是，不要单纯的完成产品的一个个功能，而是要有Owner意识，认真审视业务面临的问题，能够主动去跟进和改变，慢慢积累后续会产生质变。

业务痛点跟进，打造监控核心能力

平台从0-1搭建完成后，为了服务更多的业务，打磨产品能力，正式上云升级为阿里云ARMS前端监控平台。监控的基础能力已全部上线，后续如何发展是我需要思考的问题。如果后续在这个基础上一直做迭代优化，产品和个人都没有明显的突破与成长。

针对技术类产品，大部分是技术同学主导，在产品发展到一个阶段后，就会面临如何做后续的突破问题。我有两点建议：

（1）深入业务面临的问题，制定技术解决方案。

首先问自己几个问题：
• 业务方是谁？
• 现在业务在用自己的产品的时候都有哪些问题？
• 业务的诉求是什么？
• 自己的产品存在哪些问题？

深入挖掘这些问题，列出TOP5的答案，会发现有很多值得去做和突破的事情。

在最初的前端监控领域，产品都集中在针对采集上报的数据做统计展示阶段，通过数据指标的波动情况发现异常，然后接下来异常的定位则直接依赖于原始日志，原始日志如果覆盖不到信息，则只能靠业务同学自己复现和排查了。更多时候统计的数据无法解释，直接导致业务同学对数据的准确性产生质疑。所以监控产品要从最初的数据统计演进为问题定位。在这个阶段，主导并补齐相应的问题诊断链路。

（2）拓展视野 (技术&业务)

在主导一个产品方案/制定技术方案前，需要提前调研，辅助做出决策。调研的目的是拓展自己的技术&业务视野，其中对应的途径可以有：

• 竞品分析：当前成熟的产品听云、dynatrace、oneAPM等；

• 相关联领域同学输入/讨论：产品、后端应用监控同学等。

一个线上问题的排查，不是独立的前端监控或者应用监控就直接给到原因的，拓展自己认知的领域后，与后端中间件同学讨论，最终制定提供全链路监控的方案，来满足业务排查问题的诉求。通过这个案例可以看到，如果不跨出一步，是看不到也无法给出方案的。

业务场景不断拓展，建立保障业务稳定体系

在产品能力整体趋于稳定后，如何寻找自己的突破口？我也曾经走过误区，希望自己在技术上能有突破，所以出发点是现在有哪些技术可以在我的产品上体现出深度，直接导致越考虑越迷茫。其实，正确的出发点仍然是第二部分提到的：从业务痛点出发来制定解决方案。在这一部分不再是单点解决问题，而是体系化的考虑方案。

我有几点经验可以分享下：

开放的心态，合作共赢

技术类产品会收到各个业务方的诉求，在人力有限的情况下要支持各类诉求难度很大。这时候摆正心态，可以拉诉求方同学合作共建，更好的满足业务方诉求，同时让产品也不断拓展支持场景。

前端技术发展非常迅速，在最初小程序迅猛发展的时候，小程序的监控诉求也随之而来。但当时团队对于小程序的技术架构等并不熟悉，在此基础上做监控成本较大。其中钉钉有较多的访问量级较大的小程序，对于监控有较强的的诉求，在综合考虑业务诉求和产品拓展后，与钉钉同学合作共建支持各类小程序的监控诉求。在这次合作中，让我深刻体会到优势互补、事半功倍的效果。

体系化建设

在前期完成对于整个体系的了解，后续可以从这个体系涉及的各个环节来综合考虑解决方案。

随着业务的不断接入，监控所需的计算资源、存储资源等问题不断暴露出来，这时候我的工作不仅要保障业务稳定，更要保障平台稳定，所以在采集阶段、上报阶段、存储阶段、计算阶段考量制定保障方案。完成体系化稳定性建设后，不仅可以在大促前1分钟发现风险，也可以保障平台稳定支持大促中各类站点的监控诉求，并且在大促后沉淀赋能于日常的稳定性运维工作。