詳解~前端人需要了解的DevOps

DevOps 日漸成為研發(fā)人員耳熟能詳?shù)囊粋€(gè)組合詞，但什么是 DevOps，為什么 DevOps 對(duì)于互聯(lián)網(wǎng)企業(yè)如此重要，真正將其思考透徹的人卻不多，帶著這些困惑，本文將帶你一探 DevOps 的起源、原則和實(shí)踐，讓你搞清楚到底何為 DevOps。

DevOps 的起源可以追溯到 2008 年，在一次敏捷大會(huì)的敏捷基礎(chǔ)設(shè)施話題組被提及，從起源我們可以了解到 DevOps 的發(fā)展跟敏捷軟件開發(fā)是密不可分的。

DevOps 定義

DevOps 經(jīng)過(guò)這些年的發(fā)展，其定義也在不斷變化，先來(lái)看三段 DevOps 的 wiki 定義。

1. DevOps 2017 - 2020 年英文 wiki 定義（直譯）

?

DevOps是一種「軟件工程文化和實(shí)踐（Practices）」，旨在整合軟件開發(fā)和軟件運(yùn)維。DevOps運(yùn)動(dòng)的主要特點(diǎn)是強(qiáng)烈倡導(dǎo)對(duì)構(gòu)建軟件的所有環(huán)節(jié)（從集成、測(cè)試、發(fā)布到部署和基礎(chǔ)架構(gòu)管理）進(jìn)行全面的自動(dòng)化和監(jiān)控 DevOps 的目標(biāo)是縮短開發(fā)周期，提高部署頻率和更可靠地發(fā)布，與業(yè)務(wù)目標(biāo)保持一致。

?

2. DevOps 2021 年英文 wiki 定義（直譯）

?

DevOps 是一系列整合軟件開發(fā)和軟件運(yùn)維活動(dòng)的「實(shí)踐（Practices）」。目標(biāo)是縮短軟件開發(fā)生命周期并使用持續(xù)交付提供高質(zhì)量的軟件。

?

另：

?

DevOps 與敏捷軟件開發(fā)是互補(bǔ)關(guān)系，DevOps 的許多方面來(lái)自于敏捷方法論。

?

3. DevOps 中文 wiki 定義

?

DevOps（Development和Operations的組合詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運(yùn)維技術(shù)人員（Ops）”之間「溝通合作」的文化、運(yùn)動(dòng)或慣例。透過(guò)自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，來(lái)使得構(gòu)建、測(cè)試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。

?

提取這三段的共同點(diǎn)，可以看到不論定義如何變化，DevOps 所要實(shí)現(xiàn)的目標(biāo)都是一致的——縮短軟件開發(fā)生命周期并使用 「持續(xù)交付」 提供高質(zhì)量的軟件。由于持續(xù)交付活動(dòng)中包含了構(gòu)建、測(cè)試和發(fā)布等活動(dòng)，我更傾向于用這個(gè)定義，可以更好地縮減定義長(zhǎng)度。

另外可以看到英文直接翻譯過(guò)來(lái)的定義中都包含「「實(shí)踐」」 一詞，而中文 wiki 經(jīng)過(guò)一定的翻譯或本地化后變成了「「文化、運(yùn)動(dòng)或慣例」」，其還更強(qiáng)調(diào)開發(fā)運(yùn)維之間 「溝通合作」 這一點(diǎn)，因此將最新的英文 wiki 定義與中文 wiki 定義相結(jié)合，可以幫助我們更好地理解 DevOps，那么它的最終定義是什么就交由讀者朋友自己去領(lǐng)會(huì)吧。

DevOps 發(fā)展背景

為什么 DevOps 會(huì)如此熱門，時(shí)常被人所提及，這與其發(fā)展背景是分不開的，主要原因可以概括為以下幾點(diǎn)：

1. 敏態(tài)需求的增加，即探索性工作的增加；
• 軟件開發(fā)從傳統(tǒng)的瀑布流方式到敏捷開發(fā)，再到現(xiàn)在對(duì)敏捷開發(fā)提出了更高的要求，近些年創(chuàng)新型的應(yīng)用不斷涌現(xiàn)，在這些應(yīng)用的研發(fā)過(guò)程中多采用小步快跑、快速試錯(cuò)的方式，這些探索性工作要求運(yùn)維能夠具備一天發(fā)布多次的能力，需要企業(yè)完成由穩(wěn)態(tài)到敏態(tài)的轉(zhuǎn)變。
2. 軟件開發(fā)活動(dòng)在企業(yè)經(jīng)營(yíng)活動(dòng)中占比的不斷增加；
• 業(yè)務(wù)發(fā)展對(duì)軟件的依賴由輕度依賴、中度依賴發(fā)展到目前的重度依賴。
3. 企業(yè)存在對(duì)消除浪費(fèi)的需求。
• 軟件開發(fā)活動(dòng)在企業(yè)中的位置越來(lái)越重要，而像企業(yè)經(jīng)營(yíng)活動(dòng)一樣，軟件開發(fā)活動(dòng)中也存在著許多的浪費(fèi)，企業(yè)管理上必然存在著 「識(shí)別并消除浪費(fèi)」 的需求。
• 軟件開發(fā)中的浪費(fèi)包括不必要和必要的浪費(fèi)，不必要的浪費(fèi)有：無(wú)人使用的功能、軟件bug、等待測(cè)試、等待審批等；必要的浪費(fèi)包括：工作項(xiàng)移交、測(cè)試、項(xiàng)目管理等。

