對話徐磊：沒有不適合DevOps的企業，只有不適合DevOps的人

嘉賓簡介

徐磊，英捷創軟 LEANSOFT 創始人兼首席架構師，專註於軟體工程、DevOps 方面解決方案諮詢。有超過 10 年的軟體研發項目管理經驗，曾任 SSW 中國研發中心總經理。是資深 ALM 顧問和解決方案專家，微軟最有價值專家和大中華區域社區技術總監，認證 ScrumMaster 和敏捷教練。

StuQ 工作坊：您擁有多年 DevOps 實戰經驗，曾擔任京東商城、華為、中國農業銀行、百威英博等多個項目的高級 ALM/DevOps 顧問。您怎麼理解 DevOps？在您看來， DevOps 的核心競爭力是什麼？

徐磊：核心競爭力就是兩個字：效率。

IT 行業非常擅長發明新名詞，其實過去的 10 年中我一直都在做軟體工程相關的工作，一路走來撞上了很多這樣的名詞：SDLC（軟體開發生命周期），ALM（應用生命周期管理），敏捷，精益等等，到了 2012 年第一次聽說 DevOps。開始的時候也很迷惑，到後來發現這 10 多年都只做了一件事情，就是提高效率。DevOps 不能幫你直接解決業務問題，它只能幫你更快更好的交付業務需求，這就是效率。

這麼多年，其實軟體工程行業的關注點經歷了一個從微觀到宏觀，再回歸微觀的過程。比如一開始的 SDLC 就是一個關注軟體開發過程本身的方法論，後來發現這不夠，只關注開發本身解決不了問題，就開始向更大的範圍延展，也就是出現了 ALM。

其實 ALM 和 DevOps 所關注的問題領域很接近，只是前者更關注管理，而後者又開始向技術回歸，更加關注具體的實踐和落地的方案。而敏捷和精益在整個過程中則起到了價值觀引導和方向性指導的作用。

說的更直白一點，軟體工程行業做的就是效率的工作，我們雖然不能幫你寫代碼，做測試，但是我們會讓你寫的代碼體現出更多的價值，讓你的交付過程更加順暢，讓管理人員更有信心，讓技術人員在單位時間創造更多價值。

StuQ 工作坊：可否用一個您之前的案例，說說應用 DevOps 給開發團隊帶來哪些改變？

徐磊：案例很多，都可以和 DevOps 扯上關係，DevOps 其實就是一頂帽子，只要你做的是軟體工程領域改進效率的工作其實都可以說自己在做 DevOps。所以，不應該說 DevOps 這頂帽子給開發團隊帶來那些改變，而是 DevOps 下面的實踐給開發團隊帶來哪些改變。

我做的案例中金融行業比較多，比如：農行，興業銀行，博時基金等等。這個行業有一個普遍的特點，就是監管很嚴，造成的結果就是企業內部流程繁瑣，審批多，部門牆很嚴重。

我個人比較看重的改變其實是團隊士氣上的改變，比如之前給其中一家引入了用戶故事地圖和影響地圖實踐，協助他們完成了需求梳理過程。參與的成員普遍的反應是業務人員和技術人員可以開始對話了，而且效率很高，以往可能需要幾個月才能完成的需求梳理和設計，這次僅僅用了 2 周時間，項目就可以啟動了。而這種對話所帶來的默契在後續的開發過程中讓溝通更加順暢。

另外一家，我為他們的 iOS 開發項目定製了一套在 TFS 上面的集中自動化構建系統，這個事情讓他們的開發人員不再需要每個月抱著電腦到構建管理員那裡拷貝代碼才能發布版本。這裡解決的其實是 AppStore 證書的問題，因為企業證書是不能拷貝給開發人員的，而發布正式版本又需要這個證書，所以以前是靠人來管理，現在可以靠自動化系統。這個事情其實做的就是持續集成，但是解決的卻是流程問題。

引入 DevOps 實踐最重要的是要能帶來效率提升，讓涉及到的人員感受到價值。

StuQ 工作坊：您覺得哪一類企業適合 DevOps？如何評估一個企業適不適合，以及什麼時候適合實施 DevOps？

