萬字長文帶你徹底搞懂DevOps

• 敏態(tài)需求的增加，即探索性工作的增加；

• 軟件開發(fā)從傳統(tǒng)的瀑布流方式到敏捷開發(fā)，再到現(xiàn)在對(duì)敏捷開發(fā)提出了更高的要求，近些年創(chuàng)新型的應(yīng)用不斷涌現(xiàn)，在這些應(yīng)用的研發(fā)過程中多采用小步快跑、快速試錯(cuò)的方式，這些探索性工作要求運(yùn)維能夠具備一天發(fā)布多次的能力，需要企業(yè)完成由穩(wěn)態(tài)到敏態(tài)的轉(zhuǎn)變。

• 軟件開發(fā)活動(dòng)在企業(yè)經(jīng)營活動(dòng)中占比的不斷增加；

• 業(yè)務(wù)發(fā)展對(duì)軟件的依賴由輕度依賴、中度依賴發(fā)展到目前的重度依賴。

• 企業(yè)存在對(duì)消除浪費(fèi)的需求。

• 軟件開發(fā)活動(dòng)在企業(yè)中的位置越來越重要，而像企業(yè)經(jīng)營活動(dòng)一樣，軟件開發(fā)活動(dòng)中也存在著許多的浪費(fèi)，企業(yè)管理上必然存在著識(shí)別并消除浪費(fèi)的需求。

• 軟件開發(fā)中的浪費(fèi)包括不必要和必要的浪費(fèi)，不必要的浪費(fèi)有：無人使用的功能、軟件bug、等待測(cè)試、等待審批等；必要的浪費(fèi)包括：工作項(xiàng)移交、測(cè)試、項(xiàng)目管理等。

• 流動(dòng)原則：加速從開發(fā)、運(yùn)維到交付給客戶的流程；

• 反饋原則：建設(shè)安全可靠的工作體系；

• 持續(xù)學(xué)習(xí)與實(shí)驗(yàn)原則：采用科學(xué)的工作方式，將對(duì)組織的改進(jìn)和創(chuàng)新作為工作的一部分。

• 堅(jiān)持少做

• 產(chǎn)品開始開發(fā)時(shí)采用 MVP 原則。

• 產(chǎn)品迭代時(shí)要適時(shí)做減法。

• 持續(xù)分解問題

• 大的變更或需求拆解為一系列小的變更，快速解決。

???

• 工作可視化

• 采用 Sprint 看板將工作可視化。

• 控制任務(wù)數(shù)量

• 減少前置時(shí)間，降低測(cè)試人員的等待時(shí)間。

• 任務(wù)越多，預(yù)估越不準(zhǔn)確。

• 減少交接次數(shù)

• 減少不必要的溝通和等待。

• 持續(xù)識(shí)別和改善約束點(diǎn)

• 識(shí)別出影響流動(dòng)的主要前置因素，比如搭建環(huán)境、需求文檔。

• QA、開發(fā)、運(yùn)維、產(chǎn)品持續(xù)提升生產(chǎn)力。

• 為非功能性需求預(yù)留20%的開發(fā)時(shí)間，減少技術(shù)債務(wù)。

• 消除價(jià)值流中的困境和浪費(fèi)（導(dǎo)致交付延遲的主要因素）

• 半成品——未完全完成的工作。

• 額外工序——從不使用的文檔、重復(fù)編寫接口文檔等。

• 額外功能——用戶實(shí)際不需要的功能。

• 任務(wù)切換——將人員分配到多個(gè)項(xiàng)目或截然不同的工作任務(wù)中。

• 等待、移動(dòng)、缺陷、非標(biāo)準(zhǔn)化的手動(dòng)操作。

• 在復(fù)雜系統(tǒng)中安全地工作

• 管理復(fù)雜的工作，識(shí)別出設(shè)計(jì)和操作的問題；

