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