摘要：問題覆寫了規劃設計、開發內建、測試、部署釋出、運維監控等DevOps落地實踐中的關鍵疑點與難點。
“DevOps的價值是又快又好地傳遞軟體”
——《鳳凰項目》的作者Gene Kim和《持續傳遞》的作者JezHumble
目前數字化轉型的形勢下，軟體行業面臨着巨大的市場機遇，而軟體系統複雜度不斷增加，跨地域高效協作、多環境部署等問題也逐漸突出，DevOps能幫助企業提升軟體研發效率，通過自動化“軟體傳遞”和“架構變更”的流程，來使得建構、測試、釋出軟體能夠更加快捷、頻繁和可靠。
基于此，邀請到姚冬、蔔漢東兩位專家老師，為我們解答涵蓋規劃設計、開發內建、測試、部署釋出、運維監控等DevOps落地實踐中的關鍵疑點與難點的60個問題，希望通過這些問題與解析，幫助更多DevOps實踐者解決DevOps落地過程中的疑惑與痛點。（點選可下載下傳大綱模式的pdf文檔友善浏覽）
【一、華為端到端DevOps概覽】
Q1：華為端到端的DevOps工具鍊是如何承載靈活和DevOps相關理念和方法的？
A：靈活和DevOps的理念其實是相通的，DevOps可以視作靈活的延伸，靈活思想打破了需求與開發之間的壁壘，DevOps則通過将開發與運維間的壁壘打破，打通軟體傳遞全流程。
華為雲DevOps工具鍊DevCloud包含了從需求管理到代碼托管、建構部署、測試等一系列步驟，覆寫軟體開發全生命周期。理念往往需要結合實踐，我們可以通過DevCloud進行需求管理、每日站會等等許多靈活實踐，通過送出代碼可以觸發執行流水線，讓開發人員專注開發。
Q2：華為雲DevCloud與傳統基于開源元件拼接的工具鍊，有什麼差異優勢？
A：傳統的由開源元件拼接而成的工具鍊，大部分都是使用Jira來進行需求管理、用Git來做代碼托管、用Jenkins做DevOps開發，因為其元件大部分都是開源的，是以一般費用較低或者免費，其缺點是使用者需要掌握很多工具，而且這些工具并不是在同一個平台上。華為雲DevCloud是一站式的軟體開發平台，可以做到所有工具都在一個平台上，端到端打通覆寫整個軟體開發全生命周期。
用Jenkins的人都知道，在使用之前首先需要搭建一套Jenkins的環境，還需要定制化地做一些腳本、配置等，華為雲DevCloud相當于是一個已經封裝好了的DevOps開發工具，可以極大減少這些操作。
在華為雲DevCloud裡，将編譯建構、部署任務等做成了原子化的操作，如果我們想要做Tomcat部署，可以直接使用這些模闆，隻需要對裡面的步驟進行細微的調整即可。而且它還使用了可視化視圖，操作起來一目了然，學習成本也比較低。華為雲DevCloud還支援代碼檢查、自定義shell、Python、腳本、自定義report展示。
Q3：DevOps /靈活和SDLC 有何不同？
A：DevOps/靈活和SDLC的角度不一樣。SDLC是指系統生命周期，它提出的幾種典型生命周期模型包括瀑布模型、快速原型模型、疊代模型。靈活打破了需求和開發之間的溝通壁壘，DevOps則打通了整個軟體傳遞的全流程。
Q4：DevOps人員在與項目的結合中是否會承擔更多開發、測試、運維的工作？
A：DevOps不會讓人去承擔更多開發、測試、運維的工作。DevOps裡有一個理念：讓開發的人專注于開發、測試的人專注于測試、運維的人專注于運維，所有的工具層面的東西全部交給工具，隻要把一切可自動化的東西自動化，所有的人忙自己手頭的工作就好了。
Q5：DevOps的反模式有哪些？
A：參考《9種DevOps團隊結構适用類型與7種反型》
Q6：DevOps适合哪些行業的業務模式？對于非軟體行業是否需要調整模式?
A：DevOps也好，靈活也好，其初衷和理念适用于所有行業，但是每個行業在執行和實際落地效果上會有一些折扣，比如持續傳遞的生産環境、自動化部署、品質管控、自動化流轉等過程的實作等。
簡單而言，網際網路的一些應用，或者說SaaS應用，相對來說更适合DevOps的研發模式。原因是：其業務對軟體更新、釋出的要求較高；沒有太大的曆史包袱；相對更容易對标目标閱聽人群體，包括生産環境等。
傳統類的業務比較重，比如銀行的核心系統，實踐起來相對較難，也不是說不能用靈活或DevOps。比如持續內建、每天多次建構、多次送出代碼、自動化測試、可視化等，都可以實行。
對于非軟體行業，如硬體、嵌入式、機械類，實踐起來也比較難，比如測試自動化等，需要做一些工具或平台的适配，引進插件或工具後，流程也能夠跑起來，隻是會慢一些。
綜上，我認為靈活和DevOps本身是一條沒有終點的路，所有行業都可以到這條路上來，隻是走得難易與遠近的問題。
Q7：在企業落地DevOps有沒有什麼套路？
A：企業實際情況各不相同，落地DevOps沒有統一的套路，但會有一些建議的方式。DevOps偏工程側，通常建議先把版本管理建立起來，比如Git代碼倉、代碼分支管理等；接下來需要把流水線建構起來，在上面逐漸進行自動化測試、分層測試等。
Q8：最能有效促進Scrum團隊本身的持續改進的是什麼實踐？
A：每個團隊遇到的問題都是不一樣的，如果一定要找一個通用的答案，首先要保證團隊每日站會、評審會議等如質如期進行，以此來保持持續改進。
【二、持續規劃與設計】
Q9：基于DevOps實作持續有效規劃應該先從哪個層面去入手呢？
A：首先需要了解DevOps和靈活的含義，我們一般說的規劃與設計更偏向于靈活項目管理中涵蓋的需求和計劃。
狹義的DevOps主要是CI/CD，即持續內建和持續部署，是偏工程側的。廣義的DevOps，即本訓練營中講的DevOps是“端到端的DevOps”，從持續內建/持續部署，向前延伸到業務側，向後延伸到運維/營運側，是以也涵蓋了前段的需求和設計層面。
回到問題，基于DevOps實作持續有效規劃，應該從需求和計劃切入，包括整個的市場分析、目标客戶群體的使用者畫像，使用者的痛點是什麼，針對這些痛點提供什麼樣的功能，然後到産品應該怎麼設計，接下來才真正落到研發這個主體上。
從方法論角度來看，需求和設計層面的方法論包括設計思維、精益創業等。做好需求分析後，就要進行需求拆分，排列優先級，這樣就進到靈活項目計劃裡，方法論包括看闆、Scrum等，大規模團隊靈活架構有SAFe等。
Q10：Scrum，看闆和 XP 是靈活開發的具體方式，老師能否具體講解一下差別？
A：參考文章《DevOps VS 靈活：傻傻分不清楚》。
Scrum和看闆更側重在團隊級靈活項目管理層面，XP更偏向于工程實踐層面。
Scrum和看闆兩者比較：“标準的”Scrum包括3355的架構；看闆源自豐田的精益生産，其背後是精益的思想，通過可視化、限制在制品的數量，快速暴露問題和瓶頸點，集中對最嚴重的瓶頸點進行修複，然後去尋找下一個瓶頸點。
DevOps的很多理念同樣借鑒了精益的思想，個人認為，看闆可以應用到很多領域。另外，Scrum和看闆在實施或應用時并沒有沖突，可以結合起來使用。
Q11：企業組織架構中什麼角色或者部分适合推行DevOps落地？
A：企業組織架構中一般都沒有專門的組織來推行和落地DevOps。DevOps包括兩個部分“Dev”和“Ops”，就是指開發部門和運維部門。
幾種常見的情況：
- 如果是由開發部門來發起DevOps落地，就是由開發往運維去推進。我們平時看到比較多的是測試團隊或傳統的品質管理部門來發起，從開發到測試再往前一步到運維生産環境上去，因為這些部門本身就承擔着代碼托管、編譯建構、自動化測試等職能。
- 而有的公司會把内部的基礎設施、IT支撐、測試等放在資料中心，往前去推把自己變成類似我們講的DevOps工程師，然後通過自動化工具幫助開發團隊進行自動化部署等，這就是從運維側往前推進DevOps落地。
- 還有一種情況，就是近年來比較火的雲原生，架構師更多考慮采用微服務架構，通過基礎設施即代碼等方式自動化部署到Docker環境中去，是以引入自動化流水線、Infrastructure as Code（基礎設施即代碼）、接口測試等實踐，這些都屬于DevOps的範疇。
- 還有一些其他的角色，比如靈活教練、内部的技術教練等，他們本身就是在做研發管理的落地實踐，很自然地轉化去做DevOps推進。
綜上，DevOps的推進和落地不一定非要有一個DevOps工程師或獨立的DevOps團隊，初期引入DevOps的時候需要有一個團隊或角色去承擔起這個職責，進行概念和實踐的導入和探索，這時更容易把DevOps工程師、DevOps團隊建立起來。而後期應該把這些工程師或能力分散到各個團隊中去，讓DevOps在企業内有更廣泛的傳播和實踐。
Q12：請問在Scrum中，如果沒有項目經理，是由TeamLeader還是ScrumMaster協調資源？
A：應該由TeamLeader來協調資源，ScrumMaster不是管理角色，而更多的是一個輔助的牧羊犬的角色，在Scrum實施過程中守護團隊Scrum流程不受幹擾。
Q13：對于非産品形态的項目，Product Owner來自哪個部門更合适？（業務部門/研發部門）
A：Product Owner代表客戶，一般是哪個部門更接近業務，更了解業務和系統，就由這個部門的人來擔任。非産品形态項目的Product Owner，要求既了解業務又懂技術，一般可以由業務分析師、PMO等角色擔任。
Q14：實際開發中，客戶往往無人承擔PO的角色，而是上司來承擔，如何破解這個問題？
A：這種情況可稱為“BDD”，Boss-Driven Development，老闆驅動開發。好處是至少有一個人能拍闆；壞處是拍闆的人，你可能很難去辯駁或談判，是以最好還是能夠把客戶側的人拉進來。當然，如果老闆确實對業務非常了解，也非常專業，并且是一個可溝通的人，也是可以的。PO的核心要求是需要有一個人代表客戶或業務側，針對需求或範圍做決定，且當團隊有問題的時候，可以随時找到這個人。
Q15：影響地圖主要應用于哪個環節？
A：從HE2E DevOps實施架構圖可以看到，在端到端的DevOps實踐中，影響地圖通常用于需求規劃或業務規劃階段，與傳統的Scrum流程相比，更偏業務側。影響地圖通過四層結構：why、who、how、what來拆解業務和需求，也可以用于營運或項目冷啟動環節。
Q16：請問如果一個大的Story拆分成多個小的Story，甚至再次拆分成孫子輩的Story，如何更好地表示這些關聯關系？
A：Story拆分有兩種方式：一種是從epic（史詩故事）到feature到story的拆分，epic以月為機關，feature以周為機關，story以天為機關；另一種是平級拆分，所有拆分的故事全部叫story，隻不過它們之間存在父子關系。不管是三層還是四層，我們隻關注父子關系，從一個父story拆分出子story，如果粒度不夠小，則以子story為父story繼續拆分出它的子story。如果系統需要有層級追溯，可以用樹狀或腦圖等結構來展現。
Q17：學完課程感覺使用者故事和項目管理裡的工作包很像，二者有個共同的問題，拆解到什麼粒度是好的使用者故事？
A：故事也好，需求也好，隻是一個名字，使用者故事之是以叫使用者故事，有兩點表征：1）它是站在使用者的角度去看；2）它講了一個故事、一個場景。好的使用者故事遵循INVEST原則，即一個合适的使用者故事應該是獨立的（Independent）、有價值的（Valuable）、可讨論的（Negotiable）、小的（Small）、可估算的（Estimable）和可測試驗證的（Testable）。
Q18：如果采用靈活開發，最終的使用者需求如何呈現給使用者？如果是需要存檔的使用者需求說明書、設計說明書或操作手冊之類的文檔，适合從DevCloud導出後再修改麼？另外如果出現變更，如何確定文檔與代碼一緻？
A：如果是需求文檔，可以以使用者故事的形式存放，華為雲DevCloud或者其他工具都提供多元的存儲格式，如文本、圖檔、附件等，華為雲DevCloud有一個幫助網站，每一個新上線的功能都會在這裡進行同步和更新。
也可以把詞條或需求存放到wiki裡，并跟前端的需求條目之間建立連結。wiki本身是可以有層級關系的，可以把需求從wiki裡導出來形成文檔形式，如果做得好，還會有版本計劃，比如版本裡包括10條需求，可以統一導出一篇需求規格說明文檔。
需求和代碼之間的同步，可以通過流程等方式去控制，比如發版的檢查點，這可能需要以人工方式去做，但也可以通過一些工具來輔助。比如送出代碼的時候需要送出注釋，可以把這個注釋關聯到一個工作項上，一個需求可能會修改多個檔案裡的多段代碼，這其實就是一個完整的變更集的概念，這個變更是為了同一個目的，是有相關性的，如果要從代碼裡去剝離的話，應該會把這一次變更集統一進行剝離。在未來檢視代碼時，可以進行代碼版本比較，看兩個版本之間進行了哪些增加/修改、這些變更是為什麼目的、其意圖是什麼。
Q19：對于變化的需求或者新增的需求，是應該放到目前疊代裡，還是規劃到後面的疊代裡，持續規劃是指規劃過程貫穿整個生命周期麼？
A：變化或新增的需求都會統一放到一個大的池子裡，我們稱之為product backlog（産品待辦事項清單），這是一個一維的表格，所有需求按照優先級排列。我們要通過判斷新進需求的優先級，看它應該放在什麼位置。靈活強調需求是動态變化的，我們會定期對需求清單進行梳理，看是否需要進行優先級排序的調整，
是以變化或新增的需求不會放到目前的疊代裡，因為目前疊代是一個固定的時間視窗，且範圍相對固定，團隊對此進行了承諾。我們會将其放入大的需求池，是在下個疊代還是之後的疊代實作，取決于該需求的優先級。
Q20：對于初學者剛剛接觸一個項目，但是項目的需求不明确、結構不成熟，怎麼從靈活入手？
A：這裡包括兩種情況：初學者、項目在初級階段。如果是初學者，應該通過擷取現有資産快速熟悉和上手；如果項目處于初級階段，需求也不太明确，可以通過靈活的快速傳遞、精益的MVP等實踐，快速擷取回報，對後續工作進行指導和建議。
Q21：作為整個項目的入口，需求的品質如何把控和評測？
A：明确定義需求可以轉開發的标準，即DoR。那什麼是DoR呢？靈活開發發展了幾個年頭之後，人們發現進入疊代開發應當滿足一定條件，否則過于模糊的需求會導緻疊代的失敗，在疊代内花費過多的時間去做需求澄清，是以給進入疊代設立門檻，就是Definition of Ready，簡略稱之為“DoR”， 最初的Ready是指準備好可以進入疊代開發。
Q22：持續規劃與設計有什麼度量資料或名額用于衡量團隊績效或用于持續改進？如何衡量持續規劃與設計的成熟度？
A：度量工具推薦Scum的燃盡圖、看闆的累積流圖。研發效能的核心度量資料名額包括團隊速率、Lead time，即需求的平均傳遞時長。
Q23：靈活下的組織過程資産（配置、文檔等）這些有好的存儲方案麼？
A：理論上文檔、資産等都存儲在資産庫裡，常用的知識庫或資産平台有Conflunce、IBM的Rational Asset Manager等。資産和知識是不同的概念，現在做資産管理的相對少一些，知識庫可以用wiki等平台，便于統一維護更新和協同。
Q24：DevOps 持續規劃與設計在DevOps生命周期中是處于開始的時刻，為什麼還說代碼內建是整個DevOps生命周期的核心呢?
A：“代碼內建”包括兩部分：代碼和內建。
整個軟體生命周期包括三個版本：需求版本，即發版計劃；代碼版本；上線釋出的二進制包的版本。其中代碼版本處于承前啟後的中間位置，且是唯一真正有價值的。需求和文檔是沒有價值的，隻有由代碼編譯成二進制包并部署上線才是有價值的。在代碼層面多花一些精力是非常有必要的，所有的研發其實都是在一個代碼倉庫裡進行協同開發，包括代碼版本管理、分支管理等模式，是以将代碼視為DevOps生命周期的核心也是必然的。
軟體研發最痛苦的地方往往是在內建層面，一開始大家各寫各的代碼，一旦要将這些不同的代碼進行內建的時候，問題就出現了。持續內建的概念來源于XP，“如果代碼內建是一件非常痛苦的事情，那我們就每天多次地進行。”一切殺不死你的都會讓你更強大，持續地進行內建，你會想辦法去減少內建的痛苦。就像跑步一樣，假如以前的內建是一塊大石頭，每天多次內建就相當于将這塊石頭變成一顆顆的小石子，大石頭打在身上會非常疼，小石子就好多了。這也是我們為什麼要把內建往前提，并且持續去進行的原因，是以在DevOps生命周期中持續內建也非常重要。
【三、持續開發與內建】
Q25：如何加強開發人員對于版本品質的信心？
A：加強對版本品質的信心，不隻是針對開發人員，對所有人都應該如此。整個DevOps的過程其實就是在保障整體的版本品質，包括靜态代碼檢測、接口API測試等。
另一方面，版本對需求的映射關系或完成程度，應該從業務場景往下去切，看整個需求的比對程度。
第三點應該是我們通常說的非功能性需求（Non-functional requirements），比如負載、性能、安全、并發支援等，這些要根據我們服務承諾的品質來做相關措施。
Q26：靈活開發相比傳統開發有什麼優點？
A：我認為最大的優點或特點是靈活開發更真實，或者說它更願意承認研發的本質或現狀。
傳統的研發認為品質受三個因素制約：範圍、資源、時間，且預設範圍和資源投入是相對确定的，時間是變化的。然而，在真實場景或變化的市場下，時間和資源是固定的，沒辦法讨價還價，因為市場、業務、客戶都不會等你，在這樣的前提下，軟體的需求或範圍實際上是可以商量或讨論的，我們要以可變的範圍去赢得市場、時間視窗。
靈活開發要求我們不斷傳遞高優先級的需求，并擷取回報，不斷調整。這是靈活開發的最大的核心，承認市場是變化莫測的，需求範圍是可變的。
Q27：一個産品，既有主線版本，又有很多的行業定制分支（50+），适合什麼樣的分支政策？
A：這種場景在傳統的産品裡比較常見，個人認為應該考慮的是産品政策而不是分支政策。如果分支非常多，會導緻産品碎片化嚴重。
我們在持續內建、持續傳遞的時候，推崇主幹開發或短的分支，不希望這些分支長期存在，否則在産品進行合并時會非常痛苦，工作量也會随着分支的多少和分支存在的時間呈幾何倍數增長，是以不建議用長期存在的分支。
那可以用什麼樣的方式來解決呢？首先要看整個版本上是否一定要出現這麼多定制化的分支，這些分支有沒有可能通過配置檔案、功能開放等方式處理或實作。舉個例子，我們做項目管理的軟體，每個客戶要求的字段、功能流轉的流程都不太一樣，如果都通過代碼實作，有多少客戶就會出現多少個分支，可能都不止50個。
我們是怎麼做的呢？針對字段，我可以配置一個界面，裡面包括常見屬性的字段，這個字段可以是文本類型或下拉框等形式；功能流轉的話，新進來一個需求，它的下一個狀态是什麼、應該觸發什麼動作、應該是什麼樣的角色來觸發這個動作等這些都是可以進行配置的，這些配置資訊存在資料庫裡，變成使用者的配置資料，這樣我的主代碼主程式是保持不變的，隻需要提供一套模型根據資料去驅動适配或實作。這是我們更推崇的方式，可以用來消滅那些分支。
Q28：日常項目開發，在代碼分支管理上經常疑惑用什麼分支管理政策，比如是選擇基于生産分支工作流，還是基于環境等等，在實際實踐中，我們應該重點考慮哪些因素？既可以兼顧管理效率，又可以確定代碼品質。
A：個人建議采用分支開發主幹釋出或分支開發分支釋出的分支管理政策。基于環境進行分支建構的話，以前我們會有開發庫測試庫等倉庫管理的概念，但現在全部是持續內建、自動化部署，就沒必要再基于環境去拉取分支了。
如何保證代碼品質，我們在CI/CD流水線、自動化部署和建構的同時需要考慮每一個環境上跑哪些測試，這些測試大部分通過自動化的方式實作，也有少量的是手工進行。
Q29：像華為雲這樣團隊成員能力超強、應用場景以線上服務為主，一般會采用什麼樣的分支管理模式？
A：華為雲團隊也是采用特性分支的管理模式，同時會做多級流水線觸發不同環境的流水線來做相關建構，除了開發環境的流水線以外，還有測試、類生産環境等流水線。
Q30: 要做到主幹上的送出始終處于可釋出狀态，不受隐含的代碼沖突、送出的feature隻部分完成等因素影響，對開發團隊和基礎設施有哪些要求？
A：首先主幹上送出的流程或品質要嚴格控制，真正達到DoD（Definition of Done）的标準，這裡可能需要一些機制人為地進行管控，比如Committer機制等。送出的時候，除了非功能性的要求，比如跑相關的回歸測試、代碼檢視以外，還有很重要的功能性要求，比如對需求的實作程度的檢查。另外“基礎設施即代碼”，還要看持續內建、持續部署、自動化測試能不能快速有效地跑起來，并保持高度一緻。
Q31：持續內建的成功因素是什麼？
A：持續內建主要包括代碼倉庫、自動建構、自動部署、自動測試四個方面。要求每人每天都要向主幹送出代碼，觸發自動建構和自動部署，在類生産環境進行自動化測試，同時需要團隊每個成員確定清楚正在發生的狀況，以此來保證持續內建的成功。
Q32：華為雲上的CI/CD與K8s上搭的CI/CD有什麼差別？
A：華為雲DevCloud打通了端到端的軟體傳遞全流程，內建了常用的DevOps開發工具，不僅可以完成CI/CD，還可以直接在上面進行項目管理和開發；而K8s隻是軟體開發中一個單獨的工具，沒有項目需求管理等功能，需要配合其他工具一起使用才能實作完整的軟體開發與傳遞。
Q33：開發和修複bug的工時如何進行安排呢？之前疊代出來的bug是按照單獨工時安排，還是統一安排在開發中？
A：主要看發版的标準和要求是什麼，通常來說可以帶病發版，但如果是非常嚴重的缺陷，就不能上線，必須先修複這些bug。一般bug會跟需求放在同一個池子裡，根據它的優先級和影響程度來進行排序，決定是先修複bug還是先做需求。如果修改bug是為了掃清技術債務，建議在一個疊代裡固定一定比例的時間來進行。
Q34：感覺SaltStack和Ansible中哪個是最好的配置管理（CM）工具？為什麼？
A：兩者定位不一樣。個人認為Ansible并不是一個标準的配置管理工具，它更多是通過自動化部署的手段去touch環境這一側，SaltStack相對來說功能性更強一些。
Q35：在代碼互評審和評審流程中如何高效的提升代碼品質？
A：人機結合，将重複性的，比如檢查代碼風格、命名規則等工作交給工具；人工集中看代碼實踐的邏輯、對需求的比對等。将人從重複性的工作中解放出來，節約時間和人力。
華為實行代碼審查Committer機制，開發人員送出代碼後，會自動拉起自動化代碼檢查。送出一個Pull Request，工具比對相關的review進行評審和打分，如果是重要實作還可能會有一個評審會議，然後進入最終Committer決定是否将送出的代碼合并到主幹上去。
【四、持續測試與回報】
Q36：“通過持續測試實作快速與高品質“是靈活測試原則之一，而測試金字塔頂端的一些測試往往依賴許多外部因素，較為脆弱，容易因被測軟體之外的因素而失敗；且由于這類測試同時測試了軟體中的多個子產品，定位問題就會更難一些。對于 Flaky tests 怎樣處理比較好？删除還是進行标記使其不中斷後續的測試且不影響品質門禁？
A：Flaky Tests，就是指在被測對象和測試條件都不變的情況下，有時候失敗、有時候成功的測試。是以，Flaky Tests實際上就是不穩定的測試，或者随機失敗(随機成功)的測試。
測試金字塔之是以是正的三角形，核心理念是越往上，即金字塔頂端的測試，其跨度越大，影響面越大，一旦出現問題，爆炸的半徑也會更大，在這個層面做測試投入産出較小，工作量大且很難執行，比如測試故障定位等，而且自動化用例的複用程度或穩定性也較差，維護成本也比較高。當然該做的工作一定要做，但相對而言，建議這個層面的測試數量要适當減少。
相反，越往底層，比如單元測試，爆炸半徑相對就小一些，複用度和投入産出比也更高，而且在這個層面發現的bug應該是最多的。建議金字塔底層的測試措施應該相對多做。
中間比如接口測試或跨元件的內建等，如果微服務拆分相對顆粒度小一些，各方面相對就比較好，且接口測試相應的工具也比較多，投入産出比也會越來越大。接口測試也可以多做一些，這樣中間層變大，金字塔也會變成橄榄球形。
Q37：建構本地持續測試和雲上持續測試的對比難易程度和成本，如何選取？
A：本地持續測試和雲上持續測試的差異在于：本地需要自行對工具和版本進行維護，雲上的環境相對快捷。從成本方面考慮，雲上是按需的，性能測試、壓力測試等适合在雲上進行，因為自己去搭建一套10萬/100萬并發的環境成本非常高；越往前端的測試頻度非常高，适合在本地進行建構。另外還需要綜合考慮開發人員的使用習慣、公司對于資料的安全要求等進行選取。
Q38：從傳統的瀑布型測試到靈活測試再到DevOps，三者之間具體有什麼差別？
A：瀑布型測試是在開發完成傳遞以後才進行完整的測試，測試主體是測試人員；靈活測試往前走一步，做大量的持續內建等實踐（如果靈活實踐不隻是在管理層面的話）；DevOps是全流程測試，除了測試左移外，還有測試右移，頻繁地持續部署到準生産或生産環境上去跑相關測試，甚至還有現網測試，包括混沌工程、Chaos monkey等，其概念更廣。DevOps信奉Resilience（韌性），測試這件事很痛苦，我們要頻繁地去做。和反脆弱的概念比較一緻，“一切殺不死你的讓你更堅強”。
Q39 在測試自動化環節中應該如何簡化測試流程又能快速發現業務風險？
A：測試流程未必會簡化，所謂的簡化應該是指人員參與的流程減少，把大量能夠讓機器完成的工作交給機器、回歸測試等實作自動化，将人從枯燥的重複性的測試活動中解放出來，去做一些新型測試的探索。
Q40：SRE和DevOps有什麼差別和聯系？
A：DevOps通常由兩種角色去發起，Dev和Ops，即開發和運維。
SRE是Google首先提出的一個概念，Site Reliability Engineer（網站可靠性工程師），從Google運維體系出來的一個角色。
SRE工程師會通過自動化工具幫助開發人員，以運維的角度去參與研發并提供一些支援，包括開發一些自動化部署及運維相關的工具，通過這些工具和流程使能開發人員。
兩者比較而言，DevOps概念和範圍相對更大一些，SRE則聚焦在開發與運維層面。
Q41：在Scrum中隻有 Dev team，沒有專門的測試團隊。“做測試者勝于做檢查者”也要求測試人員不僅能發現問題更要準确定位問題。持續測試向價值流持續傳遞的兩端延伸，要求測試人員不僅要懂業務、懂開發還要懂運維，對測試人員的要求很高。在這種背景下，測試人員該如何進行職業發展規劃？
A：确實測試人員的焦慮相對更多，因為不管流程也好、角色分工也好，他都處于開發和運維之間的位置，像三明治一樣，比較難受。
換個角度來看，測試是承上啟下的活動，DevOps或靈活在開始的時候都會相對順利一些，短期成效很快，但等真正進入到測試層面，就像進入深水區，推進變得困難，原因可能就是自動化測試沒做好。這樣看來測試人員或測試活動其實大有可為，我們強調測試應該是一類活動，配置設定在整個研發生命周期過程中，而不是中間的某個階段，是以對測試人員的要求當然也會更高。
以往測試人員給人的印象是在研發送出後才參與進來，或者大量通過手工界面的點選去做回歸等工作。現在和未來，這類測試人員存在的價值會很低，未來可能會要求測試人員懂業務，從業務的角度設計測試用例；還要懂開發，需要寫測試腳本；還要懂運維。其實這些要求對所有的工程師都同樣存在，包括開發工程師，要會做架構、做設計、做開發、還可能要自己做測試、部署運維等；運維工程師也是如此，如果轉型SRE工程師的話，也要往前段去走。從這點來看，大家都在同一水準線上，所有人都要求往T型人才發展。
綜上，測試工程師應該是一個全程的品質保障人員，要從專業測試的視角對研發流程、需求、傳遞等進行品質控制，還需要引入相關實踐、開發工具或做工具內建，去賦能開發和運維。真正好的測試對整個團隊的幫助和提升應該是最大的。
Q42：與傳統項目比較，在靈活項目中，測試工作在整個流程中所占的比重是否更少了，頻次更高了，這是否意味着人效更高了？在DevOps流程下，産品人員、開發人員、主導測試人員的比例是否有一個新的經驗參考？
A：與傳統項目相比，靈活項目中，測試工作比重更大、頻次更高、人效也會更高，但這個更高不是通過人去堆，而是通過自動化工具或時間來完成。在DevOps流程下，專職的測試人員數量會下降，現在大量的開發測試是由開發人員來做，在華為内部稱為開發者測試，強調開發人員自己去做測試，以前開發測試比例差不多是3:1， 甚至1:1，現在可能是5：1或10:1的比例。産品人員跟以往應該沒有太大差異，現在強調産品思維、營運思維，業務營運人員的人數會增加。
Q43：小團隊（5人，分工：2前端，3後端，沒有專業測試人員）需要單獨配備測試人員嗎，一邊開發一邊測試，還是每個人對自己代碼負責最後一塊集中測試。這兩種哪種好一些？
A：個人認為5人團隊沒有必要配置專職測試，可以先由開發承擔測試，當團隊認為需要有一個專業的測試去知道或支援時，再去引入專業測試人員。那端到端的測試誰來做？建議是采用輪崗機制，類似on call，讓團隊成員輪流去做，這樣可以讓所有人對完整的測試都有了解和重視。
Q44：未來是否會研測一體化？
A：我認為研側一體化會是一個趨勢，開發者測試或開發測試的比例會越來越大，且不斷往前端延伸，
社會分工本就是合久必分分久必合，大分工衍生了一些新的概念，專業的人做專業的事，驅使我們更聚焦于自己的業務本質，比如IaaS（基礎設施即服務），運維/環境管理、系統管理等會有專業的人去做，可以看看你是否就是這樣一個專職的人才；測試也是如此，比如TaaS（Test as a service），也是一個非常專業的領域，要求懂開發、懂業務、懂運維。再有就是看公司的核心業務是什麼，很多公司都不是專門做測試、運維或工具的，我們應該專注聚焦于公司主營業務。
【五、持續安全與審計】
Q45：如果組織中缺少專業的安全與審計人員，應該如何去補足這方面的能力？
A：有些團隊會把這個能力轉移給相關的SaaS服務平台或第三方廠商。但平台隻能提供問題的展現，實際的安全審計處理還需要專人進行。團隊規模小時，可以通過業務上的分割和一些工具手段，盡量減輕相應人員的壓力。
Q46：小團隊安全管控得太嚴格了，對開發測試都會造成很多不便，也會影響問題排除追蹤，如何合理度量安全管控？
A：項目進入正規化流程後會有很多環境：開發環境、測試環境、類生産環境、生産環境等，可以采用多環境不同程度安全管控的政策，比如在進行開發環境測試時安全管控力度可以松一些，類生産環境測試時安全管控嚴格一些。
【六、持續部署與釋出】
Q47：持續部署是不是可以做到熱部署，不暫停業務直接通過流水線進行部署、提供使用者體驗？
A：持續部署，每一次變化都是直接部署到生産環境裡，但持續傳遞是有一定選擇性的，我們可以選擇性地把一些需要的東西部署到生産環境中。如果希望可以做到熱更新、熱部署，不暫停業務，可以通過持續部署的方式，直接使用流水線來實作。
Q48：K8s和Docker在應用上有什麼差別？
A：Docker是一種容器技術，在實踐中可以直接使用Docker進行鏡像建構等操作；K8s是進行叢集管理的技術手段，華為雲DevCloud的幫助中心有一個鳳凰商城的實踐案例，和HCIP考試中的實驗一樣，隻是多了CI/CD的環節，在這個環節中就使用了K8s。
Q49：K8S 和 雲原生是什麼關系？
A：雲原生是包括微服務、DevOps、容器化、持續傳遞等理念和方法，K8s隻是一個叢集管理的工具。
Q50：如果生産環境有等保要求，還有什麼辦法實作持續部署嗎？
A：如果生産環境有等保要求的話，不太适合直接做持續部署，這時使用持續傳遞的方式更好一些，我們可以先決定應該把哪些特性搬到生産環境上去。
Q51：新版程式修改了資料結構，如何進行應用設計或部署方案，以應對可能出現重大問題所需要的版本回退？
A：當我們做一些比較大的修改時，一般會先部署到類生産環境上，檢視沒問題後才會通過灰階的方式同步到生産環境中。
Q52：我們已經在做持續內建了，但持續傳遞和持續部署應該怎麼落地？
A：如果已經在做持續內建，且做得比較成熟了的話，再往前落地持續傳遞和持續部署會相對容易。我們經常說：持續傳遞隻是持續內建往前的一小步，最後一公裡或最後一米會比較痛苦。其實更多的痛點不在于技術層面，而是在于流程、制度層面，可能很難打穿部門牆、穿透企業管控類的要求，這些都未必是技術能解決的問題。
【七、持續運維與監控】
Q53：通過自動化的方式實作持續內建和持續傳遞，中間會不會出現幹擾而發生錯誤？
A：一般來說，通過自動化的方式實作持續內建和持續傳遞後，不是很容易發生錯誤。錯誤的出現可能是由于配置問題導緻的，在配置相應流水線時沒有配置好，比如參數出現問題，版本變得不一緻等。除此之外還可能會有一個意外導緻的問題，比如網絡故障等。
Q54：如果生産環境要求網絡隔離，還有什麼辦法實作持續部署嗎？
A：如果生産環境要求網絡隔離的話，我們的流水線一般會搭建在公司内部，也就是從送出代碼到建構部署都會在公司内部實作。這個過程中使用雲上自動化産品會少一些，因為目前大部分雲上建構的工具都必須通路公網才可以做到流水線的效果。
是以這種環境下，建議在本地搭建自動化建構流水線，或者購買可供私有化部署的工具。也可以在公網進行代碼托管和建構，隻在部署的時候通過手工部署的方式将軟體包放到網絡隔離的機器上去。
Q55：Docker與虛拟機有何不同？
A：從上圖可以用比較清楚的看到Docker和虛拟機的異同。左邊的VM是虛拟機使用，container是容器使用，也就是我們說的Docker。兩邊都有server端和Host OS（虛拟機上的系統）。我們知道每個APP上都有Bin/libs，在Docker容器技術環境下，相同的APP可以共用同一個Bin/libs。大大節省了所占的資源空間。
【八、DevOps實踐與轉型路徑】
Q56：到目前為止，已經學習了很多DevOps的功能，但是有一個困惑，對于使用DevOps是零代碼，那麼對于專業的開發人員來說，會不會慢慢降低他們的代碼開發積極性？
A：DevOps提供的零代碼是指在整個DevOps工具鍊中希望是零代碼的，通過将一切可自動化的工具自動化，将開發人員從各種維護工作中解放出來，使他們專注于開發。
Q57：在DevOps實踐中，環境差異的問題需要在哪個環節就開始着手來注意減少或者避免？
A：配置即代碼，在開發環節配置差異化的時候把環境差異等都配置進去。
Q58：在DevOps轉型過程中，對組織和團隊最有挑戰的有哪些？
A：我認為DevOps轉型最難的有兩方面：一是如何争取公司高層同意推動DevOps轉型；二是如果請了教練/顧問協助DevOps轉型，顧問/教練走後，如何繼續保持和落地DevOps實踐。
Q59：小團隊如果想要使用DevOps需要全員學習嗎，感覺每個人都學習時間成本挺高的，是否可以專人負責特定階段？
A：團隊如果想要進行DevOps轉型，需要專門有一個人把這些流程和工具研究明白，或者聘請一位外部DevOps顧問，再由整個專職人員或DevOps顧問在整個團隊進行教育訓練和推動。
Q60：四個閉環過程中遇到困難或者難點是否可以列舉？有什麼避免的方案？
A：先回憶一下四個閉環過程：
- 第一階段閉環：需求開發測試融合，将産品、研發、測試等角色融合，組建跨職能團隊，提升産品傳遞價值與品質；
- 第二階段閉環：開發測試融合，組建研發部門内部的跨職能團隊，提升自動化水準，降低修複成本；
- 第三階段閉環：研發營運一體化，實施産品自營運、自運維，打破了市場、研發、運維部門之間的壁壘，更多角色融入傳遞鍊路，提升業務響應力，建立價值回報流；
- 第四階段閉環：目标是逐漸實作所有業務線都以跨職能團隊為最小組織單元，實作業務靈活性，持續提升企業的市場競争力。
難點包括：
- 打通需求難。産品側和研發側溝通難。在傳統瀑布模式下産品和研發的溝通存在很多問題，比如需求溝通不明确等，引入靈活的計劃會議，在計劃會議上做需求澄清，可以解決這一難題。
- 開發測試融合難。在很多公司這是兩個團隊，還有些公司沒有測試的角色，要進行人員和過程的融合比較困難。
- 研發營運結合難。研發營運一體化，營運部分的内容怎麼跟開發結合也是一個難點。
- 組織結構管理難。整個流程打通了，人員的管理群組織結構的變動方面也可能會存在問題。
以上難點需要根據公司具體情況來實踐和探索最佳解決方案。
本文分享自華為雲社群《【FAQ】DevOps靈活8大領域60+常見問題解答》，原文作者：Cynthia成。
點選關注，第一時間了解華為雲新鮮技術~