很多技術(shù)人員在職業(yè)上對(duì)自己要求高，工作勤奮，承擔(dān)越來越大的責(zé)任，最終得到信任，被提拔到管理崗位。但是往往缺乏專業(yè)的管理知識(shí)，在工作中不能從整體范圍優(yōu)化工作流程，仍然是“個(gè)人貢獻(xiàn)者”的工作方式，遇到問題自己上，經(jīng)常耽誤了本職工作。

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

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

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

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

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

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

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

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

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

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

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

把原來的程序一分為二，分別部署在兩臺(tái)服務(wù)器上，中間用一個(gè)消息隊(duì)列交換數(shù)據(jù)?，F(xiàn)在兩個(gè)程序都可以充分利用服務(wù)器的資源。我們?cè)賮碛?jì)算一下吞吐量： 

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

仍然需要服務(wù)器11臺(tái)，好像沒有什么改進(jìn)嘛。我們?cè)俜治鲆幌拢涸桨感枰?1臺(tái)帶GPU的服務(wù)器，現(xiàn)在只需要6臺(tái)，我們省下了5塊GPU卡，這已經(jīng)是一筆不少的費(fèi)用。

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

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

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

例子說完了，以上就是優(yōu)化一個(gè)IT系統(tǒng)運(yùn)行效率的過程。其實(shí)，企業(yè)管理也是相似的過程，只是優(yōu)化的對(duì)象不再是機(jī)器和程序，而是人的活動(dòng)。

在一家軟件企業(yè)，有需求收集、產(chǎn)品研發(fā)、項(xiàng)目實(shí)施等多個(gè)流程，有時(shí)這些流程會(huì)有卡頓、緩慢的現(xiàn)象，看上去和一個(gè)IT系統(tǒng)的問題是一樣的。有一個(gè)著名的問題是：“在你的團(tuán)隊(duì)里，只涉及一行代碼的變更需要多久才能上線？” 從需求到交付，這個(gè)路程有多遠(yuǎn)。

我們可能經(jīng)常會(huì)遇到這樣的問題：某個(gè)現(xiàn)場(chǎng)運(yùn)維反饋了一個(gè)缺陷，看上去只是很小的問題，修復(fù)也不麻煩，卻花了很長(zhǎng)時(shí)間才解決。事后回顧這個(gè)問題，每個(gè)部門的人都有話要說：

運(yùn)維：我一發(fā)現(xiàn)這個(gè)問題，就在Jira平臺(tái)上提出來了，當(dāng)時(shí)開發(fā)也沒有回復(fù)，我就下班了。

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

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

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

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

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

把整體流程搞清楚，當(dāng)然是存在很多困難的。一個(gè)大問題就是：企業(yè)工作流程不像IT系統(tǒng)流程一樣清楚。IT系統(tǒng)一般有各種文檔，至少有源代碼可以查看。企業(yè)工作流程經(jīng)常存在一些模糊的地方，部門和崗位職責(zé)的定義不是十分清楚。人也不會(huì)像程序一樣“聽話”，為了完成自己的工作任務(wù)，人是有創(chuàng)造性的。

所以每個(gè)企業(yè)都要整理崗位和工作流程，努力把這些模糊的流程整理清楚，按照自己的業(yè)務(wù)特點(diǎn)制定一套流程規(guī)范，這是十分必要的工作。技術(shù)崗位上的人更熟悉實(shí)際的工作流程，他們走上管理崗位，在這方面是有優(yōu)勢(shì)的。

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