參考資料：極客時間-DevOps實戰(zhàn)筆記

DevOps基礎(chǔ)理論篇

1. DevOps的定義

DevOps定義：

DevOps是一種文化丧没、一場運動或?qū)嵺`去扣，強調(diào)在自動化軟件交付流程和基礎(chǔ)設(shè)施變更過程中涩蜘，軟件開發(fā)人員與其他信息技術(shù)專業(yè)人員彼此之間的協(xié)作和溝通。他旨在建立一種文化和環(huán)境弥姻，使構(gòu)建骂倘、測試、軟件發(fā)布得以快速茄厘、頻繁以及更加穩(wěn)定的進行矮冬。

軟件工程的三個重要階段：

瀑布開發(fā)模式、敏捷開發(fā)模式次哈、DevOps開發(fā)模式胎署。

2. DevOps的價值

軟件的價值：

軟件慢慢從企業(yè)內(nèi)部的支撐系統(tǒng)和成本中心，變成了企業(yè)服務(wù)的直接載體和利潤中心窑滞。

軟件交付的效率和質(zhì)量成為企業(yè)的核心價值和核心競爭力琼牧。

DevOps的價值：

提高軟件的交付效率和交付質(zhì)量恢筝。

DevOps的四個結(jié)果指標：1.部署頻率；2.變更前置時長巨坊；3.服務(wù)恢復(fù)時間撬槽；4.變更失敗率。

3. DevOps的實施

DevOps工具：

工具是提升效率最直接的手段趾撵。

標準化侄柔、流程化。

但是工具沒辦法解決人的問題占调。

DevOps文化：

職責共擔暂题、持續(xù)改進。

DevOps的三個支柱：

img

1. 人+流程=文化

   在具體的流程下究珊，人會形成一套行為準則薪者，而這套行為準則會潛移默化的影響軟件交付效率和質(zhì)量的方方面面。這些行為準則組合到一起剿涮，就形成了公司的文化言津。

2. 流程+平臺=工具

   流程標準化，并固化到平臺取试。

3. 平臺+人=培訓賦能

   平臺是標準化流程的載體悬槽，一方面可以規(guī)范和約束員工的行為，另一方面通過平臺賦能想括，所以人都能以相同的操作陷谱，獲得相同的結(jié)果∩冢跨領(lǐng)域之間的交接和專家就被平臺所取代烟逊。

4. DevOps的衡量

DevOps能力成熟度模型：

img

步驟和原則：

影響軟件交付效率和質(zhì)量進一步提升的最大瓶頸是什么？識別出改進目標和改進后要達到的預(yù)期效果铺根。

關(guān)注能力宪躯，持續(xù)改進。

部署引力圖：

img

DevOps落地實踐篇

1. 價值流分析

VSM（value stream mapping）：

持續(xù)交付平臺 -> VSM價值流交付平臺位迂。

價值就是帶給企業(yè)生存發(fā)展的核心資源访雪，比如生產(chǎn)力、盈利能力掂林、市場份額臣缀、用戶滿意度。

VSM就是價值流圖泻帮，通過價值流圖對軟件交付過程進行建模精置，使整個過程可視化，從而識別出交付過程的瓶頸和各個環(huán)節(jié)的依賴關(guān)系锣杂，不斷優(yōu)化和改進脂倦。

VSM關(guān)鍵要素：

1. 前置時間

2. 增值活動時間和不增值活動時間

3. 完成度和準確度

2. DevOps轉(zhuǎn)型路徑和常見問題

兩種軌跡：

自底向上番宁，自頂向下。

需求管理層的認可和支持是必選項赖阻。

通用路徑：

1. 尋找合適的試點項目蝶押。

2. 尋找團隊痛點。

3. 快速建立初期的成功火欧。

4. 快速展示和持續(xù)改進棋电。

DevOps轉(zhuǎn)型的J型曲線：

img

隨著交付能力的提升，質(zhì)量能力和技術(shù)債務(wù)開始顯現(xiàn)苇侵。比如大量的手工回歸測試离陶、耦合性太強。

3. 業(yè)務(wù)敏捷

交付能力提升衅檀，可以幫助業(yè)務(wù)以最小成本進行試錯，將新功能快速交付給用戶霎俩。

所以哀军，開發(fā)更少的功能，聚焦用戶價值打却，持續(xù)快速驗證杉适，就成了產(chǎn)品需求管理的核心思想。

4. 精益看板

豐田準時化生產(chǎn)系統(tǒng)柳击，拉動式生產(chǎn)猿推，關(guān)鍵在于限制在制品數(shù)量。

在制品數(shù)量上升捌肴，導(dǎo)致交付周期變長蹬叭，交付質(zhì)量下降，團隊信任下降状知。

精益看板實踐的5個步驟：

1. 可視化流程

2. 定義清晰的規(guī)則

3. 限制在制品數(shù)量

4. 管理工作流程

5. 建立反饋和持續(xù)改進

可視化流程：

根據(jù)價值流定義看板秽五。

豎向隊列，按價值流轉(zhuǎn)的各個主要階段進行劃分饥悴。比如需求坦喘、開發(fā)、測試西设、發(fā)布瓣铣。

橫向泳道，用于需求與需求之間劃清界限贷揽。

定義清晰的規(guī)則：

1. 可視化規(guī)則

2. 顯示化規(guī)則

限制在制品數(shù)量：

限制在制品數(shù)量棠笑，理論上交付的前置時間應(yīng)該大大縮短。

關(guān)鍵節(jié)點：

1. 需求流入節(jié)點擒滑。業(yè)務(wù)方和研發(fā)團隊關(guān)于需求的PK腐晾。研發(fā)團隊需要承諾業(yè)務(wù)方以最快的速度交付最高優(yōu)先級的需求叉弦。
2. 需求流出節(jié)點。開發(fā)團隊自己負責業(yè)務(wù)的發(fā)布藻糖。

管理工作流程：

1. 每日站會淹冰。關(guān)注被阻塞的任務(wù)。

2. 隊列填充會議巨柒。對任務(wù)的優(yōu)先級進行排序樱拴，展示需求的開發(fā)狀態(tài)。

3. 發(fā)布規(guī)劃會議洋满。以最終交付為目標晶乔，同步研發(fā)團隊和業(yè)務(wù)方的信息。

建立反饋和持續(xù)改進：

持續(xù)改進和對人的尊重牺勾，才是一切改進方法的終極坐標正罢。

5. 配置管理

配置管理，是站在軟件交付全生命周期的視角驻民，對整個開發(fā)過程進行規(guī)范管理翻具，控制變更過程，讓協(xié)作更加順利回还，確保整個交付過程的完整裆泳、一致和可追溯。

核心理念：版本變更標準化柠硕、將一切納入版本控制工禾、全流程可追溯、單一可信的數(shù)據(jù)源蝗柔。

6. 持續(xù)集成

認識CI：

CI就是持續(xù)集成闻葵，集成什么？為什么要持續(xù)癣丧？

集成軟件笙隙，軟件集成是一件高風險、不確定的事情坎缭。

越痛苦的事情竟痰，越要頻繁的做。

CI的定義：

CI是一種軟件開發(fā)實踐掏呼，團隊成員頻繁的將他們的工作成果集成到一起（通常每人每天至少提交一次坏快，這樣每天就會有多次集成），并且在每次提交后憎夷，自動觸發(fā)運行一次包含自動化驗證集的構(gòu)建任務(wù)莽鸿，以便盡早地發(fā)現(xiàn)集成問題。

實施CI的三個階段：

1. 每次提交觸發(fā)完整的流水線。

   關(guān)鍵詞：快速集成祥得。

   1.1. 統(tǒng)一的分支策略兔沃。定義以集成為目的的分支。

   1.2. 清晰的集成規(guī)則级及∑故瑁基于時效性的要求，不同層的CI饮焦，步驟和要求不同怕吴。

   1.3. 標準化的資源池。資源池按需初始化县踢，環(huán)境標準化转绷，任何任務(wù)可以在任何節(jié)點運行。

   1.4. 足夠快的反應(yīng)周期硼啤。CI環(huán)節(jié)不能超過10-15分鐘议经。

2. 每次流水線觸發(fā)自動化測試。

   關(guān)鍵詞：質(zhì)量內(nèi)建谴返。

   2.1. 匹配合適的測試活動爸业。

   2.2. 樹立測試結(jié)果的公信度。

   2.3. 提升測試活動的有效性亏镰。

3. 出問題第一時間修復(fù)。

   關(guān)鍵字：文化建立拯爽。

   機制：10分鐘內(nèi)修復(fù)代碼索抓，如果不能修復(fù)就回滾。

   讓CI發(fā)揮價值的關(guān)鍵毯炮，在于團隊面對持續(xù)集成的態(tài)度逼肯，以及團隊是否建立的持續(xù)集成的文化。

7. 自動化測試

自動化測試要解決什么問題：

產(chǎn)品交付速度提升桃煎，給測試工作帶來了很大挑戰(zhàn)篮幢。要測試的內(nèi)容越來越多，但是測試的時間越來越短为迈。

適合的場景：回歸測試三椿、接口測試、兼容性測試葫辐、壓力測試搜锰。

面臨問題：投入產(chǎn)出比、上手門檻耿战、維護成本高蛋叼、測試設(shè)備投入高。

自動化測試設(shè)計：

單元測試、接口測試狈涮、UI測試狐胎。

自動化測試開發(fā)：

工具和平臺支持。

測試數(shù)據(jù)歌馍、用例握巢、腳本的管理，測試過程中的數(shù)據(jù)收集骆姐、度量镜粤、分析和展示，以及測試報告的發(fā)送玻褪，都是成熟的自動化測試框架應(yīng)該具備的功能肉渴。

自動化測試結(jié)果分析：

1. 覆蓋率
2. 測試誤報率

8.內(nèi)建質(zhì)量

不應(yīng)該將質(zhì)量依賴于檢驗工作，因為檢驗工作既昂貴带射，又不可靠同规，最重要的是，檢驗工作并不直接提升產(chǎn)品質(zhì)量窟社，只是為了證明質(zhì)量有缺陷券勺。正確的做法是將質(zhì)量內(nèi)建于整個流程之中，并通過有效的控制手段灿里，來證明流程自身的有效性关炼。

內(nèi)建質(zhì)量的核心原則：

1. 問題發(fā)現(xiàn)得越早，修復(fù)成本就越低匣吊。
2. 質(zhì)量是每個人的責任儒拂，而不是質(zhì)量團隊的責任。

內(nèi)建質(zhì)量的實施思路：

我們應(yīng)該在軟件交付的各個環(huán)節(jié)中注入質(zhì)量控制的能力色鸳。

1. 需求環(huán)節(jié)社痛，定義清晰的需求準入規(guī)則。比如價值命雀、可行性蒜哀、依賴、描述吏砂、拆分撵儿、驗收條件。

2. 開發(fā)環(huán)節(jié)狐血，代碼評審和持續(xù)集成统倒。比如需求匹配度、實現(xiàn)清晰度氛雪、自動化檢查機制（風格房匆、風險、安全漏洞）。

3. 測試環(huán)節(jié)浴鸿，自動化測試和手工探索測試井氢，覆蓋安全、性能和可靠性岳链。

4. 部署和發(fā)布環(huán)節(jié)花竞，線上監(jiān)控和危險操作掃描。

優(yōu)先加強哪個環(huán)節(jié)掸哑？從源頭入手约急。

內(nèi)建質(zhì)量的實施步驟：

1. 選擇合適的檢查類型。投入產(chǎn)出比高苗分。

2. 定義指標并達成一致厌蔽。指標項、參考值摔癣。靜態(tài)指標值和動態(tài)指標值奴饮。

3. 建立自動化執(zhí)行和檢查能力。在源頭設(shè)置質(zhì)量門禁择浊。

4. 定義問題處理方式戴卜。

5. 持續(xù)優(yōu)化和改進。核心目標不是通過質(zhì)量門禁琢岩，而是為了質(zhì)量提升投剥。

內(nèi)建質(zhì)量常見問題：

img

9. 技術(shù)債務(wù)

代碼七宗罪：

img

量化技術(shù)債務(wù)：

比較常用的開源軟件是SonarQube。

計算出來的技術(shù)債務(wù)會因為開啟的規(guī)則數(shù)量和種類的不同而不同担孔。

解決方法和原則：

步驟：共識江锨、可見、止損攒磨、改善。

原則：

1. 讓技術(shù)債務(wù)呈良性下降趨勢

2. 優(yōu)先解決高頻修改的問題

3. 在新項目中啟動試點

4. 技術(shù)債務(wù)無法被消滅汤徽，也不要等到太晚

需要優(yōu)先處理的問題類型：

1. 大量重復(fù)代碼

2. 類之間嚴重耦合

3. 方法過于復(fù)雜

4. 條件判斷嵌套太多

5. 缺少必要的異常處理

6. 多表關(guān)聯(lián)和缺少索引

7. 代碼風險和缺陷

8. 安全漏洞

10. 環(huán)境管理

環(huán)境管理的挑戰(zhàn)：

1. 環(huán)境種類多娩缰。比如開發(fā)環(huán)境、測試環(huán)境谒府、生產(chǎn)環(huán)境拼坎。

2. 環(huán)境復(fù)雜度高。現(xiàn)代應(yīng)用的架構(gòu)逐漸從單體應(yīng)用向微服務(wù)應(yīng)用轉(zhuǎn)變完疫。

3. 環(huán)境一致性難以保證泰鸡。

4. 環(huán)境交付速度慢。

5. 環(huán)境變更難以追溯壳鹤。

基礎(chǔ)設(shè)施即代碼：

基礎(chǔ)設(shè)施即代碼盛龄，就是用一種描述性的語言，通過文本管理環(huán)境配置，并且自動化完成環(huán)境配置的方式余舶。

典型的就是以 CAPS 為代表的自動化環(huán)境配置管理工具啊鸭，也就是 Chef、Ansible匿值、Puppet 和 Saltstacks 四個開源工具的首字母縮寫赠制。

環(huán)境管理實踐：

1. 開發(fā)運維打通的GitOps實踐

2. 開發(fā)環(huán)境的治理實踐

3. 開發(fā)本地測試的實踐

11. 部署管理

部署和發(fā)布：

部署：通過技術(shù)手段，將本次開發(fā)測試完成的功能實體挟憔，應(yīng)用到指定環(huán)境的過程钟些。

發(fā)布：將部署完成的功能生效，對用戶可見和提供服務(wù)的過程绊谭。

質(zhì)量思想：

傳統(tǒng)的質(zhì)量思想：要在發(fā)布之前確保本次變更的功能萬無一失政恍。

DevOps的質(zhì)量思想：要在保障一定質(zhì)量水平的前提下，盡量加快發(fā)布節(jié)奏龙誊，并通過低風險發(fā)布手段抚垃，以及線上測試和監(jiān)控能力，盡早地發(fā)現(xiàn)問題趟大，以一種最簡單的手段來快速恢復(fù)鹤树。

一定的質(zhì)量水平：

與定義一個發(fā)布質(zhì)量標準相比，更重要的是扭轉(zhuǎn)團隊的質(zhì)量觀念逊朽。質(zhì)量不再是測試團隊自身的事情罕伯，而是整個交付團隊的事情。如果出了線上問題叽讳，團隊要一起來定位和修復(fù)追他，并且反思如何避免類似的問題再次發(fā)生，從失敗中學習岛蚤。

測試能力向前邑狸、向后延伸，一方面涤妒，提供工具和平臺幫助開發(fā)更容易自測单雾，另一方面，加強針對線上監(jiān)控埋點等類型的測試她紫，保證線上問題可以快速暴露硅堆，正常獲取可以輔助分析玩家行為的數(shù)據(jù)，全面提升整體的發(fā)布質(zhì)量贿讹。

低風險的發(fā)布手段：

藍綠發(fā)布渐逃、灰度發(fā)布、暗部署民褂。

線上測試和監(jiān)控：

如果驗證發(fā)布是否正常茄菊，核心在于線上測試和監(jiān)控疯潭。

DevOps新理念，監(jiān)控就是一種全量的測試买羞。

快速恢復(fù)：

線上診斷袁勺，阿里的Arthas。

解決問題畜普，向前修復(fù)和向后回滾期丰。

故障自愈，服務(wù)降級和兜底策略吃挑。

12. 混沌工程

混沌工程：

混沌工程是一門在分布式系統(tǒng)上進行實驗的科學钝荡，目的是建立人們對于復(fù)雜系統(tǒng)在生產(chǎn)環(huán)境中抵御突發(fā)事件的信心。

復(fù)雜的分布式系統(tǒng)舶衬，Netflix 公司在 2014 年公開的微服務(wù)調(diào)用關(guān)系圖：

img

服務(wù)可用性實踐：

日常的系統(tǒng)可用性保障活動埠通，故障演練、服務(wù)降級方案逛犹、全鏈路壓測端辱。

如何發(fā)現(xiàn)潛在風險，比如Netflix的混亂猴子虽画，隨機關(guān)閉生產(chǎn)環(huán)境中的實例舞蔽。

不要把可用性的假設(shè)建立在依賴服務(wù)不會出問題上。

混沌工程的原則：

1. 建立穩(wěn)定狀態(tài)的假設(shè)码撰。業(yè)務(wù)指標渗柿、技術(shù)指標。

2. 真實世界的事件脖岛。

3. 在生產(chǎn)中實驗朵栖。

4. 持續(xù)的自動化實驗。

5. 最小的影響范圍柴梆。

13. 正向度量

DevOps的核心目標陨溅，提高交付效率，提高交付質(zhì)量绍在。圍繞目標门扇，拆分度量指標。

如何定義指標：

1. 明確受眾

2. 直指問題

3. 量化趨勢

4. 充滿張力

定義指標有哪些原則：

1. 全局指標優(yōu)于局部指標

2. 綜合指標優(yōu)于單一指標

3. 結(jié)果指標優(yōu)于過程指標

4. 團隊指標優(yōu)于個人指標

5. 靈活指標優(yōu)于固化指標

哪些指標最重要：

img

如何開啟度量工作：

1. 細化指標

2. 收集度量數(shù)據(jù)

3. 建立可視化平臺

4. 識別瓶頸并持續(xù)改進

14. 持續(xù)改進

團隊最應(yīng)該具備的能力：

持續(xù)改進揣苏，始終能夠找到新的突破悯嗓，持續(xù)追求更好的狀態(tài)件舵。

DevOps做到什么程度算實現(xiàn)轉(zhuǎn)型落地卸察？核心就是團隊具備了持續(xù)改進的能力，而不是簡單的引進了幾個工具铅祸，建立幾個度量指標坑质。

PDCA方法論合武，Plan（計劃）、Do（實施）涡扼、Check（檢查）稼跳、Action（行動）。

持續(xù)改進的核心吃沪，在于建立一個學習型的組織汤善。

學習型組織的4個實踐：

1. 鼓勵正向回溯和總結(jié)

   當問題發(fā)生之后，事先準備一份詳盡的故障分析報告票彪，并拉上相關(guān)方徹底分析問題的根源红淡，給出改進任務(wù)的具體時間點。

2. 預(yù)留固定時間進行改進

3. 在團隊內(nèi)部共享業(yè)務(wù)指標

4. 激勵創(chuàng)造性降铸，并將價值最大化

   在團隊成員的績效目標中在旱，增加對團隊貢獻和技術(shù)創(chuàng)新的要求，在團隊內(nèi)部鼓勵創(chuàng)新類工作推掸。

   在團隊內(nèi)部建立激勵和選拔機制桶蝎，為好的想法投入資源，把他們變成可以解決類似問題的工具谅畅。

DevOps平臺工具篇

1. DevOps平臺建設(shè)的三個階段

階段一：從無到有

建議：引入開源工具和商業(yè)工具登渣，快速補齊現(xiàn)有能力的短板。

如何選擇工具铃彰？選擇主流工具绍豁。

• 需求管理工具 Jira；
• 知識管理工具 Confluence牙捉；
• 版本控制系統(tǒng) GitLab竹揍；
• 持續(xù)集成工具 Jenkins；
• 代碼質(zhì)量工具 SonarQube邪铲；
• 構(gòu)建工具 Maven/Gradle芬位；
• 制品管理 Artifactory/Harbor；
• 配置管理工具 Ansible带到；
• 配置中心 Apollo昧碉；
• 測試工具 RF/Selenium/Appium/Jmeter/TestNG；
• 安全合規(guī)工具 BlackDuck/Fortify揽惹；

階段二：從小到大

經(jīng)過了第一個階段被饿，企業(yè)交付鏈路上的工具基本已經(jīng)齊全了。團隊對工具的需求從夠用到好用開始轉(zhuǎn)變搪搏。另外狭握，隨著業(yè)務(wù)發(fā)展，團隊擴大疯溺，差異化需求也成了擺在面前的問題论颅。再加上哎垦，人和數(shù)據(jù)越來越多，工具的重要性與日俱增恃疯。

建議：使用半自建工具和定制商業(yè)工具漏设，來解決自己的問題。

半自建工具有哪些注意事項：

1. 設(shè)計時給擴展流出空間

2. 實現(xiàn)時關(guān)注元素治理

階段三：由繁到簡

建議：使用整合工具來化繁為簡今妄，統(tǒng)一界面郑口，簡化操作，有效度量盾鳞。

1. 企業(yè)工具平臺治理

   找到軟件交付的主路徑，用一個平臺覆蓋這條主路徑，從而串聯(lián)各個單點的能力缸兔。

2. 打造自服務(wù)的工具平臺

   用戶登錄平臺惰蜜，實現(xiàn)自己的操作抛猖，查看自己關(guān)心的數(shù)據(jù)财著。

2. DevOps產(chǎn)品設(shè)計的五個層次

五個層次：戰(zhàn)略存在層撑教、能力圈層罚拟、資源結(jié)構(gòu)層、角色框架層和感知層秆乳。

img

第一個層次：戰(zhàn)略存在層

把戰(zhàn)略建立在不變的事物上。

DevOps產(chǎn)品戰(zhàn)略定位：效率双藕、質(zhì)量忧陪、成本和安全嘶摊。

第二個層次：能力圈層

明確哪些是自己的核心競爭力，哪些是自己的邊界和底線虱颗。

第三個層次：資源結(jié)構(gòu)層

對資源的整合和調(diào)動的能力就成了核心競爭力忘渔。

至關(guān)重要資源，領(lǐng)導(dǎo)的支持宣赔。

第四個層次：角色框架層

在用戶的角度看待問題拉背，要在他們當時的場景下椅棺，去解決他們的問題两疚。

不要讓你的產(chǎn)品只有專業(yè)人士才會使用诱渤。

第五個層次：感知層

UI界面勺美。

3. 現(xiàn)代流水線必備的十大特征

img