筆者從事運營商行業開發運營工作近20年，歷經開發、運維、產品等工作崗位。從項目需求分析到開發代碼交付，再到應用上線后的運營維護，均全流程，無死角的擼了一遍。

這其中，運維崗待的時間最長。運維人員的苦逼日常，閉上眼睛至今仍像小電影樣的浮現在我的面前。

那些運維的日子里，每日不是在加班處理業務投訴工單，就是連續通宵故障處理，沒完沒了的割接、演練、上線中度過。活生生把我從一個青春活力的白胖子，熬成了一個苦大仇深的黑胖子。日漸稀少的發量是我心中永遠的痛……

運維工作除了保障日常系統穩定運行之外，這些因新業務上線帶來的問題單都是需要人一個一個的解決的，每一個問題的解決都是運維人通宵達旦的付出。

回想當年維護的填坑歲月，苦逼場景還是清晰浮現眼前。在那個缺少工具平臺的年代，你工作的年限，所謂的經驗，只能是你處理問題的思路更優，但是處理解決故障的過程每一步都不能少。

即便是做了N多年的老鳥，碰到上述的業務報障，也只能一個號碼一個號碼地去查用戶資料、查業務辦理記錄、查工單執行記錄、查報錯日志……

再根據各種資料表、臺帳表、日志信息中的蛛絲馬跡判斷用戶投訴問題產生的原因。

每一個運維苦逼，都不會忘記他人生第一個問題的處理過程，這個過程即忐忑又興奮，搞完之后還有寫一部福爾摩斯探案之業務運維捉奸記的雄心壯志。

但當你日復一日，年復一年的做著換湯不換藥的事情時，那種暴躁感，無時無刻不包裹著你，讓你即壓抑又面紅耳赤……

無數個上線，排障的夜晚都有“世界這么大，我想去看看”的沖動。無奈空癟的錢包，不斷掐醒自己的同時，告訴自己，冷靜，冷靜，要冷靜……

作為一個有思想的的運維人員，必須得想想辦法，不能總是摁著一個小電影看不是，總干些重復勞動，我就問自己，手痛不？

望著自己手上的老繭，我下定決心，懷揣找人要小電影的心情，去找開發的小伙伴商量。咱能不能做些自動或者半自動的處理界面，把投訴報障工單里需要登錄各平臺查詢的信息，根據需要自助查詢展示出來。

以此咱就不用每次查一大堆東西，登錄完CRM，登錄ACT，登錄完ACT，登錄JF，再加上相關業務日志，平臺日志。每查詢間的切換耗時，都可以讓哥看完一個小電影了。

如果展示的時候還能把關鍵信息標識加亮展示出來就更好了，再進一步，如果能把處理方案，做成依托平臺的動態知識庫直接給咱一個提示，或者干脆一鍵自動處理完報障，那就更爽了……哈哈哈，事隔多年，我仍清晰記得自己當時說得兩眼放光，仿佛見到佛祖一樣的興奮場景。

我唾沫橫飛地自淫了半小時，一臉期待地看著開發小伙伴。他很淡然的將臉從電腦屏幕前向我斜了5度，順帶瞟了一眼，說：“好啊，你和老大說一下，把我手頭這些催命的開發需求往后挪挪？”

我：“……”

在我轉動眼球的間隙，小伙伴又轉回剛才的5度角繼續敲代碼，隨帶飄了一句說：“都是賣身的，規矩大家都懂哈，先找媽咪！”

想起如果能工具化之后，自己可以有大把時間擼自己喜歡做的事情，我又借著興奮勁兒去找“媽咪”項目經理商量。

把剛才和開發小伙伴叨叨的話，又和媽咪叨叨了一遍，“咱能不能這樣…這樣…這樣？”

媽咪很冷靜，一看就是見過大場面的人，先肯定了我，說“你的想法很好”，接著話鋒一轉，“不過運維工作內容的變動多，需求不明確啊！你說的這些工單，每次上線可能導致的問題點都不一樣，要查的東西不一樣，處理過程更不一樣。沒有明確的處理邏輯，怎么弄個固定流程出來開發？總不能出一個問題開發一個功能吧。再說，開發有周期，等功能開發好上線了，這個問題熱點都過了，功能不是白費了嗎？”

