知識星球
來源：雲技術實踐
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好文請點選【閱讀原文】哦
↓↓↓
