關於Scrum+XP+DevOps的學習

最近聽了ECUG大會上孫敬雲老師的分享感受受益不淺，畢竟大學課本上只講到瀑布模型就沒有下文了，工做之後一直貫徹的都是Scrum路線，一直也沒有時間好好的去學習整理這部分的知識，直到近幾天聽到了孫老師的分享，因此就在這裏記錄下孫老師的分享也總結我本身的思路。如下內容部分摘自於孫老師的分析PPT

1 軟件工程之路

1.1 軟件工程的演進

貌似大學的那門軟件工程只給咱們講到了1980年，以後的須要咱們走出校門，在社會中進行學習。

先來看下面這張圖，是1980年至今的軟件工程演化路線，像瀑布模型你們應該是耳熟能詳。

進入1990年，Scrum這種，近幾年應該也是略有耳聞，但是像極限編程這種可能就不多據說了吧。

再向後看，進入2000年，持續集成也就是CI/CD中的CI和敏捷開發近幾年炒的火熱，互聯網公司爭先恐後，kanban（今天公司產品說，我才知道kanban是日本人發明的）也有點大勢已去，不過市場上應該還有很多公司在使用kanban。

走到了2010年，咱們所看到的應該就是幾個隨處可見的概念了，持續交付,DevOps,Scrumban（咱們近幾年說的真正意義上的Scrum）

1.2 瀑布模型

在這裏不詳細敘述，只敘述幾個痛點。

1. 產生客戶價值週期長
2. 部門、角色之間存在壁壘
3. 沒法及時響應需求變化
4. 價值流動不可見

1.3 敏捷開發

敏捷軟件開發（英語：Agile software development），又稱敏捷開發，是一種能應對快速變化需求的軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於「非敏捷」，更強調程序員團隊與業務專家之間的緊密協做、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、可以很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發過程當中人的做用。

說人話，就是更注重溝通，快速產出新版本，而且更適應需求變動的的適合小團體開發的方法。

下圖左方，是需求池的概念（好比jira中的backlog），好比7%的需求是現實中大量客戶的需求，則咱們將這7%的需求做爲優先級最高的需求。

下圖右方，是迭代和反饋的概念。

敏捷開發中有敏捷宣言，能夠更好地闡述敏捷開發的概念。

1. 個體和互動高於流程和工具（敏捷開發的站會落實了這一點）
2. 工做的軟件高於詳盡的文檔（jira、miro等更好地代替厚重的需求文檔）
3. 客戶合做高於合同談判（公司內各部門甩鍋狀況，難道不該該用合做爲公司創造價值嗎）
4. 響應變化高於遵循計劃（快速響應時長需求，而不是錯過市場變化）

1.3.1 Scrum實踐

下圖右上方是Scrum中的角色定義。

1. Product Owner（產品負責人，主要負責產品設計，需求篩選等）
2. Scrum Master（敏捷主管，主要負責項目迭代跟進等）
3. Scrum Team（敏捷團隊，主要負責需求的研發測試部署等，包括Dev、Test、Ops等）

下圖左方是用戶故事（user story）,其實就是咱們傳統意義上的需求，只不過以一種需求方的更委婉擬人的語氣來說述該用戶人羣的需求。

例如：我是一個買家，我但願個人購物車能經過價格排序，這樣我就能根據我卡中的錢進行合理的消費。

下圖中部，則是Scrum的核心流程。有不少公司光注重了其中的流程（好比站會），卻沒有獲得其中的精髓。Scrum中把一個迭代叫作一個衝刺(Sprint)，這也是不少地方把計劃會議叫作衝刺會的由來，通常一個Sprint爲1~4周。核心流程包括4個會議，以下所示：

1. 計劃會議（Product Owener、Scrum Master、Scrum Team）

   1. 從Backlog中按照優先級選擇這個Sprint要作的User Story
   2. 向團隊解釋澄清User Story的需求，並決定是否將User Story拆解爲更細粒度的Sub Task
   3. 團隊估計User Story的Story Point（用以評估story的大小，有一種好玩的方式叫作Scrum Poker）
   4. 團隊決定是否將User Story拆分Sub Task來進行跟蹤
   5. 決定這個Sprint的目標和交付的User Story

2. 每日站會（Product Owener（可選）、Scrum Master、Scrum Team）

   1. 站會維持在15分鐘之內，分遲早
   2. 團隊成員講述圍繞3點：我作了什麼，我將要作什麼，我遇到什麼困難
   3. 每人陸續進行講述，爲了快速響應，維持最新消息，包括需求調整等
   4. 以及進行高效溝通，傳遞信息，拒絕信息發散
   5. 肯定相關問題後，團體相關人員小範圍討論

