徐磊，英捷創(chuàng)軟 LEANSOFT 創(chuàng)始人兼首席架構(gòu)師，專注于軟件工程、DevOps 方面解決方案咨詢。有超過 10 年的軟件研發(fā)項目管理經(jīng)驗，曾任 SSW 中國研發(fā)中心總經(jīng)理。是資深 ALM 顧問和解決方案專家，微軟最有價值專家和大中華區(qū)域社區(qū)技術總監(jiān)，認證 ScrumMaster 和敏捷教練。

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

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

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

這么多年，其實軟件工程行業(yè)的關注點經(jīng)歷了一個從微觀到宏觀，再回歸微觀的過程。比如一開始的 SDLC 就是一個關注軟件開發(fā)過程本身的方法論，后來發(fā)現(xiàn)這不夠，只關注開發(fā)本身解決不了問題，就開始向更大的范圍延展，也就是出現(xiàn)了 ALM。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

徐磊：關鍵點是 3 句話：

• 自上而下的文化轉(zhuǎn)變

• 自下而上的實踐支撐

• 貫穿中間的工程落地

其實以上的案例已經(jīng)印證了這 3 點，沒有企業(yè)領導者對 DevOps 價值的認知，下面的人再怎么努力也沒有用，企業(yè)的方向性戰(zhàn)略還是靠幾個人的思路決定的，沒有他們腦子里面的轉(zhuǎn)變，下面人做再多也是跑偏。這部分的改變需要敏捷和精益思想的導入。但無論領導們?nèi)绾握J知這個問題，軟件研發(fā)的效率問題都是客觀存在的，所以務實的各種實踐都還是要做的。

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

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

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

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

StuQ 工作坊：您如何看待 DevOps 的發(fā)展現(xiàn)狀以及未來發(fā)展趨勢？

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

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

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

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

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

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

• 微軟 Visual Studio Team Service / Team Foundation Server 平臺：這是微軟支撐自己產(chǎn)品研發(fā)和為企業(yè)提供的研發(fā)管理平臺，提供了包括需求管理，項目管理，配置管理，測試管理，自動化構(gòu)建／發(fā)布和數(shù)據(jù)分析的完整研發(fā)管理平臺，也是我最熟悉的平臺。

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

• Atlassian 的系列產(chǎn)品，包括：Jira（需求，項目，過程管理）,BitBucket（代碼和配置管理）,Confluence（知識庫和文檔管理），Bamboo（自動化／持續(xù)集成和發(fā)布）。Atlassian 是一家專注于軟件工程管理平臺多年的公司，產(chǎn)品線隨著這么多年的發(fā)展也日趨完善和完整。我的客戶中有很多在使用這個平臺。

  https://www./

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

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

  https:///index.html

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

  https://www./teamcity/

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

• SonarQube：一體化的代碼度量平臺，支持多種語言，大量可定制的度量數(shù)據(jù)采集器和規(guī)則。

  https://www./

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

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

  https://www./product/dottest/

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

  https://github.com/dotnet/roslyn

• FxCop/StyleCop：內(nèi)置于 Visual Studio 中的靜態(tài)代碼檢查工具。

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

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

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

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

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

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

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

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

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

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

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

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

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

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