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

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

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

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

　　招銀云創(chuàng)的PaaS容器落地實踐

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

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

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

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

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

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

　　多云環(huán)境中的DevOps與運維管理實踐

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

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

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

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

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

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

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

　　持續(xù)集成的實踐與意義

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

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

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

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

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

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

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

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

　　1、 每天提交代碼

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

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

　　4、 編寫自動化測試

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

　　6、 提交之前執(zhí)行私有構建

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

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

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

　　自動化測試中的數(shù)據(jù)準備

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

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

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

　　數(shù)據(jù)準備只是自動化測試中的一個微小環(huán)節(jié)，在整個DevOps中更是占比很小，但對于eBay這樣的互聯(lián)網(wǎng)公司來說，自動化的測試數(shù)據(jù)生成顯然能夠為eBay全球化DevOps的實現(xiàn)提供前提和基礎。

　　且行且體會的DevOps之路

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

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