IT工單治理野史：由每週最高150+治理到20+

背景

相信不少人都值過班當過小秘吧，每天都要線上排查與解答各種各樣來自IT或"單聊"的問題，同時還要針對每個問題進行"覆盤"分析，在完善系統、提高體驗的同時挖掘出其中的雷點，防止某一天突然"爆炸"造成不可控的局面。

我們這邊在值班小秘每日進行線上問題排查、解答與跟蹤，工單量越大耗費的精力和成本就越高。週而復始了一段時間之後，發現IT工單量不但沒有得到明顯的降低，而且還很不穩定，一週最高可達150個，效果不是很理想。於是此項被單獨成立為一個目標，而我被指派為此項負責人，會在每週對上一週的IT工單逐個進行分析覆盤，其中治理的具體思路和過程如下。

在此之前，我們先來看一下比較振奮人心的實戰效果吧，來吧，上圖

新方案實踐

1.問題分類治理

在進行了一段時間跟蹤治理之後，發現很多問題在本質上都是同一類問題，如果是按場景、功能模組、操作節點等維度進行歸類，同一種類別算成是一個工單的話，那麼這個量級至少是一半以下，基於上述發現，我們基於這樣一個原則來進行問題歸類以及各類別的治理方案：優先分析、跟蹤治理優先順序高的類別問題，優先順序規則如下（由高到低）

•影響財務結算類問題（涉及到計費模組類的功能異常）

•影響系統穩定類問題（系統缺陷、BUG等）

•產品場景異常類問題（場景丟失、場景越界等）

•系統體驗類問題（併發、核心實操類功能效能低下、提示術語存在歧義等）

•其餘非諮詢類問題量級由高到低

•其他問題

基於以上優先順序規則，我們的歸類維度以及對應治理方案主要如下（出現頻率高的類別）

•系統類問題

◦系統缺陷類（併發、業務交叉等）-->挖出根因並修復，而不是簡單的更改資料

◦系統BUG類（程式碼邏輯錯誤）-->多方核實出正確邏輯並修復上線

•產品類問題-->多方排查核實並由產品和業務牽頭進行業務場景梳理落實需求

◦場景丟失

◦場景越界

•體驗類問題

◦功能慢需要等待-->進行效能最佳化

◦提示語歧義不明確-->展示資訊糾正抽象概括類名詞未具體語義名詞、多業務同名名詞進行區分改名、實操提示語中明確具體因由和解決方案等

◦操作繁雜-->根據具體場景進行簡化：能自動帶出的資訊自動帶出、能簡化步驟的簡化步驟、能進行合併的進行合併等

◦操作口隱藏太深-->根據對應場景進行功能模組的聚合

◦業務邏輯反人類-->重新核實業務邏輯並進行最佳化

◦重要資訊沒地兒查-->現場調研收集吐槽點、核實分析後產出需求或一些簡單資訊直接在對應模組頁面上展示出來

•業務實操類-->多次培訓

◦業務規則卡控

◦基礎資訊配置卡控

◦非同步邏輯無感

•諮詢類-->多次培訓

◦業務規則諮詢

◦協助查詢資料資訊

◦系統使用教程

◦系統中一些業務詞彙或資料的含義解釋

◦對應職責對接人員名單

•其他類

◦歷史問題（N年沒有的業務突然來量了，系統邏輯早已面目全非）-->重新核實業務邏輯並進行最佳化

◦資料類問題（N年前的資料已經結轉走了）-->提供拉回功能和許可權控制

經過上述的方案進行治理了一段時間之後，需要產品、研發、業務介入跟進開發落實類的問題是越來越少，系統的穩定性提高不少。不過呢IT單量雖然整體有所下降，但是並沒有達到預期，因由就是優先順序高的類別問題佔比總體其實並不大，而除此之外的其他類問題佔比最大的就是諮詢和實操類別的問題，而這兩類佔比更高的是諮詢類問題（幾乎是一多半），所以我們又想出了接入智慧問答機器人的方案。

2.接入智慧問答機器人

基於上述經歷呢，我們決定基於最小成本和簡易問答場景進行接入一款智慧問答機器人進行嘗試，經過與多方溝通最終採用慧言機器人：對比過程這裡不再詳述，各個機器人平臺都有對應的教程文件和對接人，隨時可看與諮詢，大體原則是：接入成本、使用場景兩個主要要素。

接入前我們整理了下述類別的資料，並會定時更新

•諮詢類問題與答案-->原材料來源於日常值班記錄和IT工單資料

◦業務規則諮詢

◦系統使用諮詢

◦名詞解釋諮詢

◦上下游關聯場景諮詢

◦其他零散類諮詢

•系統教程類文件