徐磊：我覺得沒有不適合 DevOps 的企業，只有不適合 DevOps 的人。企業都要盈利，沒有一家企業會認為效率提升對它沒有價值，所以都適合做 DevOps，而且都應該做。但是具體到人的個體，就不一定了。

這裡還是個案例，我的一家銀行客戶，一直希望能夠做到全生命周期的軟體工程管理，就是用需求把整個過程串起來，一直不能落實。2016 整個行里把互聯網金融作為戰略級決策，由副行長出面協調組織了一個跨部門跨職能的虛擬團隊來做這個事情，這個項目里終於做到了全生命周期管理。

我在這裡不想探討為什麼要做全生命周期管理，我只想說為什麼之前的 10 年都做不到，這次做到了。我參與了這個項目整個過程，我覺得最大的區別就是這個組織架構的調整。以前的人員都屬於各個部門，各自的 KPI 都是對部門的，沒有人會覺得全生命周期管理對自己有任何的好處，因為自己做的都是其中一段，做多了也沒有人會說你好。這次採用這種虛擬團隊的組織架構，讓這些人的思想一下子從做好自己這一段轉變成了做好這個項目。這個事情就成了，就是這麼簡單。

DevOps 從來都不能把它當成一個項目來說，雖然時機很重要（比如上面這個案例），但是 DevOps 的實踐可以隨時開始。沒有前期的鋪墊和探索，上面這家銀行業也不可能在這個項目中順利實施 DevOps 實踐。所以我們要做的是：持續改進，時刻準備著。

StuQ 工作坊：很多企業都有「想實施 DevOps 又不知道從何入手」的困境，您認為在實施 DevOps 過程中需要注意什麼問題？有哪些關鍵點設計？

徐磊：關鍵點是 3 句話：

自上而下的文化轉變

自下而上的實踐支撐

貫穿中間的工程落地

其實以上的案例已經印證了這 3 點，沒有企業領導者對 DevOps 價值的認知，下面的人再怎麼努力也沒有用，企業的方向性戰略還是靠幾個人的思路決定的，沒有他們腦子裡面的轉變，下面人做再多也是跑偏。這部分的改變需要敏捷和精益思想的導入。但無論領導們如何認知這個問題，軟體研發的效率問題都是客觀存在的，所以務實的各種實踐都還是要做的。

這部分的實踐要靠 Scrum，Kanban，持續集成，持續交付等等方法和實踐的支撐。而企業需要的只是一個時機，所有的努力都會被聚集在一個點上爆發。上下的思路碰撞會帶給企業量變到質變的機會。而貫穿這整個過程的是軟體工程系統和工具的落地，系統和工具中所承載的是企業的制度和流程，這些是保證企業在鐵打營盤流水兵的現實下確保持久發展的核心競爭力的基礎。

StuQ 工作坊：您是怎樣一步步成為 DevOps 大牛的？這個過程中有過什麼瓶頸么？又是怎麼克服的？

徐磊：一個事情做的夠久了，自然有些心得。我常和客戶說的一句話就是：我不比你們高明多少，但是我掉的坑肯定比你們多，從坑裡爬出來的次數多了，就知道哪些坑能爬得出來，哪些坑爬不出來。別把人往坑裡面帶，這就夠了。

瓶頸還是有的，放在 5 年前其實沒有什麼人關心軟體工程，DevOps 也遠遠沒有今天那麼火，很多人甚至都不覺得這是個正經行業，就連應聘來的人都要解釋半天我們是做什麼的。所以有一段時間這個事情其實做起來很苦逼，也一度想轉行做其他的。這應該算是瓶頸吧，估計很多做這個行業的人在中間都撤了，最後堅持下來的就算是大牛了吧。

StuQ 工作坊：您如何看待 DevOps 的發展現狀以及未來發展趨勢？

徐磊：DevOps 的現狀用方興未艾來形容是最形象不過的，2008 年這個詞出現到 2012 年被行業認可，到 2013 年 docker 出現再一次推波助瀾。現在的狀況是從管理方法論和工程方案上都已經很完整，但是企業中的實施成功案例還比較少，特別是傳統 IT 企業。

