2018年5月18日，由51CTO主辦的全球軟件與運維技術峰會在北京召開。來自全球企業的技術精英匯聚北京，暢談軟件技術前沿，共同探索運維技術的新邊界。而在本次大會上，除了眾星云集的主論壇環節，12場分論壇更是各具特色，分別聚焦了時下最受關注的容器、AI、區塊鏈、大數據、物聯網、DevOps等技術應用領域;是與會者尋找技術靈感，吸取先行者經驗的***場所。

　　在這個數字化轉型時代，企業一方面要想方設法提升生產和管理能力，另一方面則要發展自身的IT能力。只有這樣，企業才能更充分的借助IT之力發展業務，利用IT的思維來推動業務轉型。而對于企業來說，相關軟件應用的開發和運維就是這種IT能力最重要的表現。

　　實際的企業環境中，由于新技術的不斷出現、新業務模式的層出不窮，應用的開發與運維往往需要在一個相當長的時間內持續迭代和交付使用。顯然，這種業務模式對企業的IT團隊和能力來說都是一個巨大的挑戰。而在這些挑戰背后，更有多云環境、容器技術、人工智能等技術發展的推波助瀾。任何企業想要打好開發運維這場馬拉松式的戰役都不會輕松。

　　針對目前企業所關心的DevOps問題，本次WOT峰會特別設置了“DevOps轉型之路”分論壇給予專題討論。在本次分論壇中，51CTO邀請到了eBay中國研發中心技術主管茹炳晟、ThoughtWorks高級質量咨詢師秦五一、IBM混合云技術經理潘雪梅、招銀云創金融PaaS研究中心總監陳沙克等一眾業界大咖齊聚一堂，以不同的視角和維度解讀DevOps這一理念的發展、演變、應用與未來。

　　招銀云創的PaaS容器落地實踐

　　效率和成本是企業在進行很多工作時首先考慮的兩大問題，這也是很多企業在上云時所要考慮的重點。雖然云計算本身所代表的理念能夠很大程度上提升企業IT的效率和成本，但在云架構已經就緒的前提下，企業在效率和成本的道路上仍然有很長的路要走，有很多新的技術和應用需要部署。

　　在傳統的PaaS平臺中，虛擬機本身需要占用大量計算、存儲、內存等系統資源;而要解決這一問題，容器技術的使用不可或缺。招銀云創在容器平臺的架構上選擇了目前非常流行的OpenShift平臺。OpenShift是目前最為成熟穩定的容器平臺之一，而且提供了一系列CI/CD工具來幫助企業實現真正的DevOps。

　　招銀云創金融PaaS研究中心總監陳沙克表示：首先從效率層面來看，容器能夠非常高效的利用基礎架構的各類資源。以招銀云創在金融行業的經驗來看，部署一個開發環境在過去可能需要上百臺虛擬機資源;而在使用容器技術之后，僅需要十幾臺虛擬機就能完成整個開發環境的搭建。這種成本優勢還是非常大的，而在OpenShift平臺的實際運維中， 面對Kubernetes一年四次的頻繁更新，OpenShift不僅更新速度上可以***的跟隨，而且其提供的完善服務也能夠幫助企業更好的部署和使用新版本。

　　而有了基礎的容器平臺之后，招銀云創要做的便是構建整套DevOps開發工具鏈。首先，招銀云創使用了目前效果比較好的Redmine來實現統一的協作管理。這套協作體系包括了需求、計劃、開發、測試、部署、運維等模塊。

　　在開發過程中，Gitlab分布式代碼庫可以有效管理開發中的各類代碼;而SonarQube則可以方便而自動化的對代碼進行規范化檢測并掃描潛在的漏洞。***，招銀云創使用Jenkins來進行應用構建并利用Testlink來管理測試流程。當然，所有這些工具都有相關的插件，以便管理者使用Redmine來對整個開發測試流程進行管理。這便是招銀云創在實現DevOps過程中使用到的整套架構。

　　對于這樣一套現代化的容器平臺及其上運行的整套DevOps流程和工具，陳沙克引用了一段招商銀行行長田慧宇的話來進行總結：無論經濟下行的周期性因素，還是利率、匯率改革的市場化因素，抑或是去杠桿、強監管的政策性因素，都不足以改變銀行的商業模式。唯一可能從根本上改變和顛覆銀行商業模式的，是科技。

