實施DevOps的核心目標是加速團隊、企業的IT精益運行，從根本上提升IT的生產效率，加速部門、企業的業務創新能力。

是的，DevOps的優勢很明顯。那為什么它這么好，但這些年下來實際落地的企業卻這么少。除了作者提到的容器、微服務等相關的『環境因素』外，還有哪些內在因素？普元在這方面又有哪些經驗和案例？InfoQ就這些問題對普元的主任架構師顧偉進行了采訪（文末有嘉賓二維碼，掃碼加入微信群）。

受訪嘉賓簡介

顧偉，畢業于東南大學，現任普元公司主任架構師；先后參與和帶領了華為BME、中信銀行CBJUP、工商銀行CTP、中航信RI、阿里云ACE、普元云計算平臺、普元The Platform等大型項目的交付；長期致力于IT技術研究、產品設計、架構咨詢等工作，擅長Web、OSGI、CI/CD、服務治理、云計算等領域技術；對DevOps、自動化運維、微服務架構有著濃厚的興趣。

InfoQ：請介紹下您的技術背景和目前負責的項目？能否回顧總結并階段性地介紹下您的技術成長經歷？

顧偉：大家好，我是顧偉，專注于DevOps和云計算領域，擅長CI/CD、前端、OSGI、容器等技術，對各類自動化、智能化有著濃厚的興趣。目前負責普元The Platform云平臺產品的設計工作，兼顧DevOps、CaaS、IaaS等外部實施工作。

到目前，我的職業生涯中經歷的領域和技術棧比較雜，大體分為以下四個階段：

06年-07年：以項目實施為主，參與了華為BME項目的多期建設，熟練掌握了包括Java、Web、數據庫等基本技能。

07年-10年：主要參與了兩款產品研發，一款是基于Ext的所見即所得的UI產品，一款是基于Eclipse插件開發的IDE平臺，熟練掌握了主流UI框架和Eclipse的大部分源碼。回過頭來看，學習優秀框架設計的經歷，為今后的架構之路奠定了較好的基礎。

10年-12年：以大型企業級平臺實施為主，參與了工商銀行、中信銀行的統一平臺項目，也主導過中航信RI等創新項目。在加固已有知識的同時，這段經歷使我掌握了諸多企業級中間件（比如IBM MQ、ILOG、BMC CMDB等）的使用和擴展，同時也開始接觸了如云計算、大數據領域的新技術。

13年-16年：從與阿里云ACE合作云產品開始，先后歷經了普元IaaS（OpenStack），CaaS（Kubernetes + Docker），DevOps領域等產品設計及研發工作。這段時間，擁抱開源并實踐于企業級產品中，算是正式走進了企業云計算領域。

InfoQ：您曾經提到過您很關注DevOps和自動化運維。能否簡要介紹下您對這兩者的理解和未來趨勢的看法？DevOps給運維部分帶來了哪些變化？

顧偉：在我的理解里，DevOps其實是包含了自動化運維的。只是現在這兩種概念都很常見，所以我分開提及的。

大家肯定都能感覺到，DevOps、微服務、容器等概念已經越來越熱了。這讓我想到了3年前OpenStack的狀態，各大社區、創業公司、傳統企業，紛紛投入到OpenStack懷抱；而現在，雖然是有一些公司存活下來了，但總的來看誰也沒賺到多少錢，也沒有哪家公司如預想般把VMware給替代了。過熱的后果是反而把市場秩序給弄得一團糟，產品低價競爭，人員漫天要價。

我覺得現在的DevOps也到了這個岔路口，有很多公司在熱炒DevOps的概念，并紛紛宣布轉型成功；而從實際市場、尤其企業市場的反饋來看，客戶對此的評價幾乎眾口一詞：“DevOps很好，但我們很難做到”。

究其原因，最缺乏的是DevOps方案提供公司真正到深入到企業里面，沉下心來，結合實際情況進行實施實踐，從而幫助客戶切實地做到橫向協作打通、縱向工具鏈打通。所以我覺得，市場到今年底前還是會充斥著很多概念炒作；但從明年開始，大家會逐步看到，這個領域中真正的脫穎而出的，將會是那些已經將DevOps實際落地的企業和服務商。

DevOps給運維帶來的變化，主要體現在運維工具的打通，但是單單從這個角度看影響并不很明顯。如果能夠從企業、部門、團隊多維角度結合來看，才能發現DevOps獨特的地方。