•上下游互動類文件（介面、MQ等）

•各系統對接人/值班人文件

風風火火一頓整理後同步後，就開始嘗試進行推進，在日常工作中、對應的群裡以及一些聯手小夥伴們都會時不時地進行宣導，一段時間下來後發現實際效果確實是差強人意，IT單總量幾乎是沒有什麼大的變化，後來經過私下調研一些使用者的反饋後，大體總結出以下幾個原因

•不夠便捷，需要彈出京me進行諮詢

•命中率不高（是個難題）

•推廣受限（使用人員：系統操作期間非必要不會開啟京me，基本上體驗一次後就望而卻步了）

基於上述原因和結果，我們放棄了此種方案，開始著想其他方案，下圖是最近日期的一些使用資料統計

3.知識庫前置功能

基於上述兩種方案的經歷後，日常值班和IT單的型別佔比就大頭的就是一些偏向諮詢和實操類的工單了，挑選治理期間其中一週明細進行二次分析，其分佈圖如下

出去產研側類問題，我們能看看到圖中藍色和綠色部分就是所謂的諮詢和使用者類問題，而這兩類問題中可以粗略拆為基礎資訊配置和業務操作類，基於此種特色我們又想出了一種方案：進行知識庫前置

這裡我來解釋一下知識庫前置是個啥東東哈，所謂的知識庫前置是一種思想：在諮詢前透過配置好的知識庫進行攔截指引，即在對應實操上給出具體解決方案、業務頁面上給出具體指導手冊，達到具體問題/業務具體指引的效果，方便系統使用者自行快速地解決遇到的問題。

思想聽起來挺高大上的哈，其實實現起來就比較簡單了，我們這邊的系統是傳統的web網站系統

•首先在知識庫平臺上進行上述方案2中整理好的方案匯入進去，然後拿到每個知識庫的id編號

•在埋點系統上新建立一批空的埋點站位，拿到對應埋點的ID

•在系統中新增一張表用來儲存知識庫ID、埋點ID、訪問URL/業務異常碼關係（當然還有一些相容前臺體驗的屬性配置：這裡不再贅述）

•透過新增spirngMVC的攔截器進行解析其中的頁面uri或業務異常碼，在庫中進行關係檢索並拿到具體配置的知識庫內容掛在/返回頁面進行展示提醒

具體使用的展示效果圖如下

實操同步互動的業務異常攔截方式：在提示業務異常的同時，會在對應的提示資訊後邊跟著一個上下跳動的“解決方案”字樣（為了吸引注意讓使用者去點選）

點選後效果如下圖所示(彈窗中的內容都是自行編輯，此處抓取其中一個示例展示效果，並非對應上述的業務異常)

頁面掛載的攔截方式：在對應頁面上掛載此頁面涉及到的業務功能和使用教程知識庫（預設展示在頁面的右下角，點選可進行拖拽：不影響頁面使用或遮擋資訊），點選後彈出上圖所示效果的具體知識庫內容，如下圖

其實呢，說白了就是一個AOP切面的事情，一樣的道理，但是這個效果確實有著顯著的效果，透過下圖中的知識庫埋點點選資料可看到確實有人在使用，而本文最開始的IT單量統計折線圖確實能夠看到目前每週單量維持在20左右，相比最初的150、中間階段的90上下，確實整體下降量非常明顯

4.智慧問答功能（目前處於試用階段）

基於此種治理效果，基本上算是比較滿意了（心裡美滋滋），然而週而復始的值班進行線上解答與事後分析盤點，其實還是能看到諮詢類的問題佔比較多，縱橫對比發現此時的諮詢類問題提出人的所屬部門很零散（銷售、客服、運營、解決部、倉等等），問的問題也是“千奇百怪”，算是上述方案中的一些盲點區域了。基於此種特色，我們在想是否能夠在系統中提供一個簡易的問答檢索功能來支援這些"邊角"諮詢類的問題的諮詢，那麼我們們說幹就幹。

•將此類問題人工分析抽象為問答模式資料

•將資料儲存在ES進行儲存於檢索（問題欄位採用IK分詞器）

•採用NLP結合停用詞過濾（一些自定義匹配過濾：比如特定的業務單號是需要過濾的等）進行特徵詞的提取

•採用TF-IDF+餘弦相似度進行資料轉為向量的訓練與相似度匹配

•個性化加工包裝（比如識別到規則識別出的一些特定業務模組，可根據使用者錄入的單號或其他業務資料，進行入庫查詢返回給客戶帶有業務資料的解決方案）

上述為此功能的粗略設計步驟，簡易功能實現模式如下：責任鏈：es-->演算法-->模組；工廠策略：演算法