　　多云環境中的DevOps與運維管理實踐

　　云和容器的實踐是很多企業正在做或已經做到的事情。而對于云計算的未來，多云環境是不可避免的。而在多云環境下，DevOps的工具鏈構建和部署顯然會比單一的云環境要更復雜一些，且會面臨更多安全風險。而面對這類問題，作為全球領先的科技創新企業，IBM顯然有更豐富的經驗可以借鑒。

　　對此，IBM混合云技術經理潘雪梅表示：在由公有云、私有云、IBM云服務共同構成的多云環境中，IBM在DevOps最重要的工具鏈方面所給出的建議是Slack、Trello、Github、Jenkins、JMeter、Terraform、UrbanCode Deploy;分別對應了DevOps過程中的協作、代碼管理、應用構建、測試、容器部署等過程。

　　而作為容器環境的核心，IBM的整套DevOps解決方案將以IBM Cloud Private容器云平臺為核心。而這一云平臺將提供多云環境下的容器管理、編排功能。這一平臺兼容Kubernetes、Cloud Foundry、VMware、AWS等多種平臺，能夠為用戶留下更多自由選擇的空間。

　　而且，借助IBM的一體化解決方案，整個DevOps可以在圖形化的界面上實現自動化交付。這一功能的核心在于IBM Cloud Automation Manager管理工具。這套管理工具可以為目前流行的多種DevOps工具提供接口，并在統一的圖形界面下實現完整的管理功能。

　　***，在最關鍵的部署環節，IBM也有專門的Urban Code Deploy工具。這一工具可以實現應用及微服務在多種云平臺上的自動化、流程化部署，并對容錯和部署質量進行管理和監控。

　　當然，針對DevOps過程中的其他環節，IBM也有眾多相關的工具鏈和經驗可以提供。例如故障管理工具鏈、多層次事件關聯分析、服務管理與運維參考架構、運維轉型中的組織變化參考以及運維中的創新工作流程和方法等。

　　借助IBM提供的完整DevOps解決方案，企業可以更高的效率和更低的風險實現DevOps。

　　持續集成的實踐與意義

　　作為DevOps的核心環節之一，持續集成對于企業開發來說意義非凡。他能讓企業的開發部門在持續產出高質量應用的前提下保持整體的高效率運作。而做到這一點，除了合適的工具之外，更需要先進的管理和流程予以配合。否則所謂持續集成和DevOps只能是徒有虛表的花架子而已。

　　關于這一點，ThoughtWorks高級質量咨詢師秦五一有著豐富的閱歷和經驗。在本次DevOps專場中，他也用一個來自某航空公司的例子深刻闡釋了流程與管理在整個CI甚至DevOps中的價值和意義。

　　在通常的實踐中，英文的“CI”代表一系列工具集，而中文的“持續集成”則代表了這些工具集背后企業開發所要達到的境界。

　　秦五一在談到某航空公司的CI案例時表示：這家航空公司在四年前使用了ThoughtWorks的CI工具集和解決方案。目前，該公司擁有50人的開發團隊，分為7個全棧小組，在QA質量管理方面擁有一個9人的團隊。而其整體的開發架構則采用的是ASP .Net。

　　在整個DevOps流程上，該公司擁有完整的解決方案。代碼構建用的是Git，單元測試用的是Nunit和.Net Foundation。CI/CD平臺方面則是用了ThoughtWorks開發的GoCD持續集成平臺。***，該公司也擁有完整的SmokeTest、QA Deploy、E2E Test、Performance Test等測試環節以及后端的Sonar代碼檢測分析工具。

　　在這樣規模的團隊以及各類自動化工具的協助下，該公司的開發部門每天代碼提交超過30次，單元測試覆蓋率超過96%，基于Selenium Test的端到端自動化測試項目超過200條。一切指標性數據都非常***。