DevOps本質上是一個持續優化的過程，一般需要從組織、技術、流程三個維度考慮，目標是加速IT的精益運營。 DevOps推崇的是讓開發、測試、運維友好協作，倡導大家都能為各自的上下游提供便利，形成演進回環，有效的支撐業務創新。

InfoQ：你提到，DevOps很好，但也很難落地。你認為難點在哪里？如果說要突破這些挑戰，你認為團隊負責人應該重點從哪些方面入手？

顧偉：我覺得DevOps最大的難點并不是所謂的文化或組織（因為這個不是說改變或打破就能改變或打破的），而是各家公司的流程和工具都是有差異的，每家都會有自己的特色與特殊部分，很難有所謂的通用產品能解決所有問題。

舉個代碼庫工具使用方式的例子，之前在我們微信群里還單獨拿出來討論的，有的企業是主干開發、分支release；有的企業是分支開發、分支release，接著再往下細，都是分支開發并release的企業，同一個產品版本，有的是開發環境、測試環境、生產環境對應的分支物理上是不同的，也有開發測試環境相同、生產環境不同的，還有從開發到最終上線就一個分支的。而且每家做法都有很充分的理由……

想突破這種問題，對于一個團隊負責人來說，要能在一定的條件下，有效組織團隊、逐步優化流程。這里說的“一定的條件”涉及很多方面，比如不要試圖按理想情況去打通部門，這是永遠不可能的，再比如想讓團隊每個人都有一樣的高度、理解力、責任感也是很難實現的。所以對于一個團隊負責人來說，想實施好DevOps，需要理清現狀，統一概念模型，制定階段性目標，激發團隊熱情，有效規避風險；而不是一上來就是要用什么技術，要有多好的理念之類。

InfoQ：你如何看不可變基礎設施？

顧偉：看到這個問題，首先想吐吐槽：初次聽到不可變的基礎設施時，我當時不知道為什么，還想起了另外一個概念：基礎設施即代碼，雖然這兩者沒有特別的強關聯，但第一感覺就是，現在市場上很喜歡拿基礎設施來說事。

我以前做過IaaS、PaaS，也參與過運維工作，基礎設施在我的理解里是一個底層、重、固化的東西。隨著一切皆服務、一切皆代碼、無狀態這些概念起來，讓我覺得市場上的任何詞，都可以變成“怎么說都有理”的理念。

回歸正題，我認為要像不可變的基礎設施的目標前行，有兩點比較重要：

從使用者的角度來看，基礎設施最好是無差異無感知的，所謂的無差異或無感知是說無論下面是什么樣的異構硬件、不同系統等，對上層業務的服務提供方式都是統一的；

從提供者的角度來看，基礎設施從建立之初就不要再變更，只有新建與替換，粒度很重要，這也是很多人甚至會提到消除SSH的想法的原因。

對于不可變基礎設施的未來，我認為是個長期的目標。隨著容器、DevOps能力的逐步落地，給了這個目標一個可實現路徑，但真的要做到完全不變，我覺得是很難的，因為生態還沒有起來，很多層的能力或接口還沒有統一和規范，差異化永遠是不可變的最大攔路虎。

InfoQ：這兩天又有人提出了OpsDev的概念，你怎么看？

顧偉：這個我之前也看到了，看到第一句解釋后我就沒再看下去，因為從來沒有人說過DevOps到底是Dev2Ops還是Ops2Dev，為什么？因為無論是Dev還是Ops，都應該將對方視為可標準的對象，同時為對方提供足夠可規范的便捷（主動的嘗試著去適應對方），這本來就不是一個單向的過程。

所以我認為無論是叫DevOps，還是叫OpsDev，大家的目標都是一樣的，切勿認為詞語上的誰先誰后，就意味著誰主動誰被動。在不失規范與流程的前提下，打通上下游、雙向協作才是DevOps的真諦。

InfoQ：您即將在CNUTCon全球容器技術大會上和我們分享《基于微服務架構的容器云之實踐》，可否先大概介紹下你們的容器云？

顧偉：其實普元的主要目標是落地DevOps，在技術實現上，只是底層默認使用了CaaS作為支撐（當然平臺也兼容IaaS）。平臺在原有的基礎能力之上，實現了容器+微服務的部分，并不斷版本迭代演變至今。第一個版本花費約半年多時間。這次，為了契合容器大會主題，我選擇了底層CaaS部分的實踐進行分享。