以上主要從企業(yè)的角度說(shuō)明了 DevOps 的發(fā)展，這是較為深層次的原因，表層的推動(dòng)因素包括：容器化技術(shù)的發(fā)展、微服務(wù)架構(gòu)的發(fā)展等等，這些技術(shù)上的創(chuàng)新為 DevOps 提供了良好的發(fā)展條件，以解決企業(yè)面臨的這些問(wèn)題。

DevOps 原則與實(shí)踐

了解了什么是 DevOps 及其發(fā)展原因后，又該如何具體的進(jìn)行 DevOps 實(shí)踐，我們采用黃金圈法則來(lái)思考這一問(wèn)題。

DevOps 原則是總體指導(dǎo)思想，實(shí)踐是具體的執(zhí)行方法，DevOps 是一個(gè)動(dòng)態(tài)的過(guò)程，在進(jìn)行相關(guān)實(shí)踐的時(shí)候可以看看其應(yīng)用了哪些原則，當(dāng)違背原則的時(shí)候需要思考實(shí)踐的合理性。

DevOps 原則

DevOps 包含以下三大原則：

1. 流動(dòng)原則：「加速」 從開發(fā)、運(yùn)維到交付給客戶的流程；
2. 反饋原則：建設(shè) 「安全可靠」 的工作體系；
3. 持續(xù)學(xué)習(xí)與實(shí)驗(yàn)原則：采用科學(xué)的工作方式，將對(duì)組織的 「改進(jìn)和創(chuàng)新」 作為工作的一部分。

流動(dòng)原則

1. 堅(jiān)持少做
• 產(chǎn)品開始開發(fā)時(shí)采用 MVP 原則。
• 產(chǎn)品迭代時(shí)要適時(shí)做減法。
2. 持續(xù)分解問(wèn)題
• 大的變更或需求拆解為一系列小的變更，快速解決。
3. 工作可視化
• 采用 Sprint 看板將工作可視化。
4. 控制任務(wù)數(shù)量
• 減少前置時(shí)間，降低測(cè)試人員的等待時(shí)間。
• 任務(wù)越多，預(yù)估越不準(zhǔn)確。
5. 減少交接次數(shù)
• 減少不必要的溝通和等待。
6. 持續(xù)識(shí)別和改善約束點(diǎn)
• 識(shí)別出影響流動(dòng)的主要前置因素，比如搭建環(huán)境、需求文檔。
• QA、開發(fā)、運(yùn)維、產(chǎn)品持續(xù)提升生產(chǎn)力。
• 為非功能性需求預(yù)留20%的開發(fā)時(shí)間，減少技術(shù)債務(wù)。
7. 消除價(jià)值流中的困境和浪費(fèi)（導(dǎo)致交付延遲的主要因素）
• 半成品——未完全完成的工作。
• 額外工序——從不使用的文檔、重復(fù)編寫接口文檔等。
• 額外功能——用戶實(shí)際不需要的功能。
• 任務(wù)切換——將人員分配到多個(gè)項(xiàng)目或截然不同的工作任務(wù)中。
• 等待、移動(dòng)、缺陷、非標(biāo)準(zhǔn)化的手動(dòng)操作。

反饋原則

1. 在復(fù)雜系統(tǒng)中安全地工作
• 管理復(fù)雜的工作，識(shí)別出設(shè)計(jì)和操作的問(wèn)題；
• 群策群力解決問(wèn)題，從而快速構(gòu)建新知識(shí)；
• 在整個(gè)組織中，將區(qū)域性的知識(shí)應(yīng)用到全局范圍；
• 領(lǐng)導(dǎo)者要持續(xù)培養(yǎng)有以上才能的人。
2. 及時(shí)發(fā)現(xiàn)問(wèn)題
• 快速、頻繁和高質(zhì)量的信息流——每個(gè)工序的操作都會(huì)被度量和監(jiān)控。
• 技術(shù)價(jià)值流的每個(gè)階段（產(chǎn)品管理、開發(fā)、QA、安全、運(yùn)維），建立快速的反饋和前饋回路（包括自動(dòng)化構(gòu)建、集成和測(cè)試過(guò)程）。
• 全方位的遙測(cè)系統(tǒng)。
3. 在源頭保障質(zhì)量
• 過(guò)多的檢查和審批流程，使得做決策的地方遠(yuǎn)離執(zhí)行工作的地方，這導(dǎo)致流程有效性降低，減弱了因果關(guān)系之間反饋的強(qiáng)度。
• 讓開發(fā)人員也對(duì)系統(tǒng)質(zhì)量負(fù)責(zé)，快速反饋，加速開發(fā)人員的學(xué)習(xí)。
4. 為內(nèi)部客戶優(yōu)化工作
• 運(yùn)維的非功能性需求（如架構(gòu)、性能、穩(wěn)定性、可測(cè)試性、可配置性和安全性）與用戶功能同樣重要。

