最近聽(tīng)了ECUG大會(huì)上孫敬云老師的分享感覺(jué)受益匪淺，畢竟大學(xué)課本上只講到瀑布模型就沒(méi)有下文了，工作以后一直貫徹的都是Scrum路線项阴，一直也沒(méi)有時(shí)間好好的去學(xué)習(xí)整理這部分的知識(shí)巴粪，直到近幾天聽(tīng)到了孫老師的分享，所以就在這里記錄下孫老師的分享也總結(jié)我自己的思路椰苟。以下內(nèi)容部分摘自于孫老師的分析PPT

1 軟件工程之路

1.1 軟件工程的演進(jìn)

貌似大學(xué)的那門(mén)軟件工程只給我們講到了1980年叫胖，之后的需要我們走出校門(mén)她奥，在社會(huì)中進(jìn)行學(xué)習(xí)瓮增。

先來(lái)看下面這張圖糠悯，是1980年至今的軟件工程演化路線懒闷，像瀑布模型大家應(yīng)該是耳熟能詳沐扳。

進(jìn)入1990年蚓炬，Scrum這種，近幾年應(yīng)該也是略有耳聞殿遂，可是像極限編程這種可能就很少聽(tīng)說(shuō)了吧竟闪。

再向后看爽冕，進(jìn)入2000年隙赁，持續(xù)集成也就是CI/CD中的CI和敏捷開(kāi)發(fā)近幾年炒的火熱垦藏，互聯(lián)網(wǎng)公司爭(zhēng)先恐后，kanban（今天公司產(chǎn)品說(shuō)伞访，我才知道kanban是日本人發(fā)明的）也有點(diǎn)大勢(shì)已去掂骏，不過(guò)市場(chǎng)上應(yīng)該還有不少公司在使用kanban。

走到了2010年厚掷，我們所看到的應(yīng)該就是幾個(gè)隨處可見(jiàn)的概念了弟灼，持續(xù)交付,DevOps,Scrumban（我們近幾年說(shuō)的真正意義上的Scrum）

1.2 瀑布模型

在這里不詳細(xì)敘述，只敘述幾個(gè)痛點(diǎn)蝗肪。

1. 產(chǎn)生客戶價(jià)值周期長(zhǎng)
2. 部門(mén)袜爪、角色之間存在壁壘
3. 無(wú)法及時(shí)響應(yīng)需求變化
4. 價(jià)值流動(dòng)不可見(jiàn)

1.3 敏捷開(kāi)發(fā)

敏捷軟件開(kāi)發(fā)（英語(yǔ)：Agile software development）蠕趁，又稱(chēng)敏捷開(kāi)發(fā)薛闪，是一種能應(yīng)對(duì)快速變化需求的軟件開(kāi)發(fā)能力。它們的具體名稱(chēng)俺陋、理念豁延、過(guò)程昙篙、術(shù)語(yǔ)都不盡相同，相對(duì)于“非敏捷”诱咏，更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專(zhuān)家之間的緊密協(xié)作苔可、面對(duì)面的溝通（認(rèn)為比書(shū)面的文檔更有效）、頻繁交付新的軟件版本袋狞、緊湊而自我組織型的團(tuán)隊(duì)焚辅、能夠很好地適應(yīng)需求變化的代碼編寫(xiě)和團(tuán)隊(duì)組織方法，也更注重軟件開(kāi)發(fā)過(guò)程中人的作用苟鸯。

說(shuō)人話同蜻，就是更注重溝通，快速產(chǎn)出新版本早处，并且更適應(yīng)需求變更的的適合小團(tuán)體開(kāi)發(fā)的方法湾蔓。

下圖左方，是需求池的概念（比如jira中的backlog）砌梆，比如7%的需求是現(xiàn)實(shí)中大量客戶的需求默责，則我們將這7%的需求作為優(yōu)先級(jí)最高的需求。

下圖右方咸包，是迭代和反饋的概念桃序。

敏捷開(kāi)發(fā)中有敏捷宣言，可以更好地闡述敏捷開(kāi)發(fā)的概念诉儒。

1. 個(gè)體和互動(dòng)高于流程和工具（敏捷開(kāi)發(fā)的站會(huì)落實(shí)了這一點(diǎn)）
2. 工作的軟件高于詳盡的文檔（jira葡缰、miro等更好地代替厚重的需求文檔）
3. 客戶合作高于合同談判（公司內(nèi)各部門(mén)甩鍋情況，難道不應(yīng)該用合作為公司創(chuàng)造價(jià)值嗎）
4. 響應(yīng)變化高于遵循計(jì)劃（快速響應(yīng)時(shí)長(zhǎng)需求忱反，而不是錯(cuò)過(guò)市場(chǎng)變化）

