? ? 《DevOps實踐指南》 美 Gene Kim, Jez Humble, Patrick Debois, John Willis 著；劉征，王磊，馬博文，曾朝京 譯
- 個人理解：
? ? 向客戶交付價值，快速、高效、高質量交付
? ? 信息全流程共享、全過程參與、關注軟件全生命周期
? ??加速從開發、運維，到交付給客戶的流程
? ? 快速、高效溝通、反饋、信息共享
? ? 持續學習、實踐、改進
? ? 開發即運維、即測試，彼此交融，互相了解，相互支持
? ??-?不再是孤立存在的角色、階段，不再是互相埋怨、推諉，合作、深度合作
? ? - 盡可能早、盡可能小、盡可能快的發現問題、解決問題，彼此反饋，持續學習、實踐、改進，正向循環
- 摘錄
? ?*?前置時間：工單創建開始 ~ 工作完成結事；處理時間：實際開始處理工單開始 ~ 工單處理完成 -- 縮減前置時間，即縮減非處理時間，聚焦任務處理
? ?* 價值流：組織基于客戶的需求所執行的一系列有序的交付活動；為客戶設計、生產和提供產品或服務所需從事的一系列活動，包含信息流和物料流的雙重價值；把業務構想轉化為向客戶交付價值的、由技術驅動的服務所需要的流程
? ?改進日常工作其實比日常工作本身更重要
? ?可視化：給價值流中的所有成員，特別是開發人員，提供盡可能快速的反饋
? ?使用自動化，以讓人力做那些不能被自動化的高價值活動；確保可以執行少量可靠的自動化測試；確保高價值功能運行良好
? ?向客戶交付價值，在迭代中持續交付價值
? ?對組織當時的目標而言，每個決策都是最好的 -- 時代、認識、環境決定了決策的時代特征
- 序言/導言
? ? 開發部門和IT運維部門都存在一種固有沖突 -- DevOps的產生，在開發流程中、在軟件的全生命周期中，各階段、各角色的沖突不斷？為什么：各為其職，各掃門前雪
? ? 快速、安全、獨立開發、集成、測試、部署 -- DevOps價值體現
? ? 共同目標、反饋、持續學習 -- 實現方法
? ? 流動、反饋、持續學習和實驗 -- 實現方法
? ? IT公司目標：對變化莫測的市場做出反應；對客戶提供穩定、可靠、安全的服務
? ? 技術債務 -- 何為技術債？出來混總是要還的，過程中業務短板、技術短板、無意識、偷懶，潛在的造成了或大或小的問題，積累而形成的系統問題，或早或晚的會形成系統故障，給當事人或是后來者造成問題，即所謂的技術債
? ? 每個公司都是科技公司，無論他們認為自己處在哪個行業 ?-- 亞馬遜，阿里，本是互聯網銷售公司，現如今成為了最大的科技公司，業務推動技術 的發展
? ? 所有人都需要對自己的工作質量負完全責任
? ? 出現問題時，進行不指責的事后分析
? ? 高績效者更加敏捷和可靠、滿意度高、倦怠度低
- DevOps介紹
? ?- 敏捷、持續交付和三步法 1~4章，重點理解
? ?流動原則：加速從開發、運維到交付給客戶的流程
? ?反饋原則：建設更安全可靠的工作體系 -- 不同角色、不同維度的系統審視、體驗與反饋
? ?持續學習與實驗：打造高度信任的文化和科學的工作方式，將組織的改進和創新作為日常工作的一部分
? ?軟件開發的整個技術價值流中，涉及產品管理、開發、QA、IT運維和信息安全專員等不同角色，在更低的成本和努力下，保障產品的高質量、可靠性、穩定性、安全性 -- DevOps目標，與軟件開發的目標是完全一致的
? ?精益原則：聚焦如何唱片兒過系統性思考為客戶創造價值，系統性思考的范圍涉及建立持久目標、擁抱科學思維、創造流和拉動（而非推送）的協作模式，提倡從源頭保證質量、以謙遜為導向，尊重流程中的所有個體
? ?*?前置時間：工單創建開始 ~ 工作完成結事；處理時間：實際開始處理工單開始 ~ 工單處理完成 -- 縮減前置時間，即縮減非處理時間，聚焦任務處理
? ?* 價值流：組織基于客戶的需求所執行的一系列有序的交付活動；為客戶設計、生產和提供產品或服務所需從事的一系列活動，包含信息流和物料流的雙重價值；把業務構想轉化為向客戶交付價值的、由技術驅動的服務所需要的流程
? ?持續不斷的基于全局目標來優化整個系統
? ?完成時間/精確的總花費時間=%C/A=返工批標 -- 各階段階完成時間占比，確認“直下有用的工作時間”，即專心于有用的工作、而不必修得錯誤信息、補充信息、或澄清本該確定信息的時間
? ?DepOps行為和模式：開發到運維工作的快速從左向右流動 -- 避免開發工作大量堆積而未發布到生產系統，造成集中發布后問題集中出現；持續、快速的工作反饋機制；具有創意和高可信度的企業文化，支持動態的、嚴格的、科學的實驗
? ?使工作可見，技術行來的工作內容是不可見的；限制在制品數，減少并行工作數量，避免等待和相互制約；減少批量大小，及時發現問題，及時改正；減少交接次數，強化流程自動化，通過系統完成流程，減少依賴，強化階段參與，減少人員溝通、審批、知識交接，減少信息丟失；持續識別和改善維束點（痛點）
? ? 浪費：使用了超出客戶需求和他們愿意支付范圍的任何材料或資源的行為：半成品、額外工序（未給客戶增值）、額外功能、任務切換、等待、移動、缺陷、非標準或手動操作、填坑俠 -- 浪費和困境都可視化，系統的改進
? ?建立快速、頻繁、高質量的信息流，包括反饋和前饋回路
? ?復雜系統的一個特點：相同的事情做兩次，結果未必相同
? ?更安全的工作：管理復雜的工作，從中識別出設計和操作問題；群策群力解決問題，從而快速構建新知識；在整個組織中，將區域性新知識應用到全局范圍；持續培養力才 -- 不斷的對設計和假設進行難證
? ?價值流 --> 快速、頻繁、高質量的信息流
? ?遏制問題，防止蔓延，定位和處理問題，解決問題并構建新的知識 -- 群策群力
? ?盡可能在早期階段，通過全民總動員的方式來解決小問題 ?-- 事故的發生具有一次性難追溯性
? ?做決策的地方一般遠離執行工作的地方
? ?價值流中的每個人在他們的控制領域里發現并解決問題，把質量、安全、決策置于開展工作的場景中，真正的讓所有人負起責任
? ?讓成品以最低的成本、最高的質量和最快的流程生產出來
? ?技術價值流的核心是建立高度信任的文化
? ?如果沒有能力或意愿去改進現有的流程，就會持續飽受眼前問題的困擾和折磨 -- 比日常工作更重要的，是對日常工作的持續改進，把局部發現轉化為全局優化 -- 建立全局知識庫
? ?解決問題的能力和學習的價值
? ?－實踐：從何處開始，5~23章，參考
? ?性能取決于應用架構在當前或重構后是否具有可測試性和可部署性
? ?記錄型系統 和 交互型系統
? ?理解、可視化，梳理出創造價值的所有步驟 -- 組織中的每個人都有必要了解當前的工作狀態，擁有共同的目標，共同的任務列表，統一的術語
? ?保持小跨度的改進計劃，加強反饋回路
? ?每個團隊能夠獨立向客戶交付價值，發展組織能力和員工的工作習慣；多技術交叉培訓有利于員工的職業發展
? ?共同的痛點可以強化團隊的共同目標
? ?維持共同目標和相互信任，保證小團隊獨立運作，避免過多不必要的溝通和協調
? ?將運維融入日常開發工作 -- 誰的代碼誰發布、誰維護
? ?構建自服務能力
? ?改進日常工作其實比日常工作本身更重要
? ?應保證價值流的每個階段都使用類生產環境
? ?在過程中保證質量，而不是事后檢查質量，保證產出可工作和可交付的代碼
? ?完成，不是指開發人員認為已經完工，而是指可以成功的構建和部署應用，并且確定在類生產環境下按預期運行
? ?將所有人工件納入版本控制系統，確保有唯一的事實來源，從而能快速、可重復和文檔化的重建生產環境 －－版本控制系統中的所有內容處于可構建和可部署的狀態
? ?可視化：給價值流中的所有成員，特別是開發人員，提供盡可能快速的反饋
? ?單元測試的目的是證明應用的某一部分滿足程序員的預期；驗收測試的目的是證明應用滿足客戶的愿望；冒煙測試通常指針對整個應用進行的一組成熟的驗收測試 －－ 測試應滿足度量的測試覆蓋率，否則在驗證、部署時應判定失敗
? ?應盡早的在測試中發現錯誤，應心可能多的發現錯誤，應更快、更早、更廉價的識別錯誤
? ?使用自動化，以讓人力做那些不能被自動化的高價值活動；確保可以執行少量可靠的自動化測試；確保高價值功能運行良好
? ?安燈繩機制 --?當錯誤發生時，立即采取一切必要措施發現并修復錯誤
? ?向客戶交付價值，在迭代中持續交付價值
? ?開發、測試、類生產環境、生產環境采用相同的部署機制，基于版本控制系統的構建可部署到任何環境中，提高最終生產環境的部署成功率
? ?使用特性開關，實現功能的A/B、金絲雀測試，盡可能早的發現問題、解決問題
? ?對組織當時的目標而言，每個決策都是最好的 -- 時代、認識、環境決定了決策的時代特征
? ?緊耦合的單體架構 －> 松耦合的微服務，強化功能隔離，去中心化服務 －－ 必須安全的進行架構演進
? ?建立流程，使得反饋、信息可見，便于大家學習
? ?可視化：測試量一切，讓大家可以輕松的測量一切，展示一切
? ?信息輻射器，information radiator：團隊工作的顯眼位置上的手寫、繪制、印刷或電子信息展示，讓所有團隊成員以及路過的人都可以快速瀏覽最新信息 －－ 盡可能多的向所有技術利益干系人展示，讓大家準確的知道當前的程序和服務的狀態、可能會正在受到什么影響；快速確認功能是不是按預期正常運行
? ?盡早發現并修復問題，在問題還小、容易修復時修復他們，減少救火和危機次數
? ?統計和可視化：均值、均數、標準差
? ?DevOps：運維人員不再獨自、孤立的解決生產環境中的代碼缺陷，所有人都在幫忙修復生產環境缺陷，并在平衡新功能開發
? ?跟蹤工作結果有助于發現改進流程的方式
? ?在開發過程的最初階段融入可運維性需求
? ?實驗的目的是做出明智的決策，確何推出可用的功能
? ?通過端到端的回路來幫助強化組織學習
? ?反事實思維：人們往往針對已發生的生活事件創建其他可能的敘述，想像中的事件，而非現實事件
? ?最了解問題的人通常是離問題最近的人
? ?每個團隊都應該對自己的質量負責，所有變動都應有合適的人進行評審
? ?進行不指責的事后分析：梳理所有相關事件的時間表，記錄最佳理解；進行事實陳述，而不是反事實的、推測性陳述
? ?降低判定故障的閾值，尋找并放大更弱的故障信號，以便更深入的學習
? ?不能將技術工作看成是完全標準化的，力圖實現流程合規
? ?每個人都應該坦然面對失敗并承擔責任，并能夠從失敗中學習
? ?將錯誤注入到生產環境中，讓故障以特定和受控的方式方法，如 搗亂猴 實驗，演練日game day的災難恢復演練
? ?關注可恢復性，意味著公司能夠以常規、平常的方式處理可能在大多數組織里引發危機的事件
? ?彈性工程學：旨在通過向關鍵系統中注入大規模故障來提高可恢復性的練習
? ?更具恢得力的服務和更高程度的確定性；更多的學習機會和更具可恢復性的組織
? ?組織唯一的可持續競爭優勢就是比對手更快的學習能力
? ?將局部學習轉化為全局知識
? ?將反復發生的工作變得能夠重復、確定的執行：需要做什么 ，需要誰去執行，完成這個工作的所有步驟
? ?－－在邊緣探索和測試 ，獲得下一個有助于成功的創新
? ?改善閃電戰，解決關心的問題，不斷識別和解決問題的能力
? ?人們學習新東西時可能會覺得害怕、尷尬或羞恥；克服無從下手的心理恐懼
? ?創建易于審計、能證明控制有效性的流程
? ?在技術價值流中全面整合QA和運維目標
? ?建立共享庫，任何人都能輕松找到和重用組織的集體知識
? ?靜態分析工具將檢查程序代碼所有可能的運行時行為 －－ 但缺不實際的場景
? ?遙測系統
? ?有效的變更管理政策將認識到不同的類型變更會帶來不同的風險，并且有不同的方式來處理不同的變更（變更請求單RFC）
? ?安全性、可靠性、靈活性
? ?創建學習型組織，加快流程，打造一流可靠性和安全性的產品
? ?跨部門協作
? ?做正確的事，等著被開除 -- 做正確的事，并做好承擔后果的準備
? ?職責分離 －－ 強調主職責與全員負責并存？
? ?具有知識性和學習性制品
? ?精益原則：堅信前置時間，把原材料轉換為成品所需的時間，是提升質量、客戶滿意度和員工幸福感的最佳預測指標；小批量尺寸是短前置時間的一個最佳預測指標
? ?精益原則專注：為客戶創造價值，要求系統性思考，持之以恒，擁抱科學思維，創建流和拉動（而不是推動）的模式，從源頭保證質量，以謙遜為導向，尊重每一個人 －－ 主動性
? ?優化IT價值流，將業務需求轉化成為向客業內提供價值 的能力和服務
? ?人為錯誤是意外和事故虵主要且唯的根源 －－ 都是人做的；事故調查就是識別事實和原因之間的邏輯和關聯關
? ?事后分析會議：對事不對人；對事故完整的時間表達成一致的認識；列出所有造成事故的人為因素和技術因素（不去異存同）；就會后首要任務清單達成一致意見，實現預期結果的最小增量步驟；? ? ?討論事故的衡量指標和事故對組織造成的影響
? ?基本概念列表
| DOP & Handbook Glossary) | |
| 英文? | 中文 |
| A/B Testing? | A/B 測試。“先驗”性實驗，為同一個目標制定A/B兩個方案，分給不同的人體驗，以確認哪個方案更符合設計 |
| Acceptance Stage? | 驗收階段 |
| Acceptance Test-Driven Development (ATDD)? | 驗收測試驅動開發 |
| Acceptance Test? | 驗收測試 |
| Accident? | 事故 |
| Affinity? | 親和 |
| Agile? | 敏捷 |
| Andon Cord? | 安燈繩 |
| Anomaly Detection Technique? | 異常探測技術 |
| Antifragility? | 抗脆弱性 |
| Application Deployment? | 應用部署 |
| Artifact Management? | 構件制品庫管理 |
| Artifact? | 制品 |
| Automated Test? | 自動化測試 |
| Automation? | 自動化 |
| Backlog? | 待辦事項列表 |
| Bad Apple Theory? | 壞蘋果理論 |
| Bad Path? | 壞路徑 |
| Batch Size? | 批次尺寸、批量大小 |
| Blame? | 指責 |
| Blameless Post Mortem? | 不指責的事后分析 |
| Blamelessness? | 免責 |
| Blue-Green Deployment? | 藍綠部署 |
| Blue-Green Deployment Pattern? | 藍綠部署模式 |
| Branching Strategy? | 分支策略 |
| Brownfield? | 棕地 |
| Build? | 構建 |
| Business Value? | 業務價值 |
| Canary Release? | 金絲雀發布 |
| Canary Release Pattern? | 金絲雀發布模式 |
| Card? | 卡片 |
| Change Category? | 變更類別 |
| Change Schedule? | 變更計劃 |
| Cloud Computing? | 云計算 |
| Cloud Configuration File? | 云配置文件 |
| Cluster Immune System Release Pattern? | 集群免疫系統發布模式 |
| Code Branch? | 代碼分支 |
| Code Review Form? | 代碼審查表 |
| Codified Nfr? | 成文的非功能需求 |
| Collaboration? | 協作 |
| Commit Stage? | 提交階段 |
| Commit Code? | 提交代碼 |
| Compliance Requirement? | 合規性要求 |
| Compliance Checking? | 合規性檢查 |
| Compliancy Officer? | 合規檢測官 |
| Configuration Management? | 配置管理 |
| Container? | 容器 |
| Continuous Deployment? | 持續部署 |
| Continuous Integration? | 持續集成（ CI） |
| Continuous Delivery? | 持續交付（ CD） |
| Conways Law? | 康威定律 |
| Cycle Time? | 周期時間 |
| Defect Tracking? | 缺陷跟蹤 |
| Definition Of Done (DoD)? | 完成的定義 |
| Dev Ritual? | 開發慣例 |
| Developer? | 開發人員 |
| Development? | 開發 |
| Devops Transformation? | DevOps 轉型 |
| Downstream/Upstream? | 下游/上游 |
| Downwards Spiral? | 惡性循環 |
| E-Mail Pass-Around? | 電子郵件輪查 |
| Expand/Contract Pattern? | 擴張/收縮模式 |
| Exploratory Test? | 探索性測試 |
| Fast Feedback? | 快速反饋 |
| Feature? | 特性 |
| Feature Flag? | 特性標志 |
| Feature Toggle? | 特性開關 |
| Feedback/Feedback Loop? | 反饋/反饋回路 |
| Feedforward/Feedforward Loop? | 前饋/前饋回路 |
| Flow? | 流動 |
| Gated Commit? | 門控提交 |
| Gaussian Distribution? | 高斯分布 |
| Green Build? | 綠色構建 |
| Greenfield? | 綠地 |
| Handoff? | 交接 |
| Hand-Off Readiness Review? | 交接就緒評審 |
| Happy Path? | 愉快路徑 |
| Hypothesis-Driven Development? | 假設驅動開發 |
| Incident? | 事件 |
| Information Radiator? | 信息輻射器 |
| Infosec? | 信息安全 |
| Infrastructure Automation? | 基礎架構自動化 |
| Infrastructure As Code? | 基礎架構即代碼 |
| Integration Tests? | 集成測試 |
| I-Shaped, T-Shaped, E-Shaped? | I 型、 T 型、 E 型 |
| Iteration? | 迭代 |
| Itsm (It Service Management)? | IT 服務管理 |
| Ji-Kotei-Kanketsu (JKK)? | 質量檢查（ JKK） |
| Just Culture? | 公正文化 |
| Just-In-Time (JIT)? | 準時制 |
| Kaizen (In Lean)? | 改善 |
| Kaizen Blitz (Or Improvement Blitz)? | 改善閃電戰 |
| Kanban? | 看板 |
| Kata? | Kata |
| Large Batch Size Merge? | 大批量合并 |
| Latent Defect? | 潛在缺陷 |
| Lauching Guidance? | 發布指導 |
| Launch Readiness Review? | 投產就緒評審 |
| Lead Time? | 前置時間 |
| Lean? | 精益 |
| Learning Culture? | 學習文化 |
| Logging Level? | 日志級別 |
| Loosely Coupled Architecture? | 松耦合架構 |
| Micro-Service? | 微服務 |
| Minimum Viable Product? | 最小化可行產品 |
| Monitoring Framework? | 監控框架 |
| Monolithic Application? | 單體應用 |
| Monolytics? | 單體應用 |
| MTTR? | 平均恢復時間 |
| Non-Functional Requirement (NFR)? | 非功能性需求 |
| Non-Functional Requirement (NFR) Testing? | 非功能需求測試 |
| (Non) Ideal Testing Pyramid? | （非）理想測試金字塔模型 |
| One-Piece-Flow? | 單件流 |
| Operations? | 運維 |
| Operations Story? | 運維故事 |
| Ops Liaison? | 運維聯絡人 |
| Organisational Typology Model? | 組織結構模型 |
| Organization Archetype? | 組織原型 |
| Organizational Learning? | 組織級學習 |
| Over-The-Shoulder? | 觀察者評審 |
| Package? | 包 |
| Pair Programming? | 結對編程 |
| Peer Review? | 同行評審 |
| Pilot? | 試點 |
| Pipeline? | 流水線 |
| Plan-Do-Check-Act Cycle (PDCA Cycle)? | 計劃-實施-檢查-改進循環（戴明環） |
| Post-Mortem? | 事后分析 |
| Process Time? | 處理時間 |
| Product Owner? | 產品負責人 |
| Pull Request Process? | 拉動請求流程 |
| QA? | 質量保證 |
| Reduce Batch Size? | 降低批次尺寸 |
| Reduce Number Of Handoffs? | 減少交接次數 |
| Regression Test? | 回歸測試 |
| Release Branch? | 發布分支 |
| Release Manager? | 發布經理 |
| Release Pattern? | 發布模式 |
| Retrospective? | 回顧 |
| Rhythm? | 節奏 |
| Roll-Back? | 回滾 |
| Sad Path? | 不愉快路徑 |
| Safety Culture? | 安全文化 |
| Safety Conditions? | 安全條件 |
| Scaling? | 規模化 |
| Scrum? | Scrum |
| Scrum Master? | Scrum Master |
| Security Testing? | 安全測試 |
| Self Service Capability? | 自服務能力 |
| Service Deployment? | 服務部署 |
| Service Level Agreement (SLA)? | 服務級別協議（ SLA） |
| Shared Goal? | 共同目標 |
| Shared Operations Team (SOT)? | 共享運維團隊 |
| Shared Version Control? | 共享版本控制 |
| Single Repository? | 單一存儲庫 |
| Smoke Testing? | 冒煙測試 |
| Sprint? | 沖刺 |
| Staging? | Staging |
| Staging Environments, SIT? | 準生產環境 |
| Stakeholder? | 利益干系人 |
| Standard Deviation? | 標準差 |
| Standard Operations? | 標準運維 |
| Static Code Analysis? | 靜態代碼分析 |
| Swarm? | 聚集、聚焦、會診、圍觀（動詞） |
| Swarming? | 聚集 |
| System Of Engagement (SOE)? | 交互系統 |
| System Of Records (SOR)? | 記錄系統 |
| Technical Debt? | 技術債務 |
| Technology Adaption Curve? | 技術適應曲線 |
| Technology Executive? | 技術主管 |
| Telemetry? | 遙測 |
| Test Coverage Analysis? | 測試覆蓋率分析 |
| Test Story? | 測試故事 |
| Test-Driven Development? | 測試驅動開發 |
| The Downward Spiral - TDS? | 下行螺旋 |
| The Agile Manifesto? | 敏捷宣言 |
| The Lean Movement? | 精益運動 |
| The Simian Army:? Chaos Gorilla? Chaos Kong? Conformity Monkey? Doctor Monkey? Janitor Monkey? Latency Monkey? Security Monkey | 猿猴軍團（可靠性監控服務）： 搗亂大猩猩 搗亂金剛 一致性猴子 醫生猴子 看門猴子 延遲猴子 安全猴子 |
| The Three Ways? | 三步工作法 |
| Theory Of Constraints? | 約束理論 |
| Ticketing System? | 工單系統 |
| Tightly-Coupled? | 緊耦合 |
| Tool-Assisted Review? | 工具輔助評審 |
| Tool? | 工具 |
| Toyota Production System (TPS)? | 豐田生產系統 |
| Toyoto Kata? | 豐田套路 |
| Transformation Team? | 轉型團隊 |
| Trunk? | 主干 |
| User Story? | 用戶故事 |
| Value Stream Mapping? | 價值流映射 |
| Value Stream? | 價值流 |
| Velocity? | 速率 |
| Version Control? | 版本控制 |
| Virtualized Environment? | 虛擬化環境 |
| Visible? | 可視的 |
| Visualisation? | 可視化 |
| Waste? | 浪費 |
| Waste Reduction? | 減少浪費 |
| Waterfall? | 瀑布式 |
| WIP (Work In Progress / Process)? | 在制品 |
| WIP Limit? | 在制品限制 |
| Work Center? | 工作中心 |
)