持續(xù)學(xué)習(xí)與實(shí)驗(yàn)原則

1. 建立學(xué)習(xí)型組織和安全文化
2. 將日常工作的改進(jìn)制度化
3. 把局部發(fā)現(xiàn)轉(zhuǎn)化為全局優(yōu)化
4. 在日常工作中注入彈性模式
• 縮短部署的前置時(shí)間、提高測(cè)試覆蓋率、縮短測(cè)試執(zhí)行時(shí)間，甚至在必要時(shí)解耦架構(gòu)，都屬于在系統(tǒng)中引入類似張力的做法。
5. 領(lǐng)導(dǎo)層強(qiáng)化學(xué)習(xí)文化
• 領(lǐng)導(dǎo)者幫助一線工作者在日常工作中發(fā)現(xiàn)并解決問(wèn)題。

DevOps 實(shí)踐

基于 DevOps 的相關(guān)原則，有與其對(duì)應(yīng)的實(shí)踐，包括：流動(dòng)的技術(shù)實(shí)踐、反饋的技術(shù)實(shí)踐和持續(xù)學(xué)習(xí)與實(shí)驗(yàn)的技術(shù)實(shí)踐。在應(yīng)用這些實(shí)踐之前還需認(rèn)真設(shè)計(jì)組織結(jié)構(gòu)，使其有利于實(shí)踐的開展。

設(shè)計(jì)組織結(jié)構(gòu)

• 利用康威定律設(shè)計(jì)團(tuán)隊(duì)結(jié)構(gòu)。
• 康威定律：軟件的架構(gòu)和軟件團(tuán)隊(duì)的結(jié)構(gòu)是一致的。
• 軟件的架構(gòu)應(yīng)該保證小團(tuán)隊(duì)能夠獨(dú)立運(yùn)作，彼此充分解耦，從而避免過(guò)多不必要的溝通和協(xié)調(diào)。
• 過(guò)度職能導(dǎo)向（成本優(yōu)化）的危害。
• 執(zhí)行工作的人通常不理解自己的工作與價(jià)值流目標(biāo)的關(guān)系（“我之所以要配置這臺(tái)服務(wù)器，是因?yàn)閯e人要我這么做”）。
• 如果運(yùn)維部門的每個(gè)職能團(tuán)隊(duì)都要同時(shí)服務(wù)于多個(gè)價(jià)值流（即多個(gè)開發(fā)團(tuán)隊(duì)），那么問(wèn)題更是雪上加霜，因?yàn)樗袌F(tuán)隊(duì)的時(shí)間都很寶貴。
• 組建以市場(chǎng)為導(dǎo)向的團(tuán)隊(duì)。
• 將工程師及其專業(yè)技能（例如運(yùn)維、QA和信息安全）嵌入每個(gè)服務(wù)團(tuán)隊(duì)，或者向團(tuán)隊(duì)提供自助服務(wù)平臺(tái)，其功能包括配置類生產(chǎn)環(huán)境、執(zhí)行自動(dòng)化測(cè)試或進(jìn)行部署。
• 這使每個(gè)服務(wù)團(tuán)隊(duì)能夠獨(dú)立地向客戶交付價(jià)值，而不必提交工單給IT運(yùn)維、QA或信息安全等其他部門。
• 使職能導(dǎo)向有效。
• 快速響應(yīng)。
• 高度信任的文化。
• 將測(cè)試、運(yùn)維和信息安全融入日常工作。
• 保證質(zhì)量、可用性和安全性不是某個(gè)部門的職責(zé)，而是所有人日常工作的一部分。
• 使團(tuán)隊(duì)成員成為通才。
• 培養(yǎng)全棧工程師。
• 給工程師提供學(xué)習(xí)必要技能的機(jī)會(huì)，讓他們有能力構(gòu)建和運(yùn)行所負(fù)責(zé)的系統(tǒng)。
• 松耦合架構(gòu)，提高生產(chǎn)力和安全性。
• 保持小規(guī)模（“兩個(gè)披薩原則”）。

要使職能導(dǎo)向有效，需要由傳統(tǒng)的集中式運(yùn)維向提供運(yùn)維服務(wù)的方向轉(zhuǎn)變。

運(yùn)維融入項(xiàng)目開發(fā)工作