1.3.1 Scrum實(shí)踐

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

1. Product Owner（產(chǎn)品負(fù)責(zé)人，主要負(fù)責(zé)產(chǎn)品設(shè)計(jì)温算，需求篩選等）
2. Scrum Master（敏捷主管怜校，主要負(fù)責(zé)項(xiàng)目迭代跟進(jìn)等）
3. Scrum Team（敏捷團(tuán)隊(duì)，主要負(fù)責(zé)需求的研發(fā)測(cè)試部署等注竿，包括Dev茄茁、Test、Ops等）

下圖左方是用戶故事（user story）,其實(shí)就是我們傳統(tǒng)意義上的需求巩割，只不過(guò)以一種需求方的更委婉擬人的語(yǔ)氣來(lái)講述該用戶人群的需求裙顽。

例如：我是一個(gè)買(mǎi)家，我希望我的購(gòu)物車(chē)能通過(guò)價(jià)格排序宣谈，這樣我就能根據(jù)我卡中的錢(qián)進(jìn)行合理的消費(fèi)愈犹。

下圖中部，則是Scrum的核心流程。有很多公司光注重了其中的流程（比如站會(huì)）漩怎，卻沒(méi)有得到其中的精髓勋颖。Scrum中把一個(gè)迭代叫做一個(gè)沖刺(Sprint)，這也是很多地方把計(jì)劃會(huì)議叫做沖刺會(huì)的由來(lái)勋锤，一般一個(gè)Sprint為1~4周饭玲。核心流程包括4個(gè)會(huì)議，如下所示：

1. 計(jì)劃會(huì)議（Product Owener叁执、Scrum Master茄厘、Scrum Team）

   1. 從Backlog中按照優(yōu)先級(jí)選擇這個(gè)Sprint要做的User Story
   2. 向團(tuán)隊(duì)解釋澄清User Story的需求，并決定是否將User Story拆解為更細(xì)粒度的Sub Task
   3. 團(tuán)隊(duì)估計(jì)User Story的Story Point（用以評(píng)估story的大小谈宛，有一種好玩的方式叫做Scrum Poker）
   4. 團(tuán)隊(duì)決定是否將User Story拆分Sub Task來(lái)進(jìn)行跟蹤
   5. 決定這個(gè)Sprint的目標(biāo)和交付的User Story

2. 每日站會(huì)（Product Owener（可選）蚕断、Scrum Master、Scrum Team）

   1. 站會(huì)維持在15分鐘以?xún)?nèi)入挣，分早晚
   2. 團(tuán)隊(duì)成員講述圍繞3點(diǎn)：我做了什么亿乳，我將要做什么，我遇到什么困難
   3. 每人陸續(xù)進(jìn)行講述径筏，為了快速響應(yīng)葛假，維持最新消息，包括需求調(diào)整等
   4. 以及進(jìn)行高效溝通滋恬，傳遞信息聊训，拒絕信息發(fā)散
   5. 確定相關(guān)問(wèn)題后，團(tuán)體相關(guān)人員小范圍討論

3. 評(píng)審會(huì)議（Product Owener恢氯、Scrum Master带斑、Scrum Team）

   1. 類(lèi)似于傳統(tǒng)意義上的驗(yàn)收階段
   2. 介紹Sprint結(jié)果，按User Story順序演示新功能
   3. 回答相關(guān)人員對(duì)展示的疑問(wèn)勋拟，并記錄其所期望的更改勋磕，收集反饋
   4. 如果遇到一些還沒(méi)解決的障礙，則將障礙加入障礙Backlog
   5. 以User Story作為是否成功交付的標(biāo)準(zhǔn)來(lái)評(píng)價(jià)任務(wù)完成情況

4. 回顧會(huì)議（Scrum Master敢靡、Scrum Team）

   1. 回顧這個(gè)Sprint挂滓，收集Sprint的相關(guān)數(shù)據(jù)
   2. 產(chǎn)生見(jiàn)解，多問(wèn)為什么啸胧，找到各個(gè)方面的優(yōu)缺點(diǎn)赶站，進(jìn)行復(fù)盤(pán)分析
   3. 進(jìn)行頭腦風(fēng)暴分析解決方案，投票選出下期的改進(jìn)項(xiàng)
   4. 探索提高效率和質(zhì)量的方式

1.3.2 極限編程（XP）實(shí)戰(zhàn)

