第四章 流程編排

治兵不知九變之術，雖知五利，不能得人之用矣。是故智者之慮，必雜於利害。雜於利，而務可信也；雜於害，而患可解也。《九變篇》

2.1 實踐說

專案正式啟動之後，產品經理先設計了原型圖，借鑑+創造+整合完成了基本的產品形態，功能要點。按理說該摟起袖子加油幹程式碼了，還是Too Young Too Simple了。本小部門之前也有一定的研發流程規範，但是畢竟人為的東西靈活度很高，任何一個環節都可以根據反饋隨時調整、修正，真正要資訊化了，首先要解決①埋點收集資料，②合適的節點上必須寫入規劃的資料。經過基本的推導，按照之前的工作流程習慣，邏輯上就無法匹配設計好的產品功能。

總不能針對本部門的工作方式設計一套DevOps吧，這樣整個部門都可以拿個績效D了，當之無愧。但也總不能無腦的按照競品或理想化的流程來落地呀，就這麼自然而然的回到了所有資訊化、數位化的老命題，流程規整必不可少。

最後的結論就是，召開大會討論了一番研發流程的規整，先從現實世界入手，將工作流程調整到一定的狀態，來為接入系統做好準備，並且也結合公司其他部門工作習慣來探索一條「比較優」的流程，來作為標杆，首先能夠在不借助系統的情況下把事情做了。

大概最後的共識就是，各個工種如何銜接、該做哪些必須項、前置依賴如何保證等等。最重要的是程式碼分支如何管理，跟需求如何關聯等等。此處只能省略太多字，不敢說的太清楚。

2.2 流程是基礎

流程管理是實現業務整合化、標準化和模板化的途徑。流程反映了業務流，承載了績效、質量、風控、資料的要求。沒有高質量的流程，就不會有高質量的資料。如果流程的活動缺乏明確的規則和標準，就會輸出大量不規範、不準確的資料給下游，從而影響業務活動和決策活動的有效性。

即使沒有系統，沒有資訊化，也得首先有合理、高效的流程，這才是強力競爭力的基礎，數智化最多的是加持，是錦上添花。妄想通過數智化拯救羸弱流程本身不合理的業務，可能又這樣力挽狂瀾的高人，可遇不可求之。

企業在流程變革上比較被動，通常是因為當要上各類應用系統時，比如ERP、CRM等，才開始成立專案組，梳理業務流程，從藍圖規劃、現狀還原、未來流程設計，再固化到系統，十分漫長。這還算比較理想的了。有的企業上系統，只是將現有的流程固化進去。過去沒有上系統，流程還比較靈活，大家可以自由發揮，可以規避流程，現在上了系統，矛盾集中爆發，大家紛紛抱怨系統不好用，效率更低了。其實是由於流程長期缺乏優化，隨著組織規模變大、分工變細，流程進一步被割裂，同時非增值的活動大量衍生，使得數位化轉型困難重重。有一個典型的痛點——企業沒有流程架構，由於缺乏架構，流程野蠻生長，業務能力規劃無法進行，IT應用架構規劃更缺乏基礎。此時，談數位化轉型，只是空中樓閣。

那固化一套最標杆、最理想、最合適的流程到系統裡，就可以了嗎？ToB的系統有這麼簡單就好了。

2.3 編排的藝術

K8S之所以能從Swarm、Nomad、Mesos等等對手中脫穎而出，成為事實上的標準，它在「編排」這件事情上某些理念肯定功不可沒，在流程編排上是否可以借鑑一二。首先得搞清楚什麼是編排？

Wiki 百科解釋我們常說的編排的英文單詞為 「Orchestration」，它常被解釋為

本意:為管絃樂中的配器法，主要是研究各種管絃樂器的運用和配合方法，通過各種樂器的不同音色，以便充分表現樂曲的內容和風格。

計算機領域:引申為描述複雜計算機系統、中介軟體 (middleware) 和業務的自動化的安排、協調和管理。

K8S在容器編排領域，有以下概念和理念，覺得很值得借鑑或山寨用來自己設計排程系統。去年在做釋出流水線排程時，覺得需求太客製化化，調研過一些開源的類似專案，都沒有可以完全照搬的，最後完全自己設計的，擴充套件能力很弱，直到今年專案二期時才進行了專門的優化與各種任務節點規範化、標準化，才完成了開放平臺的建設，新增加一種任務型別流水線服務工作量降低到了之前的25% 以下。事後覆盤才總結出其實K8S一直有很多東西擺在那裡等待借鑑。

API 物件

API 物件是 K8s 叢集中的管理操作單元。K8s 叢集系統每支援一項新功能，引入一項新技術，一定會新引入對應的 API 物件，支援對該功能的管理操作。例如副本集 Replica Set 對應的 API 物件是 RS。API 物件都有 3 大類屬性：後設資料 metadata、規範 spec 和狀態 status。

宣告式（Declarative）

K8s 中所有的設定都是通過 API 物件的 spec 去設定的，也就是使用者通過設定系統的理想狀態來改變系統，這是 k8s 重要設計理念之一，即所有的操作都是宣告式（Declarative）的而不是命令式（Imperative）的。宣告式操作在分散式系統中的好處是穩定，不怕丟操作或執行多次，例如設定副本數為 3 的操作執行多次也還是一個結果，而給副本數加 1 的操作就不是宣告式的，執行多次結果就錯了。

2.4 結語

「勝兵先勝而後求戰，敗兵先戰而後求勝」，猶如業務的資訊化、數智化一樣，首先業務做好「勝任」數智化的準備，而後才能雙贏。

我們不可能指望祈禱流程能夠一成不變、固化的，就能滿足所有業務訴求，就像一直使用一樣的「陣形」妄想常勝。變幻莫測的排兵佈陣、兵無常形，才具備更強的戰鬥力。既然如此，那麼我們只能積極擁抱變化、小步快跑，敏捷開發，扯遠了。雖然沒有強大的技術實力來支撐任意的研發流程組合，但是借鑑容器編排、流水線編排等等根基能力，做一套一定範圍內針對DevOps領域流程編排的系統理論上是可行的。

2.5 成果展覽

企業檔案建設倒不是說不能建設，這活得加錢。眼下能折騰的，重點就是流程了，工具這些開源+外採+自建，都是確定而且可控度比較高的，不容易出成績；文化層面又太過不可控了，唯有流程介於兩者之間，可以重點關照一下。

重點完成了兩大引擎的自主研發，支援使用者編排工具集和事項集。①流水線引擎，排程編排各種研發工具，以任務節點的方式可以被管控；②需求工作流引擎，與騰訊TAPD類似，重點針對需求狀態流轉、迭代階段設定等。

工作流運轉的同時，自動驅動相關流水線的執行，範例如下圖。最終的效果是，新入職的小白使用者，只需要寫程式碼，按團隊規範流轉需求，就能夠不知不覺中接入了DevOps全週期的相關能力。