• 創(chuàng)建共享服務(wù)（類生產(chǎn)環(huán)境、部署流水線、自動(dòng)化測(cè)試工具、生產(chǎn)環(huán)境監(jiān)控臺(tái)、運(yùn)維服務(wù)平臺(tái)等），提高開發(fā)生產(chǎn)力。
• 運(yùn)維工程師融入開發(fā)團(tuán)隊(duì)。
• 使產(chǎn)品團(tuán)隊(duì)自給自足，可以完全負(fù)責(zé)服務(wù)的交付和支持。
• 派遣工程師到項(xiàng)目開發(fā)團(tuán)隊(duì)（運(yùn)維工程師的面試和聘用仍由集中式運(yùn)維團(tuán)隊(duì)完成）。
• 為每個(gè)項(xiàng)目團(tuán)隊(duì)分派運(yùn)維聯(lián)絡(luò)人（派遣的運(yùn)維工程師）。
• 集中式運(yùn)維團(tuán)隊(duì)管理所有環(huán)境，派遣的運(yùn)維工程師需要理解：新產(chǎn)品的功能、開發(fā)原因、程序如何工作、可運(yùn)維性、可擴(kuò)展性、監(jiān)控能力、架構(gòu)模式、對(duì)基礎(chǔ)設(shè)施的要求、產(chǎn)品特性的發(fā)布計(jì)劃等。
• 邀請(qǐng)運(yùn)維聯(lián)絡(luò)人參加開發(fā)團(tuán)隊(duì)會(huì)議、每日站會(huì)、回顧會(huì)議。
• 使用看板圖展示運(yùn)維工作。

流動(dòng)的技術(shù)實(shí)踐

該部分包含以下內(nèi)容：

• 運(yùn)行部署流水線的基礎(chǔ)。
• 實(shí)現(xiàn)快速可靠的自動(dòng)化測(cè)試。
• 代碼持續(xù)集成。
• 自動(dòng)化和低風(fēng)險(xiǎn)發(fā)布。
• 降低發(fā)布風(fēng)險(xiǎn)的架構(gòu)。

運(yùn)行部署流水線的基礎(chǔ)

• 自動(dòng)化環(huán)境（開發(fā)、測(cè)試、正式）搭建。
• 使用 Shell、IaC（Puppet、Ansible、Terraform）、Docker、K8S、OpenShift 等技術(shù)。
• 所有內(nèi)容做版本控制。
• 應(yīng)用程序代碼版本控制；
• 數(shù)據(jù)庫(kù)代碼版本控制；
• 運(yùn)維配置代碼版本控制；
• 自動(dòng)化和手動(dòng)測(cè)試的腳本；
• 支持代碼打包、部署、數(shù)據(jù)庫(kù)遷移、應(yīng)用配置的腳本；
• 項(xiàng)目相關(guān)文件（需求文檔、部署過(guò)程、發(fā)布說(shuō)明等）；
• 防火墻配置、服務(wù)器配置等腳本。
• 擴(kuò)展完成的定義。
• 在類生產(chǎn)環(huán)境中按照預(yù)期進(jìn)行，開發(fā)工作才認(rèn)為是完成的。

實(shí)現(xiàn)快速可靠的自動(dòng)化測(cè)試

• 持續(xù)構(gòu)建、測(cè)試和集成。
• 代碼分支持續(xù)集成到主干中，并確保通過(guò)單元測(cè)試、集成測(cè)試和驗(yàn)收測(cè)試。
• 常用工具：Jenkins、TFS、TeamCity、GitLab CI。
• 對(duì)持續(xù)集成的配合：自動(dòng)化測(cè)試工具；一旦失敗必須立即解決的文化；代碼持續(xù)合入到主干，而不是持續(xù)在特性分支上工作。
• 構(gòu)建快速可靠的自動(dòng)化測(cè)試套件。
• 單元測(cè)試：JUnit、Mockito、PowerMock
• 單元測(cè)試度量：測(cè)試覆蓋率。
• 驗(yàn)收測(cè)試：自動(dòng)化API測(cè)試、自動(dòng)化GUI測(cè)試。
• 并行測(cè)試：安全測(cè)試、性能測(cè)試、單元測(cè)試、自動(dòng)化測(cè)試。
• 測(cè)試驅(qū)動(dòng)開發(fā)：TDD、ATDD。
• 讓部署流水線始終保持綠色狀態(tài)。
• 部署流水線失敗時(shí)，所有人立即解決問(wèn)題或者立即回滾代碼，后續(xù)的代碼提交應(yīng)該拒絕。

代碼持續(xù)集成

• 持續(xù)集成代碼。
• 開發(fā)人員在自己的分支上獨(dú)立工作的時(shí)間越長(zhǎng)，就越難將變更合入主干。
• 小批量開發(fā)。
• 基于主干開發(fā)。
• 頻繁向主干提交（通過(guò)合并請(qǐng)求）代碼。

自動(dòng)化和低風(fēng)險(xiǎn)發(fā)布