極限編程是敏捷開(kāi)發(fā)中最具成效的幾種方法之一纺念，如同其他敏捷方法贝椿，它和傳統(tǒng)方法的本質(zhì)不同在于它更強(qiáng)調(diào)可適應(yīng)性能性以及面臨的困難。

它的基礎(chǔ)和價(jià)值觀是：

1. 交流（加強(qiáng)交流陷谱，解決信息不同步導(dǎo)致的問(wèn)題）
2. 樸素（秉持最小可用烙博，勤于迭代，不做拍腦袋的無(wú)用功擴(kuò)展）
3. 反饋（多接受反饋，以進(jìn)行快速調(diào)整修改）
4. 勇氣（在該重構(gòu)時(shí)重構(gòu)习勤，當(dāng)狀態(tài)不對(duì)時(shí)，放棄思考焙格，調(diào)整狀態(tài)后重新思考）

它認(rèn)為任何一個(gè)軟件項(xiàng)目都可以從四個(gè)方面入手進(jìn)行改善：加強(qiáng)交流图毕；從簡(jiǎn)單做起；尋求反饋眷唉；勇于實(shí)事求是予颤。

下圖是極限編程的13個(gè)最佳實(shí)踐。

1.3.3 思考自己的團(tuán)隊(duì)是不是敏捷

問(wèn)問(wèn)自己下面的幾個(gè)問(wèn)題：

1. 成員是否氫氣的知道團(tuán)隊(duì)的目標(biāo)冬阳？
2. 成員是否可以預(yù)測(cè)結(jié)果并且充滿信心蛤虐？
3. 成員是否主動(dòng)做事并且為此負(fù)責(zé)？
4. 成員是否愿意持續(xù)改進(jìn)團(tuán)隊(duì)肝陪？

如果你對(duì)上述幾個(gè)問(wèn)題的回答時(shí)肯定的驳庭，那么恭喜你，你們的團(tuán)隊(duì)是關(guān)注發(fā)展的敏捷團(tuán)隊(duì)氯窍，如果你對(duì)上述問(wèn)題有部分或全部否定饲常，那么你可能需要調(diào)整你的團(tuán)隊(duì)，你們只不過(guò)是在關(guān)注敏捷的形式狼讨，而沒(méi)有精髓贝淤。

1.4 DevOps模型

DevOps是一種開(kāi)發(fā)、測(cè)試和運(yùn)維之間文化溝通政供，通過(guò)自動(dòng)化的方式來(lái)進(jìn)行軟件交付和架構(gòu)變更的流程播聪，使構(gòu)建、測(cè)試布隔、發(fā)布軟件能更快捷离陶、頻繁、可靠衅檀。它的出現(xiàn)是因?yàn)檐浖饾u的認(rèn)識(shí)到枕磁，開(kāi)發(fā)、測(cè)試和運(yùn)維的緊密合作可以更好的交付軟件產(chǎn)品和服務(wù)术吝。

下圖是DevOps的標(biāo)準(zhǔn)化流程计济，通過(guò)建立一個(gè)完備的團(tuán)隊(duì)來(lái)建立一條IT服務(wù)供應(yīng)鏈，通過(guò)自動(dòng)化實(shí)現(xiàn)高效率交付排苍，不固定需求管理沦寂、工具鏈等，只專(zhuān)注于持續(xù)的穩(wěn)定的價(jià)值交付

2 三部工作法

2.1 第一工作法（工作流）

這一步工作法是關(guān)于從開(kāi)發(fā)到運(yùn)再到客戶的自左向右的工作流

2.1.1 定義工作流

下圖展示了自循環(huán)工作流的流程淘衙，其中前4項(xiàng)屬于Dev范疇传藏，后4項(xiàng)屬于Ops范疇：

1. plan（計(jì)劃）
2. code（編碼）
3. build（構(gòu)建）
4. test（測(cè)試）
5. release（發(fā)布）
6. deploy（部署）
7. operate（操作）
8. monitor（監(jiān)控）

2.1.2 工作流實(shí)踐

下圖左方是我們針對(duì)上面的工作流的一種實(shí)踐，是一種工作日志的方式，這種工作方式同樣適用于敏捷開(kāi)發(fā)（jira中的工作日志）毯侦，其實(shí)DevOps的本質(zhì)就是敏捷開(kāi)發(fā)哭靖。

