最近在經歷的一些事情，讓我突發靈感，覺得要寫點關于DevOps體系建設過程中的“流程規范”，記錄下來。

如何解讀"流程規范"

談到DevOps落地，無一例外都會提“流程規范“，我想沒有人會反對，甚至會”不放在眼里“，因為概念本身沒有什么晦澀難懂。可是一到落地，好像就是另外一番場景，“一地雞毛”，“形同虛設”，”無人問津“ ，”無人知曉“，”面子工程“等等狀況歷歷在目。

首先，很多人把“流程規范”放在一起來看待，甚至認為是等價的，我過去也這么理解。不過，現在我覺得需要區分來看待

• **流程- Process: （步驟，程序，過程）, **

• 規范- specification （規格，規范，明細單，說明書；明確說明）

上面這個圖，足夠形象解釋了他們的區別，和關注的點。前者告訴了你做什么，后者具體告訴你怎么做。

流程雖好，為啥不能落地

現實中， 組織會定義很多 XXXX流程 - 步驟1 ，步驟2， 步驟3 ， 角色A 要負責這個，角色B要負責這個。。。，階段產出是XXX
看上去很清晰，文檔規范，可是“角色”只是個名稱，現實中卻是活生生的“人”；如果把“人”變多，就成了“眾”。

• 眾口難調
• 從眾心理
• 烏合之眾
• 眾人拾柴火焰高
• ...

每個詞的背后，就代表了如何理解“眾”；對于組織的變革者，你需要理解背后代表什么，不了解“眾”，不了解“人心”，不感同“人心”，你的流程也會難以服眾。

• 你的流程是否合理？
• 你的流程是否代表大多數，而不是個性化、差異化？
• 你的流程是否具有權威性？
• 你的流程是你拍腦門想的嗎？是看某某權威的書啟發的嗎？
• 你的流程被挑戰時候，是否妥協了？
• 你的流程是為誰而設計？代表組織的利益嗎？或讓組織因此而收益嗎？
• 你的流程目標是什么？是為了改進嗎？還是為了控制約束別人，發號施令？
• 你的流程是否大家都知道并能5秒內找到？是否只是“紅頭文件”，束之高閣？
  

工具的"神圣使命"

好像流程里，很少提工具，甚至“一筆帶過”，那你的流程靠什么落地？
哇塞，工具啊！工具無敵，工具牛逼，工具能解決一起問題。彷佛霎那間，看到了勝利的曙光~, 仿佛工具一夜之間成了“救命稻草”，“銀彈”。

”工具“突然被賦予了“神圣重任”

• 流程落地靠“工具”了
• 我買了你的“工具”，是不是我們流程就跑順了，就規范了
• “工具”能不能給我出數據，能不能幫我XXXX，流程里面提到了“工具”

工具背后的“復雜性”

提到流程背后“工具”，我必須拿出下面這張圖來說道說道

• 如果你的團隊/組織只有10人左右，可以直接跳出這篇文章，因為你確實不需要工具“規范”
• 如果你的團隊規模在超過10-50人（且屬于一個團隊），定義“簡單的”規范即可，能說清楚就好；工具文檔怎么說，按照怎么做就好
• 如果你的團隊規模/數量，達到百人以上，那么你真的需要認真考慮下“工具規范”

面對如此之多的各種“DevOps”工具，每個領域選一個，最起碼也有10+吧。如果工具的“規范”都沒有，“流程”怎么可能落地？

• 工具怎么用？學習成本如何？
• 怎么命名規范一致？
• 怎么申請？
• 怎么協作？
• 怎么用好？
• 怎么采集數據？
• 怎么按照最佳實踐？
• 怎么滿足流程要求？
• 怎么面對個性化需求？
• 怎么滿足既要，又要，還要？
• 怎么讓工具“匹配并支持”流程

是不是很崩潰，這其實就是DevOps難以落地的其中一個原因~ “眾口難調”和 “眾望所歸”，“自動化的工具體系”是“組織”最后的救命稻草。

工具背后的“規范”

如何把“眾口難調”，變成 “說一不二，不可辯駁，被“馴化”，被“教育””，不管你是買，還是自己搞，這都是工具背后要去思考的。無非你買來的，人家幫你理清楚一些規范了，可是依然不能滿足“眾口難調”。

沒有“完美的”工具，不要指望世界上有一款工具，能滿足所有人的要求，所以“工具”要學會說不。滿足所有人，就意味著不可能“好用”，甚至會成為“負擔”。

• 立規矩
• 教育用戶，引導用戶
• 學會拒絕，不能拒絕就擺爛
• “一味迎合”，最終會是“一地雞毛”

**持續關注我，我會分享具體關于工具的規范~ **

流程是死的，人是活的，解決什么問題？

這里要談談，為什么要有流程？

• 具體解決某個問題？經常出問題，所有要通過流程約束？
• 流程過時了，還要一味遵守嗎？
• 流程不能解決問題，是不是證明原來本身就有問題？

“能夠“ 切實解決問題，為團隊減負的流程，才是好流程。一味不斷加碼，還不解決問題，誰會愿意遵守？

反模式

• 畫個流程圖，能滿屏各種角色，這不是流程的問題，而是組織架構的問題，大道至簡
• 一開始設計完美的流程，就意味無法落地-流程要在試錯中不斷完善，并且與“工具規范”磨合
• 缺少“工具規范”和最佳實踐指引，沒有“周到細致引導”的流程，誰會遵守呢，團隊成員需要被“教育培訓強化”
• 工具先行，靠工具來推動流程，把“工具”或者 DevOps當作“銀彈”
• 設計流程的人，沒有深入貼近群眾，走進群眾，甚至不考慮落地
• 過度迎合縱容“群眾”，你是代表組織的，縱容迎合就是破壞自己親手制定的流程
• 老舊的“流程”，還不舍得放棄，層層加碼，“學會做減法”
  

總結

最后，簡單總結，其實就是這么幾個要素。每個要素不能自洽，或者缺失，很可能這個流程就無法落地，并深入執行。

• What - 流程定義了做什么
• How - 規范定義了怎么做
• Who - 誰來參與
• When - 什么時候做
• Why - 為什么要這么做？

”流程“ 和”規范“密不可分，流程代表了組織的角色協作，”規范“指導了如何做的問題。

• 沒有”流程“哪里會有”規范“；
• 沒有”規范“，怎么可能促進”流程“的運轉；
• 清晰的“工具規范”有助于平臺的建設，事半功倍
• 流程要”簡單“，規范要”細致且嚴格，才會有事半功倍；否則”流程“就會成為”一紙空文“。

關于我，一個”野生“的DevOps實踐者，不講理論，沒有認證加持， 從”實踐“中反思總結改進。