本文整理自 GOPS2017·上海站演講《面向千萬級網際網路證券使用者的事件運維之路》

前言：

本文的主題是《面向千萬級網際網路證券使用者的事件運維之路》。

一、背景介紹

本文主要包含以下幾塊，首先看一下背景介紹。

1.1、網際網路轉型

傳統的研發團隊已經滿足不了當時業務的發展，所以我們也緊急的建設了網際網路的研發團隊。從圖上可以看到從91年到2014年底的時候我們的存量使用者只有150多萬，但是近幾年來隨著業務的發展，到2016年底我們的存量使用者達到了1000萬。

在使用者量不斷地增加，給我們整個研發團隊帶來了什麼問題？我們發生了怎樣的故事？

1.2、暴增下的影響

下面我們來看一下使用者暴增下的影響？2014年業務量趨勢增加，使用者上報的事件數也開始慢慢的上升起來。所以各個業務部門的投訴也開始多了起來。

直到2015年4月份的時候就形成了運維背的黑鍋，收到事件後不會做過多的分析，就會把事件轉給我們的研發，研發也是在這種被強幹擾的模式下完成其他需求的開發。他們這個時候就開始抱怨需求太多，沒有時間查生產問題。所以我們的生產事件得不到很好的處理。

我們當時的局面很不理想，我們的使用者體驗也是急劇下降。我們遇到這種難堪的局面怎麼解決呢？平安證券事件處理組同樣也是在這種情況下成立的，我們在成立之前我們也調研過其他的公司，比如說攜程和餓了麼，以及平安集團的電話客服中心。

1.3、事件處理組成立

我們首先來看一下他們的工作模式，我們先看一下95511這一塊，他們是以純業務的思想去幫助使用者解決問題，只需要查詢一些簡單的資訊，主要的工作是收集問題和分發問題，大部分的問題是需要我們研發團隊進行協助才能夠完成的。

但是攜程和餓了麼這兩家公司不太一樣，是以技術為主，需要查詢伺服器日誌，只有一小部分比較複雜的問題才會流轉到研發團隊。隨著整個研發團隊後續不斷地擴大下對事件處理的影響，我們最後考慮以技術為主，業務為輔的思想成立事件處理組，我們的組成部分是以開發和測試，需要具備一定的技術要求。

我們首先處理的是平安證券的開戶業務，隨著我們對這個系統不斷地進行總結和歸納，我們極少的問題會流轉到我們的研發團隊，這個時候其他的系統也同樣遇到了比較難堪的局面，所以我們也陸續承接了其他的系統。

到目前為止生產事件處理小組總共8個人，分別在上海、深圳，我們現在處理了十大核心繫統，包括平安證券的帳戶系統，主要對事件的分析、跟蹤以及提供解決方案。

1.4、事件處理流程

下面看一下事件處理組處理事件的流程。首先是接受事件，當我們的使用者發生問題之後就會找相應渠道經理和財富經理，我們統稱為客戶經理，他們會進行簡單的分析之後會把問題上報給事件處理組。我們收到後會做一系列的分析，查詢ELK的日誌系統，以及app埋點資訊和資料庫判斷問題。

當我們發現相容性的問題，或者根本查詢不到使用者日誌，這個時候我們會轉給測試人員重現生產問題。如果我們遇到一些解決不了的事情，我們也會轉給研發團隊讓他們進行協助。如果發現歷史資料的問題，我們會把指令碼整理好給到運維同事審查和執行。

如果發現是一些產品配置的問題，會找產品經理和運營的同事，把相應的產品資訊修改正確。最後我們處理完事件後就會形成一個知識庫，主要包含的是問題發生的描述以及問題的解決步驟。我們的目的是當其他的同事如果遇到相同的問題，來檢視知識庫就可以很容易的把這個事件解決掉。

我們還會根據事件的數量和嚴重程度考慮是否需要加入到我們的監控平臺去。下面分享的一些課題主要包含在我們處理事件的流程中遇到了什麼困難，我們需要通過技術為主的方式來把這個問題解決掉。

二、上報通道

下面我們來看一下上報的通道。

2.1、原有上報渠道

這些客戶經理遇到問題之後肯定也需要通過一個系統把事件報到事件處理組，平安的事件管理遵循的規範，有一套超過十年的ITSM，同樣也對接了我們集團的OA系統。到目前為止已經承接了10多家專業子公司，任務通道達到800多個，年運營量超過幾百萬單。

但是有一個渠道打破了我們原有上報方式，我們上面說到了，在2016年底的時候我們的存量使用者達到了1000萬，開戶日均200到20000，開戶量劇增了100倍，交易量也是直線上升，事件數也是成倍增加。導致這些客戶經理提交ITSM不是特別流暢，處理事件也不是特別的及時，投訴就開始多了起來。