1. 過(guò)程名稱(chēng)
2. 輸入
3. 輸出
4. 工具
5. DoD（Definition of Done，完成的定義侈离，可以理解為完成的標(biāo)準(zhǔn)）
6. 平均前置任務(wù)等待數(shù)（完成當(dāng)前任務(wù)试幽，依賴(lài)等待了多少任務(wù)）
7. 手工比例（手工操作的步驟占據(jù)了總量多少）
8. %C/A（返工指標(biāo)，完成時(shí)間/總花費(fèi)時(shí)間卦碾，總花費(fèi)時(shí)間=完成時(shí)間+修復(fù)時(shí)間）
9. 處理時(shí)間PT(真正處理該任務(wù)所花費(fèi)的時(shí)間)
10. 流動(dòng)時(shí)間FT（從接收到需求到需求完成所花費(fèi)的時(shí)間）

通過(guò)上方工作日志所記錄的數(shù)據(jù)铺坞，我們可以對(duì)我們的工作進(jìn)行階段性的分析，比如：

1. 平均前置任務(wù)等待數(shù)可以用來(lái)判斷我們的任務(wù)分配是否合理
2. 手工比例可以用來(lái)提示我們是否需要使用自動(dòng)化來(lái)優(yōu)化流程
3. %C/A可以用來(lái)判斷一個(gè)人的工作質(zhì)量是否需要優(yōu)化
4. 等等

2.1.3 版本和分支策略

2.1.3.1 普通版本管理

1. 新需求拉一條新的分支進(jìn)行開(kāi)發(fā)洲胖，命名xxx feature branch
2. 新bug拉一條新的分支進(jìn)行修復(fù)济榨，命名xxx fix branch
3. master分支保持永遠(yuǎn)可構(gòu)建成功狀態(tài)
4. 每當(dāng)新需求或新bug完成合并到主分支，觸發(fā)主分支的pipeline構(gòu)建流程

2.1.3.2 GitFLow實(shí)踐

這種方案是基于GitFLow的標(biāo)準(zhǔn)來(lái)進(jìn)行版本控制的绿映。

該方案采用develop擒滑、feature、hotfix叉弦、release橘忱、prod等分支進(jìn)行實(shí)踐，比較適合版本并存的團(tuán)隊(duì)

1. develop：主開(kāi)發(fā)分支卸奉，包含所有發(fā)布到下一個(gè)release的代碼
2. feature：新功能開(kāi)發(fā)分支钝诚，最后會(huì)合并回develop分支
3. hotfix：prod發(fā)現(xiàn)bug時(shí)，用來(lái)熱修復(fù)分支榄棵，最后會(huì)合并回develop分支
4. release：發(fā)布版本時(shí)凝颇，基于develop創(chuàng)建的分支
5. prod: 用于發(fā)布到生產(chǎn)環(huán)境的代碼的分支，只能合并不能修改疹鳄。

這種方式很靈活拧略，代碼隔離也很好，只是過(guò)于繁瑣瘪弓。

2.1.3.3 tag版本實(shí)踐

該方案是基于版本打tag的方式來(lái)進(jìn)行版本控制的垫蛆。

該方案采用master、feature腺怯、fix等分支進(jìn)行實(shí)踐袱饭，比較適合小版本滾動(dòng)升級(jí)團(tuán)隊(duì)

1. master：主分支，該分支不允許修改呛占，只允許合并虑乖，該分支永遠(yuǎn)保持可構(gòu)建狀態(tài)，發(fā)布時(shí)通過(guò)tag來(lái)進(jìn)行版本發(fā)布
2. feature：新功能開(kāi)發(fā)分支晾虑，最后會(huì)合并回master分支
3. fix：線上發(fā)生bug后疹味，用于修復(fù)的分支最終會(huì)合并到master分支

這種方式很簡(jiǎn)單仅叫，但是對(duì)多環(huán)境的支持不是很好。

我們推薦使用GitFlow+Tag的方式來(lái)進(jìn)行版本控制糙捺。以觸發(fā)多環(huán)境下的pipeline自動(dòng)化流程诫咱。

2.1.4 規(guī)劃流水線

這里主要是我們的CI/CD的流水線的結(jié)構(gòu)，可已使用Jenkins的pipeline也可以使用Gitlab的pipeline洪灯。

這里鏈接下之前寫(xiě)的Jenkinsfile教程（Jenkins Pipeline 教程）

自動(dòng)：

1. 代碼檢測(cè)（推薦使用SonarQube坎缭，教程）
2. 單元測(cè)試（很重要，java可使用junit婴渡，其他的未調(diào)研）
3. 制品（過(guò)去的jar包，如今的docker image）
4. 集成測(cè)試（很重要凯亮，屬于自動(dòng)化測(cè)試中的一個(gè)重要環(huán)節(jié)）
5. 性能測(cè)試（大部分場(chǎng)景下可能不會(huì)每次都做）
6. 安全測(cè)試（跟性能測(cè)試差不多）
7. 部署預(yù)發(fā)布（這里泛指線上以下的所有環(huán)境）

