歡迎光臨
每天分享高質量文章

Workflow 是如何一步步逼瘋運維的…「文末福利」

來源:雲技術實踐

ID:kvm_virt」


和CMDB一樣,Workflow在設計過程中也存在著各種各樣的問題。不過文章平鋪直敘到這裡,我自己也覺得有些煩躁了。不如這樣,我們這次來個特別的安排,一邊講笑話一邊分析問題。當然,這是一個根據關於需求變更的經典笑話改編而成的,也許你看過第一個,但我保證你沒有看過後面幾個。

運維的故事1:宮保雞丁


1. 討論功能而非流程

小二:有位客官點了一份宮保雞丁。

廚子:好嘞!

廚子做到一半……

小二:客官說菜里不要放肉。

廚子:你大爺,我肉都回鍋了。

然而,廚子還是一點點把肉挑出來了。

又過了一會兒……

小二:客官問菜里能給加點兒腐竹嗎?

廚子:你不知道腐竹得提前泡水?炒到一半才說?你去跟他說,想吃腐竹就多等半天。

小二:啊,你怎麼不早說?

廚子:我怎麼知道他要往宮保雞丁里放腐竹。

然而,廚子還是去泡腐竹了。

又過了一會兒……

小二:客官問菜里有沒有加茄丁?

廚子:加了茄丁,那還能叫宮保雞丁嗎?哪個店家這麼做菜?

又過了一會兒……

小二:客官說還是加上雞丁吧。

廚子:你這不是玩兒我呢麽?你順道問問他,腐竹還要不要?不要我就扔了。

客官:咦,怎麼這麼慢?反正還沒付錢。那個什麼,小二,菜我不要了,退了吧。


Workflow在設計時,需要考慮實現的是功能而非流程。流程並不是一成不變的,往往需要在使用過程中不斷地優化和調整,展開討論並實體化一個Workflow是無意義的,需求的反覆變更是令人崩潰。不論怎樣,實體化的Workflow都沒法滿足你的業務需求。因為,在你的開發周期還沒有結束的這段期間里,需求和流程可能已經變更好幾次了。


因此,Workflow管理系統在設計和實施中,需要提供足夠的柔性,來滿足不同應用的需要。完成組件化的功能模塊,讓用戶自己去構建流程。而不是把所有的流程全部寫死。讓廚子負責提供組件,把雞丁、茄丁、腐竹什麼的統統都做好。至於怎麼搭配,讓食客自主選擇。


2. 無“鎖”不能

場景二

小二:有位客官點了一份宮保雞丁。

廚子甲:好嘞!

廚子乙:好嘞!

過了一會兒……

小二:客官,你要的兩份宮保雞丁來啦,請你慢用。

客官:我只要了一份,為啥端了兩盤上來?怎麼著,想黑某家?說話間,探臂膀伸手拉出了二十八斤重的魚鱗紫金刀。


Workflow在下發Case的時候,往往是面向一個角色、一個群組而非一個具體的自然人。兩個廚子相互之間是沒有溝通的,所以有可能出現多人操作的情況。


假如這個操作是冪等的(操作多次和操作一次的影響是相同的)則無所謂。反之,多次操作就會出現很嚴重的問題。


程式開發時,必須要考慮到併發操作所帶來的影響,這是起碼的意識。在Case派發的時候,必須有“鎖機制”。實現方法可以使用Case認領的方式來解決,只有認領的人才能看到任務內容。如果一個Case已經被人認領了,那麼它將被鎖定,不能進行第二次點擊,除非Case的狀態被修改(比如放棄或者轉交)。必須註意,Case的執行在任何一個環節上都不能出現多頭管理的情況。


3. 色即是空

客官:小二,給我來一份宮保雞丁。

小二:客官,你這雞丁是要山雞、野雞還是家養的土雞?

客官:某家自是要家養的土雞了。

小二:客官,雞丁是切長塊兒,還是方塊兒?

客官:刻意地啰嗦了,隨你罷了。

小二:客官,你這配菜是要黃瓜丁、花生米、還是胡蘿蔔丁?

客官:都要都要,你等只管快些上菜。

小二:客官,我們這有李、高、王三位師傅,你要誰伺候你這頓飯食?

客官:滾!


把流程設計得太複雜,是一件非常糟糕的事情。切記,少就是多,多即是無。


我們舉一個硬體報修流程的例子。我們的團隊曾經在討論由誰發起報修申請的這個問題上,出現過兩種不同的聲音。傳統觀點認為發起人應當是SE。還有一種不同的觀點認為,所有人都可以發起報修申請,這樣做可以及時報修。第二種觀點就是典型的“畫蛇添足”。硬體有沒有故障是需要人去確認的。你比方說,我把兩路電源拔掉一路再插上,對於系統來說就是一次故障,但實際上電源並不需要維修。既然需要人來確認,那麼這個角色只能是SE。只有SE是負責服務器管理的,他既是有權限查看的人,也是最具權威判斷的人。如果所有人都去發起報修申請,最後還是需要SE來確認的。採取這樣的方式,不但不能及時報修,還憑空多出一個確認環節,豈不是庸人自擾麽?


