一個CEO的內部分享：企業(yè)級IT服務的變與應變

 移動互聯網的廣泛應用和云計算的高速發(fā)展，給企業(yè)的傳統IT架構帶來了巨大的挑戰(zhàn)：用戶體驗前置、IT基礎設施廣泛云化，產品迭代速度越來越快，傳統運維隨著DevOps理念的普及正逐漸轉向云運維、業(yè)務運維。

云智慧從2010年推出監(jiān)控寶，至今已經形成了一套完整的企業(yè)級應用性能解決方案閉環(huán)，以解決企業(yè)用戶體驗前置帶來的挑戰(zhàn)，和云計算的快速發(fā)展帶來的系統架構變化的挑戰(zhàn)。云智慧這幾年為什么會走出這樣一條產品發(fā)展路徑?其企業(yè)級應用性能解決方案是如何煉成的呢?

以下是云智慧CEO殷晉對云智慧產品發(fā)展路徑的思考和分享：

大家現在都知道，云智慧圍繞應用性能提供了一套完整的企業(yè)解決方案，形成了云智慧的吉祥三寶：監(jiān)控寶，透視寶和壓測寶，那么為什么云智慧要選擇這種產品發(fā)展路徑呢?云智慧產品的發(fā)展路徑不是拍腦袋作出的決定，更不是復制國外APM產品得來的，其“原動力”非常簡單：依據真實的客戶需求，發(fā)現用戶的真實問題并予以解決，這就形成了云智慧的三款產品。

監(jiān)控寶是如何成為站長神器的

回溯云智慧的發(fā)展歷程，為什么會在2010年上線第一款產品監(jiān)控寶呢?當時的出發(fā)點其實非常簡單，我們希望從運維同學最痛的點出發(fā)，來解決他們無法實時感知自己的網站在用戶端是否能順利訪問的問題!

在2010年前后，中國的網絡狀況是非常差的，連基本的互聯互通都會經常出問題，DNS更是經常造成大面積的網絡癱瘓。運維最痛苦的事，就是完全沒有辦法知道用戶是否能夠訪問自己的網站。所以那個時候，有些站長工具流行起來，包括現在大家還能看到的“阿里測”等。用戶投訴說網站訪問不了的時候，運維都會去用阿里測來Ping一下自己的服務器，看看哪些地方有問題。但是這種做法明顯屬于亡羊補牢，因為用戶已經受到了影響，更何況大部分用戶在這種情況下只會罵一句：什么破網站，然后默默的關掉瀏覽器!

監(jiān)控寶的出發(fā)點就是想解決這么簡單的一個問題。開始的產品思路也非常簡單，如果把HTTP/Ping這種一次性使用的工具變成一個自動化的，周期性的監(jiān)控，那么它就變成了一個服務，而按照這個思路出發(fā)，監(jiān)控寶就做出來了!

監(jiān)控寶問世以后，受到了廣大用戶的歡迎，用戶數量增長很快，后面的發(fā)展基本上就是用戶真實需求在驅動產品的發(fā)展了。監(jiān)控寶的功能從最初的網站監(jiān)控延伸到服務器監(jiān)控、服務監(jiān)控，再到自定義監(jiān)控。做完這些功能以后，監(jiān)控寶在功能上的發(fā)展出現了一段停滯期，因為從基本的運維監(jiān)控需求出發(fā)，這幾個功能已經覆蓋了中小客戶的日常運維需求，包括運維巡檢的需求。

監(jiān)控寶的商業(yè)化之路

云智慧花了一段時間不斷優(yōu)化監(jiān)控的使用體驗，同時開始考慮監(jiān)控寶的商業(yè)化之路。因為經過一段時間的用戶接觸，我們發(fā)現監(jiān)控寶在設計之初，對企業(yè)用戶的服務理念是有重大缺陷的。

監(jiān)控寶最早的用戶以個人站長為主，所以那時候沒有賬戶的概念，只有用戶。但對于企業(yè)來說，企業(yè)里面有團隊，有團隊就會產生協作的需求，所以當時采用了一種共享用戶的策略來滿足這種需求。

為什么會采用共享用戶的方式呢?因為那段時間恰逢微博興起，監(jiān)控寶完全按照分享的思路來設計，這非常有利于傳播。利用分享的概念，以病毒式傳播迅速樹立起口碑，所以監(jiān)控寶的早期用戶增長非?？?，迅速覆蓋了運維圈，這是好處。

