自動化運維中的腳本管理和工單管理
本次分享來自自動化運維群的分享，摘錄整理出來。
先來一張圖，這是我在去年的時候規做的一個資料庫方向規劃。
藍色的部分是我們已有的部分，另外的部分是我們當時做得不好的地方。 當然這個過程說起來都是辛酸淚。都是一點一滴的改進。
本次分享里說到的腳本管理和工單管理其實這是裡面的兩個模塊，此外，我們還做了很多的模塊。 所以先來簡單說下目前系統的使用情況，這是我做的一個看板，已經做了前後端分離，可以統計調用API的次數，部署實例的次數等，這些都是一些業務屬性。
下面還有平台的一些使用頻率的統計，通過這些我可以知道目前系統的使用情況。
我還做了一個功能的統計表，可以看到不同功能的使用情況，這樣也能知道一些功能的使用情況，是否存在明顯的問題。
這是近一段時間的統計數據，如果前端發起了一次請求，就會記錄下來。
簡單介紹完，我來說說腳本管理和工單模塊的建設思路。
運維平台的發展逃不過幾個步驟，腳本化，工具化，可視化和自動化，注意在自動化的階段前，有一個階段是可視化。
但是顯然在很多時候我們的腳本化做得不夠好，比如代碼里可能會有這樣的實現的代碼：
這種雖然能夠實現功能，但是對於平台的維護來說，就是無數的鉤子，不可控的鉤子。
如果腳本的路徑發生變化或者要對腳本做變動，幾乎是一件不可能完成的事情
所以隨著腳本的引入，發現了更多的問題，最大的問題就是現有的腳本沒法直接用。要用起來，比如要適應一定的規則，然後最大的隔閡就來了，開發不懂運維，運維不懂開發，這樣的情況會讓問題白熱化。
所以對於腳本的管理很重要，但是缺少一些規範可行的方式。
我做了如下的總結：
1）為了能夠快速平滑的接入，腳本管理中的腳本語言其實不是瓶頸，都應該全面支持，比如使用perl,使用shell,SQL等，如果腳本本身很穩定，那麼完全可以接入進來，總之就是這個環節要開放，不一定要完全是python腳本。平台的開發功能是python,但是腳本管理不一定是python。
2）在腳本管理中，腳本和菜單如何映射，這是個關鍵，我們可以把腳本屬性參數化，比如腳本名，腳本的類型等這些也是作為一種元數據來管理。這樣就會是一個統一的介面的方式，至於具體的連接方式，比如樹形結構或者其他可行的方式。
3）平台方向上可以提前規劃，但是對於開發和業務同學來說，無需配置大量的url，就可完成一些基礎或者複雜功能的擴展。
4）現有的基礎架構和功能，腳本化對於它來說也是起到促進作用。需要提前規劃和已有的基礎功能是否有可銜接的地方。
5）腳本管理支持文件的上傳和腳本內容編輯。這個就是偏具體技術的實現了，比如ACE編輯器。
6）腳本的參數管理，有的腳本是1個參數，有的是2個，其實對於後台來說，就是拿到腳本來處理，怎麼做標識和匹配。
7）腳本管理中，有些腳本是通用的，如果希望能夠持續使用，必須要提前規劃好範圍和類別。有些腳本是具體的一些業務場景需要的，需要明確需要的參數和許可權。
腳本不光用通用和私有的範圍，而且還需要細化到具體的作用域範圍。
上面的內容看起來篇幅比較大，我們再做一層提煉。
腳本管理模塊主要做這些工作：
目標：初步實現腳本的提交，腳本審核和腳本查看功能
任務細則：
l 實現腳本信息的可配置化管理
l 實現腳本的信息查看
l 腳本類別和信息的管理
l 腳本信息提交後由腳本管理員審批
l 腳本審核後可以統一發送通知郵件
所以這就是我們工作中需求和設計之間的一個轉化，我們可以想出很多要做的事情，但是我們還要做減法，哪些是優先要做的，哪些是錦上添花的。
這是一個腳本信息的列表。 這裡需要注意的是我們在資料庫中會維護這個數據結構，資料庫中也會存儲對應的腳本內容，同時在文件系統中也會存在對應的文件，那麼我們所做的變更就會是兩個層面，資料庫層面和文件層面。
資料庫層面的就是腳本的提交，基本通過前端的輸入，提供了腳本內容，腳本的狀態就是「待審核「
這個階段的意義就是提交腳本的時候壓根不需要聲明腳本的路徑，這個工作是在審核的時候來做的。
而重要的工作就是腳本審核階段，腳本審核主要是完成兩件事情，一個是腳本的路徑規劃，另外一個是腳本在中控伺服器上生成。
這樣一來我們就有了一個初版的腳本管理結構，目錄都是統一規劃的，不是所有的腳本都要融入進來。
我們做了一個初版的腳本提示，如果創建了一個腳本會發送相應的郵件，這樣一來這就是一個正式的過程。
有了消息提醒，這就是一個相對完整的審核過程了。
然後來說下工單管理模塊的建設。
運維工作其實也是一種服務，所以對於運維提供的服務來說，甭管你是使用了高大上的方式或者規範的流程還是手工處理，如果高效完成，那對於應用來說就是大大的贊。
實際上，很多公司裡面的工單基本會和兩類屬性掛鉤，一類屬性是部門預算，或者說是工時，比如處理一個問題，需要花費2個小時，那麼這個服務就可以通過工時的方式來評估服務的結算費用，第二類屬性是服務質量，比如工單的處理結果是否滿意，是否有一些規範的操作流程等，這些是需要做工單反饋的。
至於工單模塊和運維模塊的建設，哪個在先？其實這是一個互相促進的過程。早期的工單肯定沒有自動化運維的輔助，所以肯定是有工單模塊，但是早期的工單模塊建設肯定不夠完善，基本操作和審批是脫節的，那就需要完成工單的自動化處理。互相促進之後，這就是一個完善的鏈條了。
所以簡單來說，工單系統和運維繫統需要對接起來，對接之後就能夠互相關注自己特定的業務範圍，把每一個環節都做到了可控和可考核。
我補個圖來說明一下。
這個是一個初版的工單處理流程圖，這個階段是完成一個初步的系統對接。
第一步是申請工單系統的介面許可權，即工單的審批還是在已有的工單系統中完成，而工單的信息一定有一個流水編號，是一個唯一的ID值，我需要的就是根據這個唯一的編號能夠從工單系統中得到一個JSON數據串，得到這個數據串之後我來解析它把它拆分為符合業務屬性的工單。所以所做的工作會分為以下幾個步驟：
1）解析工單信息，根據流水號信息解析工單的格式
2）工單拆分，把原來的一個工單拆分為多個業務工單，這個過程對應用同學來說是透明的。比如資料庫許可權開通的工單，會自動拆分為兩個工單，資料庫許可權工單和系統許可權工單。
這個階段的意義在於，兩個系統開始對接起來了，雖然不是一種很自然的對接方式，但是彼此打開了一扇窗。
第二個階段就可以更近一步，這個時候我們可以對工單系統開放介面，讓他們把數據推送過來，就不用我們去拉取了。這將是一個自動的推送過程，可以省去很多的檢查和反覆確認環節。
這個階段的工作的一大亮點就在於我們可以在工單拆分為業務工單，處理完成之後，確認工單完成，讓工單系統開放一個寫入介面，我們把工單的狀態回傳過去。這樣業務操作就形成了一個閉環。形成閉環是這個階段最重要的一件事情，這樣審批的關注審批環節，業務操作的關注業務操作環節，各司其職。
第三階段是更大的一個階段，比如我們的工單可以和外部的系統通過介面交互，那麼我們就可以和其他系統開始打通這個鏈路。 這是一個更大更全面的過程，會有更多的事情和介面需要對接。
這個階段的意義就在於，這是一個全鏈條的過程，我們可以在這個階段更多的挖掘運維數據的價值，比如工單的處理效率，工單的數據統計分析，工單的指派，業務工單拆分 邏輯等。 這些都可以逐步的細化和改進。
所以逐步迭代，完成系統的對接，完成業務支持，不知不覺，運維工作已然發生了很大的變化。
這也是我給大家分享的初衷所在。
TAG:楊建榮的學習筆記 |