DevOps改變了過去整個交付模式的運作，但是它並不適合所有業務。
DevOps一詞來自於Development和Operations的組合，突出重視軟件開發人員和運維人員的溝通合作，通過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。DevOps概念最早興起於2009年的歐洲，是爲解決傳統軟件開發模式中運維工程師的痛點而生，但它其實包含了三個部分：開發、測試、運維。DevOps並不是一個單純的技術概念，雖然誕生至今已有十年，但現階段國內關於DevOps如何落地的討論依然很多。DevOps對於企業來說到底意味着什麼？企業的軟件系統向DevOps轉變的過程中需要考慮哪些因素？當前DevOps落地實踐還面臨哪些困難？
InfoQ 記者有幸在 ArchSummit 全球架構師峯會（深圳站）2019 現場採訪到了華爲雲DevCloud高級架構師，聽他分享軟件架構和開發模式的演進歷程、企業和團隊如何判斷自身是否應該實踐DevOps，並總結了華爲在實踐DevOps過程中沉澱下來的寶貴經驗。
以下是視頻採訪的全部內容，爲方便讀者查看，視頻下方也附上了文字內容。
InfoQ：您好，非常感謝您參加ArchSummit全球架構師峯會 2019（深圳站）的視頻採訪，首先請您做一下簡單的自我介紹，包括您的工作經歷。
何代義：大家好，我叫何代義，我是97年大學畢業，畢業後一直在華爲工作，做架構相關的工作應該有10幾年了。我們公司有SE崗位，也有架構師崗位，後面兩個有些混爲一體了，但是內容還是有些差別。我是03年左右開始做SE，也做過很多架構，同時做過一段時間的架構方法等。因爲華爲內部的軟件架構還有系統級的方案種類非常多，並不是只有一種架構，所以在這個過程中經歷了很多種不同需求，包括如何設計好架構以適應業務需要，一直是在做這個方面的工作，將近有快20年了。
InfoQ：您在華爲從事軟件及架構工作20多年，在軟件架構領域想必親身經歷了很多次架構模式、軟件開發模式的變革，能否請您梳理一下這20多年來，軟件架構領域比較重要的幾次變革？
何代義：我們九幾年剛從學校畢業的時候，軟件架構剛剛從C/S模式往瀏覽器服務端B/S模式演變，那時候Java才剛出來，CGI正好大行其道。當時應用開發以客戶端服務器模式爲主，在速度、客戶端的耦合性等方面都做得不好。剛開始轉向瀏覽器服務器模式時，主要講的是如何實現一個系統的軟件棧，比如分層，如何把服務器列表拆成不同的層次，再後來出現EJB（企業級JavaBean），再往後J2EE。這個時候包括CGI到Servlet到JSP一系列的發展，以及後面纔出來的Spring Boot等，其實它們都是從一個脈絡發展過來的。這個脈絡講的是如何做好一個軟件，這是軟件實現的架構。
第二個架構，指的是軟件如何組成的架構，這和前面是兩個不同的東西。一開始是單體架構，我們公司最擅長做這種東西，因爲我們的盒子類軟件，它要求極致的性能，資源又是有限的，無論是處理器的能力，還是內存的容量都是有限的，如何有效利用空間，又要將性能做到極致，那時候就是單體架構，通過指針、內存共享這些方式。從產出有效代碼生產率的角度來看，其實並不高，如果是一個很大的項目，存在幾百萬上千萬行代碼的時候，出一個版本一般開火車要開一年左右。後來就是從單體軟件到服務化到SOA化，再到後面拆成可DevOps服務化這樣的一路嚴謹。這一套方式就是講如何通過API協同的方式拆分，核心目的是減少團隊之間的溝通成本。因爲過去要走正步的時候，你可以直接使用別人的數據，但是別人數據一動，大家都要動，需要做非常多的協調工作。而SOA化也好，後面的服務化也好，微服務也好，其實就是要拆，拆成單元，圍繞自己的數據把邏輯做完整，接口開放好，其他人只是面向接口使用。這樣一來減少了很多會議，也提高了運作的效率，而且交付的速度也快了。因爲拆的小，後面容易快速驗證。然後交付模式也從過去的瀑布模式到敏捷，到持續集成持續交付，再到DevOps，而這裏面都是需要軟件的架構做適應性的變化和支撐的。
這些過程其實我在華爲都經歷過。我們一開始是做單體軟件，追求極致的性能，把成本做到最低。性能好、成本低，這是過去盒子類軟件的必殺利器，功能可能同質化速度比較快，因此要想辦法在相同成本下把性能做到更優。後來開始面向IT類軟件，內部要做很大的系統，就必須分而治之，先拆，拆了再協同起來，再做服務化、微服務化這一系列東西。
InfoQ：您剛剛提到DevOps是現在比較流行的軟件開發模式，它是因爲什麼需求而誕生的？
何代義：我一直強調，這些軟件變化的本質都是爲了提升效率。過去單體軟件開一個版本火車，要開至少九個月，甚至十二個月。因爲那個時候還是瀑布模式，需要層層驗證，協作團隊多而且相互有依賴，每個團隊都有自己的版本節奏，最後出來東西就會比較慢。後來我們對單體架構做了優化，通過組件來協同、拆分、集成，這是我們爲了適應雲化場景做出的改變。DevOps除了能夠快速反饋，還因爲我們在面向雲化場景交付的時候，DevOps很關鍵的一點是責任團隊都是自己，從需求到開發到交互到運維，都是靠一個團隊來解決問題。過去我們可能敝帚自珍，下游組織詬病上游組織輸出的東西，因而帶來很多爭論。但是引入DevOps之後我們只考核結果，比如是不是有客戶投訴，業務量是不是上去了，是不是出現業務的中斷，而在DevOps組織中，這些結果是由整個團隊共同負責的。
DevOps改變了過去整個交付模式的運作，但是它還是不適合我們設備類的業務線。因爲設備類業務還是會有下游廠商，必須要有合同，必須要有客戶組織，我們不能總是去動客戶的東西。原先我們有一些合同裏會寫明，一年只允許升級一次或者一個季度只允許改動一次，改動代碼的時候都有很嚴謹的一套流程，如果中間不小心出了故障，都是要罰款的。就算我們現在說用DevOps不怕出問題，只要快速解決問題就行，對客戶來說那也是不可以的，原來的要求都還在。
所以DevOps在我們公司內部也只是一部分組織在實踐，比如華爲雲、手機的雲端服務，還有內部組織能力相關服務採用的是DevOps。華爲的軟開雲會給外部客戶提供軟件開發的雲服務，同時我們內部研發的作業也是在這個雲上運行，它採用的就是DevOps的開發方式，能夠快速獲得反饋，快速形成特性，快速解決問題。
InfoQ：您剛剛提到，華爲內部也不是所有的場景業務都適合實踐DevOps，那麼什麼樣的公司或團隊適合採用DevOps？可以從哪些維度來判斷？
何代義：首先，一個單體軟件是做不了DevOps的，因爲敏捷不起來。DevOps的前提是要做到敏捷，就是到了後面運維段、運營段，需要能夠基於結果或數據反饋快速反應，再反過來優化前面的工作，而做單體軟件的企業是做不到這一點的。比如一些領軍級的ERP軟件公司和CRM公司，其實它們現在都還做不了DevOps。因爲他們過去有很重的歷史包袱，軟件架構還沒有拆開，但要做到DevOps，就需要解耦，從而做到可持續交付。像某CRM公司已經是SaaS化服務領域比較領先的企業，但它現在的版本節奏還是很長，很難實現真正的DevOps。
不一定是因爲商業模式，而是必須要有技術架構支撐，包括組織能力也要準備到一定程度之後才能做DevOps。但是，一些初創企業，比如想做一些互聯網業務的探索，它的初衷是要驗證自己的商業思想的正確性，這種驗證就要敏捷，而且是商業敏捷。
爲什麼我總說，DevOps不是業界提的只包括運維，而是還要包括運營。我在公司內部強推的是，將來就是看所支撐的客戶，在規劃組件特性的時候，不同組件到底存在的價值有多大，是砍掉還是收縮還是擴張，主要是基於經營數據，不只是看運行情況是否健康。一些小的初創公司通過云爲用戶提供服務，這種模式就比較適合一開始就用DevOps。當然，如果有追求的企業，尤其是以軟件的形式提供服務的企業，也要把自己過去的單體架構拆成可以DevOps的架構，然後再做轉型。企業轉型到可以DevOps是一個漫長的過程。因爲過去厚重的歷史包袱拆起來有一定難度，像很多領軍級的B2B軟件公司目前都還在轉向DevOps的漸進發展過程中，做了好多年都還沒做到位。
InfoQ：傳統的軟件開發模式向DevOps轉變的過程中，可能會面臨哪些困難和挑戰？有沒有什麼好的應對方法？
何代義：首先是思想上的轉變，然後架構方面需要將原來比較重的服務全部拆開，包括開發、交付、運維、運營，這是一項很大的工作。爲了適應拆開的架構，組織可能也需要做調整。華爲內部有這麼一個說法：架構決定組織。在我的邏輯裏面，架構清晰就不存在太多的重疊和交叉，“治衆如治寡，分數是也”，先把它拆成很小的塊之後分別完成各自的職責，再協同起來實現一個大的任務，拆分過後就需要組織調整。這是第一個變化。第二，流程要做調整。第三，需要有工具和環境來支撐。
架構其實有一點很關鍵，就是要抽象，要平臺化，要聚類，讓業務專注業務。我們過去有中間件，到了雲上其實就是Paas服務或IaaS服務，總之需要有公共的服務，術業有專攻。組織也要做相應的變化，要水平化、垂直化，按照架構拆分和協同好。除了要有工具環境的支持，流程也要支撐，公司的考評體系也要改變。
InfoQ：華爲雲實踐DevOps經歷了哪幾個階段？
何代義：一開始也是鬆土，然後需要建立適應DevOps的組織模式。爲了適應不同的業務模式，華爲內部有很多種不同的組織。最早十年前的時候，公司內部組織可能都是一樣的，做終端軟件也好、做盒子類軟件也好、IT類軟件也好，都是一樣的。華爲公司是IPT流程，IPT流程適合做盒子類軟件，它會涉及很多組織協同一起做一個很大的項目，但是到了雲上服務，肯定會變得不一樣，終端軟件也不一樣。不同的時候，企業有不同的問題，組織要適應問題來做改變。我剛到公司的時候參加培訓，當時會說弱矩陣、強矩陣，這是當時的一種陣形，後來到了敏捷，會有陣形的改變，主要是有不同的角色結合到一起。到了DevOps之後，我們的組織要有更多的改變。現在公司內部對編碼、架構、軟件工程各工段的能力要求都有一些新的追求。我們過去是把盒子的質量和性能做到最優，那我就是最優的。現在我們還說，我們是優雅的最優，就是說我們的軟件代碼是非常精煉和優雅的，甚至可以給人家欣賞。這對組織內部端到端的過程就提出了更多要求，我們又新增了很多角色或者組織來把這個工作做好，這些都是適應需要而做的調整。
InfoQ：華爲DevOps團隊中內部包括哪些角色？不同角色之間是怎麼分工的？
何代義：以我們這邊的團隊爲例，簡單地說就是CTO Office下面加上具體的業務單元。CTO Office的職責是建設公共能力，比如說運維工作涉及的監控、撥測、部署等需要的能力，還有中間件等。CTO Office需要幫他們做一些公共的事情，包括抽象軟件框架再提供給大家用。大家只需要做自己業務屬性範疇內的工作。CTO Office相當於是一個公共組織，爲大家服務，反過來也會驅動大家往前走。然後就是各個業務團隊。在我們公司內部有“全功能團隊”這樣一個說法，指的是在一個組織裏面，從設計到開發到驗證再到運維，都要由自己的團隊來負責。CTO Office團隊的運維只是從整體角度出發，具體業務本身的運維還是由各個業務團隊自己的運維來做。工程師交付出來的DevOps單元，要由自己來負責。DevOps單元是全功能的，其中包含多種角色，有SA、針對過程的QA、針對結果的測試等一系列能力，這些都是由各個業務團隊自己負責的。我們公司內部很強調賽馬，大家會在方方面面做比拼。一個團隊在組織中存在的價值，靠的就是做出來的業務結果。
InfoQ：DevOps組織或團隊中不同的角色，比如架構師、QA、運營、運維這些角色，不同的角色之間協作應該是什麼樣的？
何代義：首先每個角色要有自己應該承擔的職責。但是在華爲內部有一種文化，就是圓圈。如果都是以圓爲邊界的話，那相鄰的圓中間肯定有縫。這時候圓就要畫大一些，你要侵入到別的領域去，你也可以接觸別人的東西。大家在公司、團隊內部是要聞過則喜的，不能像刺蝟一樣，那在組織中間生存不下去了。像我現在的角色是架構師，我就會去到端到端的任何地方，看到問題就會伸手過去，努力幫大家一起想辦法。比如如何拆服務、如何設計模型、如何做運維的監控、如何快速發現問題，這其中某個技術或方法如果我有相應的經驗，或者是見到過優秀的實踐，都會跟大家分享。只要是爲了結果好，大家的胸懷還是比較寬廣的，至少在一個組織裏面是這樣。當然方式方法還是需要注意。
InfoQ：所以在華爲內部的DevOps組織中，架構師會主動推着這個模式往下走？
何代義：我們內部對架構師的要求很高，當一個項目失敗的時候，架構師一般是要擔責任的，整個組織的失敗，架構師也要擔責。無論這個架構師過去有多高的成就都沒有用，我們要對結果負責，結果沒做好就要擔責，包括帶業務團隊的CTO、業務領導也要擔責。
InfoQ：您認爲有所謂的“DevOps工程師”這樣一個職位嗎？它是一個被濫用的詞語嗎？
何代義：我認爲是。DevOps是一種思想，就是商業角度要敏捷，所以它其實是貫穿始終的。從開發的角度，要想到後面的運維，在開發中間，就要想到哪些指標是要拿來做監控的，要爲後面的工作做優化。不能像過去那樣只關注架構，在開發的時候，既要考慮編譯部署，可能也要關注測試和部署，而不是什麼都交給SRE團隊，現在整個端到端的流程都要做。這也有好處。過去因爲我們的架構師團隊很強悍，即使是上千人協同的非常大的系統都能很好地分解和協同，這其中架構設計的工作量非常大。但是架構師以外的工程師，可能就只懂自己負責的一小塊工作。轉向DevOps之後，工程師就變成全功能了，技能也會提升很多，包括端到端思考的能力等。這對於員工是一個機會，也是好事情，各有優劣。
InfoQ：所以如果企業或組織實踐DevOps思想，就意味着內部不管是什麼崗位的工程師都應該嘗試涉及更多的工作內容？
何代義：這樣一來個人成長會更快。如果工程師只聚焦於自己的編碼能力的話，眼界就可能很窄，寫出來的代碼不一定會好。知識只聚焦於一點的時候，你做東西就不會想到，這可能會影響到別的點。同理，其實在職場裏面，本來就是要不斷學習新的能力。
InfoQ：那麼華爲並沒有所謂DevOps這個崗位？
何代義：沒有這個崗位。
InfoQ：有觀點認爲“DevOps將成爲主流，它的流行程度將在 2019 年達到頂峯”，您是否贊同這個觀點？爲什麼？
何代義：這要從不同視角看。在華爲內部，盒子類的東西永遠不可能用DevOps，包括我們的終端類軟件，因爲這些軟件至少包含上億行代碼，一旦出現問題影響面非常大。我的觀點是，如果是Software Provider，也就是軟件提供商，就可以做持續集成，持續交付可能也可以做，但是DevOps是不行的；但如果是Software as a Service，就可以做DevOps，還是要看自己的商業模式。
我們公司內部做過一個實踐，通過籤合同的模式來做商業敏捷，這需要跟客戶達成一致，如果新特性增加就要新增一個簽單，才能夠回款，包括客戶的數據如何跟我們這邊的數據打通、快速返回進行聯合開發和聯合創新。我們跟部分客戶做了這樣的實踐，也有價值，但這種客戶就屬於戰略性客戶，他們願意做這樣的嘗試並提供相應的預算，不是所有的客戶都願意這麼做，這是On premise模式。
而On demand模式是適合DevOps的，如果是On demand模式，軟件依然採用傳統的開發模式，而不是DevOps模式，那麼交付速度就會很慢。現在一些頂級CRM和數據庫公司都在轉向DevOps，他們的產品是以服務的形式提供給客戶，所以可以採用DevOps進行快速迭代。但是如果是賣給客戶的服務就不一樣了，你必須要對質量負責，而且客戶買單到底該怎麼掏錢，他掏的是這部分特性的錢，還是掏的使用時間的錢是不一樣的。如果客戶買的是原先的特性，而沒有爲新特性掏錢，那公司自然不可能白白提供新的特性。但是像辦公軟件套件轉成雲服務之後，採用DevOps就是合理的，因爲快速迭代新特性才能吸引更多用戶持續使用，才能掙到錢。像一些頂級手機公司，大家都認爲是創新能力很強的企業，但它的軟件開發過程其實並沒有採用DevOps。說到底還是得看公司的業務模式。
後記：
華爲雲對於DevOps的理解和深度實踐體現在多個方面。近期華爲開發者大會HDC上重點分享的華爲應用市場AppGallery Connect服務，就是華爲終端聯手華爲雲DevCloud構建的全新移動應用工程管理（DevOps）平臺，它帶來了敏捷的項目管理、端雲協同、微服務架構、持續部署、現網監控等服務，可以幫助開發者更快速、高質量地實現移動應用一站式開發。同時，AppGallery Connect還與華爲雲攜手，爲移動開發者推出CloudNative服務和端雲協同的Serverless服務，讓移動開發者在敏捷、簡便的雲原生道路上可以專注應用快速上線和業務創新，也能充分發揮華爲 “端管雲”的生態合力。
從某種意義上來說，華爲雲的一系列DevOps創新與實踐，特別是此次AppGallery Connect與華爲終端的聯手，對於後端人才相對匱乏的許多準一線互聯網地區，如四川等地的移動互聯網創業公司來說，是一個不錯的利好。畢竟，愈加簡便的開發、部署、運維環境，可以更加充分地釋放四川等地區創業者在文化、創意等領域的人才優勢。
也許，中國移動互聯網未來的競爭版圖，會因爲雲計算廠商的創新而逐漸顯露出新的格局，讓我們拭目以待。
採訪嘉賓介紹：
何代義，華爲雲DevCloud高級架構師，在華爲從事軟件及架構工作20多年。在系統設計、架構設計方法等領域有系統的理解和實踐經驗。從初始起步構建支持雲化（含服務化/微服務化）、構建DevOps的軟件系統；以及將舊有軟件系統遷移到支持雲化（含服務化/微服務化）、構建DevOps的軟件系統等方面，積累了較爲豐富的經驗和知識。