現在想想當年媽咪的口活就是好，他這炮彈樣兒的美顏靈魂N連問，讓我瞬間軟了，呃……

自此，一顆為運維人做些什么的種子在我的心中埋下了根。本著為運維人做些什么的想法，我后來從運維崗轉到了產品崗。

理想是豐滿的，現實是骨感的。在自己為運維人做些什么的種子長大的過程的，自己也折騰了不少bug出來，讓曾經的運維同事掀了桌子，但那一刻更堅定了自己的初衷。

說個題外話，雖然開發和運維都很苦逼，但認真比對一下，我認為沒有工具依托的運維是個更苦逼，更委屈的活兒。問題都不是自己產生的，不但要幫著擦屁股，還要挨罵的永遠是運維人。這種心里的憋屈，沒有體驗過的人是不能感同身受的......

在做產品開發的日子里，每當自己稍閑下來的時候，為運維人做些什么的躁動仍然燃燒著我，那種感覺就像看了小電影，老婆沒在身邊的感覺一樣。有沒有什么產品方案能減輕一些運維人員的苦力，壓力？

基于產品的角度，我重新梳理運維工作的現狀和需求痛點，對于日常工作在一線的運維人員，需要構建一套具備運維自助能力平臺，以此滿足日益增長的運維需求。

1. 運維人員往往不具備開發環境，開發所需要的版本管理、開發資料在運維人員使用的安全環境中，便捷性是得不到保障的。

2. 運維人員的開發能力大部分聚焦在使用數據庫的SQL語句及相關腳本語言。而開發一個完整的系統，從登錄到權限管理、菜單頁面、后臺功能，再小的麻雀須要五臟俱全，否則難以推廣使用。

3. 基于事務式的運維任務很多是臨時性的，很多同類的任務處理頻次往往隨著一次系統的變更而爆發，一個并不長的周期之后，隨著系統的逐漸完善又逐漸降低或再不需要處理，這是咬牙式純項目開發帶來的一個窘境。

4. 運維人員的工作種類繁多，日常的投訴工單處理、生產數據的生命周期管理、各種運維報表（kpi日報、周報、月報等）、系統監控巡檢、突發故障處理等等，留給運維人員的余額時間不足。

5. 目前市面上的自動化運維工具或平臺主要針對的是paas層的運維管理，對于基于業務層拉通后的OPS運維難以解決。

1、排障過程中，大量數據獲取的支撐

運維排障過程中所需要訪問的數據是海量的，需要連接各種不同業務系統中數據庫的業務數據、系統性能指標數據、日志文件數據等來幫助問題的判斷，想要查什么數據，都可快速在平臺里獲取到。

TIP：脫敏！脫敏！脫敏！安全之責不可少啊！

2、零開發

零開發！零開發！零開發！重要的事情說三遍。對于開發人員來說，實現一個具體的需求功能，開發代碼也許并沒有那么難，但對于運維人員來說，真的是臣妾做不到啊~

3、場景可配置

對于運維來說，場景化功能是剛需。場景可能是一個投訴工單的處理流程；可能是一個系統故障點的發現及自愈處理流程；可能是領導交代的一個取數任務；可能是每天要出具一份新業務的態勢報告。無窮盡的場景不能通過一個個的開發定制來實現，要能通過通用的功能配置實現。配置的過程要足夠快捷，且易用性要高，復用性高。否則問題周期都過了，場景還配不出來，運維是會掀桌子滴~

4、數據操作可關聯

運維在排障查數據時，往往不是只查一個表的數據，而是查完第一張表，再根據第一張表中的某條記錄再查第二張，第三張、第四張……所需要查看的數據隨著業務流程的復雜度而增加，甚至還要查日志、查代碼。所以功能上要實現數據查詢的可關聯性，通過參數化查詢結果來實現其他數據的查詢。

5、數據展現的靈活化

數據庫中的數據往往是表格化展現的，其中數據的變化邏輯難以通過表格形式直觀展現，大量的可視化界面成為高效手段方式。不同的數據需要不同的展現形式，需能通過靈活的配置提供不同的數據展現。如常規的柱狀圖、曲線圖、餅圖、雷達圖、面積圖都是運維數據展現所應該具備的。