• 群策群力解決問題，從而快速構(gòu)建新知識(shí)；

• 在整個(gè)組織中，將區(qū)域性的知識(shí)應(yīng)用到全局范圍；

• 領(lǐng)導(dǎo)者要持續(xù)培養(yǎng)有以上才能的人。

• 及時(shí)發(fā)現(xiàn)問題

• 快速、頻繁和高質(zhì)量的信息流——每個(gè)工序的操作都會(huì)被度量和監(jiān)控。

• 技術(shù)價(jià)值流的每個(gè)階段（產(chǎn)品管理、開發(fā)、QA、安全、運(yùn)維），建立快速的反饋和前饋回路（包括自動(dòng)化構(gòu)建、集成和測(cè)試過程）。

• 全方位的遙測(cè)系統(tǒng)。

• 在源頭保障質(zhì)量

• 過多的檢查和審批流程，使得做決策的地方遠(yuǎn)離執(zhí)行工作的地方，這導(dǎo)致流程有效性降低，減弱了因果關(guān)系之間反饋的強(qiáng)度。

• 讓開發(fā)人員也對(duì)系統(tǒng)質(zhì)量負(fù)責(zé)，快速反饋，加速開發(fā)人員的學(xué)習(xí)。

• 為內(nèi)部客戶優(yōu)化工作

• 運(yùn)維的非功能性需求（如架構(gòu)、性能、穩(wěn)定性、可測(cè)試性、可配置性和安全性）與用戶功能同樣重要。

• 建立學(xué)習(xí)型組織和安全文化

• 將日常工作的改進(jìn)制度化

• 把局部發(fā)現(xiàn)轉(zhuǎn)化為全局優(yōu)化

• 在日常工作中注入彈性模式

• 縮短部署的前置時(shí)間、提高測(cè)試覆蓋率、縮短測(cè)試執(zhí)行時(shí)間，甚至在必要時(shí)解耦架構(gòu)，都屬于在系統(tǒng)中引入類似張力的做法

• 領(lǐng)導(dǎo)層強(qiáng)化學(xué)習(xí)文化

• 領(lǐng)導(dǎo)者幫助一線工作者在日常工作中發(fā)現(xiàn)并解決問題。

• 利用康威定律設(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)作，彼此充分解耦，從而避免過多不必要的溝通和協(xié)調(diào)。

• 過度職能導(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ì)），那么問題更是雪上加霜，因?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è)披薩原則”）。

• 創(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)化環(huán)境（開發(fā)、測(cè)試、正式）搭建。

• 使用 Shell、IaC（Puppet、Ansible、Terraform）、Docker、Kubernetes、OpenShift 等技術(shù)。

• 所有內(nèi)容做版本控制。

• 自動(dòng)化和手動(dòng)測(cè)試的腳本；

• 支持代碼打包、部署、數(shù)據(jù)庫遷移、應(yīng)用配置的腳本；

• 項(xiàng)目相關(guān)文件（需求文檔、部署過程、發(fā)布說明等）；

• 防火墻配置、服務(wù)器配置等腳本。

• 應(yīng)用程序代碼版本控制；

• 數(shù)據(jù)庫代碼版本控制；

• 運(yùn)維配置代碼版本控制；

• 擴(kuò)展完成的定義。

• 在類生產(chǎn)環(huán)境中按照預(yù)期進(jìn)行，開發(fā)工作才認(rèn)為是完成的。

• 持續(xù)構(gòu)建、測(cè)試和集成。

• 代碼分支持續(xù)集成到主干中，并確保通過單元測(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í)，所有人立即解決問題或者立即回滾代碼，后續(xù)的代碼提交應(yīng)該拒絕。

• 持續(xù)集成代碼。

• 開發(fā)人員在自己的分支上獨(dú)立工作的時(shí)間越長，就越難將變更合入主干。

• 小批量開發(fā)。

• 基于主干開發(fā)。