手動(dòng)：

1. 驗(yàn)收測(cè)試
2. 部署線上

2.1.5 Scrum+XP+DevOps流程

看過(guò)了上面的部分边臼，你一定嗤之以鼻，因?yàn)橄旅娴膱D其實(shí)就是上面的Scrum圖+Pipeline的圖假消。其實(shí)下面你的這張圖才能真正意義上的指導(dǎo)我們?nèi)绾卧诠ぷ髦袑?shí)踐Scrum+DevOps柠并。我將下面的圖分層了4塊，讓我們一起看看下面的圖吧

Scrum+XP流程

第一部分的需求池的這個(gè)概念我們?cè)谏戏降腟crum中已經(jīng)看到了富拗，在這里不做詳細(xì)解釋?zhuān)绻洸惶辶司视瑁梢曰氐缴戏?1.3.1 進(jìn)行復(fù)習(xí)。

第二部分的Scrum流程需要我們?cè)賮?lái)回顧一下啃沪，一個(gè)迭代中的4個(gè)會(huì)議還記得嗎粘拾，不記得就回去看看吧，通過(guò)小迭代來(lái)進(jìn)行可持續(xù)的速度小型發(fā)布创千，其中要落實(shí)XP的13個(gè)實(shí)踐缰雇，包括集體所有權(quán)、簡(jiǎn)單設(shè)計(jì)追驴、重構(gòu)等等械哟。

CI/CD

通過(guò)代碼版本控制來(lái)觸發(fā)我們的的CI和CD的構(gòu)建。

通過(guò)發(fā)布編碼標(biāo)準(zhǔn)殿雪，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)暇咆，代碼riew等來(lái)提升我們的代碼質(zhì)量以進(jìn)行優(yōu)質(zhì)的代碼持續(xù)集成。

在持續(xù)集成之后丙曙，迎面而來(lái)的是構(gòu)建爸业、測(cè)試、部署亏镰，這幾個(gè)步驟的才是真真正的表現(xiàn)我們的團(tuán)隊(duì)的持續(xù)交付的質(zhì)量沃呢。

在3和4兩個(gè)步驟，我們會(huì)看到下方有包含對(duì)號(hào)和錯(cuò)號(hào)的表格拆挥，這個(gè)我們會(huì)在接下來(lái)的地方講到薄霜，這個(gè)是個(gè)CI/CD反饋表某抓，用來(lái)表示我們某個(gè)階段的CI/CD的縮略情況，可以通過(guò)這個(gè)反饋來(lái)進(jìn)行相關(guān)的分析惰瓜。

2.2 第二工作法（反饋流）

2.2.1 持續(xù)反饋

下方的圖是CI/CD的持續(xù)反饋圖否副，可能做過(guò)Jenkins的Pipeline的小伙伴已經(jīng)能看出它了。

頂部的“表頭”其實(shí)就是我們的Pipeline的流程崎坊，而每一行是我們的歷史構(gòu)建記錄备禀，通過(guò)這張圖我們可以清洗的看到我們?cè)谀骋浑A段的pipeline的執(zhí)行情況，就可以看到我們?cè)谀囊粋€(gè)節(jié)點(diǎn)發(fā)生錯(cuò)誤的情況比較高奈揍。

在這個(gè)流程中最重要的就是測(cè)試部分曲尸，如果我們的團(tuán)隊(duì)對(duì)包括單元測(cè)試在內(nèi)的測(cè)試環(huán)節(jié)如果不是很重視，那這個(gè)反饋將對(duì)我們的團(tuán)隊(duì)毫無(wú)意義男翰。

在DevOps中另患，我們推崇測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，通過(guò)先寫(xiě)單元測(cè)試蛾绎，集成測(cè)試等用例來(lái)驅(qū)動(dòng)我們的開(kāi)發(fā)進(jìn)行編碼昆箕。

2.2.2 查看在制品

這里的制品的含義就是我們所構(gòu)建的，比如java的jar租冠，golang的native鹏倘，docker的docker image等。

通過(guò)DevOps的反饋顽爹，我們可以查看制品所在的story的目前階段

2.3 第三工作法（學(xué)習(xí)）

2.3.1 不斷嘗試和重復(fù)學(xué)習(xí)

讓我們?cè)賮?lái)看下面這張圖纤泵，對(duì)比上面的那種圖，在我們的編碼镜粤、測(cè)試夕吻、部署三個(gè)階段多了個(gè)小錘子的標(biāo)志。

