華爲精益敏捷專家：DevOps轉型中的那些坑

陳軍--原騰訊高級項目經理、華爲精益敏捷專家

DevOps是如今很是流行的一個詞，不少人都在提DevOps，在往那個方向去轉，但轉的時候坑特別多。

現實是很理想的，你們都以爲作了DevOps以後就會很是快了，業務就會很是好了，但其實作了DevOps以後，你的業務也不必定會很是好。在不少公司內部也有共識，工程跟業務沒有任何關係，但作了總比沒作好。

這是轉型的J型曲線，這個曲線出如今DevOps2018的報告裏，但這個曲線在不少變革當中都會出現，這個是Model的原型，作任何一場組織變革，DevOps也好，敏捷也好，都會通過這樣的曲線，這中間有一個很是大的坑要過，經歷過這個痛苦的過程以後，你的績效會變得愈來愈好。

轉型的時候咱們但願你們有一個思考的邏輯。這個思考邏輯從上到下是Values、Principles、Methods、Tools&activities。不要一心鋪到工做上，要想清楚價值是什麼，採用的是什麼原則，要用什麼樣的方法，再取決於用什麼樣的工具跟活動。

敏捷價值觀就是敏捷宣言那四句話，那四句話是咱們的價值觀，價值觀下面有原則、工具、實踐活動，這是思考轉型的邏輯，DevOps也是同樣的。

DevOps裏面有敏捷、精益、持續集成、持續交付 ，裏面包括不少東西，你在真正解決問題的時候要獲得什麼樣的好處，你用的是什麼原則，用的是什麼方法，而後再配相應的工具，這是你轉型的原則。我以爲這樣很是重要，若是思考不清楚就不要去用。

因此咱們在作一件事情的時候，你要得到的價值是什麼？這是你要思考的邏輯。

1-DevOps是個坑

這個圖你們能夠看得很清楚，第一個是Dev&Ops，原來的Dev和Ops是分開的。當咱們用了DevOps以後，它仍是一個坑。最怕的是把這個坑丟給客戶了，因此咱們這裏很是重要的原則就是坑誰都不要坑客戶，你不要把很差的東西給客戶。

在華爲有一個團隊，領導意識到在轉型的過程中確定會有坑，因此領導幫團隊去承擔了處分，最後處分的是領導。這個也是在DevOps轉型時很是重要的點，團隊必定會犯錯，但做爲領導要幫團隊創造容錯氛圍，不要一犯錯就指責團隊，坑誰都不要坑客戶，這是很是重要的點。

這是DevOps的模型，能夠看到最底層的東西是精益管理。

精益的來源是誰？豐田。

豐田最重要的兩個原則是自生產和自動化。但這兩個原則實際上是衝突的，這個廠講流動要快，另外一個廠講出了問題要停下來，因此這兩個是衝突的，豐田不只要快並且質量要好。

最先豐田是作織布機的，把手動織布機改爲了自動織布機。一開始的版本有問題，一旦織布機的線斷了以後織布機不會停，跑着跑着出來的布是有問題的，由於裏面的線斷了，因此出來的是殘次品，質量很是很差。後來豐田作了改進，一旦線斷了織布機會停掉，須要人把線接起來再跑，這就是豐田注重質量的原則和方法。

創建如下游爲中心而優化，作到質量內建。不能把問題留在下游，一旦這個過程出了問題，整個生產都要停下來，這是持續集成、持續交付很是重要的原則，一旦流水線出問題斷了，你第一時間要處理流水線，而不是填新的代碼，這是很是重要的原則。

2-技術債務拖後腿是一個坑

這是目前很是隱形的問題，雖然你們不是很在意，但若是你的產品想長期發展，想速度愈來愈快，這是很重要的事情。咱們能夠從漫畫裏看到，這兩我的一直在挖坑，發現本身挖到必定程度就出不去了。咱們如今就是這樣，咱們是在給本身挖坑，雖然看起來還以爲很快，但回過頭會發現，那些坑已經填不了了。

質量分外部質量和內部質量。外部質量是用這個產品時體會到的，一般是經過測試去覆蓋的，內部質量是指代碼。從這個系統思考圖，能夠看到有不少的惡性循環。若是外部質量差，測試信息會受到影響，測試周期會愈來愈長，由於不知道哪裏會出問題，會影響到交付週期。可能會盡快交代碼，交代碼會亂寫，內部質量會愈來愈差，這是惡性循環。內部質量和外部質量之間的影響是有實質的，不會那麼快的反映出來，因此不少時候咱們重視外部質量，但忽略了內部質量。內部質量差的時候，會發現核心功能會愈來愈慢。