現況是，新興行業（互聯網企業）憑藉著輕裝上陣，無歷史包袱和相對簡單的業務模型，天生就具備 DevOps 的優勢，而且他們作出了很多非常漂亮的實踐，分享到社區；但是傳統企業 IT 的複雜度其實比新興行業要高的多，這些實踐確實具備借鑒意義，但是如何真正引入到傳統企業的 IT 併產生價值這就是最近幾年的主要趨勢了。

作為 IT 行業從業者，其實很容易被滿天飛的各種公眾號文章，博客，宣傳所誤導；好像互聯網的玩法才是好的。其實我們真的要認清形勢，互聯網在整個 IT 業裡面的體量恐怕連 10% 都不到，絕大多數軟體開發從業人員是在為各種企業的 IT 部門工作的，真正解決他們的痛點才是 DevOps 應該關注的問題。

StuQ 工作坊：可否推薦一些您用過的好用的 DevOps 工具？

徐磊：DevOps 的範疇很大，從工具角度來說可以分成這樣幾類，這些工具都是我在工作中常用的，所以不全，只是我比較了解的。

1、全生命周期管理平台：這類工具的重點是在企業研發中形成端到端的管理能力，建立整個研發流水線（這裡的流水線包括需求，開發，測試，交付整個過程，不僅僅是自動化流水線）。

微軟 Visual Studio Team Service / Team Foundation Server 平台：這是微軟支撐自己產品研發和為企業提供的研發管理平台，提供了包括需求管理，項目管理，配置管理，測試管理，自動化構建／發布和數據分析的完整研發管理平台，也是我最熟悉的平台。

https://www.visualstudio.com/zh-hans/team-services/

Atlassian 的系列產品，包括：Jira（需求，項目，過程管理）,BitBucket（代碼和配置管理）,Confluence（知識庫和文檔管理），Bamboo（自動化／持續集成和發布）。Atlassian 是一家專註於軟體工程管理平台多年的公司，產品線隨著這麼多年的發展也日趨完善和完整。我的客戶中有很多在使用這個平台。

https://www.atlassian.com/

2、自動化引擎：這類工具主要解決 DevOps 中的自動化過程的管理和執行。自動化工具一般都是提供一個引擎 + 各種插件。

Jenkins：這應該算是最常見也是最受歡迎的自動化引擎了，引擎簡單可靠，可擴展性好，具備大量好用的插件，社區支持完善。

https://jenkins.io/index.html

TeamCity：非常好用的企業級自動化平台，是老牌軟體工具廠商 JetBrians 旗下的自動化引擎。我曾經非常喜歡 TeamCity 對單元測試的支持，因為它是第一個做到將測試信息聚合顯示並做時間線跟蹤的工具。

https://www.jetbrains.com/teamcity/

3、代碼度量工具：這類工具一般被獨立使用或者集成在以上的自動化引擎中，為團隊提供持續的代碼質量度量信息，幫助團隊持續得到反饋。這類工具又可以可以分成靜態檢查工具和運行時檢查工具。

SonarQube：一體化的代碼度量平台，支持多種語言，大量可定製的度量數據採集器和規則。

https://www.sonarqube.org/

Coverity：特別擅長 C/C++/C# 等語言的靜態代碼檢查工具，當然對其他主流語言也有很好的支持，內置的代碼相似度檢查非常有用。主打安全性檢查。https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html

Parasoft dottest：主流語言支持都很棒，包括：C/C++/Java/.net。包括代碼覆蓋率和單元測試支持等運行時檢查工具。

https://www.parasoft.com/product/dottest/

.NET Compiler Platform (Roslyn)：內置於.net 編譯器中的動態代碼分析引擎，可以在編程的同時對代碼進行動態分析並給出建議。而且此工具也是開源的

https://github.com/dotnet/roslyn

FxCop/StyleCop：內置於 Visual Studio 中的靜態代碼檢查工具。

CheckStyle/FindBugs/PMD：專註於 Java 平台的代碼檢查工具，非常多團隊的默認選擇，和 Jenkins 集成的非常多。

4、自動化測試工具：這類工具可以按照層次分成單元測試，自動化功能測試和性能測試這樣 3 類。