• 頻繁向主干提交（通過合并請(qǐng)求）代碼。

• 自動(dòng)化部署步驟：構(gòu)建、測(cè)試、部署；相關(guān)流程包括：

• 代碼打包、構(gòu)建；

• 上傳 Docker 鏡像；

• 創(chuàng)建預(yù)配置的 Kubernetes 服務(wù)；

• 自動(dòng)化單元測(cè)試、冒煙測(cè)試；

• 數(shù)據(jù)庫遷移自動(dòng)化；

• 配置自動(dòng)化。

• 應(yīng)用自動(dòng)化的自助式部署

• 開發(fā)人員專注于編寫代碼，點(diǎn)擊部署按鈕，通過監(jiān)控指標(biāo)看到代碼在生產(chǎn)環(huán)境中正常運(yùn)行，在代碼出錯(cuò)時(shí)能獲得錯(cuò)誤信息快速修復(fù)。

• 通過代碼審查、自動(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í)（包括缺陷、性能問題、安全問題、可用性問題等），都能快速得到反饋。一旦發(fā)現(xià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í)踐。

• 松耦合架構(gòu)

• 面向服務(wù)的架構(gòu)

• 安全地演進(jìn)企業(yè)架構(gòu)

• 絞殺者應(yīng)用模式：API封裝已有功能、按新架構(gòu)實(shí)現(xiàn)新功能、API版本化。

• 云原生架構(gòu)

• 什么是遙測(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è)通過推模式，主動(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è)并解決問題。

• 集中式監(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ù)的訪問；

• 系統(tǒng)和應(yīng)用程序的變更（特別是特權(quán)變更）；

• 數(shù)據(jù)的變更，例如增加、修改或刪除數(shù)據(jù)；

• 無效輸入（可能的惡意注入、威脅等）；

• 資源（內(nèi)存、磁盤、中央處理器、帶寬或其他任何具有硬/軟限制的資源）；

• 健康度和可用性；

• 啟動(dòng)和關(guān)閉；

• 故障和錯(cuò)誤；

• 斷路器跳閘；

• 延遲；

• 備份成功/失敗。

• 將建立生產(chǎn)遙測(cè)融入日常開發(fā)工作。

• 使用遙測(cè)指導(dǎo)問題的解決。

• 建立自助訪問的可視化遙測(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ì)引入告警疲勞問題，需要更智能的報(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ā)生后的告警

• 試著問有什么指標(biāo)可以預(yù)測(cè)故障。

• 異常檢測(cè)技術(shù)

• 平滑統(tǒng)計(jì)技術(shù)：使用移動(dòng)平均數(shù)，利用每個(gè)點(diǎn)與滑動(dòng)窗口中所有其他數(shù)據(jù)的平均值，來轉(zhuǎn)換數(shù)據(jù)。

• 支持高級(jí)異常檢測(cè)的工具：Prometheus、Grafana。

• 通過遙測(cè)使部署更安全——部署后能立即發(fā)現(xiàn)問題。

• 價(jià)值流中的所有人（開發(fā)人員、開發(fā)經(jīng)理、架構(gòu)師、運(yùn)維團(tuán)隊(duì)等）共同承擔(dān)運(yùn)維事故的下游責(zé)任。

• 共同承擔(dān)值班工作、共同解決生產(chǎn)環(huá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)轭檰柣蚣尤雸F(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ì)。

• 在功能中集成A/B測(cè)試

• 向用戶隨機(jī)展示一個(gè)頁面的兩個(gè)版本之一。

• 在發(fā)布中集成A/B測(cè)試

• 使用特性開關(guān)。

• 在功能規(guī)劃中集成A/B測(cè)試

• 不僅要快速部署和發(fā)布軟件，還要在實(shí)驗(yàn)方面不斷提升，通過實(shí)驗(yàn)主動(dòng)實(shí)現(xiàn)業(yè)務(wù)目標(biāo)和客戶滿意度。