• 自動(dòng)化部署步驟：構(gòu)建、測(cè)試、部署；相關(guān)流程包括：
• 代碼打包、構(gòu)建；
• 上傳 Docker 鏡像；
• 創(chuàng)建預(yù)配置的 K8S 服務(wù)；
• 自動(dòng)化單元測(cè)試、冒煙測(cè)試；
• 數(shù)據(jù)庫(kù)遷移自動(dòng)化；
• 配置自動(dòng)化。
• 應(yīng)用自動(dòng)化的自助式部署
• 開發(fā)人員專注于編寫代碼，點(diǎn)擊部署按鈕，通過(guò)監(jiān)控指標(biāo)看到代碼在生產(chǎn)環(huán)境中正常運(yùn)行，在代碼出錯(cuò)時(shí)能獲得錯(cuò)誤信息快速修復(fù)。
• 通過(guò)代碼審查、自動(dòng)化測(cè)試、自動(dòng)化部署，控制部署風(fēng)險(xiǎn)，必要時(shí)使開發(fā)人員也可進(jìn)行部署操作，測(cè)試人員和項(xiàng)目經(jīng)理可在某些環(huán)境中進(jìn)行部署。
• 將部署和發(fā)布解耦
• 部署指在特定環(huán)境中安裝制定版本的軟件。
• 發(fā)布指將產(chǎn)品特性提供給所有客戶或部分客戶使用。
• 基于環(huán)境的發(fā)布模式
• 藍(lán)綠部署
• 灰度（金絲雀）發(fā)布
• 基于應(yīng)用的發(fā)布模式
• 實(shí)現(xiàn)特性開關(guān)，好處：輕松地回滾、緩解性能壓力、可以屏蔽服務(wù)依賴。
• 實(shí)現(xiàn)黑啟動(dòng)：發(fā)布潛在風(fēng)險(xiǎn)的新特性時(shí)，隱式調(diào)用，僅記錄測(cè)試結(jié)果。
• 持續(xù)交付的實(shí)踐
• 持續(xù)交付是指，所有開發(fā)人員都在主干上進(jìn)行小批量工作，或者在短時(shí)間存在的特性分支上工作，并且定期向主干合并，同時(shí)始終讓主干保持可發(fā)布狀態(tài)，并能做到在正常的工作時(shí)段里按需進(jìn)行一鍵式發(fā)布。開發(fā)人員在引入任何回歸錯(cuò)誤時(shí)（包括缺陷、性能問(wèn)題、安全問(wèn)題、可用性問(wèn)題等），都能快速得到反饋。一旦發(fā)現(xiàn)這類問(wèn)題，就立即加以解決，從而保持主干始終處于可部署狀態(tài)。
• 持續(xù)部署的實(shí)踐
• 持續(xù)部署是指，在持續(xù)交付的基礎(chǔ)上，由開發(fā)人員或運(yùn)維人員自助式地定期向生產(chǎn)環(huán)境部署優(yōu)質(zhì)的構(gòu)建版本，這通常意味著每天每人至少做一次生產(chǎn)環(huán)境部署，甚至每當(dāng)開發(fā)人員提交代碼變更時(shí)，就觸發(fā)一次自動(dòng)化部署。
• 大多數(shù)團(tuán)隊(duì)采用持續(xù)交付實(shí)踐。

降低發(fā)布風(fēng)險(xiǎn)的架構(gòu)

• 松耦合架構(gòu)
• 面向服務(wù)的架構(gòu)
• 安全地演進(jìn)企業(yè)架構(gòu)
• 絞殺者應(yīng)用模式：API封裝已有功能、按新架構(gòu)實(shí)現(xiàn)新功能、API版本化。
• 云原生架構(gòu)

反饋的技術(shù)實(shí)踐

這部分包含以下內(nèi)容：

• 建立遙測(cè)系統(tǒng)
• 智能告警
• 應(yīng)用反饋實(shí)現(xiàn)安全部署
• 應(yīng)用A/B測(cè)試
• 建立評(píng)審和協(xié)作流程

建立遙測(cè)系統(tǒng)

• 什么是遙測(cè)（Telemetry）？
• 遙測(cè)包含監(jiān)控，實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)實(shí)時(shí)、高速和更精細(xì)的監(jiān)控技術(shù)。
• 相比于傳統(tǒng)的網(wǎng)絡(luò)監(jiān)控技術(shù)，遙測(cè)通過(guò)推模式，主動(dòng)向采集器上推送數(shù)據(jù)信息，提供更實(shí)時(shí)更高速更精確的網(wǎng)絡(luò)監(jiān)控功能。
• 遙測(cè)的三大維度
• Tracing（跟蹤），Metrics（指標(biāo)） , Logging（日志）。
• 可觀察性
• 系統(tǒng)可以由其外部輸出（遙測(cè)的數(shù)據(jù)）推斷其內(nèi)部狀態(tài)的程度。
• 能發(fā)現(xiàn)、預(yù)測(cè)并解決問(wèn)題。
• 集中式監(jiān)控系統(tǒng)（可使用：Prometheus、SkyWalking）
• 在業(yè)務(wù)邏輯、應(yīng)用程序和環(huán)境層收集數(shù)據(jù)。
• 負(fù)責(zé)存儲(chǔ)和轉(zhuǎn)發(fā)事件和指標(biāo)的事件路由器。
• 應(yīng)用程序日志遙測(cè)（ELK、審計(jì)日志、Metrics）
• 重大應(yīng)用事件清單：
• 認(rèn)證/授權(quán)的結(jié)果（包括退出）；
• 系統(tǒng)和數(shù)據(jù)的訪問(wèn)；
• 系統(tǒng)和應(yīng)用程序的變更（特別是特權(quán)變更）；
• 數(shù)據(jù)的變更，例如增加、修改或刪除數(shù)據(jù)；
• 無(wú)效輸入（可能的惡意注入、威脅等）；
• 資源（內(nèi)存、磁盤、中央處理器、帶寬或其他任何具有硬/軟限制的資源）；
• 健康度和可用性；
• 啟動(dòng)和關(guān)閉；
• 故障和錯(cuò)誤；
• 斷路器跳閘；
• 延遲；
• 備份成功/失敗。
• 將建立生產(chǎn)遙測(cè)融入日常開發(fā)工作。
• 使用遙測(cè)指導(dǎo)問(wèn)題的解決。
• 建立自助訪問(wèn)的可視化遙測(cè)信息系統(tǒng)（信息輻射器）
• Grafana
• SkyWalking
• Kibana
• 發(fā)現(xiàn)和填補(bǔ)遙測(cè)的盲區(qū)（建立充分而完整的遙測(cè)）
• 業(yè)務(wù)級(jí)別：訂單量、用戶數(shù)、流失率、廣告展示和點(diǎn)擊等。
• 應(yīng)用程序級(jí)別：事務(wù)處理事件、應(yīng)用程序故障等。
• 基礎(chǔ)架構(gòu)級(jí)別：服務(wù)器吞吐量、CPU負(fù)載、磁盤使用率等。
• 客戶端軟件級(jí)別：應(yīng)用出錯(cuò)和崩潰、客戶端的事務(wù)處理事件等。
• 部署流水線級(jí)別：流水線狀態(tài)、部署頻率等。