但是不利之處在于，當我們真正開始把監(jiān)控寶賣給運維人員超過3個人的公司的時候，我們發(fā)現，原來的模型無法支持企業(yè)級的權限控制和協作。于是才有了監(jiān)控寶在功能上幾乎停滯了半年，我們花了大量的時間和精力去重構底層的賬戶模型，監(jiān)控寶才有了企業(yè)版的概念和模型。

當監(jiān)控寶真正的不斷應用于大企業(yè)的時候，我們開始考慮市場和需求的變化，從2013年開始，監(jiān)控寶陸續(xù)的增加了很多功能：內容監(jiān)控，API監(jiān)控，網頁性能監(jiān)控，安全監(jiān)控等等。

每一次產品的迭代和發(fā)展，都是云智慧面對市場的一個選擇，比如：

l 內容監(jiān)控主要是想把監(jiān)控寶發(fā)展到政府部門對網站監(jiān)控的市場，但是后來證明我們在很小的規(guī)模的時候不具備攻克政府客戶的能力，所以選擇了把這個功能下架;

l API監(jiān)控是因為我們看到了移動App的迅猛發(fā)展，對運維形成了新的挑戰(zhàn)，運維需要新的工具來解決這個問題;

l 網頁性能監(jiān)控是因為我們想把網頁性能更加詳細的展示給客戶;

l 安全監(jiān)控是想把監(jiān)控寶的價值進一步提升，為用戶提供一站式的監(jiān)控服務。

這就是監(jiān)控寶的發(fā)展過程，我們能夠發(fā)現，監(jiān)控寶的定位非常明確，就是給企業(yè)的運維工程師提供一個高效易用的工具，把運維的日常巡檢工作自動化，把他們從繁瑣的日常監(jiān)控工作中解放出來，做更有價值的事情。

因移動互聯網而生的透視寶

作為企業(yè)服務型公司，產品不斷的發(fā)展總要有一個路徑可循的，我們遵循的路徑就是IT成熟度模型。

這是當初考慮開發(fā)透視寶這個產品時的思考模型，里面有兩個維度，X軸是IT成熟度，Y軸是商業(yè)價值。監(jiān)控寶的定位在于一種簡單的場景，解決最基本的全棧IT基礎設施監(jiān)控的問題，對于很多IT成熟度很高的公司來說，這種工具的價值并不明顯，因為監(jiān)控寶解決的問題在他們的成熟度下已經被解決的比較好了。

于是我們就開始考慮，對于IT成熟度很高的客戶，他們有什么樣的需求，需要什么樣的產品呢?非常幸運的是，當我們思考這個問題的時候，我們正處在一個最好的時間點：

1.移動互聯網飛速發(fā)展

2.云計算快速普及

在這個時候，如果我們還是考慮切入傳統的ITSM，ITOA， ITOM等等領域，估計已經無路可走了。移動互聯網+云計算帶來了一個新的命題，叫做用戶體驗前置。什么是用戶體驗前置呢?我們看看傳統的銀行系統，如果你不去柜臺，或者登陸他們的網銀，你是不會接觸到他們龐雜的IT系統的。但有了移動互聯網，一切都不一樣了，通過手中的App/微信公眾號等，開始無縫的和他們的IT應用系統打交道，IT應用再也不是看不見摸不著的東西了。

這塊是一個戰(zhàn)略的空白區(qū)間，云計算的發(fā)展更是給企業(yè)傳統IT應用架構帶來了巨大的變化。用戶體驗前置，IT應用架構變化，但是市場上沒有一個很好的工具能夠幫助用戶解決他們在這兩塊的監(jiān)控難題。

在傳統的IT成熟度很高的企業(yè)級客戶那里，原來的IBM、HP、CA、Oracle、Compuware、Riverbed、Netscout等公司已經給他們建立了非常完善的監(jiān)控系統，如果沒有移動互聯網和云計算的沖擊帶來的變化，云智慧作為一個創(chuàng)業(yè)公司肯定是沒有什么機會的。

正是因為行業(yè)的巨大變化，作為創(chuàng)業(yè)公司，云智慧的機會就來了。我們發(fā)現這塊市場幾乎是空白的，但是客戶的問題又是客觀存在的，所以開始考慮做透視寶這款產品。

剛開始做透視寶的時候，我們并沒有完全想清楚這個問題，所以立項的時候，是以監(jiān)控寶企業(yè)版2.0開始的。但是在不斷梳理用戶需求的過程中，我們發(fā)現，這塊需求完全不是監(jiān)控寶應該覆蓋的用戶需求范圍，所以我們決定把它作為一個獨立產品來做。

