基于小程序的DevOps工單系統

韓欣怡，高銘，靳海濤

（北京信息科技大學，北京，100020）

0 引言

目前高校及科研院所大都已經在一級部門間啟用或開始啟用信息化的溝通協作系統，但由于存在較多歷史遺留問題，并沒有實現完全的信息化。同時，一級部門下設的二級機構之間，信息化協作水平較低，尚處于使用郵件在同一份文檔內進行溝通協作的傳統模式。隨著去年新冠疫情爆發，線上辦公的普及，上述傳統模式轉為云文檔在線協作，部分提高了溝通效率，但依然存在操作復雜、流程繁復等弊端。

以高校GPU資源申請場景為例：申請資源的用戶需要填寫在線收集表，申請記錄會自動收集到申請記錄表格中，每一條記錄都包括用戶的基本信息（姓名，工號等），申請的資源的詳情，以及申請的處理進度。資源管理員需要定期查看申請記錄表格，并根據用戶的申請需求和資源的實際情況，對用戶的申請做出相應的處理。用戶想要了解申請進度，需要自行查看申請記錄表格中的處理狀態，且表格并未進行有效的權限管理。部門間的高溝通成本和低協作效率會放大上述問題的影響，降低基礎設施的使用效率，導致資產的無形損失。

1 工單系統分析

■ 1.1 工單系統發展現狀

客服工單管理系統目前在國內外技術都比較成熟，基本涵蓋工單管理、客戶管理、知識庫管理、在線客服、呼叫中心等功能模塊。為了更好的獲取客戶反饋信息，實時追蹤和處理解決客戶反映的問題，21世紀初，美國多家公司致力于開發客戶管理、工單管理、統計報表等服務，幫助公司及時獲取客戶所需，解決客戶急需解決的問題或意見與建議[1]。國內后續也有很多企業致力于幫助開發者和企業可以更快速低成本的搭建自己的客戶服務系統，使用戶的問題可以更方便的提交和反饋。其中的工單系統將工單作為部門協同、任務流轉記錄、提升效率、改善和提升服務體驗的工具，在公司內部各個部門進行流轉處理[2]。經過我們查閱資料等方式，總結為主要以下三個問題：（1）用戶分級操作不明確：學生無法通過自主填寫信息完成資源申請；（2）用戶申請狀態難追蹤：在申請記錄非常多的情況下，用戶就難以在眾多的記錄中查找自己的申請記錄，且不方便管理員更新申請的處理狀態；（3）流程中溝通成本巨大：用戶申請占用大資源需要相關領導審批，但用戶無法通過填寫一張簡單的申請表格來描述自己對大資源的需求，還需要自行聯系資源管理員，級級上報，等待審批，最后才能為用戶分配資源。可見，巨大的溝通成本導致的特殊申請的效率極其低下。

■ 1.2 工單系統需求分析

由于本系統最主要研究的是各高校以及科研院所中不同層級資源申請的問題，設計并開發一款適用于高校及科研院所內部使用的工單管理系統，旨在高校及科研院所之間的協同配合工作，使得資源管理員可快速響應各層級用戶的申請，解決用戶問題。我們設計的工單系統是面向不同級別用戶申請資源的一種區別于線下傳統的線上系統，針對于不同級別的用戶，如普通用戶與管理員，而普通用戶又有級別的區別，這些不同的級別也都對應著不同的工單流轉方式以及所需要的審批工程。圖1是工單系統所要完成的基本功能。

圖1 工單系統功能圖

2 工單系統基本設計

該工單系統的前后端是分離獨立的，采用了client/server模式，以及MVC的三層設計模式[3]，前后端交換數據使用的是JSON格式[4]；系統后端采取Java語言寫，使用java web技術開發，MyBatis-Plus技術進行封裝，基于的是SpringBoot2框架[5]、微服務架構；系統前端分為兩個大的模塊，其中之一是管理員后端，另外一個模塊即普通用戶進行申請的小程序前端，管理員后端使用了Vue.js框架技術，Vue.js框架能快速的搭建與用戶交互的環境，使用戶有良好的交互式體驗；數據庫的實現采用了MySQL數據庫，是安全、跨平臺、高效的數據庫系統，與我們系統的后端Java語言緊密結合。