智能告警

• 解決告警疲勞
• 充分而完整的遙測(cè)會(huì)引入告警疲勞問(wèn)題，需要更智能的報(bào)警。
• 使用統(tǒng)計(jì)分析方法，而非靜態(tài)閾值設(shè)置告警
• 使用均值和標(biāo)準(zhǔn)差（適用于正態(tài)分布的數(shù)據(jù)）：度量數(shù)據(jù)與均值存在較大標(biāo)準(zhǔn)差時(shí)告警。
• 使用預(yù)防故障的告警，而不只是故障發(fā)生后的告警
• 試著問(wèn)有什么指標(biāo)可以預(yù)測(cè)故障。
• 異常檢測(cè)技術(shù)
• 平滑統(tǒng)計(jì)技術(shù)：使用移動(dòng)平均數(shù)，利用每個(gè)點(diǎn)與滑動(dòng)窗口中所有其他數(shù)據(jù)的平均值，來(lái)轉(zhuǎn)換數(shù)據(jù)。
• 支持高級(jí)異常檢測(cè)的工具：Prometheus、Grafana。

應(yīng)用反饋實(shí)現(xiàn)安全部署

• 通過(guò)遙測(cè)使部署更安全——部署后能立即發(fā)現(xiàn)問(wèn)題。
• 價(jià)值流中的所有人（開發(fā)人員、開發(fā)經(jīng)理、架構(gòu)師、運(yùn)維團(tuán)隊(duì)等）共同承擔(dān)運(yùn)維事故的下游責(zé)任。
• 共同承擔(dān)值班工作、共同解決生產(chǎn)環(huán)境問(wèn)題。
• 讓開發(fā)人員跟蹤工作對(duì)運(yùn)維人員的影響。
• 使開發(fā)的應(yīng)用易于部署，提升運(yùn)維人員幸福感。
• 讓開發(fā)團(tuán)隊(duì)自行管理生產(chǎn)服務(wù)。
• 首先由開發(fā)團(tuán)隊(duì)管理，然后才交由集中的運(yùn)維團(tuán)隊(duì)管理。
• 運(yùn)維工程師由生產(chǎn)支持轉(zhuǎn)變?yōu)轭檰?wèn)或加入團(tuán)隊(duì)，幫助做好部署準(zhǔn)備，建立服務(wù)發(fā)布指南（包括：支持有效的監(jiān)控、部署可靠、架構(gòu)能支持快速頻繁的部署等）。
• 為團(tuán)隊(duì)分配SRE人員。SRE定位：SRE就是軟件開發(fā)工程師負(fù)責(zé)了運(yùn)維工作，SRE非常稀少，只能分配給最重要的團(tuán)隊(duì)。

應(yīng)用A/B測(cè)試

• 在功能中集成A/B測(cè)試
• 向用戶隨機(jī)展示一個(gè)頁(yè)面的兩個(gè)版本之一。
• 在發(fā)布中集成A/B測(cè)試
• 使用特性開關(guān)。
• 在功能規(guī)劃中集成A/B測(cè)試
• 不僅要快速部署和發(fā)布軟件，還要在實(shí)驗(yàn)方面不斷提升，通過(guò)實(shí)驗(yàn)主動(dòng)實(shí)現(xiàn)業(yè)務(wù)目標(biāo)和客戶滿意度。

建立評(píng)審和協(xié)作流程