3. 評審會議（Product Owener、Scrum Master、Scrum Team）

   1. 相似於傳統意義上的驗收階段
   2. 介紹Sprint結果，按User Story順序演示新功能
   3. 回答相關人員對展現的疑問，並記錄其所指望的更改，收集反饋
   4. 若是遇到一些還沒解決的障礙，則將障礙加入障礙Backlog
   5. 以User Story做爲是否成功交付的標準來評價任務完成狀況

4. 回顧會議（Scrum Master、Scrum Team）

   1. 回顧這個Sprint，收集Sprint的相關數據
   2. 產生看法，多問爲何，找到各個方面的優缺點，進行復盤分析
   3. 進行頭腦風暴分析解決方案，投票選出下期的改進項
   4. 探索提升效率和質量的方式

1.3.2 極限編程（XP）實戰

極限編程是敏捷開發中最具成效的幾種方法之一，如同其餘敏捷方法，它和傳統方法的本質不一樣在於它更強調可適應性能性以及面臨的困難。

它的基礎和價值觀是：

1. 交流（增強交流，解決信息不一樣步致使的問題）
2. 樸素（秉持最小可用，勤於迭代，不作拍腦殼的無用功擴展）
3. 反饋（多接受反饋，以進行快速調整修改）
4. 勇氣（在該重構時重構，當狀態不對時，放棄思考，調整狀態後從新思考）

它認爲任何一個軟件項目均可以從四個方面入手進行改善：增強交流；從簡單作起；尋求反饋；敢於實事求是。

下圖是極限編程的13個最佳實踐。

1.3.3 思考本身的團隊是否是敏捷

問問本身下面的幾個問題：

1. 成員是否氫氣的知道團隊的目標？
2. 成員是否能夠預測結果而且充滿信心？
3. 成員是否主動作事而且爲此負責？
4. 成員是否願意持續改進團隊？

若是你對上述幾個問題的回答時確定的，那麼恭喜你，大家的團隊是關注發展的敏捷團隊，若是你對上述問題有部分或所有否認，那麼你可能須要調整你的團隊，大家只不過是在關注敏捷的形式，而沒有精髓。

1.4 DevOps模型

DevOps是一種開發、測試和運維之間文化溝通，經過自動化的方式來進行軟件交付和架構變動的流程，使構建、測試、發佈軟件能更快捷、頻繁、可靠。它的出現是由於軟件逐漸的認識到，開發、測試和運維的緊密合做能夠更好的交付軟件產品和服務。

下圖是DevOps的標準化流程，經過創建一個完備的團隊來創建一條IT服務供應鏈，經過自動化實現高效率交付，不固定需求管理、工具鏈等，只專一於持續的穩定的價值交付

2 三部工做法

2.1 第一工做法（工做流）

這一步工做法是關於從開發到運再到客戶的自左向右的工做流

2.1.1 定義工做流

下圖展現了自循環工做流的流程，其中前4項屬於Dev範疇，後4項屬於Ops範疇：

1. plan（計劃）
2. code（編碼）
3. build（構建）
4. test（測試）
5. release（發佈）
6. deploy（部署）
7. operate（操做）
8. monitor（監控）

2.1.2 工做流實踐

下圖左方是咱們針對上面的工做流的一種實踐，是一種工做日誌的方式，這種工做方式一樣適用於敏捷開發（jira中的工做日誌），其實DevOps的本質就是敏捷開發。

1. 過程名稱
2. 輸入
3. 輸出
4. 工具
5. DoD（Definition of Done，完成的定義，能夠理解爲完成的標準）
6. 平均前置任務等待數（完成當前任務，依賴等待了多少任務）
7. 手工比例（手工操做的步驟佔據了總量多少）
8. %C/A（返工指標，完成時間/總花費時間，總花費時間=完成時間+修復時間）
9. 處理時間PT(真正處理該任務所花費的時間)
10. 流動時間FT（從接收到需求到需求完成所花費的時間）

經過上方工做日誌所記錄的數據，咱們能夠對咱們的工做進行階段性的分析，好比：

1. 平均前置任務等待數能夠用來判斷咱們的任務分配是否合理
2. 手工比例能夠用來提示咱們是否須要使用自動化來優化流程
3. %C/A能夠用來判斷一我的的工做質量是否須要優化
4. 等等

