本文深入探討了一站式自助業務運維平臺的設計思路與實現方式，旨在通過智能化手段提升運維效率，優化用戶體驗，并確保數據安全。

一、現狀背景分析

業務系統功能研發上線后，用戶在使用過程中會遇到各種各樣的問題。

或是用戶在前端頁面能夠查看的數據字段范圍有限，無法滿足用戶業務開展所需信息清單，必需運維同事協助從后臺了解到更多字段信息；

或是用戶進行中的業務單據出現異常，需要運維同事協助在后臺排查定位并解決等。

為保障業務正常運轉，需要上下游眾多系統能力的協調配合。由于各個系統分屬在不同部門甚至不同公司，導致數據查詢類運維問題大概率僅涉及到單個系統。

異常解決類運維問題較大概率會涉及到多個相互關聯的系統，當在單個系統排查定位之后，需要上下游系統同步排查定位及配合修復。

而“官本位”思維作祟導致運維同事在所負責系統排查定位好問題后將查詢結果反饋給用戶，用戶拿著自己實際一知半解的結果信息繼續向其他相應系統運維方繼續咨詢，直至問題解決。

如果深入分析業務運維現狀我們至少會問四個問題：

• 業務系統前端頁面所展示信息為什么不能滿足用戶業務正常開展？
• 運維工作是服務于用戶的，但在運維過程中為什么需要用戶作為鏈接的“橋梁”在不同系統運維方間傳遞信息？
• 運維同事對后臺數據庫直接操作增刪改查的行為是否合適、安全以及是否有更好的運維支持方法？
• 業務開展過程中涉及到需修改業務數據場景的，根據過往經驗現有支持途徑可分為線上系統或線下紙質工單走完相應審批流程，然后用戶將審批結果及需修改的數據信息交付系統運維同事來操作數據變。

這個過程中經常會出現由于用戶對需修改業務數據范圍理解不足，導致運維同事在實際操作時還需要與用戶往復溝通，甚至需要用戶根據多次溝通的結果重新提交數據修改單據并發起新的審批流程。

針對這種情況我們會問：業務數據修改訴求的提交及審批過程是否可以在同個系統內完成，并且是在完整定位需修改業務數據范圍后再進行呢？

大家可能會問：是否可以把業務系統功能建設的足夠健壯、足夠完善，不出現任何運維問題呢？這種理解思路是否具備可行性？我只能說理想很豐滿，現實卻不足以達成。

因研發資源受限、業務不斷發展且業務邏輯足夠復雜、產品經理綜合能力有限、需求/項目上線時間節點緊迫及上下游系統配合程度有限等等因素，都導致無法在業務系統功能設計、建設中做到盡善盡美。

因此，我們要置身于現實背景情況來思考如何解決用戶業務運維所遇到的痛點。

現有業務運維邏輯對用戶而言類似于互聯網電商行業經常提到的“人找貨”模式，這種方式在互聯網行業初期由于受限于基礎設施、技術水平等條件限制當時是適用的，后來隨著基礎設施的不斷完善，技術水平的持續提升，不斷有很多更好的模式來為用戶提供更好的服務。

當前互聯網行業已經發展到“貨找人”模式階段，“貨找人”模式追求的是基于用戶訴求來從浩瀚的商品庫中自動匹配用戶最需要的物品，并展現給用戶來決策。

“貨找人”模式不僅減少了用戶檢索成本，同時為用戶盡可能提供了一站式服務。

那么在解決用戶業務運維過程所遭遇的痛點中，是否可以利用類似“貨找人”思維來構建一站式自助業務運維能力呢？

答案是肯定的。

二、平臺產品能力設計

一站式自助業務運維的產品設計思路可以在如下幾方面彰顯其優勢：

• 運維系統與業務系統是相輔相成的，運維系統作為業務系統的補充，在滿足用戶業務正常開展訴求的前提下可以作為用戶需求的收集窗口，對于呼聲強烈的運維功能逐步將其向業務系統遷移，助推業務系統的不斷完善、健壯。
• 運維問題無論涉及到單個還是多個系統運維方，都支持用戶在一站式自助業務運維系統內實現運維問題的提問、排查定位、審批及消除解決等全流程動作
  閉環。