• 防止「過(guò)度控制變更」
• 反事實(shí)思維容易認(rèn)為事故是由于缺乏審批流程導(dǎo)致。
• 建立同行評(píng)審，縮短審批流程
• DevOps 中高績(jī)效的組織更多地依賴同行評(píng)審，更少地依賴外部變更批準(zhǔn)（層層審批）。
• 代碼評(píng)審
• 每個(gè)人的代碼提交到主干時(shí)，必須由同行進(jìn)行評(píng)審；
• 每個(gè)人應(yīng)該持續(xù)關(guān)注其他成員的提交活動(dòng)；
• 定義高風(fēng)險(xiǎn)變更，從而決定是否需要請(qǐng)領(lǐng)域?qū)＜疫M(jìn)行審查；
• 將大的提交變更拆分成小批量變更。
• 利用結(jié)對(duì)編程改進(jìn)代碼變更
• 研究表明：結(jié)對(duì)的程序員比兩個(gè)獨(dú)立工作的程序員慢了15%，而‘無(wú)錯(cuò)誤’代碼量卻從70%增加到了85%。
• 測(cè)試和調(diào)試程序的成本通常比寫初始代碼的成本高出多倍。
• 評(píng)估合并請(qǐng)求的有效性
• 與在生產(chǎn)環(huán)境產(chǎn)生的結(jié)果無(wú)關(guān)。
• 有效合并請(qǐng)求的基本要素：必須足夠詳細(xì)地說(shuō)明變更的原因、如何做的變更，以及任何已識(shí)別的風(fēng)險(xiǎn)和應(yīng)對(duì)措施。

持續(xù)學(xué)習(xí)與實(shí)驗(yàn)的技術(shù)實(shí)踐

這部分包含以下內(nèi)容：

• 將學(xué)習(xí)融入日常工作
• 將局部經(jīng)驗(yàn)轉(zhuǎn)化為全局改進(jìn)
• 預(yù)留組織學(xué)習(xí)和改進(jìn)的時(shí)間

將學(xué)習(xí)融入日常工作

• 公正文化和學(xué)習(xí)文化
• 人為錯(cuò)誤往往不是問(wèn)題的根本原因，可能是復(fù)雜系統(tǒng)中存在不可避免的設(shè)計(jì)問(wèn)題而導(dǎo)致。
• 不應(yīng)該對(duì)造成故障的人進(jìn)行「點(diǎn)名、責(zé)備和羞辱」，我們的目標(biāo)是最大限度地抓住組織學(xué)習(xí)的機(jī)會(huì)。
• 從學(xué)習(xí)的角度看待錯(cuò)誤、報(bào)錯(cuò)、失誤、過(guò)失等。
• 相關(guān)實(shí)踐1：在事后分析中，不指責(zé)，公正地進(jìn)行評(píng)判，使工程師自己愿意對(duì)事情負(fù)責(zé)，并且熱情地幫助其他人避免同樣的錯(cuò)誤發(fā)生；廣泛地公開事后分析會(huì)議結(jié)果。
• 相關(guān)實(shí)踐2：在生產(chǎn)環(huán)境中引入受控的人為故障（搗亂猴），針對(duì)不可避免的問(wèn)題進(jìn)行演練。
• 降低事故容忍度，尋找更弱的故障信號(hào)
• 隨著組織能力的提升，事故數(shù)量大幅降低，故障越不應(yīng)該出現(xiàn)。
• 在復(fù)雜的系統(tǒng)中，放大微弱的故障信號(hào)對(duì)于防范災(zāi)難性故障事關(guān)重要。
• 重新定義失敗
• 高效能DevOps組織的變更頻率是平均水平的30倍，即使失敗率只有平均水平的一半，也顯然意味著故障總數(shù)更多。
• 鼓勵(lì)創(chuàng)新并接受因此帶來(lái)的風(fēng)險(xiǎn)。
• 創(chuàng)建故障演練日
• 幫助團(tuán)隊(duì)模擬和演練事故，使其具備實(shí)戰(zhàn)能力。
• 暴露系統(tǒng)的潛在缺陷。

將局部經(jīng)驗(yàn)轉(zhuǎn)化為全局改進(jìn)