2.1.3 版本和分支策略

2.1.3.1 普通版本管理

1. 新需求拉一條新的分支進行開發，命名xxx feature branch
2. 新bug拉一條新的分支進行修復，命名xxx fix branch
3. master分支保持永遠可構建成功狀態
4. 每當新需求或新bug完成合併到主分支，觸發主分支的pipeline構建流程

2.1.3.2 GitFLow實踐

這種方案是基於GitFLow的標準來進行版本控制的。

該方案採用develop、feature、hotfix、release、prod等分支進行實踐，比較適合版本並存的團隊

1. develop：主開發分支，包含全部發布到下一個release的代碼
2. feature：新功能開發分支，最後會合並回develop分支
3. hotfix：prod發現bug時，用來熱修復分支，最後會合並回develop分支
4. release：發佈版本時，基於develop建立的分支
5. prod: 用於發佈到生產環境的代碼的分支，只能合併不能修改。

這種方式很靈活，代碼隔離也很好，只是過於繁瑣。

2.1.3.3 tag版本實踐

該方案是基於版本打tag的方式來進行版本控制的。

該方案採用master、feature、fix等分支進行實踐，比較適合小版本滾動升級團隊

1. master：主分支，該分支不容許修改，只容許合併，該分支永遠保持可構建狀態，發佈時經過tag來進行版本發佈
2. feature：新功能開發分支，最後會合並回master分支
3. fix：線上發生bug後，用於修復的分支最終會合併到master分支

這種方式很簡單，可是對多環境的支持不是很好。

咱們推薦使用GitFlow+Tag的方式來進行版本控制。以觸發多環境下的pipeline自動化流程。

2.1.4 規劃流水線

這裏主要是咱們的CI/CD的流水線的結構，可已使用Jenkins的pipeline也可使用Gitlab的pipeline。

這裏連接下以前寫的Jenkinsfile教程（Jenkins Pipeline 教程）

自動：

1. 代碼檢測（推薦使用SonarQube，教程）
2. 單元測試（很重要，java可以使用junit，其餘的未調研）
3. 製品（過去的jar包，現在的docker image）
4. 集成測試（很重要，屬於自動化測試中的一個重要環節）
5. 性能測試（大部分場景下可能不會每次都作）
6. 安全測試（跟性能測試差很少）
7. 部署預發佈（這裏泛指線上如下的全部環境）

手動：

1. 驗收測試
2. 部署線上

2.1.5 Scrum+XP+DevOps流程

看過了上面的部分，你必定嗤之以鼻，由於下面的圖其實就是上面的Scrum圖+Pipeline的圖。其實下面你的這張圖才能真正意義上的指導咱們如何在工做中實踐Scrum+DevOps。我將下面的圖分層了4塊，讓咱們一塊兒看看下面的圖吧

Scrum+XP流程

第一部分的需求池的這個概念咱們在上方的Scrum中已經看到了，在這裏不作詳細解釋，若是記不太清了，能夠回到上方#1.3.1 進行復習。

第二部分的Scrum流程須要咱們再來回顧一下，一個迭代中的4個會議還記得嗎，不記得就回去看看吧，經過小迭代來進行可持續的速度小型發佈，其中要落實XP的13個實踐，包括集體全部權、簡單設計、重構等等。

CI/CD

經過代碼版本控制來觸發咱們的的CI和CD的構建。

經過發佈編碼標準，測試驅動開發，代碼riew等來提高咱們的代碼質量以進行優質的代碼持續集成。

在持續集成以後，迎面而來的是構建、測試、部署，這幾個步驟的纔是真真正的表現咱們的團隊的持續交付的質量。

在3和4兩個步驟，咱們會看到下方有包含對號和錯號的表格，這個咱們會在接下來的地方講到，這個是個CI/CD反饋表，用來表示咱們某個階段的CI/CD的縮略狀況，能夠經過這個反饋來進行相關的分析。

2.2 第二工做法（反饋流）

2.2.1 持續反饋

下方的圖是CI/CD的持續反饋圖，可能作過Jenkins的Pipeline的小夥伴已經能看出它了。

頂部的「表頭」其實就是咱們的Pipeline的流程，而每一行是咱們的歷史構建記錄，經過這張圖咱們能夠清洗的看到咱們在某一階段的pipeline的執行狀況，就能夠看到咱們在哪個節點發生錯誤的狀況比較高。

