實施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計劃，好像這都是部門經理的事情。說白了就是缺乏自我管理能力。現在的人確實受打擾太多，但這不是執行不力的藉口。建議大家制定計劃時，要短期不要長期，要實踐而不是停留在概念。
實施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計劃，好像這都是部門經理的事情。說白了就是缺乏自我管理能力。現在的人確實受打擾太多，但這不是執行不力的藉口。建議大家制定計劃時，要短期不要長期，要實踐而不是停留在概念。