■ 2.1 后端基本設計

后端表現層（Web層）是與Service層接口交互的層次，主要負責接受客戶端的請求，向客戶端發送請求結果。通過前端的表現層調用方，即后臺管理系統前端（Browser）、微信小程序前端、微信服務器這三部分前端調用，通過HTTP協議調用JSON向表現層傳參，,之后表現層再把自己接受到的數據通過Service層接口傳到Service層[6]。

后端服務層（Service層）設計是與數據庫進行直接交互的層級，表現層接受到的數據通過接口調用，傳給Service層對外暴露的接口，通過接口數據即被傳到了服務層，服務層的需要通過MDS加密類等工具實現加密數據、格式化日期數據等功能，將表現層傳過來的數據進行統一的格式化處理，格式化處理后的數據會通過數據持久層接口傳送到數據庫。

后端數據持久層，即直接與數據庫進行交互的層級，這部分操作是通過標準的Java應用編程接口向數據庫傳入需要存儲的數據[7]。

■ 2.2 前端視圖層設計

系統前端視圖層總共有四個模塊，即消息模塊、工單模塊、審批模塊、用戶信息模塊，這四個模塊分別調用控制層中的消息控制層接口（MessageController）、工單管理控制層接口（WorkController）、審批工單控制層接口（ApprovalController）、用戶控制層接口（AuthController）這四個控制層。

2.2.1 用戶信息模塊

用戶信息模塊中，分為用戶信息注冊和用戶登錄兩個主要功能。其中用戶信息注冊是指在首次使用此工單系統時，用戶需要填寫自己的個人信息，主要是明確信息的身份等級。以圖2(a)進行小程序前端注冊頁面的展示。用戶登錄功能，傳入微信login()接口獲取的臨時代碼，服務器返回一個有時限的登錄token（令牌），需要客戶端保存好，每次訪問接口時都要將token通過HTTP請求頭發送到后端，作為登錄的憑證。token中包含用戶id，學號和工號（如果是學生就攜帶學號，教師就攜帶工號），也就是說對于首次登錄的用戶，會讓其填寫基本的個人信息，主要是為了獲取用戶的身份等級，以確認用戶提交工單后自動流入的節點，但登錄時可能會有一些錯誤登錄的情況，有專門的錯誤代碼返回一些錯誤的信息，并且在頁面上給予用戶提示。同一個用戶在后續登錄系統的過程中，會一直攜帶著被保存的token，也就意味著，后續用戶打開工單系統小程序將能自動登入系統。

2.2.2 消息模塊

消息模塊中，使用前端小程序的用戶可以發送消息給負責審批的管理員，后臺的管理者也可以將審批的意見反饋給用戶，調用的都為發送信息接口，并且普通用戶以及管理員都可以通過消息詳情接口的調用去“查看消息詳情”，“收件箱列表顯示”和“發件箱列表顯示”是通過“消息收件箱接口”和“消息發件箱借口”來獲取到具體消息列表的，以上消息模塊所完成的功能由控制層中的消息控制層來統一調度，并且每一條未讀的工單信息都會標有“未讀”，圖2(b)是前端小程序的消息模塊頁面。

2.2.3 工單模塊

在工單模塊中，分別有工單列表顯示、發起工單和查看工單詳情這三個具體的功能。工單列表顯示即通過調用工單列表借口，來查看用戶申請的歷史工單和在審工單等；用戶發起工單即在申請資源時，要填入自己想要申請的具體內容（即標題），還要填寫自己的留言（即申請資源的原因和用途），在選擇流程中，可以選擇上傳截圖證明，文件證明或是聊天記錄，填寫完以上所有必填項之外，提交按鈕會變為藍色，最后發送請求給接口/workOrder/save，后端在工單表中新增工單記錄，并根據工單流程自動在審批關系表中新增記錄，表示工單已經流入第一個審批節點，查看工單詳情即可以通過調用工單詳情接口來查看工單詳情來查詢工單的具體審批情況。

