1 - 趨勢與本義
隨著技術的發展, 基礎設施和應用程式之間的界限會變得越來越模糊, "服務"管理也將變得更加全面和簡單。
透過實施DevOps可以便捷地搭建包含交付流水線的研發協作平臺，可以快速實現商業價值。
在這一過程中，反對將DevOps絕對理論化、模型化，而是堅持DevOps的實踐性和靈活性。
明確“DevOps具體能做什麼？或者應做什麼？”是成功實施DevOps的一個必要前提。
DevOps就是應對產品研發、交付、運維過程中各團隊（開發、質量、運維）交匯處的工作，讓各團隊能集中精力做自己的主業。
2 - 結構與組織
2.1 關注點分離： 分開考慮系統不同的方面
- 內聚原則： 內聚（各部分之間相互關聯的程度），單模組內的高內聚是可取的
- 耦合：模組間相互依賴的程度，要實現模組間的低耦合。
- 高內聚低耦合的系統自帶關注點分離，反之亦然。
2.2 微服務
- 可以簡單地將每個微服務視為一個隱式的三層架構（表示層、業務層、資料層），
- 但通常是指業務層，包含有許多小的服務組成，彼此之間使用語言無關的協議來通訊
- 適用於持續交付：部署小型獨立的服務
2.3 康威定律
- 設計軟體的組織結構等價於軟體的組織結構
- DevOps的主要目標是與不同的角色共同協作，最好是一個跨職能團隊。
- 微服務模式正好密切反映了跨職能團隊
2.4 服務組合使用
- 不盲目推崇某個工具和服務的優點, 而是使用不同的工具和服務來提高自動化程度和效率是當前的主流趨勢
- 因此一整套的CICD環境必然包括多種工具和服務, 涉及不同的組合和整合方法
3 - 流水線
流水線是DevOps的核心，實現持續交付的核心在於Pipeline。
透過自動化流水線，讓需求小批次流轉，實現軟體短週期的頻繁交付，
把Jenkins作為基礎設施，而不是操作管理介面，這是研發協作平臺整合流水線技術的重點。
釋出計劃的管理： 在持續交付模式下，釋出操作仍然是一個嚴肅的事情，需要非常審慎的對待
- pipeline的執行結果
- codereview的結果
- 釋出視窗
- 人工檢查的結果等等
3.1 分支管理/開發流程/環境
- pull request機制: 程式碼稽核之後再進行後續操作
- 制定分支的運用策略: 對應環境/合併規則等
- 開發流程與分支相對應
3.2 自動化測試
要實現Pipeline，重點之一在於自動化測試
- 一切皆可自動化！
- 高效的自動化測試能夠使部署變更有更好的質量。
- 規範的測試流程和粒度: 包含必要的測試型別和合理的測試順序
- 例如: 靜態測試--->>構建--->>礎設施配置--->>應用程式部署--->>環境驗證--->>單元測試--->>整合測試--->>系統測試
3.3 藍綠部署
- 使用標籤名來區分藍綠環境, 實現更靈活/安全的機制
- 積極使用雲端計算環境中類似AutoScaling的功能, 靈活安全地調整伺服器數量等資源
- 只適用於狀態伺服器
- 新版本的應用程式在部署和使用前, 需要在內部/備用環境進行嚴密的測試
- 藍綠部署的架構需要和CICD進行結合
3.4 錯誤處理
- 自動觸發CICD任務開始執行, 如果執行失敗, 得到的不應該僅僅是一個通知
- 例如, 在生產環境, 必須及時發現的錯誤, 因此採取自動回滾等錯誤處理措施是極其重要的
3.5 及時通訊工具
- 來自CICD的資訊應該被合理的展現和存放, 便於追蹤關聯資訊
- 例如, 在teams或者Slack中, 應傳送到對應的頻道
4 - 雲化環境
內部雲化的工具平臺，包括內部的開發工具鏈平臺，測試工具鏈平臺，安全工具鏈平臺，運維工具鏈平臺等，將各種標準化技術平臺的能力輸送給各個業務線團隊，提升團隊整體質量和效能。
在使用雲服務的情況下, 自動化伺服器的構建和銷燬, 將使得DevOps架構更為簡潔，也就是實現了不可變基礎設施的環境
可以簡單地批次建立或銷燬基礎設施, 並實現不可變基礎設施和藍綠部署
- 快速簡單地進行不可變基礎設施的建立和銷燬
- 在不影響正常服務的情況下進行釋出操作
- 能夠將整套基礎設施回退到正常版本, 及時處理故障
- 操作簡潔, 透過命令列或API方式方便與其他工具和服務整合
5 - 資源管理
5.1 建立公司或大部門級別的標準應用庫
以標準化應用為中心，是整個研發協同活動的基石，
應用資訊可以直接對應一個服務，一個程式碼庫，一個環境，一條流水線，一個監控job,一個質效資料。
依靠應用這個維度，串聯整個研發協作過程，程式碼、資源、流水線、監控、運維、故障、質效等等都是圍繞著應用維度來開展，
開發、測試、運維、安全等等技術團隊也就可以在各自平臺上去定義它的應用，並實現無縫的銜接。
應用有了標準庫，也就有了生命，有了生命週期的管理。
應用不再只是一個乾癟的代號或標識，而是一個活動集合一個工作系列。無論是新建和停用，都會影響到一系列的工作環節，當然這個過程我們需要各種自動化串聯。
5.2 容器化的資源管理
使用容器，讓各套環境配置、軟體包、資源型別等保持一致。
軟體包管理、目錄管理、基線變更、運維指令碼等等透過一個dockfile就可以規範解決，再透過分散式配置中心實現對不同環境的配置管理，基本實現了環境的標準化以及運維服務的下沉。
6 - 監控
“如果你不能度量它，你就無法改進它。”
圍繞應用，建立一站式監控管理，包含多維度立體式的監控體系，並且透過統一的報警設定，建立共同的響應機制。
- 透過監控服務並在問題發生時採取適當的行動來緩解服務當機的影響
- 針對不同的應用程式來提供監控介面，全面瞭解當前系統的健康狀態
- 使用的監控軟體型別不同，監控的結構也有所不同
6.1 度量管理：DevOps儀表盤
建立快速和持續的從右到做的反饋尤為重要，透過建設質量和效能的資料看板，讓整個交付過程更加透明，暴露出瓶頸點並持續改進。
列舉一些常見的度量點，這些應該在應用的維度下系統展示，而不是在一個個內部平臺上去跳轉，去人工採集。
- 專案進度和風險大盤
- 需求完成率
- 專案及時率
- 程式碼靜態分析結果
- 流水線執行頻率、時長和成功率
- 釋出執行頻率、時長和成功率
- 監控報警頻率和趨勢
- 線上故障情況統計等
6.2 視覺化
- 利用KLK或者EFK技術棧可以方便, 實時地對資料進行視覺化
- 透過Logstash或者Fluentd採集伺服器的syslog/資源佔用狀態等指標, 在同一個時間軸上實現視覺化, 就可以掌握系統的整體和詳細狀態.