從技術談到管理，把系統優化的技術用到企業管理

不少技術人員在職業上對本身要求高，工做勤奮，承擔愈來愈大的責任，最終獲得信任，被提拔到管理崗位。可是每每缺少專業的管理知識，在工做中不能從總體範圍優化工做流程，仍然是「我的貢獻者」的工做方式，遇到問題本身上，常常耽誤了本職工做。因而翻了不少書，看了不少文章，學習了不少「爲人處世的藝術」和「企業發展的戰略」，最終把本身幹成了研發部主管，技術卻逐漸荒廢。管理工做是什麼呢，技術和管理是大相徑庭的兩條發展方向嗎？

不是的。技術和管理都要作到量化分析，全局優化，存在不少類似的方法。這裏用一個系統性能優化的場景舉個例子，你們能夠體會一下：

公司裏有一個程序，運行在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系統通常有各類文檔，至少有源代碼能夠查看。企業工做流程常常存在一些模糊的地方，部門和崗位職責的定義不是十分清楚。人也不會像程序同樣「聽話」，爲了完成本身的工做任務，人是有創造性的。因此每一個企業都要整理崗位和工做流程，努力把這些模糊的流程整理清楚，按照本身的業務特色制定一套流程規範，這是十分必要的工做。技術崗位上的人更熟悉實際的工做流程，他們走上管理崗位，在這方面是有優點的。

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