聽云科技首席科學家高級副總裁趙宇辰先生分享：

　　大家下午好，我來自于聽云。講之前我先切個題，今天下午的主題分為兩塊，一塊叫AI相隨，一塊叫云相伴，我這個場正好是AI相隨的最后一場，又銜接著云相伴，大家如果看我們這個公司的名稱聽云也正好跟云相關，其實聽云一直是從事AI賦能于云生態的一個廠商，具體我們做什么呢？可能很多在座的伙伴沒有聽過聽云，聽云是做應用性能監控，英文叫APM，我們這個應用是指廣義的應用，比如手機端的APP，包括網頁到后端的JAVA、程序等等，只要是數字化相關的東西，在我們看來都是為了輔助業務而做的應用，我們聽云的職責就是把這些業務上的應用正常的維持下去，保障我們業務的正常運行。

　　其實在APM領域，在應用性能監控方面，聽云作為國際權威榜單GartierAPM魔力象限里中國唯一入圍的公司，2015年到2018年也和國際廠商進行了很多次的交流，也受到了很多的認可。在Linux基金會的CNL榜單中監控類中國公司中，聽云和阿里、華為等等一起進入了這個榜單。

　　同時聽云是一個有十二年成長經驗的公司，在這十二年中我們服務了非常多的企業，比如金融支付、運營商及云服務、能源交通、科技制造、電子商務等等，小到幾十人的公司大到BAT，從互聯網到傳統的企業我們都服務過。

　　結合我們今天的話題，十二年前我們剛開始的時候服務了很多互聯網的企業，現在我們發現服務了越來越多傳統的企業，這是微軟的Satya說的一句話，現在不管你是高科技還是傳統企業還是互聯網，很多企業都運行在軟件或者應用之上，所有的軟件、所有的應用都依賴于數字化，我們正是服務好這些數字化。

　　我們也發現數字化帶來了很多挑戰，以前我們去銀行直接去柜臺就可以了，現在我們都通過手機APP來進行操作，這時候挑戰就來了，如果它的體驗不好的話，很多用戶可能會留下很多不好的印象，比如我們看蘋果APP市場里面，就會有很多評論，為什么這個APP打不開，為什么體驗這么差。

　　對于數字化來說帶來這么大的挑戰，但是一旦我的后端程序或者前端的APP不能正常工作了，直接影響了我后端業務的表現，直接影響到今天的貸款量，今天到底有多少業務中斷了，所以應用的性能直接影響到業務的表現。舉一個國外銀行的例子，大家可能都聽過巴克萊銀行的例子，是歐洲一個很大的銀行。在2017年某一個下午突然服務器崩潰，崩潰時間不長，只有90分鐘，但是這個崩潰造成了什么樣的影響呢？它造成的影響是用戶無法操作ATM，他在ATM取款的時候客戶很難正常操作，數千上萬客戶受到了影響，這個時候社交媒體就涌出了大量的客戶憤怒的抱怨，同時在媒體上面也有相應的報道。對于巴克萊銀行的直接經濟損失可能達到了上千萬元，有人說我就花17美分去購買一個香蕉它都不讓我去購買，我感到很羞愧。

　　我們看到應用是否正常運行其實直接影響到我們的業務，在數字化的情況下對我們運維產生了非常大的挑戰，比如我們簡單的在手機端查詢余額或者進行轉帳的簡單操作，在我們看來很簡單，輕觸一下手機轉帳成功。但其實在后端我們看下來它有非常多的不同的數據的操作，數據的交互在進行，可能我們輕輕的點擊后端生成了上千條的數據。現在我們也看到很多新的技術也引入進來，比如云計算、敏捷開發、大數據、人工智能、微服務等等，這些新的概念也涌進來，各行各業都受到了影響，不光是銀行。

　　如何在這些新的東西引入進來的時候，能讓我們把運維服務做好，同時把我們的業務做好，這是一個非常難的難題。整體來說我們聽云的解決方案是什么呢？在我們左邊看起來，左邊是真實的用戶，比如說它可能是通過APP去訪問這個業務，也有可能是通過瀏覽器去訪問這個業務，他經過了一系列網絡之后來到了右邊，基于云的基礎架構，私有化的基礎架構之上有一些自己的業務系統，這些業務系統可能訪問不同的程序。

　　聽云做的第一件事兒是什么呢？就是在全球有幾十萬的布點，在中國覆蓋了所有主流的鄉、市、鎮，聽云這款產品叫Network是模仿真實的用戶訪問情況，主動的訪問后面的應用情況，來判斷是不是應用正在正常的進行當中。同時光有這個也不夠，我們還想知道真實用戶是怎么樣的，所以我們看到在真實用戶這兒有一個聽云APP產品，它可以監控真實用戶APP的使用場景。在國內我們現在大概有6億終端，可能后面都嵌的是聽云的SDK，可以獲取到真實的APP的響應情況，有沒有崩潰，對于業務是否正常操作等等。這個只是覆蓋了用戶的前端，從用戶的角度來看這個問題。我們看看是不是能從后端也把它監控起來。在基礎架構之上我們也有一個聽云Sys的產品，覆蓋整個基礎架構的監控，同時在這個上面具體的業務，我們有聽云的Server來覆蓋這樣的產品，所以整體來說我們打造了一個全平臺的產品，希望從用戶端一直打造到最后的服務器端或者云上，或者私有化各種場景下我們都能把相應的數據采集到。