單元測試框架：Junit, Nunit, Google Test，Xunit，Mocha，Jasmine 等。這類工具其實是編程框架，是開發人員用來快速創建單元測試代碼的基礎。

自動化功能測試：Selenium 和類似的 Appium 等工具。這類工具從 GUI 界面入手，模擬用戶的行為並通過驗證界面元素的狀態來完成測試。

性能測試：Jmeter，LoadRunner，VisualStudio Load Test 等。這類工具一般通過對後端服務的 api 模擬用戶行為，並配合一定 pattern 的壓力模擬來完成對應用性能的測試。

5、環境和應用編排工具：其實這是兩類解決不同層面問題的工具，一個是解決基礎設施編排的，一類是解決應用編排的，但是從 DevOps 的角度來說，它們都一樣，因為我真正需要的是應用，而不是基礎設施。

Docker：這個不用解釋了，DevOps 的興起其實很大程度上是被 Docker 的熱度帶起來的。最近 Docker 發布了 LinuxKit 工具，其實已定程度上進入基礎設施編排領域了，再加上 DockerSwarm 的成熟，其實已經是一個從集群管理，操作系統和應用的全面解決方案了。

Kubernetes(k8s)，ApacheMesos(dc/os) 和 Service Fabric：這幾個加上 Docker Swarm 就構成了最近幾年非常火熱的編排平台陣營。從雲平台的興起到應用編排平台的火熱，其實代表了 IT 界回歸應用本身的過程。這些平台給企業帶來了集群環境的統一化管理方案，對現代應用運維有非常巨大的推動作用，是每一個 IT 從業者都應該了解和熟悉的工具。

Chef/Puppet/PowerShell DSC：這些工具應該說和 Docker 解決了同樣的問題，但是採用了不同的思路。類似的工具在 2010 年左右開始出現，極大的推動了 DevOps 實踐中「環境獲取能力」的提升，可以說是 DevOps 領域中第一批非常有價值的工具。

6、虛擬化和雲平台：這類工具無需解釋了，雲平台是過去幾年火熱的話題。但是今天各大公有 / 私有雲都已經成熟的環境下，企業怎樣最大化雲平台的價值才是重點。

公有云：微軟 Azure, AWS，阿里雲，青雲等

私有云：微軟 System Center/Azure Stack，OpenStack，vmware，KVM 等

最後想說的是，這裡工具繁多，但沒有任何一個工具可以說自己是 DevOps 的工具，就算是全生命周期管理平台也無法涵蓋企業和團隊的所有 DevOps 訴求。所以 DevOps 的工具選型永遠是要搭建最適合自己的工具鏈，而這些工具的開放性就是最應該關心的問題。

StuQ 工作坊：我看到您是一位活躍的分享者，在 InfoQ 上發表過多篇備受歡迎的文章，6 月份也將和 StuQ 合作推出經典課程《DevOps 實戰》，您通過這門課程想解決學員面臨的哪些問題？這個課程的與眾不同之處在哪裡？

徐磊：很高興我的分享能夠被很多社區的朋友認可。這次和 StuQ 合作推出的《DevOps 實戰》是延續了之前已經運作多年的《LEANSOFT 領航員》課程，這個課程從 2008 年開始運作到現在已經積累了非常豐富和成熟的內容，而且我們一直堅持理論 + 案例 + 實踐的方式來進行授課。

如果說與眾不同之處就是我們會提供真實的環境給學員，學員需要直接動手操作，實際體驗 DevOps 實踐的落地效果。這種授課方式對我們的老師來說是非常大的挑戰，普通的培訓課程有 PPT 就行了，但是我們會提供全套在線的環境，代碼和操作手冊；老師不僅僅要會講，還要會操作，現場解決學員的問題甚至直接 debug 代碼，對授課的老師有極高的實戰要求。

所以，我們其實是把每期培訓都當成一個真實項目來對待的。可以說我們的課堂就是一個真實的研發中心，學員獲得的不僅僅有理論和實踐分享，還可以通過動手實驗建立起對 DevOps 的感性認識，加強後續實施 DevOps 的信心。

那麼，這場與眾不同的 DevOps 經典課程具體會講些什麼呢？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！