怎麼減小技術債務？ 咱們說衡量代碼質量的惟一標準是你在作代碼檢視的時候每分鐘說了多少個F詞。我在一個關於DevOps的網站上看到一篇很是火的博文，推薦了DevOps相關的十本書。推薦的第一本書其實跟DevOps並不相關。要把DevOps作好，基礎代碼質量是很是重要的事情。

怎樣減小技術債務？代碼的規範是很是重要的。爲何代碼的規範很是重要？首先你的代碼是寫給人看的，不是寫給機器的，這是很是重要的事情。讀代碼和寫代碼的比例時間是10：1，你的代碼必定要先寫給人看再寫給機器。你想一想若是要看別人寫的代碼，若是你很痛苦，怎麼改這個代碼？不少的遺留代碼咱們不敢去改，由於看不懂，因此代碼規範很是重要。在谷歌專門有一種人是作代碼規範review的，他們內部有一個可讀性的證書，有了這個證書才能review別人的代碼，並且有權利把別人的代碼打回去。若是他的代碼沒有經過，是沒辦法提交的，谷歌作的就是這麼嚴格，可讀性是很是重要的事情。

規範與度量包括代碼規範、代碼質量度量。谷歌的code review作的很是嚴格，必定要經過code review才能提交代碼。工具輔助包括規範檢查、代碼質量檢查。重構這個事很重要，比較重要的是童子軍規則，在出營地的時候要比進營地時的這塊地更乾淨。若是我看了這一段代碼，當我關閉這段代碼的時候，必定要改。重構不是運動，不是臨時想起來就要大範圍搞一下，必定是平時就要去作的習慣，看到代碼不爽就要去改。

3-團隊的一個案例中的坑

某實施DevOps的團隊遇到下面的問題，一開始他們採用主幹開發，可是頻繁提交代碼集成沒法保證主幹的質量（主幹健康度的度量），QA會常常找團隊，團隊以爲很是煩，慢慢他們再也不那麼頻繁提交，作完一堆需求再一塊兒提交。後來PM抗不住了，改變策略採用分支開發，大量的問題在集成測試時爆發，致使集成測試時間很緊。若是是你，你會怎麼給他建議？

我給的建議是，其實他們採用分支開發是日後退的，在持續集成裏有一個很是重要的原則，他們繞過痛苦的事情就會更痛苦，頻繁提交是ok的，他們要解決的問題是怎樣把主幹集成度作起來，而不是日後退。當時他們也有作單元測試，但他們的單元測試是後補的，不是跟代碼一塊兒提交的，因此主幹健康度比較差。他們要改變的是把單元測試和代碼同時提交，必定要跑過單元測試代碼才能往上提。如今華爲提交代碼到主幹的時候，都會有一個所謂的門禁，門禁裏面要檢查不少東西，包括代碼、規範、質量指標、單元測試都要跑通才能提交代碼。

這裏面有兩個，一個是機器檢查，一個是Code Review，這兩個都提交才能夠。但不能說主幹質量很差就日後退，要解決主幹質量的問題，而不是日後退，因此越痛苦的事情越要常常作，越要頻繁去作，痛苦的點纔是你要改進的點。

讓代碼流動起來，並快速得到反饋。必定要小批量頻繁提交代碼，但提交代碼是有前提的，要過門禁才行。

4-微服務是個坑

微服務也是咱們如今提的比較多的東西，到底要不要作？不少人都在說。這裏的理念是什麼？若是你的代碼是一坨shit，切成微服務就是N坨shit，是管理一坨仍是N坨？你作微服務的基礎是系統要比較好，微服務架構要緊的是如何正確劃定邊界，微不微其實不重要。咱們最近有一個上海的團隊，他們切了微服務嚐到了一些甜頭，但更痛苦的是服務間的耦合以及服務與硬件的耦合，這讓他們很是痛苦，改一個地方要改好多服務。這個團隊在跟南大教授合做，一個是微服務密度的問題，一個是微服務拆分的問題，其實不少服務不用拆，既然耦合度這麼高幹嗎要拆？微服務改了以後其餘的都要動，幹嗎還要改？

這是Martin Fowler2015年提出的 單體優先 。微服務自己在作的時候有很大成本，它的成本能不能給你帶來更多的收益？這是咱們在作一項決策時會考慮的，就是投資回報率的問題。

Martin Fowler強調單體優先，若是一開始作微服務不少的基礎設施都要跟上，這個成本蠻高，因此他提到微服務溢價的問題，要看微服務的好處能不能抵消成本。

構建演進式的架構，地球之前的大陸是在一塊地，隨着時間的推移和環境的變化才慢慢演進出了各個洲、各個塊，咱們的架構也是同樣的，不必定一開始就要建立合適的架構，能夠建立演進式的架構，能夠在特定的時間進行轉換。咱們要注意幾個原則，講的都是解耦的問題。