• [ChatOps] 使用聊天機(jī)器人、積累組織知識(shí)
• 自動(dòng)化工具集成到聊天中，比如（@bot depoy owl to production）；
• 操作結(jié)果由機(jī)器人發(fā)送回聊天室，每個(gè)人都能看到發(fā)生的一切；
• 新來(lái)的工程師也可以看到團(tuán)隊(duì)的日常工作及執(zhí)行方式；
• 看到他人互相幫助時(shí)，人們也會(huì)傾向于尋求幫助；
• 使用話題組，建立起組織學(xué)習(xí)，知識(shí)得到快速積累。
• 加強(qiáng)了透明、協(xié)作的文化。
• 將標(biāo)準(zhǔn)、流程和規(guī)范轉(zhuǎn)化為便于執(zhí)行的形式
• [ArchOps] 使工程師成為構(gòu)建者，而不是砌磚工；
• 將手動(dòng)操作流程轉(zhuǎn)換為可自動(dòng)化執(zhí)行的代碼；
• 將合規(guī)性使用代碼表達(dá)出來(lái)。
• 運(yùn)用自動(dòng)化測(cè)試記錄和傳播知識(shí)
• 自動(dòng)化界面測(cè)試，令使用者知道系統(tǒng)如何使用；
• 單元測(cè)試，令調(diào)用者知道方法API如何使用。
• 項(xiàng)目開發(fā)中包含非功能性的運(yùn)維需求
• 對(duì)各種應(yīng)用和環(huán)境進(jìn)行充分的遙測(cè)；
• 準(zhǔn)確跟蹤依賴關(guān)系的能力；
• 具有彈性并能正常降級(jí)的服務(wù)；
• 各版本之間具有向前和向后的兼容性；
• 歸檔數(shù)據(jù)來(lái)管理生產(chǎn)數(shù)據(jù)集的能力；
• 輕松搜索和理解各種服務(wù)日志信息的能力；
• 通過(guò)多個(gè)服務(wù)跟蹤用戶請(qǐng)求的能力；
• 使用功能開關(guān)或其他方法實(shí)現(xiàn)簡(jiǎn)便、集中式的運(yùn)行時(shí)配置。
• 把可重用的運(yùn)維用戶故事納入開發(fā)
• 將重復(fù)的運(yùn)維工作通過(guò)編碼進(jìn)行實(shí)現(xiàn)。
• 技術(shù)選型需要考慮運(yùn)維因素
• 不能減慢工作流；
• 思考舉例：TIDB VS MySQL 該如何選擇。

預(yù)留組織學(xué)習(xí)和改進(jìn)的時(shí)間

• 償還技術(shù)債務(wù)制度化
• 定時(shí)「大掃除」
• 開發(fā)和運(yùn)維針對(duì)非功能性需求進(jìn)行優(yōu)化，橫跨整個(gè)價(jià)值流。
• 價(jià)值：賦予一線工作人員不斷識(shí)別和解決問(wèn)題的能力。
• 讓所有人教學(xué)相長(zhǎng)
• 所有的工程師都越來(lái)越需要某些技能，而不只是開發(fā)人員如此。
• 越來(lái)越多的技術(shù)價(jià)值流采用了DevOps的原則和模式。
• [每周學(xué)習(xí)文化] 每周一次的學(xué)習(xí)時(shí)間，每個(gè)同伴既要自己學(xué)習(xí)，又要教別人。
• 內(nèi)部顧問(wèn)和教練
• 成立內(nèi)部的教練和咨詢組織，促進(jìn)專業(yè)知識(shí)在組織內(nèi)的傳播。

實(shí)踐重點(diǎn)

DevOps 的實(shí)踐包含許多內(nèi)容，提煉了以下重點(diǎn)方便查閱：

• 流動(dòng)原則的實(shí)踐
• 部署流水線的基礎(chǔ)（所有內(nèi)容做版本控制、在類生產(chǎn)環(huán)境按預(yù)期工作才算完成）
• 實(shí)現(xiàn)快速可靠的自動(dòng)化測(cè)試（自動(dòng)化運(yùn)行、始終保持流水線處于綠色狀態(tài)）
• 代碼持續(xù)集成（小批量開發(fā)）
• 自動(dòng)化和低風(fēng)險(xiǎn)發(fā)布（自助式部署、部署和發(fā)布解耦、采用持續(xù)交付）
• 降低發(fā)布風(fēng)險(xiǎn)的架構(gòu)（云原生架構(gòu)）
• 反饋原則的實(shí)踐
• 建立遙測(cè)系統(tǒng)（Tracing、Metrics、Logging）
• 智能告警（使用統(tǒng)計(jì)分析方法和預(yù)防故障的告警）
• 應(yīng)用反饋實(shí)現(xiàn)安全部署（部署后立即發(fā)現(xiàn)問(wèn)題、共同承擔(dān)責(zé)任）
• 應(yīng)用A/B測(cè)試（功能規(guī)劃中集成A/B測(cè)試、使用特性開關(guān)）
• 建立評(píng)審和協(xié)作流程（同行評(píng)審、減少審批流程、結(jié)對(duì)編程）
• 持續(xù)學(xué)習(xí)與實(shí)驗(yàn)原則的實(shí)踐
• 將學(xué)習(xí)融入日常工作（從學(xué)習(xí)的角度看待事故、尋找更弱的故障信號(hào)）
• 將局部經(jīng)驗(yàn)轉(zhuǎn)化為全局改進(jìn)（ChatOps、讓規(guī)范便于執(zhí)行、非功能性的運(yùn)維需求）
• 預(yù)留組織學(xué)習(xí)和改進(jìn)的時(shí)間（定時(shí)償還技術(shù)債務(wù)、教學(xué)相長(zhǎng)、內(nèi)部教練）

結(jié)語(yǔ)

DevOps 的發(fā)展與技術(shù)的發(fā)展相輔相成，也為技術(shù)人員提供了更多的學(xué)習(xí)道路和發(fā)展方向，借用一句 DevOps 領(lǐng)袖的話來(lái)作為本文的結(jié)束語(yǔ)。

歡迎自薦投稿到《前端技術(shù)江湖》，如果你覺(jué)得這篇內(nèi)容對(duì)你挺有啟發(fā)，記得點(diǎn)個(gè) 「在看」哦