在這個流程中最重要的就是測試部分，若是咱們的團隊對包括單元測試在內的測試環節若是不是很重視，那這個反饋將對咱們的團隊毫無心義。

在DevOps中，咱們推崇測試驅動開發，經過先寫單元測試，集成測試等用例來驅動咱們的開發進行編碼。

2.2.2 查看在製品

這裏的製品的含義就是咱們所構建的，好比java的jar，golang的native，docker的docker image等。

經過DevOps的反饋，咱們能夠查看製品所在的story的目前階段

2.3 第三工做法（學習）

2.3.1 不斷嘗試和重複學習

讓咱們再來看下面這張圖，對比上面的那種圖，在咱們的編碼、測試、部署三個階段多了個小錘子的標誌。

這裏的編碼、測試、部署，分別表明着開發、測試、運維，三個崗位須要不斷的嘗試、配合和重複學習來讓這條IT服務供應鏈更快速更穩定更自動化，讓信息反饋更精準、更全面的覆蓋到整個服務生命週期。

2.3.2 測試四象限

首先畫一個由x軸支持評價和y軸業務技術導向組成的四象限，咱們將咱們DevOps中的全部種類的測試流程放入其中，來將每個測試落實在一個二維區間內，再在每一種測試上標識一個工做投入程度，組成下面的圖。

咱們以前提過，在XP極限開發中，咱們推崇測試驅動開發，由於測試驅動開發可讓咱們在開發以前更加深刻的理解業務，而且基於接口定義程序，更好的組織咱們的軟件架構。

因此下圖是咱們的測試流程應在咱們的工做中所佔有的工做比例，若是全部的工做經歷爲100%的話，那麼6顆星則爲60%，每顆星佔據10%。

良好的開發習慣，和標準的測試流程可讓咱們的代碼質量更上一層樓。

2.3.3 運維四象限

上面咱們說了測試的四象限，這裏咱們說說運維的四象限，咱們以緊急性爲x軸，重要性爲y軸，這個四象限實際上是不少工種的人都會使用到的，會將咱們天天的任務放到裏面，用來肯定任務的優先級，咱們知道基於這種四象限，咱們的優先級會有下方四種：

1. 緊急且重要
2. 緊急不重要
3. 重要不緊急
4. 不重要不緊急

咱們將運維的工做放在上面，若是大部分的工做都落實在緊急且重要的第一象限上的話，那麼說明咱們的DevOps流程是有問題的，好比咱們的運維的大部分精力都在天天的線上緊急修復之類的任務，就說明咱們的開發和測試的質量是有問題的。

運維的工做不該該重點在右方，而應該重心左移，偏向於重要不緊急，多作一些規劃性的工做，好比從傳統部署方式轉向k8s容器編排等工做。

3 工程化指南

3.1 實踐整合

在上面咱們將上面說講述的知識合併起來，組成咱們真正在工做中實踐所要用到的東西。Scrum+XP+DevOps

3.2 創建工程師文化模型

小團隊內部要作到：

1. 可視化面板和主動領取任務(信息扁平化，加速效率，共同目標幫助隊友完成任務)
2. 成爲用戶故事的負責人（每一個人都要有主人翁意識，認爲本身是UserStory的主人）
3. 20%的非功能性需求（給開發一點非業務的技術需求，提高多巴胺，產生樂趣）
4. 合入主幹的代碼須要審覈（合代碼須要組內review，下降代碼出問題的機率）
5. 週期性的技術分享（每一個人都要分享，對本身所學到的東西進行沉澱，同時也吸收組內其餘人的分享）

公司級別：

1. 舉辦黑客馬拉松（選擇一個主題，讓公司的開發進行參與，進行開發，討論，提高技術激情）
2. 舉辦技術沙龍

3.3 目錄結構

定義每種語言的標準的目錄結構，好比下方的目錄結構就是Node.js的標準目錄結構，我將一些語言級通用的結構用紅框畫了出來。

1. src
2. test
3. .env
4. Compilefile
5. Dockerfile
6. Jenkisnfile

3.4 版本控制規劃

下圖使用的是基於Tag的版本控制，我這裏看推薦使用GitFLow+Tag的方式來進行基於Tag多多環境的版本控制的方式進行構建使用。

3.5 快速失敗的流水線

下圖中的快速失敗的概念是指當pipeline中某一節點未達到經過的要求，則再也不運行以後得節點，以當前節點的失敗爲整個pipeline的失敗。

像jenkins原生就兼容快速失敗。下圖是jenkins最新的Blue Ocean界面，很友好的。

3.6 可視化反饋平臺