目前我們的容器云既可以運行于私有云（OpenStack、VMware），也可以支持在公有云（阿里云）上運行。平臺以微服務架構為支撐，使用了Kubernetes + Docker的組合，以CoreOS、Flannel、SkyDNS等作為支撐選件，集成了包括MySQL、Redis、GIT、Nexus、Jenkins、Docker Registry等基礎服務，形成了一款用于支撐企業DevOps的容器云平臺。平臺最終架構圖（含DevOps能力）如下：

InfoQ：這套容器+微服務實現的DevOps方案，您認為哪類行業的企業可以借鑒參考？傳統企業可以在哪種情況下，開展怎樣的嘗試？又該如何拆分傳統應用？

顧偉：這套方案相對來說，比較適合有一定規模的企業或互聯網公司。因為如果團隊較小、業務較簡單（比如只有極少數量的App），那首要的問題還不在精益化上，通過人來做管理配置，也不會特別復雜。

對于傳統企業來說，我的建議是嘗試需要首先從這兩方面開始：

持續發布能力：這是打通開發測試與運維的最佳著手點，也是業界目前方案成熟度較好的模塊。

自服務能力：自助和自動，是打通上下游、提升運營效率的有效手段，自服務能力強調的正是這一點。

至于提及微服務化是如何進行單塊應用拆分，我覺得是這之后的事情：沒有配套的運營支撐平臺，何談微服務架構。

InfoQ：您提到過目前的這個方案在13年的時候普元就有提出過。當年是在什么樣的情況下想到的呢？為什么當時沒有落地這樣的想法？

顧偉：翻翻歷史，這個點子是13年的時候，我們董事長劉亞東先生提出的，當時他指出：“數字化未來會將企業每個人、每臺機器都變成一個節點，企業信息平臺需要具備打通供應鏈、資金鏈、物流鏈、銷售鏈、服務鏈等能力，這就需要企業在未來競爭中找到自己的位置，就必須用數字化企業云平臺”。

至于為什么當時沒有落實下來？我個人覺得，畢竟當時董事長提出的無論數字化、還是連接一切等概念還比較前沿，我們團隊的積累和認知不是很夠等種種原因吧，沒有在當時真正執行起來。現在回過頭來看，算是在給當時的愿景圓夢吧！

InfoQ：為什么微服務的架構要采用容器做默認承載？如果不采用容器技術，您認為微服務化會面臨怎樣的難題？除了微服務化架構的實現，普元還有在其他情況下使用過容器技術嗎?

顧偉：首先我的觀點是，微服務架構和容器沒有任何關系，大家也可去翻一翻Martin Flower的文章。那為什么現在大家看到的文章中，提到微服務就會提容器，或者提DevOps，本質上是因為以下兩點：

其實很多公司的現狀是僅僅實現了容器管理，但是又想接下來向微服務化靠攏，于是就出現了強關聯的概念。

事實上，現在也確實存在很多企業把兩者結合在一起使用。無意中讓大家誤會了兩者的關系。

但是這只是說明了兩者相伴相生的現象，并不意味著強因果關系。

容器的優勢在于：輕量化、原子化、可移植性、快速集成等，而這與微服務所倡導的松耦合、高內聚有著異曲同工之處。 在實際使用中，往往容器+微服務確實可發揮 1+1>2 的功效。

容器可以作為默認承載，但要支撐企業級系統，不能只有默認承載。因為容器的相關技術完備性現在還不足以完全支撐業務，像容器的存儲方案、有狀態服務方案這些生態技術還并不太成熟。

如果不采用容器技術，傳統VM技術、或者說IaaS，甚至純物理機架構，照樣可以支撐微服務架構，只是在管理上稍微復雜些。在普元，我們是通過統一的環境管理（內部系統叫SEM），來屏蔽底層基礎設施差異的，大家可參考我們異構環境下的統一概念模型：

目前容器技術的使用主要在這款數字化云平臺里，其他地方用的較少，只在一些客戶試點項目中有過嘗試。

InfoQ：相比較歷史系統的DevOps，基于容器技術的DevOps具有哪些特點和優勢，適用于哪些情況？您是否認同“容器改變DevOps”這種觀點？

顧偉：DevOps有時會讓人覺得很遙遠，也有很多企業會覺得先做到自動化運維就足夠了，大家對于這個概念其實褒貶不一。技術方案上，也是層出不窮，近期看到一些微信群、公開課、沙龍在討論DevOps實現：有用容器的；有基于Puppet、SaltStack延伸的；還有一些生于Cloud Foundry、OpenShift這些傳統PaaS之上。換而言之，DevOps其實并不局限于任何具體技術，只是容器技術在實現DevOps時有一定的優勢：

