陳軍--原騰訊高階專案經理、華為精益敏捷專家

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敏捷部落格

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

文章轉載請註明出處。

&n