• 防止「過度控制變更」

• 反事實(shí)思維容易認(rèn)為事故是由于缺乏審批流程導(dǎo)致。

• 建立同行評(píng)審，縮短審批流程

• DevOps 中高績效的組織更多地依賴同行評(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%，而‘無錯(cuò)誤’代碼量卻從70%增加到了85%。

• 測(cè)試和調(diào)試程序的成本通常比寫初始代碼的成本高出多倍。

• 評(píng)估合并請(qǐng)求的有效性

• 與在生產(chǎn)環(huán)境產(chǎn)生的結(jié)果無關(guān)。

• 有效合并請(qǐng)求的基本要素：必須足夠詳細(xì)地說明變更的原因、如何做的變更，以及任何已識(shí)別的風(fēng)險(xiǎn)和應(yīng)對(duì)措施。

• 公正文化和學(xué)習(xí)文化

• 人為錯(cuò)誤往往不是問題的根本原因，可能是復(fù)雜系統(tǒng)中存在不可避免的設(shè)計(jì)問題而導(dǎo)致。

• 不應(yīng)該對(duì)造成故障的人進(jìn)行「點(diǎn)名、責(zé)備和羞辱」，我們的目標(biāo)是最大限度地抓住組織學(xué)習(xí)的機(jī)會(huì)。

• 從學(xué)習(xí)的角度看待錯(cuò)誤、報(bào)錯(cuò)、失誤、過失等。

• 相關(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ì)不可避免的問題進(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)新并接受因此帶來的風(fēng)險(xiǎn)。

• 創(chuàng)建故障演練日

• 幫助團(tuán)隊(duì)模擬和演練事故，使其具備實(shí)戰(zhàn)能力。

• 暴露系統(tǒng)的潛在缺陷。

• [ChatOps] 使用聊天機(jī)器人、積累組織知識(shí)

• 自動(dòng)化工具集成到聊天中，比如（@bot depoy owl to production）；

• 操作結(jié)果由機(jī)器人發(fā)送回聊天室，每個(gè)人都能看到發(fā)生的一切；

• 新來的工程師也可以看到團(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á)出來。

• 運(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ù)來管理生產(chǎn)數(shù)據(jù)集的能力；

• 輕松搜索和理解各種服務(wù)日志信息的能力；

• 通過多個(gè)服務(wù)跟蹤用戶請(qǐng)求的能力；

• 使用功能開關(guān)或其他方法實(shí)現(xiàn)簡便、集中式的運(yùn)行時(shí)配置。

• 把可重用的運(yùn)維用戶故事納入開發(fā)

• 將重復(fù)的運(yùn)維工作通過編碼進(jìn)行實(shí)現(xiàn)。

• 技術(shù)選型需要考慮運(yùn)維因素

• 不能減慢工作流；

• 思考舉例：TIDB VS MySQL 該如何選擇。

• 償還技術(shù)債務(wù)制度化

• 定時(shí)「大掃除」

• 開發(fā)和運(yùn)維針對(duì)非功能性需求進(jìn)行優(yōu)化，橫跨整個(gè)價(jià)值流。

• 價(jià)值：賦予一線工作人員不斷識(shí)別和解決問題的能力。

• 讓所有人教學(xué)相長

• 所有的工程師都越來越需要某些技能，而不只是開發(fā)人員如此。

• 越來越多的技術(shù)價(jià)值流采用了DevOps的原則和模式。

• [每周學(xué)習(xí)文化] 每周一次的學(xué)習(xí)時(shí)間，每個(gè)同伴既要自己學(xué)習(xí)，又要教別人。

• 內(nèi)部顧問和教練

• 成立內(nèi)部的教練和咨詢組織，促進(jìn)專業(yè)知識(shí)在組織內(nèi)的傳播。

• 流動(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)問題、共同承擔(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é)相長、內(nèi)部教練）