作者：慕扉

利用实时监控服务 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 分钟发现危险，也能够保障平台稳固反对大促中各类站点的监控诉求，并且在大促后积淀赋能于日常的稳定性运维工作。

结束语

每个人的经验与负责的工作各不相同，无奈间接照搬他人胜利的教训，同时很多总结的点都是知易行难，但能够从优良同学的教训及总结中找到本人认可的内容，保持并一直在本人身上实际，只有一直实际能力缓缓转化为本人的能力。

原文链接
本文为阿里云原创内容，未经容许不得转载。