很多技術人員在職業上對自己要求高，工作勤奮，承擔越來越大的責任，最終得到信任，被提拔到管理崗位。但是往往缺乏專業的管理知識，在工作中不能從整體範圍優化工作流程，仍然是“個人貢獻者”的工作方式，遇到問題自己上，經常耽誤了本職工作。於是翻了很多書，看了很多文章，學習了很多“為人處世的藝術”和“企業發展的戰略”，最終把自己幹成了研發部主管，技術卻逐漸荒廢。管理工作是什麼呢，技術和管理是截然不同的兩條發展方向嗎？

不是的。技術和管理都要做到量化分析，全域性優化，存在很多相似的方法。這裡用一個系統性能優化的場景舉個例子，大家可以體會一下：

公司裡有一個程式，執行在10臺伺服器的叢集上。現在業務量增加了，請求處理不完。老闆把你找來，要你優化這個程式。接到這個頭疼的任務，你把開發測試運維各個部門的人都找來開會想辦法，有人說資料庫該升級了，有人說程式碼寫的太爛要優化，有人說機器太少再加5臺，還有人說我們要改架構上雲，上了雲以後就再也沒有這種問題了。你該聽誰的呢？

先彆著急動手。有一句話叫做“沒有度量就沒有優化”，首先要“度量”這個現象。先把設計人員找來，瞭解一下這個程式是什麼功能，工作流程是什麼樣的。

程式架構：這個程式處理圖片識別的業務，從網路埠接收圖片，識別圖片裡面的資訊，然後在圖片庫裡進行對比，最後輸出相似圖片。處理過程是這樣的：

搞清楚程式架構，接下來我們需要度量資料。有一些資料很容易得到，還有一些資料似乎沒人搞得清。於是你給研發團隊佈置了一個任務，讓他們在程式裡面埋點，儘快收集一些資料指標。開發人員改了一版程式，部署上去。在生產線上跑了一天，得到一些資料指標： 

• 輸入：每天需要處理100萬張圖片，這是從上游工序收集到的
• 識別函式：識別1張圖片平均時間是0.5秒
• 比對函式：比對1個圖片的平均時間是0.4秒

現在我們計算一下：處理1張圖片的時間是0.9秒（0.5 + 0.4），1臺機器1天可以處理圖片96000（86400 / 0.9），10 臺機器1天可以處理圖片96萬（96000 * 10），達不到100萬。要完成每天100萬的處理量，需要伺服器10.4臺（100萬 / 96000），約等於11臺。

是不是告訴老闆必須要買伺服器了呢：“需要買1臺伺服器，帶GPU的！”。先彆著急。

我們分析一下程式執行過程：識別函式和比對函式是序列執行的。識別函式忙碌的時候，比對函式是空閒的，它在等待識別的結果。同樣的，比對函式忙碌的時候，識別函式也是無事可做的。也就是說，伺服器的資源並沒有得到充分利用，GPU卡和資料庫的資源都有很大的浪費。

怎樣提高資源利用率呢？可以改變一下程式的架構，調整成下面這樣：

把原來的程式一分為二，分別部署在兩臺伺服器上，中間用一個訊息佇列交換資料。現在兩個程式都可以充分利用伺服器的資源。我們再來計算一下吞吐量： 

• 程式X：處理一個圖片需要0.5秒，1臺伺服器1天處理圖片172800（86400 / 0.5），100萬圖片需要伺服器 5.8 臺（100萬 / 172800），約等於6臺。
• 程式Y：處理一個圖片需要0.4秒，1臺伺服器1天處理圖片216000（86400 / 0.4），100萬圖片需要伺服器 4.6臺（100萬 / 216000），約等於5臺。

仍然需要伺服器11臺，好像沒有什麼改進嘛。我們再分析一下：原方案需要11臺帶GPU的伺服器，現在只需要6臺，我們省下了5塊GPU卡，這已經是一筆不少的費用。

架構師又提供了一個資訊：在原方案裡面，識別函式和比對函式序列執行，所以只能用同樣的併發執行緒數執行。新方案已經分離到兩個程式中，所以比對函式就可以設定更高的併發執行緒數，可以提高到原來的4倍。

這是一個好訊息，程式Y的吞吐量可以提高4倍，這樣一來，只需要1.16臺伺服器就可以處理完100萬資料，約等於2臺。

按照改進後的架構，只需要6臺帶GPU的伺服器，再加2臺不帶GPU的伺服器，總計需要8臺伺服器。不僅可以完成處理任務，還可以預留一些GPU卡，以備以後業務發展。