那么怎么做呢?

上面那張圖是我們一開始考慮的產品技術架構，下面這張圖是我們梳理清楚了透視寶要滿足的需求之后畫出來的端到端應用監(jiān)控架構圖。我們認為，如果要解決用戶體驗前置的問題，必須從用戶端著手開始監(jiān)控和采集數據，同時在整個用戶體驗交付鏈條的每一個環(huán)節(jié)都要進行監(jiān)控。采集所有的數據，通過對數據的分析，來發(fā)現和解決可能發(fā)生在每一個環(huán)節(jié)的影響用戶體驗的風險因素。

透視寶從2014年4月22日開始立項，到了8月份，我們推翻了原來的設計和架構，重新做了一版，并于2014年12月18日對外發(fā)布了第一個版本的產品。為什么會推翻重來，就是因為我們在開始沒有把透視寶的真正需求梳理清楚，上面的兩個圖沒有搞出來。當我們把透視寶的定位搞清楚之后，自然形成了一個產品的價值階梯。

同時也梳理清楚了監(jiān)控寶和透視寶這兩款產品的邊界：

現在的透視寶產品發(fā)展，基本上都是延著這條路徑在不斷的向前發(fā)展。有了監(jiān)控寶+透視寶，云智慧基本上建立起真正覆蓋IT成熟度較高的企業(yè)級用戶需求的產品力。我們第一次有能力來服務企業(yè)級客戶，而這些產品的發(fā)展就構成了云智慧在2015年從SMB市場向企業(yè)級客戶市場邁進的動力。

企業(yè)級用戶的大規(guī)模壓力測試需求

到了企業(yè)級用戶市場，我們又發(fā)現了新的用戶需求痛點，就是性能測試問題。在SMB客戶那里，產品上線之前不會做大規(guī)模的性能測試，很難產生性能測試需求。而答案還是在上面的那張IT成熟度模型圖里面，因為SMB客戶的IT成熟度較低，同時網站/應用的商業(yè)價值也比較低，所以他們不會、也沒必要投入那么多資源來做這種事情。

而在IT成熟度高的企業(yè)級客戶那里，壓測是產品上線前的必備流程，甚至在很多DevOps實踐比較好的企業(yè)里，壓測不僅用于上線前的測試，而是和他們的CI系統集成，作為每次Build都要執(zhí)行的常規(guī)監(jiān)測手段，從而實現Release Automation。

然而現在市面上的性能測試軟件幾乎在這種新的變化面前是無能為力的。用戶體驗前置要求性能測試基于真實的場景和真實的鏈路來進行，而和CI系統的集成也不是那些傳統測試軟件能夠搞定的事情。

所以基于云智慧全球分布式部署的服務器網絡、公有云資源、客戶私有云資源構建的壓力測試網絡，根據真實用戶在網站和APP上的使用場景進行測試，提供開放的API接口可以讓CI系統驅動測試自動運行的壓測寶就應運而生了。

有了壓測寶，云智慧的應用性能解決方案形成了一個閉環(huán)，能夠幫助企業(yè)解決用戶體驗前置帶來的挑戰(zhàn)，以及云計算的快速發(fā)展帶來的系統架構變化的挑戰(zhàn)。

Q：能說說APM技術各種可能的發(fā)展方向嗎?在這些方向中，云智慧都會去哪里?

A：APM現在的基本技術有幾個關鍵字，端到端，軟件探針覆蓋各種開發(fā)語言和框架。我認為未來可能會有幾個演變的方向。

1， 各個基礎的云平臺會默認集成APM的技術來幫助云上的應用更好的運行，和云的深度結合是一個方向

2， 微應用架構帶來的全新挑戰(zhàn)

APM現在主要的價值在于復雜IT應用架構的場景下幫助用戶快速的自動繪制應用拓撲和代碼級問題定位，但是微應用部署本身就是對復雜的IT應用架構的解耦。所以在微應用架構不斷演進的情況下，APM的后端監(jiān)控技術和方案也會不斷變化。

在用戶入口層面(App， Browser， H5 in wechat/dingding)的監(jiān)控會越來越重要。對于我們來說，怎么能夠讓透視寶更加開放，易于和用戶的使用場景整合是一個值得深思的方向，就像監(jiān)控寶，用戶可以完全通過API來無感知的使用監(jiān)控寶。

生成海報

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。