6、界面布局配置的靈活化

一個場景功能的可用性，與界面布局是否合理息息相關。場景展現是上下結構，還是左右布局，得由運維人員自己說了算。不好用的界面操作邏輯，運維人員會說還不如直接查表來得直觀快捷。

7、數據分析及處理過程可配置

正常開發中對于數據的使用不只是展現，還需要對數據做各種聚合或轉換的運算操作。開發人員可以用代碼來實現，但運維人員在不能寫代碼的情況下要實現數據處理，必須得提供一套可配置的通用數據處理模塊來實現。這個數據處理要能做批量數據分析處理，還要能做實時數據分析處理……

8、要能對接自動化處理

畢竟咱是做自動化產品的公司，各個場地要隨時可對接已有運維類的產品工具。

9、界面可視化要美觀

是的，這是個看顏值的時代……

10、重點信息要能凸顯標記

11、要有自配置大屏

此時我腦海里閃現出前端美女茜茜那能殺死我的眼神，弟弟一抖，不寒而栗，拉住了如脫韁的野馬一般擴張的思路。

所以筆者擬定了第一版的場景化運維平臺的功能架構：

(開發過程中的艱辛省略5萬字……)

念念不忘，必有反響。筆者所在的團隊終于將第一版的場景化運維開發平臺上線了。

厲害我平哥，人狠話不多。廢話不多說，先給大家看看一些場景效果圖：

上面圖片是通過業務鏈大屏配置功能配置出的某業務系統的可視化展現，以應用及應用關系為主要展現目標，展現各應用的實時運行狀態。

各應用節點上可展現多維度指標，如負載主機數量、應用實例數量、異常實例數量、告警數量等信息；

應用節點連線代表應用之間的調用關系，以動畫連線代表調用方向。連線上展現的指標可自由增加配置，如配置業務的調用總量、調用失敗率、調用耗時等指標。

應用配置了下鉆展現頁，展現此應用的物理部署視圖，包含主機、應用實例、交換機、網絡等層級關系的展現，以及各實體的性能指標展現。

要特別說明的是，應用主機以及應用關系，都是根據數據自動生成，無需手動逐一配置，以此大大降低了運維人員在配置這種展現圖時的工作量。

上面的圖表展現，均是通過平臺的kpi日報功能配置實現，通過配置數據口徑及展現圖表即可實現運維數據的可視化soeasy~，媽媽再也不用擔心我的運維了......

圖表之間配置了聯動關系，點選某個節點或某個曲線中的時間點數據，可自動根據其代表的對象來獲取下鉆的明細數據，圖例中通過指標告警快速定位并下鉆到告警業務自檢場景。

而各表格之間，可通過配置的下鉆功能和聯動功能，自由跳轉查看相關數據。

該產品平臺一切，都圍繞可自由定義這個目標來實現。

上圖是數據分析處理過程，通過底層的通用數據處理邏輯來實現數據的實時處理（基于flink平臺的數據處理能力相當強大，誰用誰知道，哈哈哈~）

各類數據指標通過配置生成，后臺同樣通過搭建在flink實時計算平臺的通用計算模塊來實現數據處理。

目前此平臺已在筆者所在的客戶現場上線運行。這套系統涵蓋了從自定義數據采集，到自定義數據處理邏輯，最后到自定義前臺展現的各功能模塊。運維人員可通過這套平臺自己搭建所需要的運維場景。

目前已實現的場景包括：

繳費不開機投訴場景

優惠計費不準確投訴場景

業務辦理失敗投訴場景

業務互斥場景

寬帶業務辦理異常場景

各環節工單積壓場景

工單應急開機處理場景

數據庫巡檢場景

中間件巡檢場景

數據庫故障處理場景

業務鏈大屏場景

數據庫大屏場景

……

以上，是一個老運維人本著為運維人做點什么的初心，這些年來和小伙伴們一起迭代出來的階段性成果，寫出來，和大家分享一下，畢竟在這“疫滿人間”的時刻，我們需要更多的溫暖。

如果你需要了解產品的詳細信息，請后臺留言。

說好的小視頻，在這里：