靈活：DevOps的一項重要工作是“編排”工具鏈，要求能夠對“原子活動”進行快速串接，而容器本身對于原子化及編排能力就有很好的支撐。

集約：DevOps的一大價值是資源集約管理，容器相對于傳統VM，在資源利用上就有很大優勢，其資源長短生命周期皆宜的特征，對于像開發測試云這樣的需求尤其合適。

標準：以鏡像為粒度的管理模式，相比于零散腳本、多變介質、各種小工具等規范度不高的傳統開發運維，給了實施者一定的標準。伴隨著配置、服務狀態等生態技術的補充，容器實施DevOps的方案會變得更完善。

您提到的“容器改變DevOps”說法，我認為偏絕對；我更傾向于“容器讓DevOps更容易”。

InfoQ：對于容器的運維，您認為有哪些需要特別注意的問題呢？能否詳細談談的雙模架構（模態1：傳統技術，模態2：容器技術）的自動化運維？

顧偉： 我認為對于容器本身的運維，其實和傳統的運維沒有太大差別。要說容器運維有什么特別注意點，我覺的下面大家可關注以下3點：

選擇一個合適的框架，不要什么都自己研發：目前業界很好的框架并不多，K8S、Mesos、Docker本身的一些，選擇您覺得和你們理念最一致的，作為你的基礎框架。

避免慣性思維：很多做過傳統運維的同學，在遇到容器時，第一想法還是用既有知識和習慣管理，所以大家會發現，現在很多企業把容器當VM用，或者宿主系統一定要XXX，這個往往束縛了容器運維的優勢。

要向上抽象：畢竟容器還不能完全替換企業既有，那資源、中間件、應用的運維和容器的運維是不是可以統一，這就要求在運維角度抽象一層模型，便于后續的一體化運營平臺的建設。

對于雙模架構的自動化運維，核心問題就在于能否抽象出一套兼容的模型，屏蔽各種異構差異化，可從以下四個方面考慮：

環境：主機、存儲、網絡、容器的差異化。

配置：應用配置與環境配置，動態配置與靜態配置。

倉庫：三方倉庫、部署包倉庫、鏡像倉庫等。

流程：編譯流程、部署流程、故障流程等。

InfoQ：您說這個點子成功在于：”市場上的客戶反饋和內部的能力驅動”。能否將這兩個方面進行詳細的展開論述？

顧偉：不僅僅是這個點子，我認為任何點子的成功都離不開這兩方面：

客戶反饋：反饋的核心價值在于驅動產品向正確的方向演進，比如小米，從設計之初就籠絡了一群發燒友，請他們來提建議，幫助做設計。換個時髦的詞叫MVP，意思和快速推出試錯試對，這與管理學中的PDCA質量環有著想通的理念。我們要做大設計小版本，進而通過Inside-out & Out-inside的有效配合，基于反饋快速迭代，才能推出符合市場需求的產品。

能力驅動：這個也可以講成康威定律，我更傾向于稱之為康威定律+，團隊一定程度上決定了業務架構，擁有一個全棧的團隊，對于一些創新類點子有著非常重要的作用。在一個點子形成之初，原型、場景、計劃、設計、迭代模式、技術預研等，環環相扣，任何決定都對后期的發展有著的重要影響，所以我一直認為：有什么樣的基因，做什么類型的事情。有什么能力的團隊，做什么規模的事情。

InfoQ：最后一個問題：技術變革日新月異的今天，對于立志在技術領域中長久發展的年輕人，您有什么建議和忠告？

顧偉：忠告不敢當，結合我帶新人的經驗談談一些想法吧。

首先，技術是學不完的，以前是，現在更是。對于剛開始工作的同學，在精不在廣。任何有一定規模的技術框架，都有很多值得深入學習的地方，別人為何這么設計，相比同類產品有什么優勢。多思考，多總結。不要一味的只管調試代碼，fix bug……

學技術之外，也要學做人。技術再牛，如果無法融入團隊，那還是沒用。此外，新同學必須要有自主性。現在很多新同學有個通病，遇到問題就問導師。不是說不能問，關鍵在于問之前你有沒有真正的花精力嘗試過，或者試著問題縮小到一定范圍，不能說一遇到個坎就找人幫忙，會讓團隊的人覺得事情交給你很不放心。

最后就是執行力很重要。很多同學都會定目標定計劃，但卻很少有人制定對應的check計劃，好像這都是部門經理的事情。說白了就是缺乏自我管理能力。現在的人確實受打擾太多，但這不是執行不力的借口。建議大家制定計劃時，要短期不要長期，要實踐而不是停留在概念。