作者：慕扉

應用實時監控服務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分鐘發現風險，也可以保障平臺穩定支持大促中各類站點的監控訴求，並且在大促後沉澱賦能於日常的穩定性運維工作。

結束語

每個人的經歷與負責的工作各不相同，無法直接照搬別人成功的經驗，同時很多總結的點都是知易行難，但可以從優秀同學的經驗及總結中找到自己認可的內容，堅持並不斷在自己身上實踐，只有不斷實踐才能慢慢轉化為自己的能力。

推薦文檔：
阿里雲業務實時監控服務ARMS：https://www.aliyun.com/product/arms
阿里雲業務實時監控服務ARMS前端監控：https://arms.console.aliyun.com/#/retcode
阿里雲業務實時監控服務ARMS前端監控文檔：https://help.aliyun.com/document_detail/58652.html

ARMS是阿里雲原生團隊非常重要的一款產品。目前已經服務瞭如人人視頻、完美日記、暢捷通等眾多客戶，雲原生中間件的技術和產品體系，如何幫助企業降低業務的運行成本和技術風險？如何提升業務的迭代速度？針對雲原生場景下常見的技術挑戰和痛點，阿里雲、人人視頻、暢捷通技術專家有哪些技術經驗和思考？我們將在9月18日13:00 雲棲大會「雲原生中間件」全面揭祕！

掃碼或點擊閱讀原文預約直播，獲取雲原生中間件的實戰經驗和落地思考。
閱讀原文：https://yunqi.aliyun.com/2020/session91