一是將大型的域分割成變動孤島；
二是針對可替代性進行設計。可替代性是什麼？原來不少的系統跟模塊不敢去改，雖然這塊可能不少人沒用，但咱們也不敢改，由於有耦合性，咱們不敢動。若是針對可替代性作服務，這個服務若是不用了，隨時能夠停掉，把服務直接殺死接新服務就能夠了；
三是最小化共享依賴，重點關注自治和冗餘，而不是重用。

5-度量是個坑

度量咱們聽到的最多反饋是什麼？這玩意兒就是給上面看的，沒什麼用。沒有這些指標，我咋知道下面的人乾的咋樣？這是咱們聽到最多的說法。包括有人說爲了確保數據的真實性，須要加上考覈指標。有一些團隊是分佈式的，在不少地方，他們想知道異地團隊在幹什麼事。咱們有一個IT系統，怎麼確保他們更新的數據是真實的？是否是要加一些考覈指標去考覈他？保證他更新的數據是真實的。這些都是咱們常見的對度量的誤解。

有哪些度量的誤區？一是數據的生產者不是數據的消費者，數據生產者不關心數據的價值，也不關心數據準確與否。不少時候數據是給領導看的，不是給咱們看的；二是數據的生產者關心是佛會對本身帶來懲罰或受益，不關心數據跟軟件開發的關係。這會產生什麼問題？數據造假；三是數據等於控制，必定要看到數據才知道下面的人在幹什麼。

度量的意義究竟是什麼？咱們以爲度量的意義是改進。改進在於什麼？本身跟本身比，不要橫向比較，每一個團隊都不同，橫向比較是很是痛苦的一件事情，咱們在華爲是踩過坑的，這個事我就不太好講了。橫向比較和晾曬的緣由，致使不少團隊的數據造假，這是華爲真正踩過的坑，曾經是華爲內部很轟動的事情。度量會告訴咱們離目標還有多遠，現狀是什麼，進展如何。

這是一個度量指標的體系，很是多，你們能夠參考一下。

度量是一個系統工程，須要不斷演進。首先你要知道度量不是免費的，有成本，須要有效性和可靠性，咱們收集的數據最好是機器產生的，而不是人去填的，這個很重要。第二個是OMTM，這是精益數據分析的概念，叫單一關鍵指標。選擇適合當前的產品階段的指標，重點優化該指標。最好是這一段時間就優化這一兩個指標，不要分得太散。第三個是隨時審視，作加法也要作減法，不要讓度量成爲團隊的負擔。最重要的一點，不要跟考覈掛鉤，不要橫向比較，這是華爲踩過的很是大的一個坑，一旦跟考覈掛鉤，一旦橫向比較，數據必定會造假。

6-缺少全局視角，阻礙進一步提高是一個坑

這是DevOps三步工做法中的內容，第一步是持續流動，第二步是持續反饋，第三步是持續學習。今天咱們要講的是持續學習。

這裏有一個案例，數據大屏讓團隊擁有全局視角。咱們在華爲內部看團隊數據是否作好，就要看數據大屏是否作起來了，研發全部的數據在這個屏上都能看到。這是一個微服務團隊的分數，包括服務得分、服務告警、API訪問次數TOP等等都有，能夠根據本身的狀況去作。消費者那邊的數據纔多，今天現場的左屏一直延伸到右屏都是數據。這個用處是什麼？讓研發團隊看到全局，知道我這個東西發出去以後有多少人在用，有沒有問題，有問題要及時解決。

這是其中一個案例，這個接口原來有性能問題，就是在沒有大屏以前。運維也跟團隊講了，但沒人管，你們都在作新的需求。後來有了大屏以後，這個就很前沿的，由於它的性能不好，團隊和領導看了安排人員去優化，接口性能提高了9倍。

經過大屏數據挖掘用戶潛在需求，提高滿意度。這也是一個真實案例，經過服務發出去，關注運營指標，他們看到在9月份訪問量忽然增長，但用戶數又沒有變。他們進一步分析，找到用戶去問，爲何這個時段的訪問量這麼大？後來發現是由於用戶按期會有巡檢，而後就挖掘了更多用戶的需求。這對於開發團隊來說也是很重要的一點，不少時候東西發出去不知道用戶的滿意度怎樣，有沒有人在用。

最後再回顧一下這張圖，咱們轉型的思考邏輯，首先是價值，作這個事情對咱們的價值是什麼？咱們須要的原則是什麼？咱們應該用什麼樣的方法？對應的工具和時間活動究竟是什麼？DevOps不僅是工具，轉型應該是更高維度的思考，自上而下。

文章來源：Worktile敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。