• 系統運維同事無需直接對數據庫操作增刪改查動作，在保證數據安全的前提下降低了運維同事重復作業的難度，并提高用戶業務運維協助排查定位、解決的便捷性。

回歸到用戶業務運維提出問題的形式，大致存在三種類型：

• 清楚地了解運維問題關鍵信息，例如訂單編碼、問題類型及需要達到的目的等。
• 大致了解運維問題，能夠從業務層面給出自己理解的問題描述。
• 有相關運維問題的系統截圖，由于對系統了解程度不深，以截圖形式來提問。

2.1 產品架構圖

一站式自助業務運維平臺能力可以解決用戶運維過程中所遇到的痛點，并且可以根據用戶提出問題形式的不同來對應分配相應產品能力。

以數據庫資源為基礎，搭建包括場景化運維及機器人應答能力，并且業務運維平臺與上下游系統實現賬號體系打通并聯動，設計的輔助模塊功能主要是從數據安全層面實現用戶可查看、操作數據的隔離。（如圖1）

圖1 一站式自助業務運維平臺產品架構圖設計

聚焦解決用戶業務運維問題痛點，如下會分別對一站式自助業務運維平臺關鍵產品模塊進行介紹。

2.2 場景化運維能力

如果用戶清楚地了解運維問題關鍵信息，場景化運維能力可提供支持，實現運維問題”提出->定位->審批（如需）->解決”的閉環解決。假設訂單已到貨但無法驗收。

用戶在場景化運維能力中輸入相應訂單號，選擇查異常，就可以看到按照訂單全生命周期信息流轉軌跡所呈現的最新狀態及異常定位點，和需操作動作“重推ERP”，用戶點擊“重推ERP”按鈕即可解決此問題。

對比原來在系統運維方排查定位好問題后，用戶登錄到業務系統并找到對應頁面中可操作按鈕進行操作的流程，極大簡化了運維問題解決的難度，并且處理效率也有極大提升。

假設在排查定位好運維后需要修改業務數據，則在當前頁面展示將要修改的數據范圍清單，用戶提交審批后，各節點審批方都可以看到待修改數據范圍清單，并且在審批通過后系統自動完成數據修改。

在前端所展示的信息全生命周期信息中包含業務節點清單和運維節點清單：

1）業務節點是用戶在業務系統中可以看到的狀態節點信息；

2）運維節點在業務正常開展過程中對用戶是不可見的，僅是系統運維方在數據庫維度對數據流轉軌跡的跟蹤。（如圖2）

圖2 場景化運維能力設計

2.3 自助應答能力

如果用戶大致了解運維問題或有相關運維問題的系統截圖，提問的運維問題信息先由OCR技術及NLP對其解析語義，然后根據運維問題類型由RPA機器人決定調用知識庫或場景化運維能力排查定位問題并給出下一步應執行動作，同樣極大簡化問題解決的難度并提升了處理效率。

一站式自助業務運維平臺前端頁面所展示信息應該對用戶是可理解的，例如數據庫字段名應轉化為中文名呈現等。（如圖3）

圖3 自助應答能力設計

2.4 配置化能力

隨著業務的快速發展，運維系統也需要配合支持快速迭代更新。當前系統迭代方式更常見的為固定時間停機、發版、上線的模式，此種模式不僅會導致系統在某段時間內不可用，并且新功能開發周期較長，進一步降低了系統的可用性。

為解決系統迭代過程中此類不足，可通過前端可配置模塊來實現，配置化能力支持場景化能力邏輯、知識庫、審批流、數據字典及賬號權限等在保證系統始終可用的前提下實現了新能力/舊能力更新等無需發版快速上線。（如圖4）

圖4 配置化能力設計

三、總結

遵從“以用戶為中心，以服務用戶為核心，以解決用戶痛點為重心”的原則，一站式自助業務運維平臺的搭建不僅可以很好地解決用戶現存運維過程中遇到的的各種痛點、難點，在保障安全的基礎上，通過一站式自助業務運維及配置化敏捷迭代的雙輪驅動模式，加持智能化技術手段提高效能的同時助力用戶產品體驗的極大提升。