再說一個關於硬體報修的例子。當SE發起報修申請後,需要由Owner(服務器的業務使用方)進行審批,因為一些故障的維修需要停機,審批的過程也就是告知Owner做好準備。只有Owner審批完成後,郵件才會發送給廠商。假設這台故障機需要停機維修,Owner在收到申請的時候有兩種選擇。第一,Owner只是審批通過,但什麼都不乾,等廠商的維修人員到現場後再做停機處理。第二,Owner先完成業務遷移工作並關停設備,然後審批通過發送報修郵件,廠商到現場後可以直接維修。


第一種做法,廠商的維修人員到了現場不能及時處理,還要等待系統遷移下線。整個確認過程中涉及到業務、監控、SE、IDC、硬體廠商五方進行溝通,大大增加了個角色之間的交互工作。這種流程的發佈,會導致各角色之間反覆的多次確認。在不管怎樣都需要停機的情況下,先做和後做是沒有區別的,一個線上系統如果發現硬體問題,應當在第一時間及時遷走,而不是等待。如果業務不能停,是部署規劃不到位的問題。如果確實沒有條件在第一時間展開遷移工作,那麼應當儘快搭建遷移環境,待完成遷移工作後再發送報修郵件。


4. 君臣不分

客官:小二,小二,快些出來。

小二:客官,你有何吩咐?

客官:你這鳥店家,某家點了一壇老酒,五斤牛肉,兩張大餅,清蒸黃魚、紅燒鹿肉、孜然羊腿、宮保雞丁各一份,現在已過了半個時辰,為何不見上菜?

小二:客官莫急,其他的菜都已做好。只因後院雞肉不曾備得,掌柜的回家去取了。客官稍帶片刻,待那宮保雞丁做好,小的一併給你端上來。

客官:混賬,你這廝好生無禮。待到那時,黃花菜都涼了,那還能吃嗎?不要走,且先請你吃我一拳。


我們還是用硬體報修系統的流程來舉例。SE在發起報修申請的時候,為了合併處理,允許一次提交多個故障設備。Workflow把所有的設備,作為一個Case發佈出去了。但是,這些設備不一定一次性修完。因為,有些設備可能沒法下線,而有些不是一個供應商,所以如果等待Case內的所有設備都修完再終結就會出現邏輯問題。有些設備明明修完了,在流程中卻屬於未完成的狀態。而且Case里可能會有很多Owner,到底誰來關閉這個Case也是個問題。


所以Case應當是分級管理的。一個Case下麵包含若干個Task,一個設備對應一個Task。Case由報修人創建,Task隨著填寫設備自動生成,每一個Task完成後由SE確認關閉,當所有Task都關閉時,Case自動關閉。


5. 死路不通

掌柜:小二,客官點的宮保雞丁為什麼遲遲沒上來。

小二:雞肉沒有了,所以沒做。

掌柜:混賬東西,那你為什麼不和客官打聲招呼,讓他換個菜,害得人家在那裡等了半個時辰。

小二:不是你說,客戶為先,不能Say No的嗎?菜又做不了,拒絕又不行,你讓我怎麼辦?


Workflow在沒有結束之前,不管流程走到哪一步,都必須能夠進退自如,不能丟在一個角落裡面就沒有下文了。假使一個操作我執行不了,那麼應當允許我拒絕執行,讓業務狀態回退或者結束。一些Workflow系統的“官本位”的設計理念非常嚴重。往往是審批這一步有拒絕權限,而審批人面對申請從來都是看也不看,一律“同意、謝謝、請支持”。反而是在執行環節,執行人在面對錯誤的請求時無法拒絕,只好到線下去找申請人進行溝通。


6. 名詞亂入

客官:小二,這道“火山噴雪”煞是有趣,快些給某家來上一份。

小二:好嘞!“火山噴雪”一盤,請你慢用。

客官:我去,這是什麼?你這廝竟敢戲耍某家,這不是西紅柿拌白糖麽?


Workflow作為規範實體,在業務描述中要使該業務領域的專有名詞。當行家要說行話,用詞必須要準確,不能去自己造詞。比如,我們有兩個不同ISP的資料中心,要在它們之間構建一套DNS系統。為了實現流量劃分,根據請求的客戶端地址範圍分別提供不同的域名解析結果,實現將不同線路上的用戶劃分到兩個不同的資料中心去。這就是View的概念,View就叫View,而且只能叫做View,你不能叫分組解析等其他的名字,因為在DNS裡面沒有你那個所謂的分組解析的概念。亂起名字會引起混淆,對於操作者來說,有可能會引起誤操作。


《Linux雲計算及運維架構師高薪實戰班》2018年07月16日即將開課中,120天衝擊Linux運維年薪30萬,改變速約~~~~

    *宣告:推送內容及圖片來源於網絡,部分內容會有所改動,版權歸原作者所有,如來源信息有誤或侵犯權益,請聯繫我們刪除或授權事宜。

    – END –


    更多Linux好文請點擊【閱讀原文】

    ↓↓↓

    赞(0)

    分享創造快樂