　　具體我們能干什么呢？第一個，輔助研發測試，第二個，日常運維，第三，體驗改進，第四，運營優化。我把這四點稍稍展開一點，講一些細節。研發測試其實痛點是什么，可能大家做業務的時候偶爾也會給研發測試的進行溝通，會發現研發測試很難去完整的測試出APP，我這個應用系統到底是否正常，它總會出現一些異常的情況。剛上線之后可能會出現大量不可控的bug和故障，IT團隊時時刻刻都處于救火的狀態，給用戶帶來不好的體驗，甚至嚴重影響業務的正常運行。面對這樣的挑戰，我們通過興業銀行的一個落地案例來體現聽云如何應對類似的研發測試場景。

　　在興業銀行這兒我們可以快速的定位排查，比如我們的代碼中有沒有BUG，手機APP有沒有崩潰，有沒有各種異常，同時我們覆蓋了興業各種主流的APP包括我的網銀、家庭銀行、信用卡包括一些小程序等等。

　　我們再看一個具體的實際的能力，剛剛也看到了，比如我們看到了一個后端的程序可能是跨過了多個服務器或者多個組件進行的，如何把這些服務器、組件統一的綜合的看起來，我們會有一個全棧溯源式問題追蹤，能快速的知道到底具體是哪個服務器或者哪個具體的代碼出現了問題。同時我們也具有代碼級的根源分析能力，以前需要一些專家級的人員來進行長時間的判斷，現在我們可以很快的把具體每一行代碼，哪一塊具體的錯誤給查找出來。

　　日常運營的時候其實我們發現對于一些正常出現的業務失敗，比如無法登錄，APP閃退等等，很多時候我們是被動的解決問題，比如用戶投訴或者社交網絡上有人抱怨了，或者APP市場里面有人提意見了，這個時候我們才被動的解決問題。同時這個問題很難去有效的定位，比如可能會進到網絡部門，網絡部門可能會覺得網絡沒有問題，那就流轉到數據庫部門，數據庫覺得數據庫也沒有問題，一看好像各個部門都覺得沒有什么問題，這就造成了一個非常耗時去解決真正問題的問題。

　　舉一個興業銀行的例子，這邊我們應用到了網絡金融部，覆蓋了多個渠道的服務器，當這個事情真正發生的時候，比如有一些故障真正發生的時候不需要用戶主動來找我，而是我通過一些報警的機制主動的發現一些問題，這些報警會主動指出一些錯誤，我可能還能通過報表到底是哪個指標出了錯誤。甚至我能看到每一個網絡請求，甚至每一個設備它們到底是哪里出現了問題，可以快速、精確的定位到具體的問題。

　　我們再舉一個模仿落地的例子，這個是用聽云Network主動去探測尋找問題的案例，這條線明顯跟其他線不太一樣，講的是三大運營商，說明網銀業務的可用性突然下降了，同時三大運營商的客戶都受到了影響。我們再仔細下降一點，發現大量的線上任務超時，很多頁面超過60秒都不能打開。這個時候我們就要分析問題了，要通過一些比較偏技術的，比如說Ping、Tracer去看。最后我們發現是數據庫的變更造成的，那可以很快的去確定這個范圍，不在網絡部，在數據部門，可以盡快的去解決這樣的問題。其實我們碰到了很多這樣的場景，同樣是三大運營商受到了影響，但是后來發現根本不是數據庫的問題，而是DNS被劫持了，那我們就需要去那個城市或者那個省份去解決DNS劫持的問題。

　　同時我們發現類似的場景還很多，背后的原因可能是多種多樣的。再舉一個例子，突然某一個運營商的波動特別大，它的延時特別長，那我們的建議是什么呢？趕緊聯系這個運營商，跟這個運營商探討一下到農行的線路是不是有什么故障。

　　所以我們看到一個簡單的問題，一個網銀慢的問題，可能它發生的根源是多種多樣的，只有通過數據和工具的手段能讓我們更好的服務好我們的客戶。這個例子也是20%的資源加載不出，可能在我測試這兒看來沒有問題，我的網站打開都沒問題，但是就有20%的客戶投訴說慢了，為什么呢？最后我們發現是適配的問題。

