萬字長文帶你徹底搞懂什么是 DevOps

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

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

DevOps 定義

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

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

?

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

?

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

?

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

?

另：

?

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

?

3. DevOps 中文 wiki 定義

?

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

?

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

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

DevOps 發(fā)展背景

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

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

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

DevOps 原則與實踐

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

DevOps 原則是總體指導思想，實踐是具體的執(zhí)行方法，DevOps 是一個動態(tài)的過程，在進行相關實踐的時候可以看看其應用了哪些原則，當違背原則的時候需要思考實踐的合理性。

DevOps 原則

DevOps 包含以下三大原則：

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

流動原則

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

反饋原則

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

持續(xù)學習與實驗原則

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

DevOps 實踐

基于 DevOps 的相關原則，有與其對應的實踐，包括：流動的技術實踐、反饋的技術實踐和持續(xù)學習與實驗的技術實踐。在應用這些實踐之前還需認真設計組織結構，使其有利于實踐的開展。

設計組織結構

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

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

運維融入項目開發(fā)工作

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

流動的技術實踐

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

• 運行部署流水線的基礎。
• 實現(xiàn)快速可靠的自動化測試。
• 代碼持續(xù)集成。
• 自動化和低風險發(fā)布。
• 降低發(fā)布風險的架構。

運行部署流水線的基礎

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

實現(xiàn)快速可靠的自動化測試

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

代碼持續(xù)集成

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

自動化和低風險發(fā)布

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

降低發(fā)布風險的架構

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

反饋的技術實踐

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

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

建立遙測系統(tǒng)

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

智能告警

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

應用反饋實現(xiàn)安全部署

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

應用A/B測試

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

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

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

持續(xù)學習與實驗的技術實踐

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

• 將學習融入日常工作
• 將局部經(jīng)驗轉化為全局改進
• 預留組織學習和改進的時間

將學習融入日常工作

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

將局部經(jīng)驗轉化為全局改進

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

預留組織學習和改進的時間

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

實踐重點

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

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

結語

DevOps 的發(fā)展與技術的發(fā)展相輔相成，也為技術人員提供了更多的學習道路和發(fā)展方向，借用一句 DevOps 領袖的話來作為本文的結束語。