2.2.4 審批模塊

審批模塊中，分別有審批工單列表、查看工單詳情，以及審批工單這三個部分的功能，在審批工單列表中，調用審批工單列表接口可以看到所有工單的審批狀態；在審批工單時在進行工單的審批，管理員審批需要經過幾個節點，即不同的層級，節點轉換的觸發條件是：審批人員點擊“通過”按鈕。后端刪除目前審批表中的相關記錄，并查詢流程表獲取下一個節點信息，在審批表中新增記錄，表示工單已經流入下一個節點。同時將上一個節點的審批信息全部記錄到審批記錄關系表中，圖2(c)是查看工單申請批詳情界面。

圖2

■ 2.3 后臺網頁端頁面設計

在工單小程序的后端管理平臺中，網頁的頁面主要包括五個具體頁面。首先是管理員的注冊登錄頁面，管理員可以選擇以用戶名密碼的方式進行登錄，也可以通過微信直接掃碼登錄頁面，并且只有管理員的登錄才是有效的，其它普通用戶無法成功登錄[8]。主要的功能性設計包括管理模塊、用戶模塊等，管理員可以對任一工單或是用戶做右側Actions中的任意操作，如圖3以工單管理具體頁面作為主要展示：其中ID號是依照工單申請的順序依次排列的，工單標題為自己填寫，工單的創建時間是根據系統自帶的時間而定，工作狀態分為三種：即在審、不通過和順利通過，其中在審是指此工單已經進入審批階段，并且目前已經通過的節點沒有其他的問題；不通過是指某一個節點，管理員在審批的時候拒絕了用戶的CPU申請，工單申請中途夭折，所以該工單的狀態為不通過；狀態為順利通過時是指，此工單固有的審批節點流程已經進行完畢，即完成了此類型工單系統所需要的工單流程。

圖3 后端工單管理頁面基本展示

3 數據庫實現

數據庫的設計在我們工單系統的開發中占了非常重要的地位，之所以夠有效的存儲數據，滿足各類用戶的應用需求，那么良好的數據庫設計可以節省的存儲空間，保證所需存儲數據的完整性，減少數據冗余的情況[9]。我們設計的數據庫主要包含了以下四個模塊的數據，分別是工單信息、用戶信息、權限管理和流程信息。工單信息包括了我們設計的工單表、已經審批完成的工單歷史表，正在進行管理員審批的工單狀態表、還有工單審批記錄表，也就是說工單信息覆蓋了工單從開始填寫到審核完畢的全過程；用戶信息包括用戶表、學院表、專業表和部門表，涵蓋了用戶信息的各類屬性；權限管理模塊包括權限表、角色表，是根據用戶的不同等級來劃分權限，也對應著不同的角色；流程信息包括了流程表、流程節點表，根據不同的角色使其進入指定的節點流程。

對于一些工單申請的用戶，在后端的數據庫中其基本的信息都有記錄，管理員可以隨時在后端數據庫中管理用戶的基本信息或是對表中的數據進行查詢、刪除或是更改。

4 結束語

我們通過采取client/server模式完成了前后端的環境架構、建立GitHub倉庫并使用Java語言編寫前后端代碼，并采用MySQL數據庫完成數據庫的構建和實現，順利地開發了基于小程序的DevOps工單系統，可以用于各個高校與科研院所的線上工單申請流程。目前已經基本解決了目前線下各個層級間溝通成本高，時間耗費大，用戶申請時體驗感欠佳等各方面的問題，之后我們也會持續對此次開發的工單系統進行實時測評，并對用戶提出的問題進行及時地改善與維護。