我們平安是一家綜合金融集團，它有保險、銀行和證券的業務，2015年、2016年諸多的存量使用者是保險業務員帶來的業務開拓。當他們遇到問題之後也同樣需要把問題提交到ITSM上面來，我們的保險業務員大部分的時間在客戶的現場，不在辦公區域，所以他們提交上來比較困難。

2.2、微信渠道

當然我們為了解決我們的渠道不太流暢的問題也緊急的建設了微信渠道。現在微信渠道總共有兩個海量獲客群，每個群裡有500個客戶經理。

2.3、微信群問題

• 首先讓他們通過微信的方式把問題反饋給事件處理組。但是經過執行一段時間之後我們發現微信渠道有很大的問題，上報的成本比較低，質量比較差，往往是一句話，股票交易不了。這樣一句話給事件處理組不太好處理，因為我們需要根據使用者的資訊查詢使用者的日誌才能判斷，所以來來回回溝通成本比較大。
• 第二塊，由於微信群裡的人數比較多，資訊交叉比較錯亂，滾動刷屏的概率比較大，所以我們的遺漏率也是比較高的。
• 第三塊通過微信群跟蹤處理問題比較麻煩，不太好維護，不太好統計資料分析。
• 並且我們沒有人力一一回復這些微信群裡的資訊，所以我們的效率也是比較低下。

2.4、移動端的反饋系統MSS

與此同時我們深刻認識到這些保險業務員通過移動端反饋系統是他們的需要。很多保險的同事在我們客戶的現場，不在辦公區域。就為他們建設了移動端的反饋系統MSS，讓他們通過系統自助的進行提交和反饋。

MSS並不是特別的複雜，只是提供了一套簡單的H5的前後臺。上報起來也是比較方便的，只需要輸入使用者的資訊和使用者發生問題的描述，以及使用者發生問題的截圖，就可以把問題上報到事件處理組。

我們收到問題之後也會通過MSS後臺把這個問題進行處理掉，處理掉之後他們也可以根據前臺查詢自己提交問題處理的進度。當MSS系統執行一段時間之後我們也做了很多的問卷調查，有很多客戶經理他們認為我們回答了一些問題還想對這個問題進行繼續提問。

所以我們加入到第二張圖就是互動式的聊天功能，他們如果對事件還有疑問可以發離線訊息，我們會在MSS後臺給他們一一進行答覆，直到他們明白為止。

所以我們就這樣解除掉了我們對微信的捆綁，不過這個過程也是比較痛苦的，因為我們需要反覆的和這些客戶經理進行宣導。我們為了解決事件及時率的問題，我們也引用到了微信企業號，上報人把這些問題上報出來之後讓他們第一時間知道有新的事件上報過來，需要利馬處理。

當我們通過MSS後臺處理掉之後也會給我們的上報人推送一條訊息，讓他們知道我們處理的解決方案需要他們緊急幫使用者把這個問題解決掉。通過移動端的反饋系統解決掉了訊息比較雜亂、渠道不太流暢，以及處理效率比較低下的問題。

2.5、實施效果

下面看一下MSS推動的走勢圖。大部分是通過微信的渠道把這個問題上報給我們事件處理組。經過我們不斷地對系統進行完善，不斷的宣導，90%的問題是通過MSS這個系統把問題提交上來的。

三、資料構造

下面我們來看一下第三塊，資料構造。

3.1、重現資料

我們發現一些相容性的問題，或者根本查不到使用者的日誌，我們需要轉給我們的測試同事重現我們的生產問題。可是我們往往發現我們的測試同事在我們的測試環境下面構造測試資料的時候是比較困難的，原本的方式是我們和測試人員總結了一些大量的sql指令碼，需要什麼帳號的時候對資料庫進行一系列的操作就可以得到我們想要的帳號。

• 第一塊準確性比較差的問題。因為我們有大量的sql指令碼和大量的儲存過程依賴的關係比較強，很容易出錯。
• 第二塊維護成本比較大，當開發修改了業務的場景，導致我們構造出來的測試資料的正確性不夠，所以來來回回和他們的溝通成本比較大。
• 第三塊資料來源比較多。
• 第四塊，如果對資料庫來回切換操作，比較耗時，也是比較費力的過程。

3.2、功能特點

下面我們看一下我們需要一個什麼樣的平臺？我們需要能夠準確、快速的在測試環境下能把測試資料構造出來，需要構造常規的資料和複雜的資料來支援多場景、多業務，需要提供視覺化的介面給我們，操作起來比較容易，並不是大量的sql指令碼。