這里的編碼繁仁、測(cè)試涉馅、部署，分別代表著開(kāi)發(fā)黄虱、測(cè)試稚矿、運(yùn)維，三個(gè)崗位需要不斷的嘗試捻浦、配合和重復(fù)學(xué)習(xí)來(lái)讓這條IT服務(wù)供應(yīng)鏈更快速更穩(wěn)定更自動(dòng)化晤揣，讓信息反饋更精準(zhǔn)、更全面的覆蓋到整個(gè)服務(wù)生命周期朱灿。

2.3.2 測(cè)試四象限

首先畫(huà)一個(gè)由x軸支持評(píng)價(jià)和y軸業(yè)務(wù)技術(shù)導(dǎo)向組成的四象限昧识，我們將我們DevOps中的所有種類(lèi)的測(cè)試流程放入其中，來(lái)將每一個(gè)測(cè)試落實(shí)在一個(gè)二維區(qū)間內(nèi)盗扒，再在每一種測(cè)試上標(biāo)識(shí)一個(gè)工作投入程度跪楞，組成下面的圖缀去。

我們之前提過(guò)，在XP極限開(kāi)發(fā)中甸祭，我們推崇測(cè)試驅(qū)動(dòng)開(kāi)發(fā)缕碎，因?yàn)闇y(cè)試驅(qū)動(dòng)開(kāi)發(fā)可以讓我們?cè)陂_(kāi)發(fā)之前更加深入的理解業(yè)務(wù)，并且基于接口定義程序池户，更好的組織我們的軟件架構(gòu)咏雌。

所以下圖是我們的測(cè)試流程應(yīng)在我們的工作中所占有的工作比例，如果所有的工作經(jīng)歷為100%的話校焦，那么6顆星則為60%赊抖，每顆星占據(jù)10%。

良好的開(kāi)發(fā)習(xí)慣寨典，和標(biāo)準(zhǔn)的測(cè)試流程可以讓我們的代碼質(zhì)量更上一層樓氛雪。

2.3.3 運(yùn)維四象限

上面我們說(shuō)了測(cè)試的四象限，這里我們說(shuō)說(shuō)運(yùn)維的四象限凝赛，我們以緊急性為x軸注暗，重要性為y軸坛缕，這個(gè)四象限其實(shí)是很多工種的人都會(huì)使用到的墓猎，會(huì)將我們每天的任務(wù)放到里面，用來(lái)確定任務(wù)的優(yōu)先級(jí)赚楚，我們知道基于這種四象限毙沾，我們的優(yōu)先級(jí)會(huì)有下方四種：

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

我們將運(yùn)維的工作放在上面，如果大部分的工作都落實(shí)在緊急且重要的第一象限上的話宠页，那么說(shuō)明我們的DevOps流程是有問(wèn)題的左胞，比如我們的運(yùn)維的大部分精力都在每天的線上緊急修復(fù)之類(lèi)的任務(wù)，就說(shuō)明我們的開(kāi)發(fā)和測(cè)試的質(zhì)量是有問(wèn)題的举户。

運(yùn)維的工作不應(yīng)該重點(diǎn)在右方烤宙，而應(yīng)該重心左移，偏向于重要不緊急俭嘁，多做一些規(guī)劃性的工作躺枕，比如從傳統(tǒng)部署方式轉(zhuǎn)向k8s容器編排等工作。

3 工程化指南

3.1 實(shí)踐整合

在上面我們將上面說(shuō)講述的知識(shí)合并起來(lái)供填，組成我們真正在工作中實(shí)踐所要用到的東西拐云。Scrum+XP+DevOps

3.2 建立工程師文化模型

小團(tuán)隊(duì)內(nèi)部要做到：

1. 可視化面板和主動(dòng)領(lǐng)取任務(wù)(信息扁平化，加速效率近她，共同目標(biāo)幫助隊(duì)友完成任務(wù))
2. 成為用戶故事的負(fù)責(zé)人（每個(gè)人都要有主人翁意識(shí)叉瘩，認(rèn)為自己是UserStory的主人）
3. 20%的非功能性需求（給開(kāi)發(fā)一點(diǎn)非業(yè)務(wù)的技術(shù)需求，提升多巴胺粘捎，產(chǎn)生樂(lè)趣）
4. 合入主干的代碼需要審核（合代碼需要組內(nèi)review薇缅，降低代碼出問(wèn)題的概率）
5. 周期性的技術(shù)分享（每個(gè)人都要分享危彩，對(duì)自己所學(xué)到的東西進(jìn)行沉淀，同時(shí)也吸取組內(nèi)其他人的分享）