在第二工做法中，咱們學習到了反饋工做流，若是使用jenkins構建pipeline的時候，咱們就能夠經過jenkins原生支持的可視化結果來了解到咱們近期的CI/CD狀況。

3.7 持續改進

在咱們的產品設計中，有一個MVP的概念，它的意思是最小可行產品，這個概念來自於《精益創業：新創企業的成長思惟》這本書中，書中提倡首先定義一個面向市場的最小可用的極簡原型產品，而後再不斷的試驗和學習中，以最小的成本和最有效的方式來驗證產品是否符合用戶需求，靈活調整方向，以達到「快速失敗，廉價失敗」的方式來驗證產品是否符合市場需求。這是一種不斷學習，挖掘用戶需求，迭代優化產品的方式。

咱們對待咱們的團隊，其實也要像對待咱們的產品同樣，不停地學習，不停地嘗試，不停地優化，這樣讓咱們的團隊快速成長，要容許咱們的團隊犯錯（可是不能重複掉進相同或類似的坑中）。

3.8 更多的質量保證

3.8.1 CI/CCD

經過良好的測試+自動化流水線來提升咱們的代碼的質量

在部署前：

1. 集成測試
2. 性能測試
3. 安全性測試

部署後測試：

1. 自動化測試
2. 驗收測試

3.8.2 環境與配置管理

經過配置中心來區別應用在各個環境中的配置，以防止出現踩到帶着開發測試的配置上線的這種老舊坑。

3.8.3 製品庫管理

製品庫推薦也一樣隔離開，預發和生產使用同一個製品庫，開發和測試使用同一個製品庫，在兩個製品庫之間，須要人爲來審覈和同步。

3.8.4 流程控制

這裏的流程控制主要指的是CI/CD的流程控制。由於咱們都知道jenkins單節點在同一時間自由一個pipeline能構建，也就是說單節點jenkins不能多條pipeline併發構建。因此咱們須要搭建分佈式的jenkins集羣，來對pipeline的構建進行調度。

另外一種更好的方式就是經過gitlab或其餘支持併發pipeline構建的工具進行構建。

下方的pipeline中在測試環節分紅了三個分支，這個特性咱們再使用jenkins的pipeline時是有完美支持的，名字叫並行流，是根據條件來判斷三個分支是否進行的。

3.8.5 數據收集和監控

咱們的服務上線後，咱們須要使用兩種方式來確保咱們線上使用的服務可以健康的提供服務。

1. 日誌
2. 監控

經過採集咱們的線上的服務的日誌，來對線上日誌進行分析，達到實時監控服務健康狀況的需求。這裏推薦使用市場較爲開放通用的開源方案ELK

咱們同時還要對咱們的中間件，流量，物理硬件等進行相關監控，以肯定基礎環境的實時監控狀況，這裏我推薦使用Prometheus+Granfa進行監控。

3.8.6 容災

當咱們的應用日益複雜且用戶量逐漸提升後，咱們須要對咱們的服務進行容災配置以及週期醒的混沌工程演練。咱們的服務應該像下圖同樣逐漸進階爲可用性更高的部署方式。

3.8.7 緊急事件處理

咱們永遠都不能心安理得的拍着胸口說咱們的服務很是的問題，可用性能達到100%。由於100%是咱們的服務的可用性極限，就算咱們的服務可用性作到6個9，8個9，可是永遠也達不到100%，永遠只能無限的趨近於100%。由於咱們永遠都沒辦法避免黑天鵝事件。可是咱們能作的是出現黑天鵝事件後，咱們要快速響應，將咱們的損失降到最低。下面就說說當出現線上故障的時候，咱們應該怎麼作才能更好的減小咱們的損失。

事故發生前（凡事有預案）:

1. 提早準備可能出現的事故
2. 全員參與容災演練
3. 多作混沌工程，提升服務的可用性和健壯性

事故發生時（先通報，後處理）：

1. Ops和Dev相互通報
2. Ops和Dev各自向上級彙報
3. 主管決定是否繼續向上級彙報

事故處理中(先止損，後查因)：

1. 是否有處理預案
2. 有預案，Ops主管10分鐘內作回滾決定
3. 無預案，Ops主管和Dev主管決定回滾和補救方案

事故處理後（反思，定級）：

1. Ops通報事故處理結果
2. 24小時內主要責任部門牽頭矩形Case Study
3. 對事故進行定級

本文來自 納蘭小築，本文不予回覆，評論請追溯原文
查看原文