例子說完了，以上就是優化一個IT系統執行效率的過程。其實，企業管理也是相似的過程，只是優化的物件不再是機器和程式，而是人的活動。在一家軟體企業，有需求收集、產品研發、專案實施等多個流程，有時這些流程會有卡頓、緩慢的現象，看上去和一個IT系統的問題是一樣的。有一個著名的問題是：“在你的團隊裡，只涉及一行程式碼的變更需要多久才能上線？” 從需求到交付，這個路程有多遠。我們可能經常會遇到這樣的問題：某個現場運維反饋了一個缺陷，看上去只是很小的問題，修復也不麻煩，卻花了很長時間才解決。事後回顧這個問題，每個部門的人都有話要說：

• 運維：我一發現這個問題，就在Jira平臺上提出來了，當時開發也沒有回覆，我就下班了。
• 開發：我當時正在開發新版本的功能，寫一段很複雜的程式碼。看到這個問題的時候，已經是下班時間了。運維只描述了問題現象，沒有說明現場部署的版本。我不知道在哪個版本上修復這個問題，只好在最新的釋出版上先把它改掉了，然後把包發給測試。我在Jira上也回了訊息，要求運維把現場版本號發出來；
• 測試：我收到開發的包，打算做一下測試。整個整合環境已經升級了，我需要把測試環境恢復到老的版本。這事我搞了一上午，下午的時候搞了一遍測試，發現幾個缺陷，把問題提給開發了。
• 開發：我收到測試提的Bug，修改以後又發了一個版。這次應該沒問題了。
• 運維：環境上的包沒有版本標識，我花了很長時間核對所有版本的Md5碼，才找到了版本號，在Jira上回了。這個問題很緊急，我想盡快解決，於是就拿測試給我的最新版，想嘗試安裝一下。我不知道這個包能不能相容現場的環境，只能試試看。我在預釋出環境上搞了一天，也沒把他裝上去，看起來是不行的。
• 開發：我看到現場版本號，這是一個非常老的版本，已經一年多了。我進入這個專案才三個月，在微信上AT了好幾個人。程式碼基線也不知道在哪裡，找了很久才找到。修復之後已經很晚了。還是要交給測試測一下。
• 測試：整合環境還是要恢復一下，我搞了三個小時。測試確認沒有問題，就交給運維了。
• 運維：我收到安裝包，在預釋出環境上試了一下，沒什麼問題。生產環境要麻煩一些，我一開始只更新了一個節點，發現問題仍然間歇性的出現。後來才知道要還有2個節點也要部署。這次搞了一天，下次再有這樣的情況，我就知道怎麼做了。

從每個人的角度看，自己都很忙碌，花了很多時間解決問題。但是從缺陷解決的角度看，事情在不斷的卡頓、等待。在這些勞動過程中，真正有效的、能產生價值的勞動佔多少呢？這就是DevOps需要解決的價值流動問題，需要建立一套體系，衡量這個流程，不斷優化它。

從上面一個缺陷解決的過程來看，技術部門存在很多問題，有一些問題是單點的，比如：

• 程式碼管理：程式碼基線不明確，版本無法回溯
• 釋出管理：釋出文件沒有妥善保管
• 版本管理：版本號沒有明確的烙印，編號不清楚。無法判斷新老版本的相容關係
• 基礎設施管理：研發人員沒有辦法迅速得到基礎設施，為了建立一個測試環境需要花很長時間
• 部署管理：測試人員手工部署，需要花很久才能完成一次部署
• 環境管理：現場的伺服器上部署了哪些程序，沒有一套管理辦法，需要登入上去檢視

看到這些問題，是不是就可以開始改進了呢？還是不要著急。像優化一個IT系統一樣，我們要搞清楚工作流程，然後度量這個流程，再整體優化。在整體情況不清楚的情況下，區域性優化是沒有用的，優化一個區域性的效率，可能適得其反，造成更大的浪費。

把整體流程搞清楚，當然是存在很多困難的。一個大問題就是：企業工作流程不像IT系統流程一樣清楚。IT系統一般有各種文件，至少有原始碼可以檢視。企業工作流程經常存在一些模糊的地方，部門和崗位職責的定義不是十分清楚。人也不會像程式一樣“聽話”，為了完成自己的工作任務，人是有創造性的。所以每個企業都要整理崗位和工作流程，努力把這些模糊的流程整理清楚，按照自己的業務特點制定一套流程規範，這是十分必要的工作。技術崗位上的人更熟悉實際的工作流程，他們走上管理崗位，在這方面是有優勢的。

工作流程明確之後，就可以對流程節點進行度量。我們可以採用視覺化技術對資料進行分析，比如看板、資源投入狀態、任務燃盡圖等等，尋找卡頓活動，判斷瓶頸資源。這方面有一些科學的方法，軟體行業也在從製造行業學習精益生產的理論。對於一個大規模的軟體企業，在管理方面有所改善，形成的效率提升是巨大的。