《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 | 工作中心 |