读书笔记：《DevOps实践指南》

    《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）

   安全性、可靠性、灵活性
   创建学习型组织，加快流程，打造一流可靠性和安全性的产品
   跨部门协作
   做正确的事，等着被开除 -- 做正确的事，并做好承担后果的准备