公司級(jí)別：

1. 舉辦黑客馬拉松（選擇一個(gè)主題捅暴，讓公司的開(kāi)發(fā)進(jìn)行參與恬砂，進(jìn)行開(kāi)發(fā)，討論蓬痒，提升技術(shù)激情）
2. 舉辦技術(shù)沙龍

3.3 目錄結(jié)構(gòu)

定義每種語(yǔ)言的標(biāo)準(zhǔn)的目錄結(jié)構(gòu)泻骤，比如下方的目錄結(jié)構(gòu)就是Node.js的標(biāo)準(zhǔn)目錄結(jié)構(gòu)，我將一些語(yǔ)言級(jí)通用的結(jié)構(gòu)用紅框畫(huà)了出來(lái)梧奢。

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

3.4 版本控制規(guī)劃

下圖使用的是基于Tag的版本控制狱掂，我這里看推薦使用GitFLow+Tag的方式來(lái)進(jìn)行基于Tag多多環(huán)境的版本控制的方式進(jìn)行構(gòu)建使用。

3.5 快速失敗的流水線

下圖中的快速失敗的概念是指當(dāng)pipeline中某一節(jié)點(diǎn)未達(dá)到通過(guò)的要求亲轨，則不再運(yùn)行之后得節(jié)點(diǎn)趋惨，以當(dāng)前節(jié)點(diǎn)的失敗為整個(gè)pipeline的失敗。

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

3.6 可視化反饋平臺(tái)

在第二工作法中蹦锋，我們學(xué)習(xí)到了反饋工作流兆沙，如果使用jenkins構(gòu)建pipeline的時(shí)候，我們就可以通過(guò)jenkins原生支持的可視化結(jié)果來(lái)了解到我們近期的CI/CD情況莉掂。

3.7 持續(xù)改進(jìn)

在我們的產(chǎn)品設(shè)計(jì)中葛圃，有一個(gè)MVP的概念，它的意思是最小可行產(chǎn)品憎妙，這個(gè)概念來(lái)自于《精益創(chuàng)業(yè)：新創(chuàng)企業(yè)的成長(zhǎng)思維》這本書(shū)中库正，書(shū)中提倡首先定義一個(gè)面向市場(chǎng)的最小可用的極簡(jiǎn)原型產(chǎn)品，然后再不斷的試驗(yàn)和學(xué)習(xí)中厘唾，以最小的成本和最有效的方式來(lái)驗(yàn)證產(chǎn)品是否符合用戶需求褥符，靈活調(diào)整方向，以達(dá)到“快速失敗抚垃，廉價(jià)失敗”的方式來(lái)驗(yàn)證產(chǎn)品是否符合市場(chǎng)需求喷楣。這是一種不斷學(xué)習(xí)，挖掘用戶需求讯柔，迭代優(yōu)化產(chǎn)品的方式抡蛙。

我們對(duì)待我們的團(tuán)隊(duì)，其實(shí)也要像對(duì)待我們的產(chǎn)品一樣魂迄，不停地學(xué)習(xí)粗截，不停地嘗試，不停地優(yōu)化捣炬，這樣讓我們的團(tuán)隊(duì)快速成長(zhǎng)熊昌，要允許我們的團(tuán)隊(duì)犯錯(cuò)（但是不能重復(fù)掉進(jìn)相同或相似的坑中）绽榛。

3.8 更多的質(zhì)量保證

3.8.1 CI/CCD

通過(guò)良好的測(cè)試+自動(dòng)化流水線來(lái)提高我們的代碼的質(zhì)量

在部署前：

1. 集成測(cè)試
2. 性能測(cè)試
3. 安全性測(cè)試

部署后測(cè)試：

1. 自動(dòng)化測(cè)試
2. 驗(yàn)收測(cè)試

3.8.2 環(huán)境與配置管理

通過(guò)配置中心來(lái)區(qū)別應(yīng)用在各個(gè)環(huán)境中的配置，以防止出現(xiàn)踩到帶著開(kāi)發(fā)測(cè)試的配置上線的這種老舊坑婿屹。

3.8.3 制品庫(kù)管理

制品庫(kù)推薦也同樣隔離開(kāi)灭美，預(yù)發(fā)和生產(chǎn)使用同一個(gè)制品庫(kù)，開(kāi)發(fā)和測(cè)試使用同一個(gè)制品庫(kù)昂利，在兩個(gè)制品庫(kù)之間届腐，需要人為來(lái)審核和同步。

