很多技術人員在職業上對自己要求高，工作勤奮，承擔越來越大的責任，最終得到信任，被提拔到管理崗位。但是往往缺乏專業的管理知識，在工作中不能從整體范圍優化工作流程，仍然是“個人貢獻者”的工作方式，遇到問題自己上，經常耽誤了本職工作。

于是翻了很多書，看了很多文章，學習了很多“為人處世的藝術”和“企業發展的戰略”，最終把自己干成了研發部主管，技術卻逐漸荒廢。管理工作是什么呢，技術和管理是截然不同的兩條發展方向嗎？

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

公司里有一個程序，運行在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系統一般有各種文檔，至少有源代碼可以查看。企業工作流程經常存在一些模糊的地方，部門和崗位職責的定義不是十分清楚。人也不會像程序一樣“聽話”，為了完成自己的工作任務，人是有創造性的。

所以每個企業都要整理崗位和工作流程，努力把這些模糊的流程整理清楚，按照自己的業務特點制定一套流程規范，這是十分必要的工作。技術崗位上的人更熟悉實際的工作流程，他們走上管理崗位，在這方面是有優勢的。

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