一星期8天

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

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

公司里有一個程序，運行在10臺服務(wù)器的集群上。現(xiàn)在業(yè)務(wù)量增加了，請求處理不完。老板把你找來，要你優(yōu)化這個程序。接到這個頭疼的任務(wù)，你把開發(fā)測試運維各個部門的人都找來開會想辦法，有人說數(shù)據(jù)庫該升級了，有人說代碼寫的太爛要優(yōu)化，有人說機器太少再加5臺，還有人說我們要改架構(gòu)上云，上了云以后就再也沒有這種問題了。你該聽誰的呢？

先別著急動手。有一句話叫做“沒有度量就沒有優(yōu)化”，首先要“度量”這個現(xiàn)象。先把設(shè)計人員找來，了解一下這個程序是什么功能，工作流程是什么樣的。

程序架構(gòu)：這個程序處理圖片識別的業(yè)務(wù)，從網(wǎng)絡(luò)端口接收圖片，識別圖片里面的信息，然后在圖片庫里進行對比，最后輸出相似圖片。處理過程是這樣的：

搞清楚程序架構(gòu)，接下來我們需要度量數(shù)據(jù)。有一些數(shù)據(jù)很容易得到，還有一些數(shù)據(jù)似乎沒人搞得清。于是你給研發(fā)團隊布置了一個任務(wù)，讓他們在程序里面埋點，盡快收集一些數(shù)據(jù)指標。開發(fā)人員改了一版程序，部署上去。在生產(chǎn)線上跑了一天，得到一些數(shù)據(jù)指標： 

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

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

是不是告訴老板必須要買服務(wù)器了呢：“需要買1臺服務(wù)器，帶GPU的！”。先別著急。

我們分析一下程序運行過程：識別函數(shù)和比對函數(shù)是串行執(zhí)行的。識別函數(shù)忙碌的時候，比對函數(shù)是空閑的，它在等待識別的結(jié)果。同樣的，比對函數(shù)忙碌的時候，識別函數(shù)也是無事可做的。也就是說，服務(wù)器的資源并沒有得到充分利用，GPU卡和數(shù)據(jù)庫的資源都有很大的浪費。

怎樣提高資源利用率呢？可以改變一下程序的架構(gòu)，調(diào)整成下面這樣：

把原來的程序一分為二，分別部署在兩臺服務(wù)器上，中間用一個消息隊列交換數(shù)據(jù)。現(xiàn)在兩個程序都可以充分利用服務(wù)器的資源。我們再來計算一下吞吐量： 

• 程序X：處理一個圖片需要0.5秒，1臺服務(wù)器1天處理圖片172800（86400 / 0.5），100萬圖片需要服務(wù)器 5.8 臺（100萬 / 172800），約等于6臺。
• 程序Y：處理一個圖片需要0.4秒，1臺服務(wù)器1天處理圖片216000（86400 / 0.4），100萬圖片需要服務(wù)器 4.6臺（100萬 / 216000），約等于5臺。

仍然需要服務(wù)器11臺，好像沒有什么改進嘛。我們再分析一下：原方案需要11臺帶GPU的服務(wù)器，現(xiàn)在只需要6臺，我們省下了5塊GPU卡，這已經(jīng)是一筆不少的費用。

架構(gòu)師又提供了一個信息：在原方案里面，識別函數(shù)和比對函數(shù)串行執(zhí)行，所以只能用同樣的并發(fā)線程數(shù)執(zhí)行。新方案已經(jīng)分離到兩個程序中，所以比對函數(shù)就可以設(shè)置更高的并發(fā)線程數(shù)，可以提高到原來的4倍。

這是一個好消息，程序Y的吞吐量可以提高4倍，這樣一來，只需要1.16臺服務(wù)器就可以處理完100萬數(shù)據(jù)，約等于2臺。

按照改進后的架構(gòu)，只需要6臺帶GPU的服務(wù)器，再加2臺不帶GPU的服務(wù)器，總計需要8臺服務(wù)器。不僅可以完成處理任務(wù)，還可以預留一些GPU卡，以備以后業(yè)務(wù)發(fā)展。

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

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

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

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

• 代碼管理：代碼基線不明確，版本無法回溯
• 發(fā)布管理：發(fā)布文檔沒有妥善保管
• 版本管理：版本號沒有明確的烙印，編號不清楚。無法判斷新老版本的兼容關(guān)系
• 基礎(chǔ)設(shè)施管理：研發(fā)人員沒有辦法迅速得到基礎(chǔ)設(shè)施，為了建立一個測試環(huán)境需要花很長時間
• 部署管理：測試人員手工部署，需要花很久才能完成一次部署
• 環(huán)境管理：現(xiàn)場的服務(wù)器上部署了哪些進程，沒有一套管理辦法，需要登錄上去查看

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

把整體流程搞清楚，當然是存在很多困難的。一個大問題就是：企業(yè)工作流程不像IT系統(tǒng)流程一樣清楚。IT系統(tǒng)一般有各種文檔，至少有源代碼可以查看。企業(yè)工作流程經(jīng)常存在一些模糊的地方，部門和崗位職責的定義不是十分清楚。人也不會像程序一樣“聽話”，為了完成自己的工作任務(wù)，人是有創(chuàng)造性的。所以每個企業(yè)都要整理崗位和工作流程，努力把這些模糊的流程整理清楚，按照自己的業(yè)務(wù)特點制定一套流程規(guī)范，這是十分必要的工作。技術(shù)崗位上的人更熟悉實際的工作流程，他們走上管理崗位，在這方面是有優(yōu)勢的。

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