DevOps 軟件架構師行動指南 - 讀書筆記整理
對於《DevOps 軟件架構師行動指南》這本書，整體偏大框架的介紹，但是仍然還是有一定的閱讀價值，至少對 DevOps 架構方法論和關鍵技術有一個全面的瞭解和認知。
DevOps 是什麼？
書裏面給出定義爲，DevOps 是一套實踐方法，在保證高質量的前提下縮短系統變更從提交到部署至生產環境的時間。實際上看了這個定義你也很難對 DevOps 有一個全面的瞭解。因此也可以定義爲，DevOps 是在保證質量的前提下，提供的一整套從開發，測試到生產運維的持續交付和管控方法論。在整個過程中需要實現自動化，可視化，流水線式作用，同時將質量管控無縫嵌入其中。
網上可以找到的另外一個 DevOps 的定義如下：
DevOps（英文 Development 和 Operations 的組合）是一組過程、方法與系統的統稱，用於促進開發（應用程序 / 軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它的出現是由於軟件行業日益清晰地認識到，爲了按時交付軟件產品和服務，開發和運營工作必須緊密合作。
所以要真正理解 DevOps 其一是要認識到是 Dev 和 Ops 兩個部分的組合，其次是實際開發，運維和 QA 三者之間的協同和交互問題。而對於自動化，持續集成等僅僅是解決上面這個問題採用的工具和手段。
DevOps 拓展了原有的持續集成方法論，其一是增加了組件化和微服務架構的內容，其二是在 PaaS 變成容器雲平臺後，增加了和 PaaS 平臺對接和持續交付內容。
對於持續集成和持續交付兩者區別，個人強調如下：
持續集成面向的是開發團隊，交付面向的是用戶
持續集成涉及到編譯，構建，打包，部署一系列動作，但是交付可能僅僅涉及環境遷移DevOps 強調的持續集成和交付，不僅在新系統的全新開發過程，其更加重要價值在於老系統在後續變更中的持續交付和集成能力。也就是常說的實現了開發，運維和質量管控的一體化作業。也就是我們經常說的，打開了開發和運維之間的鴻溝，真正實現了開發，運維的一體化作業。
DevOps 提倡將運維人員作爲首要的干係人，並在需求階段一開始就介入。
什麼意思？
簡單來說就是一個應用系統的開發，在從前期需求，設計階段來說就應該確保應用本身是可運維，可監控的，而不是應用上線後才發現不可運維和管理。
運維人員後期運維難的一個重要原因就是前面所有開發和測試過程對他們都是黑盒，對於這種部署在軟硬件環境裏的黑盒系統，在出現故障時候他們也很難第一時間查找到真正的原因並快速解決。
DevOps 和敏捷
對於 DevOps 研發過程一體化推進過程中，往往都會和敏捷方法論融合，特別是當前主流的 Scrum 敏捷方法論。而敏捷方法論核心仍然是需求條目化，短週期迭代，可視化這幾個關鍵點的實踐。而其中的敏捷和短週期迭代本身就是和 DevOps 核心思路和價值觀一致。
在協同上面要注意到，DevOps 有兩個重點：其一是開發，QA + 測試，運維三大角色之間的協同；其二是軟件打包版本在開發，測試，生產多個環境間的自動化部署和遷移。
人們從不同的視角定義 DevOps，例如運維人員採用敏捷實踐，開發人員承擔運維責任，以及其它一些視角的定義。但共同目標都是縮短一個功能或改進點從業務思路構想到最終部署給用戶的時間。
雲即平臺
在 DevOps 有一個重點就是應用託管和自動部署，在自動部署的過程中才是需要動態的創建虛擬機和分配資源。因此和 DevOps 真正配合協同的是 PaaS 平臺層能力，而不是 IaaS 平臺。同時我們可以看到，DevOps 實踐過程中更多的是和更加輕量化的 Docker 容器協同，而 Docker 容器管理的基礎單位是鏡像。
在和 PaaS 協同時候，對於底層軟硬件設施的基礎架構和可見性進一步對開發人員屏蔽。
對於虛擬機故障的恢復，一個重點就是狀態的保持和遷移，對於分佈式架構師要做的主要決策之一就是如何在應用的不同部分劃分狀態。對於無狀態組件最容易快速恢復和遷移，對於客戶端 Session 狀態由於數據量很小，也方便處理，而對於不同數據量狀態處理方法：
1. 少量的持久狀態：需要在多個會話間維護，可以保持在文件系統中，採用ZooKeeper或Memcached
2. 中等量狀態：採用Memcached保存，並提供持久化存儲機制
3. 大量的持久狀態：保持在結構化數據庫，或者Hadoop分佈式文件系統中環境是執行軟件系統的一組計算資源，包括了所有支持軟件，數據集，網絡通信，以及執行軟件系統所需要定義的外部實體。
對於環境，我們常會分爲開發，測試，UAT，生產等多個環境，但是這並不是雲平臺特有的屬性。簡單的創建和快速遷移環境的能力纔是雲平臺特有的能力。而這正是 DevOps 裏面實現持續集成和交付的關鍵。
將生產輕鬆地從一個環境切換到另一個環境的結果就是使業務連續性的實現變得更加容易。業務連續性意味着當主數據中心發生災難的時候業務能夠繼續運作。
第 2 章整體寫得相當弱，特別是對於 DevOps 爲何需要和雲結合，維護需要 PaaS 平臺能力沒說透徹。對於這部分內容可以參考我前面的一篇文章說明：
DevOps 最佳實踐 - 處理好敏捷研發，持續集成和容器雲三者集成
運維
運維整體架構可以參考 ITIL 標準體系。運維服務包括供給硬件，提供軟件，或者支持不同的 IT 功能。由運維提供的服務還包括了 SLA 服務等級水平協議的規格說明，軟硬件環境狀態監控，容量規劃，事件管理，故障和問題跟蹤處理，日常環境檢查，環境和數據備份，業務連續性和信息安全等。
容量規劃實際上仍然需要業務部門或 IT 項目提供具體的容量需求，運維部門在整體進行容量測算和規劃，以在滿足業務系統性能需求的前提下保證最高的資源利用率。
比如一個業務系統在進行前期方案設計的時候就要做好業務模型測算，做好應用容量規劃工作，對於業務模型測算可以參考：
IT 方案硬件資源預估 - 從 TPCC 規範到業務能力測算模型
軟硬件的性能和狀態監控是實施了雲平臺後運維人員工作的一個重大改變，即底層資源已經被雲平臺接管，運維人員日常監控不再是傳統方式登陸到物理服務器或虛擬機後臺，因爲這些資源本身也可能是動態在變化。在這種情況下運維更加需要藉助雲平臺提供的性能監控分析和日誌查看工具來輔助完成運維監控工作。
DevOps 不僅僅是考慮軟件變更在交付過程中的自動化，也需要考慮後續運維過程的自動化。所以對於運維這塊的自動化和智能化專門發展了 AIOps 分支。
AIOps 首先要解決自動化運維，其次纔是解決智能化運維，對於智能化運維本身也包括了基於已有規則的智能化處理，和基於運維數據日誌分析後的自動化規則生成和處理。
對於 AIOps 可以參考我前面輸出的這篇文章。
IT 服務治理
單獨的一個內容，需要提供什麼樣的服務，安全要求如何，合規要求如何？SLA 服務級別如何定義？日常的變更，發佈，問題，事件管理流程是如何的？業務連續性如何保證？高可用性如何保證？這些都需要在 IT 服務和治理管控框架中進行定義。
對於服務設計需遵循標準化，松耦合，抽象，可複用，自治，無狀態，可發現，可組裝等標準原則。
在應用成功部署上線和交付後就涉及到服務移交，服務移交是開發角色和運維角色之間的一個重要銜接點，如何移交，具體究竟應該移交哪些內容？
一個簡單的原則就是：
最終移交的內容和文檔，能夠確保運維人員後續的日常運維和管控要求。服務移交一定不是移交一個全黑盒的軟件部署包，否則後續運維人員很難真正進行運維。
監控是運維過程中最重要的核心，因爲它收集事件，檢測事故和度量以判斷是否符合服務等級協議。它提供服務改善的基礎。服務等級協議也可以定義和監控運維活動，例如事故發生後的響應時間。監控的結果由開發或運維團隊來進行分析並採取行動。
監控可以和其他控制結合在一起，例如對雲資源的自動伸縮控制。
**由 IT 服務和日常運維來反向推動持續服務改進：**這個實際可以單獨寫一篇文章來談，持續服務改進的主要焦點是在 IT 服務和業務需求之間達成一致。
ITIL 提出的持續改進關鍵步驟包括了提出目標 -》定義度量和 KPI-》採集數據 -》分析數據 -》改進方案和計劃 -》執行改進 -》觀察和分析結果。
同傳統發佈不同，DevOps 發佈屬於高頻率的小規模發佈，可以將 DevOps 發佈視爲更小規模的併發流。一種審視 DevOps 和 ITIL 之間關係的方法是，DevOps 對各種 ITIL 服務提供持續交付，而不是將這些服務打包進主要發佈版本。（如何理解？）
書裏面這部分內容仍然沒有將 DevOps 和傳統運維過程的交叉點講太明白。
微服務架構和 DevOps
實施 DevOps 往往需求架構調整，其關鍵原因就是儘量減少每次部署動作對整體應用的影響，同時匹配前面談到的持續高頻，小規模發佈的需求。而這種調整的關鍵就是微服務架構。對於微服務架構我前面很多文章都已經談到過了，但這本書這部分仍然沒有講透。
微服務架構對於部署流水線作業帶來的好處可以總結爲：
1. 團隊可以按微服務模塊單獨劃分，減少團隊之間的耦合和交叉影響
2. 多個微服務模塊組件松耦合，完全可以獨立自治管理，對於變更發佈僅需要發佈最小組件單位，降低風險
3. 微服務模塊更加容易部署到輕量Docker容器，實現快速的自動化部署和集成微服務架構本質仍然是組件化架構 + 接口服務化，可以看到這種松耦合架構，再加上單個可以獨立管理和部署的組件更加輕量，方便我們更加容器去實施自動化部署和持續集成。也方便軟件和服務部署時的最小化原則。
在傳統的單體架構轉變爲微服務架構後，你管理的模塊數，管理的接口集成點數都呈現指數級別的增加，如果你還是採用人工去處理編譯，構建，集成和部署問題，那麼將極大的耗費人力工作量投入。
也就是說微服務轉型本身也推動了通過 DevOps 的自動化流水線來實現持續集成和持續交付。但是微服務化本身是技術層面的詞彙，而對於最終業務用戶來說仍然看到的是一個完整的應用系統。因此這裏就存在應用系統 -》微服務模塊的兩層結構。
這也是我多次提到的 DevOps 流水線必須支持父子多級流水線的原因。在微服務化後，整個整個 DevOps 和部署流水線過程的管理難度，即我所有的管理對象，配置和版本控制對象都必須到組件級別，同時還需要進一步管理好組件間的集成和依賴關係。
構建和測試
從代碼提交到版本控制系統開始，整個部署流水線的工作就啓動。
部署流水線工作一個重點就是持續集成，對於持續集成我在前面博客有文章專門談到過了，書裏面介紹了定義持續集成的一種方法是在一個階段和下一個階段之間有一個自動觸發器，直到集成測試。持續集成需要完成代碼構建打包，部署，單元測試，環境遷移，集成測試，部署等一系列動作。
編譯和構建
對於編譯和構建兩個詞有時候在混用，實際兩者有區別，參考網上的一段描述如下：
編譯：把當前源代碼編百譯成二進制目標文件
構建：先把工程中所有源代碼編譯度成目標文件，再link鏈接成可執行文件（或者lib、dll，看具體工程）。這其中，如果有源文件在此之前知被單獨編譯過，這個文件就不參加編譯，它之前編譯時產生的目標文件參加link（鏈接）過程。構建和打包
傳統的打包往往僅僅指將編譯構建完成的文件達成一個大的 EAR 或 WAR 部署包的過程，即多個編譯完成文件達成一個大包。在採用容器雲進行部署的時候，打包過程還包括鏡像文件製作過程，即基於鏡像模板來生成一個包含了部署文件的鏡像文件。
在部署流水線中移動系統要關注兩個方面的內容，其一是可追溯性，可追溯意味着對於生產中的任何系統，可以準確的確定它如何進入生產環境。這意味着不僅要跟蹤源代碼，還需要跟蹤所有工具命令。其二在移動過程中需要關注各個環境之間的差異，以確保在環境遷移過程中能夠自動化地配置和設置各種環境變量信息。
Jenkins，Github，Ant，Maven，JUnit 等都是我們可以採用的持續集成和管理工具。
構建的目的是創建適合於部署的東西，有多種把系統元素打包並用於部署的標準方法，其中包括了打包爲 WAR 部署包，製作虛擬機鏡像或者製作類似 Docker 容器鏡像等。
我們看到在 DevOps 和 Docker 集成的時候，實際在第一次部署前首先是製作 Docker 容器鏡像，然後對整個容器鏡像文件進行部署，同時在後續環境遷移過程中遷移的基本單位也是該容器鏡像文件。
部署
部署是將服務的某個版本投入到生產環境的過程。對於服務部署更加需要關注的是後續服務的版本升級。服務部署的總體目標是：對系統用戶產生最小影響的情況下，將服務的升級版本投入到生產環境中，這些影響可能是失敗或停機時間。
在容器雲中的部署，則是指從鏡像倉庫中拿到鏡像文件在進行實例化的過程，而非直接將部署包部署到虛擬機或容器中。
服務的變更有三個原因：修復錯誤，提升服務質量或者增加新功能。
對於微服務模塊的部署，其場景往往更加複雜，一方面是微服務模塊本身的部署和應用託管，一方面是需要將微服務模塊提供的微服務 API 接口註冊到微服務網關。同時可以看到對於微服務模塊本身在進行服務升級或變更的時候需要全面的分析微服務模塊和服務 API 接口相互之間的依賴和影響關係。
注：在當前一個完整的微服務應用體系內部，K8s+Docker 容器雲平臺可以和類似 SpringCLoud 框架體系，Eureka 等註冊中心實現集成。即實現在微服務模塊自動化部署完成後自動進行微服務的註冊。
對於灰度發佈或滾動升級是保證系統安全可靠運行的一個常見方法，爲了實現滾動升級需要 PaaS 管理平臺和微服務模塊本身的配置改造來支撐。滾動升級在資源使用方面更加有效，但是容易引起邏輯一致性問題：
1. 單個服務多個版本同時服務，容易提供不一致的服務
2. 客戶端可能假設依賴服務的一個版本，但是實際上是由另外一個版本服務提供邏輯一致性的解決方法是使用某些功能開關的組合，向前或向後兼容，以及版本意識和管理。部署必須偶爾回滾，對於功能開關還需要支持回滾功能。
功能開關用來控制是否激活一個功能，而在判斷一個功能是否激活的時候，需要判斷是否所有涉及到該功能的服務都全部升級完成，只有全部升級完成才能夠在所有虛擬機上同時激活該功能。同時在分佈式架構和集羣中，還需要採用 ZooKeeper 等事務協調機制來保證一致性。
服務版本需要支持向前兼容性，如果一個服務版本升級不能向前兼容，這就意味着所有原來消費老服務版本的系統或模塊都需要進行修改。在這種情況下往往只能夠發佈一個新版本服務，保證新老版本服務同時運行，並在後續變更中逐漸消亡或替代老服務版本。
部分部署方法：藍綠髮布和金絲雀發佈。
注意兩種發佈模式實際都會有新版本和舊版本兩套環境，在藍綠髮佈下流量全部切換到新版本環境，如果出現問題再切換回去；而對於金絲雀發佈則是先切換少量流量到新版本環境，如果沒有問題再逐步完成更多流量的切換。
提供自動化的回滾能力仍然是在自動化部署和持續集成中需要考慮的問題，而對於回滾真正的難點在於數據庫和數據的回滾，而不是部署包和鏡像文件的回滾。對於數據的回滾當前仍然是一個難題，如果是完全恢復上一次的數據庫備份，仍然需要耗費相當長的時間才能夠完成。
監控
隨着 DevOps 的發展對監控提出了新的挑戰，DevOps 的持續交付，持續部署和強烈依賴自動化意味着更加頻繁的系統變更，同時在使用微服務架構時也使得數據流的監控更具挑戰。這裏面實際的難點包括了多方面：
1. 持續變更增加了監控本身的複雜度，持續的變更和部署使整個環境處於一種不穩定狀態。
2. 和雲環境的集成增加了監控難道，特別是PaaS平臺集成後底層資源往往處於不可見狀態。
3. 監控已經從傳統的網管類資源監控，轉移到了應用和服務監控，如APM應用性能分析和服務監控。
4. 微服務架構下微服務模塊和服務接口都成倍增加，即要監控部署包又要監控服務接口
5. 在大型分佈式系統中，管理和分析日誌成爲一個大的挑戰對於 DevOps 的監控，我們一定要意識到一個大的變化點，即從傳統的網管應用對資源層的監控，轉移到了對應用和服務本身的性能監控分析。監控不再侷限於傳統的 CPU 和內存，數據庫和中間件關鍵指標，而更多的變化爲對應用本身的性能，服務性能，服務調用鏈的實時分析和監控。
無代理監控方案對應用和環境侵入最小，配置容易，但是可能需要開放更多端口，存在安全隱患。同時無代理方案本身監控的指標詳細度往往也不足夠。
監控的目的和用途，書裏面主要列舉了如下幾個方面的內容：
1. 故障檢測：包括兩種方式一種是完全外置，一種是需要內置代理到應用或服務器
2. 性能下降檢測：對於訪問延遲，吞吐量，CPU和內存利用率等是常用的監控指標體系。
3. 容量規劃：長期容量規劃需要人工進去，而短期完全藉助PaaS平臺本身的資源動態調配擴展能力。
4. 用戶交互：最好理解爲對用戶訪問行爲信息的數據採集和分析，包括訪問時長等性能信息。
5. 入侵檢測：主要是通過設置的安全策略和網絡流量監測來判斷是否遭到入侵。**數據採集（用戶行爲，運維日誌，應用和服務器狀態信息）+ 預設報警或預警規則 =》實時警告。**監控的核心是記錄和分析運維時間序列數據。監控系統可以直接度量或收集存在的數據，統計，日誌，然後轉換爲指標，這些指標的屬性包括了時間和空間。然後使用預定義的協議將這些數據傳輸到存儲庫。
日誌是事件的時間序列，日誌在監控中起着非常重要的作用，尤其是在 DevOps 設置中。對於日誌監控不再只是傳統運維中的數據庫和中間件日誌，在 DevOps 中運維人員已經成爲第一干系人，因此日誌包括了應用和服務的關鍵日誌信息，這些日誌方便運維人員進行故障診斷和問題排查。
日誌關鍵信息
日誌關鍵信息包括了機器 ID，進程 ID，類型，錯誤等級，時間，詳細內容，關鍵標籤等。對於日誌監控，現在常見的 ELK(ElasticSearch, Logstash, Kibana) 是一個完整的覆蓋日子採集，分析和可視化展示的完整解決方案。
而對於 flume 更多隻是日誌採集方案，當然也可以基於 flume，storm，kafka 等主流技術來自定義適合業務需求的日誌採集和監控解決方案。
監控系統向運維人員提供重要的事件信息，這些信息以警報或警告的形式提供，其滿足預設的觸發條件的時候就被觸發。在監控系統中，將包含大量覆蓋系統很多方面的大量指標，意味着可能會產生大量的警報或警告信息，因此在預警或報警規則設置的時候需要折中處理，否則會告警疲勞。
對於監控的工具，可以分爲三大類工具進行分析
1. 傳統的網管類監控工具：例如Nagios, Zabbix等開源監控解決方案。
2. 基於日誌採集和分析類工具：例如前面談到的ELK解決方案，Flume+Storm+Kafka解決方案等。
3. APM應用性能監控工具：基於自上而下的監控和分析路線，從應用和服務入手再到資源層。隨着 DevOps 的發展，個人更看好 APM 應用性能監控和發展，即我們傳統的對資源的監控，基於 CPU 和內存，進程等的由下而上的監控更多都是被動式的監控模式，更逐漸會被自上而下的監控，基於應用和服務驅動的監控替代，即一種主動第一時間發現問題，面向客戶並提示客戶滿意度的模式。
Prometheus（普羅米修斯）是一套開源的監控 & 報警 & 時間序列數據庫的組合。Prometheus 基本原理是通過 HTTP 協議週期性抓取被監控組件的狀態，這樣做的好處是任意組件只要提供 HTTP 接口就可以接入監控系統，不需要任何 SDK 或者其他的集成過程。這樣做非常適合虛擬化環境比如 VM 或者 Docker 。
Prometheus 應該是爲數不多的適合 Docker、Mesos、Kubernetes 環境的監控系統之一。近幾年隨着 k8s+docker 容器雲的流行，Prometheus 成爲了一個越來越流行的監控工具。
安全與安全審計
在 DevOps 的實踐中，需要考慮如下一些安全方面的活動和內容：
1. 安全審計：DevOps的全流程是否符合企業標準的安全策略，包括Dev和Ops基於安全的協作活動。
2. 部署流水線安全：整個部署流水線作業是否會受到惡意攻擊和侵入。
3. 微服務架構安全：其中重點是保留的微服務接口服務本身的安全。**安全審計：**DevOps 中一個流行語即是，基礎設施即代碼，也就是說把腳本和 DevOps 過程規格說明視爲代碼，使用和代碼相同的質量控制實踐。安全策略，監管規則和配置可以自然地內置在基礎設施代碼和自動化中以便於審計。自動化也可以幫助生成安全審計和合規性報告。
安全這章講得不太好，實際上更多是雲安全，應用安全，基礎設施安全等方面內容的歸納總結，而實際我們真正關心是 DevOps 下的安全，即 DevOps 部署流水線和微服務架構下需要怎樣的安全策略和技術配合支撐等。
在整個 DevOps 流水線設計中，實際是可以加入安全審計插件來自動化完成相關安全檢查。其中包括了代碼規範性檢查，代碼安全和漏洞掃描，同時也包括了對於容器安全方面的檢查也可以前移到 DevOps 持續集成階段來完成。
傳統的 Devs 和 Ops 也分別形成了安全關注點的兩個不同領域。開發者關注應用安全設計，而運維關注基礎設施和運維環境安全。應用安全本身也依賴於運維安全。通過基礎設施即代碼，開發人員驅動的自動化和 DevOps 工具，DevOps 正在把一些運維安全責任轉移給開發人員和工具。
對於 DevOps 實踐，從一開始就應該考慮安全驗證和確認，並且通過 DevOps 流水線自動化的在不同階段執行，包括安全檢測也可以通過自動化工具在某一個階段自動執行。但是在單元，集成和系統級別上執行合適的和半自動化的安全分析和測試不是一件簡單的事情。
對於 DevOps 的安全，不僅僅是關於應用和運維安全的，而且也是關於流水線本身的安全，例如構建 / 測試服務器安全，微服務組件安全，環境安全和動態配置期間的安全等。
其他非功能性需求
首先 DevOps 流水線本身也是一個軟件產品，這產品的最終用戶是開發和運維；其次，DevOps 流水線具有過程的屬性，相對於產品質量和性能，這裏提到的一些非功能性需求更多的與過程質量和性能相關。
對於 DevOps 流水線的非功能需求和質量關注點可以簡單描述如下：
1. 可重複性：重複相同操作的可能性程度。
2. 性能：執行DevOps操作所需要的時間和資源。
3. 可靠性：在一定時間週期，DevOps流水線和內部各軟件保持服務狀態的程度。
4. 可恢復性：失敗的DevOps操作恢復到希望狀態的程度。
5. 互操作性：特定環境下，不同的DevOps工具通過接口有效地交換信息的程度。
6. 可測試性：通過測試，DevOps運維軟件能夠很容易地展示錯誤。
7. 可修改性：修改DevOps軟件，過程或應用運維環境所需要的工作量。對於 DevOps 流水線來說，這裏面最重要的仍然是可靠性，可重複性和性能，同時還包括在出現故障後的快速恢復能力，包括了整個流水線的全程可視化監控和管理能力。這些都是遠行科技在進行 DevOps 支撐平臺研發和流水線功能的時候重點考慮的內容。
這要求流水線中的每個活動涉及到的組件或工具，都具備暴露南向和北向接口服務的能力，提供供管理監控臺進行狀態監控和日誌數據實時採集的能力。這些都是必須工作，而不是簡單的通過工具實現自動化就完事。
業務關注點
DevOps 的目的是減少從向系統提交變更到這個變更被部署在正式生產環境所需要的時間，同時保證高質量。保證高質量意味着，在將最終的高質量系統提升到正式生產環境之前，可能進行多次問題檢測和問題修復的迭代。減少問題檢測和問題修復的時間也是重要的。
因此兩個重要的度量是，從提交到初始生產環境的時間和問題檢測到修復的時間。對於 DevOps，這部分進一步從五個方面給出了實踐指導：
1. 在開發系統時，讓Dev把Ops作爲首要干係人。
2. 讓Dev更直接地參與到故障和問題處理過程中，包括對詳細異常信息和日誌的查看和分析。
3. 爲了將軟件變更部署到生產環境，強制執行一致性的過程。
4. 開發基礎設施代碼的時候採用與開發應用程序代碼相同的實踐。
5. 實施持續交付的流水線自動化作業能力。持續部署流水線
持續部署流水線主要包括了 5 個階段，即構建和測試，燒製，部署，發佈，拆解。
1. 構建和測試：版本管理工具，分支管理，自動化構建腳本和自動構建，自動化單元測試等。
2. 燒製（打包）：即製作虛擬機鏡像或輕量的Docker容器鏡像。
3. 部署：部署一個獨立的應用程序棧，需要支持負載均衡，伸縮，監控，組網和數據庫等能力。
4. 發佈：發佈重點是DNS路由器的重新分配和遷移
5. 拆解：一旦所有流量遷移到新棧後，拆解舊棧標準化的應用程序生命週期在持續部署系統中作爲一個計劃實施。標準的鏡像文件的部署也不僅僅是鏡像啓動，還涉及到服務的註冊，負載均衡的掛接，環境變量和配置文件的修改等一系列工作。
在我們自己的流水線功能設計中，重點是分爲構建，打包，部署幾個關鍵動作。構建如果是基於 Maven 的話，則是選擇指定的 Pom 文件，構建源代碼路徑。而對於打包則是進行容器鏡像製作的過程，你需要指定鏡像模板並編寫 dockerfile 來完成。對於部署重點則是設置相應的部署策略，最有動態調度策略，集羣配置，存儲配置等。
當持續集成和持續交付兩個分離的時候，一般來說並不會實現一個完整的從開發測試到生產環境的長流水線，而是會將生產環境的發佈進行單獨的流水線設計，對應到發佈管理功能。
下圖爲遠行 DevOps 介紹可參考：
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://www.toutiao.com/i6953431903194153505