　　但就是這樣的團隊，其代碼在CI監視器上的CI狀態卻始終是紅色的警報狀態，應用交付也非常緩慢。究其原因，代碼提交和測試流程的不規范是罪魁禍首。開發人員提交的代碼過不了測試、開發人員配置錯誤、測試與開發不同步、開發人員各自為政等各類現象同時在團隊中出現。***的表象之下則是整個團隊的低效運行。

　　對此，秦五一在入住該團隊之后提出了一系列改進建議：

　　1、 每天提交代碼

　　2、 不要提交無法構建的代碼

　　3、 立即修復無法集成的構建

　　4、 編寫自動化測試

　　5、 所有提交的代碼必須通過所有的測試和審查

　　6、 提交之前執行私有構建

　　7、 不要遷出無法構建的代碼

　　在這些原則的指導以及一系列基于這些原則的具體流程修訂之后，該公司每個可用的業務應用版本所花費的平均工時從之前的180工時直接降低為55個工時，整體效率在不增加成本的情況下提升了三倍，效果可謂立竿見影。

　　由此可見，CI過程中所用到的各類軟件僅僅是工具，而在工具已經齊備的條件下，改進工作流程，強化合作及規章制度才是團隊做到DevOps的核心因素。

　　自動化測試中的數據準備

　　測試是保證代碼、構建乃至應用可用、有效的必須環節，是保證應用達到可用狀態的必要步驟。因此，保證有效的測試就成了DevOps實際有效的重點環節。

　　但對于多數互聯網公司來說，業務龐雜、用戶數量龐大、業務流程長等特點會讓應用發布之前的測試變得非常復雜。這其中，數據的準備是重中之重。對此，eBay中國研發中心測試基礎架構技術主管茹炳晟表示：以eBay的經來看，在所有CI失敗的情況中，有30%的情況并不是代碼或構建本身的問題，真正的問題出在測試數據的準備和使用上。由于業務、數據結構及其他變動經常會導致測試所需的數據是時時變動的;而一旦測試數據的準備沒有針對變動做出相應變化就會導致整個CI測試的失敗。因此測試數據的準備就變得極其重要。而對于eBay這種跨國電商平臺來說，不同的用戶、不同的語言、不同的貨品、不同的法律法規、不同的物流、不同的支付手段等等一系列不同將導致測試數據的準備本身就變成了一個極端復雜的過程。

　　在初期階段，eBay使用基于Java的數據工具來有針對性的生成測試數據。雖然這種方法能夠讓不同的測試人員定制化的產生自己測試所需的數據，但這卻是一種操作起來相當繁瑣的笨辦法。因此，后來eBay的測試數據生成進入了2.0時代：基于函數的測試數據生成。這時，數據可以根據不同類型和需求進行批量的模式化快速生成;這大大簡化了測試人員的操作壓力和時間成本，但這仍然不夠自動化。最終，eBay的測試數據生成進入了3.0階段：測試數據生成變為了一個微服務，測試流程只需調用這一服務即可;整個過程變得高效和自動化;而這一微服務亦由專門的開發人員進行更新和維護。

　　數據準備只是自動化測試中的一個微小環節，在整個DevOps中更是占比很小，但對于eBay這樣的互聯網公司來說，自動化的測試數據生成顯然能夠為eBay全球化DevOps的實現提供前提和基礎。

　　且行且體會的DevOps之路

　　不得不說，對于任何企業來說DevOps都是一個巨大的***。它關系到企業的業務和應用，關系到企業對IT的投資建設，更關系到企業IT團隊的管理和開發思路。我們甚至可以將DevOps比喻為企業IT開發團隊的精神內核。無論怎樣形容DevOps的重要性都毫不為過。

　　在DevOps這個龐大的概念下，企業不僅要在架構和工具上進行相應的革新，更需要對人員和思維進行再造，才能實現高效的持續集成、持續交付。而對于不同類型的企業和業務，要達成這一目標所需的路徑和技術各不相同。可以說每個企業都有一條屬于自己、屬于這項業務、屬于這個團隊的DevOps之路，而所有的DevOps方法和經驗都只能借鑒和參考，真正的DevOps則需要自己去實踐和體會。而WOT峰會所提供的正是這樣一個能讓每一個在DevOps路徑中上下求索的人相互交流、相互提攜的平臺。