1. 首页
  2. 后端

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

应用实时监控服务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分钟发现风险,也可以保障平台稳定支持大促中各类站点的监控诉求,并且在大促后沉淀赋能于日常的稳定性运维工作。

结束语

每个人的经历与负责的工作各不相同,无法直接照搬别人成功的经验,同时很多总结的点都是知易行难,但可以从优秀同学的经验及总结中找到自己认可的内容,坚持并不断在自己身上实践,只有不断实践才能慢慢转化为自己的能力。

本文来自投稿,不代表程序员编程网立场,如若转载,请注明出处:http://www.cxybcw.com/203503.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code