3.8.4 流程控制

這里的流程控制主要指的是CI/CD的流程控制蜂奸。因?yàn)槲覀兌贾纉enkins單節(jié)點(diǎn)在同一時(shí)間自由一個(gè)pipeline能構(gòu)建犁苏，也就是說(shuō)單節(jié)點(diǎn)jenkins不能多條pipeline并發(fā)構(gòu)建。所以我們需要搭建分布式的jenkins集群扩所，來(lái)對(duì)pipeline的構(gòu)建進(jìn)行調(diào)度围详。

另一種更好的方式就是通過(guò)gitlab或其他支持并發(fā)pipeline構(gòu)建的工具進(jìn)行構(gòu)建。

下方的pipeline中在測(cè)試環(huán)節(jié)分成了三個(gè)分支祖屏，這個(gè)特性我們?cè)偈褂胘enkins的pipeline時(shí)是有完美支持的助赞，名字叫并行流，是根據(jù)條件來(lái)判斷三個(gè)分支是否進(jìn)行的袁勺。

3.8.5 數(shù)據(jù)收集和監(jiān)控

我們的服務(wù)上線后雹食，我們需要使用兩種方式來(lái)確保我們線上使用的服務(wù)能夠健康的提供服務(wù)。

1. 日志
2. 監(jiān)控

通過(guò)采集我們的線上的服務(wù)的日志魁兼，來(lái)對(duì)線上日志進(jìn)行分析婉徘，達(dá)到實(shí)時(shí)監(jiān)控服務(wù)健康情況的需求漠嵌。這里推薦使用市場(chǎng)較為開(kāi)放通用的開(kāi)源方案ELK

我們同時(shí)還要對(duì)我們的中間件咐汞，流量，物理硬件等進(jìn)行相關(guān)監(jiān)控儒鹿，以確定基礎(chǔ)環(huán)境的實(shí)時(shí)監(jiān)控情況化撕，這里我推薦使用Prometheus+Granfa進(jìn)行監(jiān)控。

3.8.6 容災(zāi)

當(dāng)我們的應(yīng)用日益復(fù)雜且用戶量逐漸提高后约炎，我們需要對(duì)我們的服務(wù)進(jìn)行容災(zāi)配置以及周期醒的混沌工程演練植阴。我們的服務(wù)應(yīng)該像下圖一樣逐漸進(jìn)階為可用性更高的部署方式。

3.8.7 緊急事件處理

我們永遠(yuǎn)都不能問(wèn)心無(wú)愧的拍著胸口說(shuō)我們的服務(wù)非常的問(wèn)題圾浅，可用性能達(dá)到100%掠手。因?yàn)?00%是我們的服務(wù)的可用性極限，就算我們的服務(wù)可用性做到6個(gè)9狸捕，8個(gè)9喷鸽，但是永遠(yuǎn)也達(dá)不到100%，永遠(yuǎn)只能無(wú)限的趨近于100%灸拍。因?yàn)槲覀冇肋h(yuǎn)都沒(méi)辦法避免黑天鵝事件做祝。但是我們能做的是出現(xiàn)黑天鵝事件后砾省，我們要快速響應(yīng)，將我們的損失降到最低混槐。下面就說(shuō)說(shuō)當(dāng)出現(xiàn)線上故障的時(shí)候编兄，我們應(yīng)該怎么做才能更好的減少我們的損失。

事故發(fā)生前（凡事有預(yù)案）:

1. 提前準(zhǔn)備可能出現(xiàn)的事故
2. 全員參與容災(zāi)演練
3. 多做混沌工程声登，提高服務(wù)的可用性和健壯性

事故發(fā)生時(shí)（先通報(bào)狠鸳，后處理）：

1. Ops和Dev相互通報(bào)
2. Ops和Dev各自向上級(jí)匯報(bào)
3. 主管決定是否繼續(xù)向上級(jí)匯報(bào)

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

1. 是否有處理預(yù)案
2. 有預(yù)案悯嗓，Ops主管10分鐘內(nèi)做回滾決定
3. 無(wú)預(yù)案碰煌，Ops主管和Dev主管決定回滾和補(bǔ)救方案

事故處理后（反思，定級(jí)）：

1. Ops通報(bào)事故處理結(jié)果
2. 24小時(shí)內(nèi)主要責(zé)任部門(mén)牽頭矩形Case Study
3. 對(duì)事故進(jìn)行定級(jí)

本文來(lái)自納蘭小筑绅作，本文不予回復(fù)芦圾，評(píng)論請(qǐng)追溯原文
查看原文