3.3、UTA資料構造平臺

所以我們提出需要一個平臺化的概念，這個時候就和測試人員共同建設了資料構造平臺，他們提供業務邏輯，我們來實施程式碼工作。UAT資料構造平臺功能並不是特別多，我們只需要常規資料、複雜資料和報表的功能。

下面是常規的資料構造，構造起來比較容易，只需要輸入使用者的姓名和身份證號碼。輸入完之後就可以把我們想要的帳號資訊構造出來。大家看到介面比較簡單，複雜的資料構造的介面沒有貼出來，只是介面上的元素多了許多，比如是否需要加入可用、可取，是否需要設定我們的風險評測的等級。

下面我們來看一下具體的實施情況。我們原本是想通過程式碼來呼叫總結的指令碼達到我們想要的帳號，可是為了避免我們的研發團隊頻繁的修改業務場景，我們維護程式碼工作量比較大。最後改用調他們的介面業務邏輯，構造常規的資料需要呼叫35個介面，可想而知資料構造的後臺是多麼的複雜。

3.4、資料構造體系

構造資料平臺完成我們的三大體系：

• 第一個是帳戶體系，設定使用者資料的相關操作。
• 第二塊是三方體系，需要繫結三方存管，多方存管。
• 第三塊需要給我們的帳號加入一些協議來完成我們的交易體系。

3.5、資料構造平臺使用情況

下面我們來看一下使用的情況。我們的資料構造平臺是今年6月份開始建設起來的，建設起來之後首先給的是事件處理組的人員和測試人員進行試用。試用完之後需要反饋修改資訊給我們，從而來完善我們的系統。到目前為止我們每天在這個平臺上構造80—90條測試資料，不僅僅是為了測試生產事件，更多的資料是測試版本需要的測試帳號。

然後是結果的分佈，分為成功和失敗，以及正在處理中的資料。大家可以看到10%的失敗率，是因為開發在部署版本的時候導致環境不可用帶來了失敗。

最後是個人使用的統計。這一塊也統計過，通過傳統手工的方式構造出一條測試資料，就算指令碼極為豐富，對資料庫的表結構足夠熟悉的情況下，通過平臺來構造出來的效率足足比手工的效率提高了8倍左右。

四、服務中心

4.1、資料分析

下面我們來看一下第四塊，我們的服務中心。下面是資料分析，是資料化可視平臺。我們需要分析各個系統的執行情況，如果讓我們統計每週或者每月的資料走勢對我們來說比較困難，我們就在想能不能把每天處理的事件沉澱下來，定期進行分析。

所以我們把一些離散的資料匯聚起來，讓整體的資料有一定的邏輯。所以把上面ITSM以及MSS資料收集起來，放到資料倉庫裡邊去，通過資料化可視平臺展示出來。今天主要看一下週報，遇到了什麼困難。

4.2、事件分析

上面就是事件處理組的週報，這塊只是去掉了事件解決率和及時解決率的走勢線。我們需要把各個小類的問題綜合成幾大類：資料類、程式類、諮詢類。諮詢類的走勢就代表著產品的互動問題，或者新的業務規則，或者我們業務規則發生改變之後帶來的這些諮詢。

可以從上面這個圖表看到近兩個月的資料走勢，平均諮詢類的走勢佔比每期總量的80%以上。所以這麼龐大的資料對於我們事件處理組來說是比較頭痛的一個問題，因為這些諮詢類的問題比較多，對我們的工作量產生比較大的影響。

這個時候就和運營的同事商討，如何把諮詢類的佔比降下去。首先產品的互動需要設計的更加人性化一點，其次把我們總結出來的知識庫形成文件發給客戶經理，讓他們知道一些簡單的解決方案，讓他們知道怎麼處理它，但是效果並不是特別好。

這個時候有個大膽的想法，我們能不能把這些同事和客戶經理匯聚在一起，我們通過互動交流進行知識的分享。

4.3、直播平臺

最後我們選擇了平安集團的知鳥直播平臺進行知識的分享。我們作為主講嘉賓把一些疑難雜症的問題通過主動的方式傳遞給他們，讓他們知道這些常見諮詢問題的處理方法。做法也比較簡單，到目前為止每個星期二的晚上八點鐘做知識的直播，每一期是一個小時，30分鐘的主講和10分鐘的做題，15分鐘互動交流環節。

我們的直播主要分為四期，第一期是事件流程分享，告訴他們如何正確的把事件上報到我們的事件處理組，事件處理組處理事件的優先級別是什麼，都需要告訴他們。其餘的幾期是把我們上報問題比較多的問題拿出來一一講解，讓他們知道怎麼去幫助使用者解決。