　　第三點，如何用聽云來提升今天的體驗和客戶成功。在滿足客戶的基本需求之后，我們很難去進一步提升客戶的體驗，比如說很多客戶會投訴慢、響應時間長、效率低等等，怎么去解決這個問題呢？我來舉一個在光大銀行落地的實例，光大銀行大家看，左邊是光大銀行的網絡和APP，右邊是他們后端的架構，同時我們就把聽云的APP產品聽云的Sys產品部署在廣大上，一邊是監控用戶端，一邊是監控后端。當用戶發生響應時間慢，加載不出來的情況怎么辦呢？這個時候我們會聯系研發人員，去看到底崩潰、慢請求是什么原因。甚至我們能夠做到個性化的判斷，可能個別的用戶他不能訪問這個網站，但不代表所有客戶不能訪問這個網站，所以我們可以進行個性化的用戶體驗，具體的去排除潛在的原因，然后把這個原因提交給業務人員，同時業務人員再把類似的信息提交給客服人員，這時候客服人員可能就可以確定確實剛剛發生了這樣的問題，問題可能出在什么地方，我們可能會用什么樣的方式來去解決這樣的問題。

　　為什么剛剛說可以個性化呢？我們可以把具體的用戶定位出來，比如根據他的手機號或者唯一標識符可以具體定義到它發生的崩潰，比如在崩潰之前他進行了哪些操作，可能查了余額又提交了一個貸款申請，突然崩潰了，這個操作軌跡我們都能還原出來，以及相應的技術方面的代碼歸棧等等我們都可以拿出來，第一是幫助客服人員去確認確實有這樣的問題，更快的把這些錯誤信息傳遞到后端，讓開發人員去解決這樣的問題。

　　第四個，運營優化。在銀行內部經常會進行一些營銷活動，比如需要拿一些用戶畫像，線上的營銷活動的跟蹤，精準營銷等等。我們也可以把相應的數據拿下來，不管是從APP端還是網頁端，我們都可以做漏斗轉化、留存分析、用戶體驗包括最后的用戶路徑，包括打用戶行為溯源等等。

　　剛剛講四大場景，研發測試、體驗改進、日常運維、運營優化，我們講了三個例子，農行、光大、興業。聽云在成長過程中也在不斷的發展，我們立足于應用性能監控也做了多方面的拓展，一方面希望能做到橫向拓展，能拓寬業務邊界，不光是我們知道有哪些代碼錯誤，哪些報錯，404，網頁錯誤等等，這些是給研發人員看的。在業務層面看是需要知道業務的可能性是怎么樣的，手下可能有幾十個業務，業務下面可能還有子業務，它們的表現怎么樣，有多少業務今天已經完成了，有多少業務出錯了，這是我關心的事情。如何用業務的信息跟IT的信息結合起來，幫助我們的業務做更好的決策。

　　另一方面我們希望能做縱向擴展，利用AI人工智能的技術，希望能幫助客戶提高效率，減少解決問題的時間，盡量能幫助他們更好的實現業務上的發展。

　　一個是我們如何結合業務運維，這是南方電網的案例，可以把南方電網的業務建模成N層的構建，比如它有它的營銷體系、4A平臺、資產管理等等，這些業務之下還有他們的子業務，可能是呈樹狀結構。對于每個業務流程怎么去分析，他們的業務操作有哪些，對于全棧的業務，各種指標如何做分析和判斷，做數據挖掘，這個是我們業務運維的場景。

　　同時在AI方面，一個是智能警報，傳統上來說，可能很多時候我要做報警，我要去手動設置非常多的東西，去指定我要去什么東西做報警，上限是什么，下限是什么，閾值是什么，在現在看來我們希望把產品做的盡量簡單。用戶幾乎不需要進行任何的輸入，背后我們有多個算法在同時進行各種操作，判斷出來是不是當前的場景異常，然后提醒客戶。

　　其實我們發現異常之后這只是第一步，我們告訴你可能你現在APP有點問題，你的整個業務受到一些影響，但是客戶得解決問題，他得知道到底這個錯誤在什么地方，怎么去定位這個問題。比如我們看到這邊有一個波峰，在那段時間可能整個響應時間變長了，對于業務方來說用戶體驗就下降了，對于運維來說也很難去挖到具體的根源是什么。

　　我們做了一鍵根源分析的系統，結合了大數據和實時計算，能夠快速的一鍵定位到真正的根源。比如這個例子，可能某一個城市的主站網絡發生了問題，或者新的Android版本發生了問題，定位這個問題我可能需要幾天甚至幾周的時間去把這個問題，現在我只需要輕輕一點，通過后臺大量的數據我可以分析出這個異常的潛在的根因是什么。

　　在我們聽云看來，整個數字化分為五步，從一開始的IT是獨立成本中心，后來逐漸成了IT支撐業務，到后來成了競爭優勢，我們聽云希望幫助客戶在轉型當中讓數字化成為業務的本身，同時可以讓我們的數字化和IT從一個成本中心變成它真正的競爭優勢。