4.4、直播資料

下面看一下直播這一塊的資料，主要分為總觀眾人數和總瀏覽人數，總觀眾人數是直播同時線上的人數，總瀏覽人數需要加上回看的資料。因為我們幫他們進行直播分享之後，這個時候我們也會同樣給他們傳送一些訊息，讓沒有來看的一些同事來回看我們的視訊。

同樣也會定期的分析，不管是週報還是月報，如果發現他們有問題我們也會進行知識的直播。其實做法相對比較容易，成本也不是特別大，但是效果還不錯，只是說敢不敢於去嘗試的問題。

4.5、QA服務中心

通過每週總結熱點問題形成知識庫，給到這些客戶經理進行培訓，進行知識的分享。

在我們直播的互動交流環節中，我們有很多客戶經理他們提到，他們想通過一個系統來查詢我們的解決方案，並不是我們提供給他們的文件。

其實我們每個系統都有他們自己的幫助中心，但是對於這些客戶經理而言查詢起來比較困難，我們就為他們建設QA的服務中心，專門針對於客戶經理的幫助中心。

通過幫助中心達到服務檯的自助服務，主要是業務的流程和已知問題，和各個系統的熱點問題都會放進來。

4.6、AQ服務中心展示

下面我們來看一下QA服務中心，主要包含的是首頁、列表頁以及內容展示頁。我們先看一下首頁，包含的是各個系統的模組可以根據關鍵來查詢我們問題的解決方案。

下面是我們的熱點問題，我們需要把最近經常處理的問題總結出來，放到我們的QA服務中心裡面去。

下面是我們的內容展示頁，有很多流程圖是事件處理組提供的，但是我們提供之前也給到產品經理確認，每週如果沒有特殊的情況下我們會進行維護一次，會在我們的事件處理組的週會上面把熱點問題討論出來。

五、監控

下面我們看一下我們的第五塊監控。

5.1、被動轉主動

其實往往大批量的使用者發生之後我們都需要通過使用者上報之後我們才知道什麼地方出了問題，我們需要解決它。沒有達到提前告警的功能，或者說當用戶想把這個問題提交上來的時候我們已經知道，或者我們已經在解決中，或者已經解決掉了。所以我們深刻認識到問題的所在。

所以需要把被動的方式轉化成一個主動的過程，我們需要提醒告警，處理大批量的問題，來提高我們使用者的體驗。

其實在平安證券大大小小的監控比較多，CPU、流量，空間，重大的監控比較多，這些對事件處理組而言並不是那麼重要，因為我們需要根據我們的規則做我們自己的監控。

下面是我們在處理開戶業務的時候總結的一些規則，我們主要對每日申請的開戶量和開戶的詳情以及開戶渠道的分佈做的一系列監控。

5.2、監控實施

上面我們說到了在我們處理事件的過程中我們通過事件的數量和處理事件的嚴重級別來考慮是否需要加入到監控的需求裡面去。定期的觀察事件的走勢，然後來做一系列監控。

上面這一塊舉了一個具體的例子，我們的帳戶系統和交易系統狀態不太一致的情況做了監控，這個專案上線的時間並不是特別長。主要的原因是使用者投訴起來，處理非常麻煩。

我們首先說一下專案的背景，每天交易系統和帳戶系統會拿到清算檔案做一些清算，修改資料庫的股東卡的狀態資訊。但是往往我們發現有些使用者的狀態不太一致，所以我們做了監控。

5.3、監控成效

下面看一下我們監控的成效，主要是正常資料和異常資料的分佈圖，其次是異常資料的個數，可以點選列表詳細頁看到具體使用者資料。

第三塊是我們告警的方式，到目前為止我們現在主要是以郵件的方式告警，我們收到郵件之後就會把這些問題解決掉。最後我們看一下指標的引數，通過監控之後，近期沒有收到使用者的投訴，不過根本問題的原因還需要研發檢查自己的程式碼，把根本的問題解決掉。

所以我們通過把被動轉化成主動的過程，處理批量使用者的問題來提升使用者的體驗。

六、總結

下面看一下總結，總結主要分為以下三塊。

• 第一，需要關注處理事件的每個環節，如果發生問題需要通過技術為主的方式處理掉。
• 第二，儘量通過工具平臺化提升效率。
• 第三，需要在方法方式上進行不斷地創新，給予一線同事最好的支援。

作者：

袁友高，一名IT男，2013年加入了平安證券，參與和見證了生產事件組的組建和發展。

原文來自微信公眾號：高效運維