最近公司在严抓代码质量+需要学习自动化集成与测试。 感觉Devops是一种趋势，相信随着历史的推进，一个越来越讲究质量的时代即将到来。而且精益理念不仅仅应用在IT行业，人生成长也应该敏捷、快速迭代。 一、Devops的三原则。 内容：回顾DevOps的发展史，探讨了DevOps组织转型的三步工作法：流动原则、反馈原则和持续学习与实验原则。 1. 流动： 使工作可见、限制数量、减少批量大小，减少交接次数，持续识别改善约束点，消除价值流中的困境和浪费。 2. 反馈原则 建立快速的反馈机制，对于实现技术价值流中高质量、可靠性和安全性至关重要，要在问题发生时识别问题、群策群力解决问题并构建新的知识，在源头控制质量，并且不断为工作重心做优化。 3. 持续学习与实现 接收系统中会发生故障的实时，并鼓励讨论任何问题，以建立一个安全的工作系统，还要求将日常工作的改进制度化，把局部成果转化为可供组织全局使用和学习的恶知识以及不断向日常工作注入张力。 二、Devops实践: 内容：DevOps转型的多个方面，包括选择切入点，理解架构与组织的关系，以及组建转型团队，还探讨了如何将运维工作融入开发团队的日常工作。 1. 选择合适的切入点 谨慎得选择切入点，选择不会对组织造成巨大影响的团队，选择有开拓精神的团队选择有多领域知识的人，选择和各部门有良好关系的人。 2. 通过绘制价值流图了解到了向客户交付价值所要做的工作。 3. 运用康威定理设计组织架构 4. 将运维融入日常开发工作 三、流动技术实践: 内容：实现了使工作从开发到运维快速流动的架构和技术实践，从而快速、安全地向客户交付价值。 1. 构建从开发到运维的快速工作流，需要确保任何人都能按需获得类生产环境。通过让开发人员在软件项目的最初阶段就使用类生产环境，可以显著降低生产环境出现问题的风险。为实现全面自动化测试奠定了基础 2. 创建了一组全面的自动化测试，用来确保构建始终处于绿色的可部署状态。我们在部署流水线中组织好了测试套件和测试活动，还建立了规范，要求无论谁的代码变更导致自动化测试失败，大家都要竭尽全力地将系统恢复到绿色状态。 3. Puppet Labs的《2015年DevOps现状报告》表明，基于主干的开发方式能带来更高的生产力、更好的稳定性，甚至更高的工作满意度和更低的职业倦怠率。 4. 将发布和部署融入日常工作，能够把部署时间从几个月缩短到几分钟，使组织能够快速地向客户交付价值，同时避免意外事故和服务中断。此外，开发人员和运维人员的紧密合作，能使运维工作变得人性化。 5. 使工作从开发到运维快速流动的架构和技术实践，从而快速、安全地向客户交付价值。 四、反馈技术实践: 内容：通过实施反馈回路，可以让每个人都为实现共同的目标而协作，当发生问题时及时发现问题，并通过快速检测和恢复的机制，保障所有功能不仅能按照设计在生产环境中运行，而且还实现了组织目标和组织学习。我们还研究了如何让开发和运维共享目标，从而提高整个价值流的健康程度。 1. 在问题发生时就能发现问题是多么地重要，这样才能及时地找出原因，并迅速补救。 2. 本章探讨了几种用于分析生产环境遥测数据的统计技术，通过它们能更早地发现和解决问题，并且能在问题较小的时间予以解决，从而避免造成灾难性后果。这些技术使我们能识别出那些微弱的故障信号，并及时采取行动，从而建立一个更安全的工作系统，同时提高实现目标的能力。 3. 反馈机制，它使得我们可以在日常工作的每个阶段改进服务，不管是将变更部署到生产环境，在出现问题时请求工程师修复代码，让开发人员跟踪下游工作，建立非功能性需求来帮助开发团队编写更优的生产就绪代码，还是将有问题的服务交回给开发团队自己管理。 4. 成功不但需要快速地部署和发布软件，还要在实验方面超越竞争对手。采用假设驱动的开发、定义和度量客户获取渠道，以及A/B测试等技术，能够安全、轻松地进行用户实验，从而让员工发挥出创造力和创新能力，并进行组织性学习。 5. 本章讨论了一些要整合到日常工作中的技术实践，它们能够提高变更的质量，降低部署出错的风险，减少对审批流程的依赖。GitHub和塔吉特的案例研究表明，这些实践不仅改善了工作成果，而且还极大地缩短了前置时间，并提高了开发人员的生产力。这些工作需要高度信任的文化。 五、打造持续学习性组织技术: 内容：探讨了在组织中创造学习和实验文化的实践。当我们在复杂系统中工作时，从事故中学习，创建共享代码库和共享知识是必不可少的，这有助于工作文化更公正，系统更安全、更具弹性。 1. 不指责的事后分析会议和在生产环境中注入故障都强化了这样一种文化：每个人都应该坦然面对失败，承担责任，并从失败中学习。事实上，当事故数量大幅降低时，容忍度同时也下降了，从而让我们能够继续学习。正如Peter Senge所说：“组织唯一的可持续竞争优势就是比对手更快的学习能力。” 2. 通过主动和广泛地传播新知识来实现这个目标，例如采用聊天室、架构即代码、共享源代码库、技术标准化等方法。这样做不仅能提升开发和运维团队，更能提升整个组织，因此组织中的每个工作者都在为积累集体经验添砖加瓦。 3. 本章描述了如何建立一系列惯例，来帮助强化终身学习以及重视在日常工作中改进日常工作的文化。具体实现方法是：预留偿还技术债务的时间；创建论坛，使大家能够在组织内部和外部互相学习和指导；通过辅导、咨询，或者仅仅设置一段面谈时间，让专家能够为内部团队提供帮助。 六、集成信息安全、变更管理、和合规性的技术实践： 内容：探讨了如何将DevOps原则应用于信息安全，帮助我们实现目标，并确保安全是所有人日常工作的一部分。更好的安全性确保了我们能防护数据、理智地对待数据，能在安全问题酿成灾难以前恢复。最重要的是，我们可以让系统和数据的安全性变得比以往更好。 1. 通过将安全控制集成到已经创建的机制中，确保所有按需环境都处于加固的低风险状态，以及通过将安全测试集成到部署流水线中，确保在预生产和生产环境中创建安全遥测系统。这样，我们可以在提高开发和运维效率的同时，提高整体安全性。 2. 让每个人都承担信息安全责任的实践，将所有的信息安全目标都纳入价值流中每个人的日常工作。这样显著提高了控制的有效性，能更好地预防安全漏洞，更快地检测到安全漏洞并从中恢复。此外，还大大减少了准备和通过合规审计的工作时间。
Devops指南读书笔记 价值流：一个组织基于客户的需求所执行的一系列有序的交付活动； 流动原则 第一步，流动原则：通过持续加强工作内容的可视化，减少每批次大小和等待时间，内建质量以防止缺陷向下游传递，从而增强流动性。通过加速技术价值流的流动，可以缩短满足内部客户和外部客户的需求的前置时间，进一步提高工作质量。具体的目标：缩短代码从变更到生产环境的。 提升价值流的流动性的手段： 1）限制在制品数：准确评估团队的任务承载量，同时严格限制同时并行的任务； 2）减小批量大小：缩短前置时间和提高交付物质量，应该持续不断追求小批量模式；最小的批量定义为单件流，每次操作只执行1个单位产品的处理； 3）减少交接次数：一项工作在团队之间交接时，需要大量的沟通——请求、委派、通知、协调，而且经常需要排优先级、调度、消除冲突、测试和验证，实现自动化。 4）持续识别和改进约束点：环境搭建、代码部署、测试的准备和执行、紧密耦合的架构。 5）消除日常中的困境：半成品、额外工序、额外功能、任务切换、等待、移动、缺陷、非标准或手动操作、填坑侠。 反馈原则 通过在整个价值流和组织中建立快速、频繁、高质量的信息流，包括反馈和前馈回路，可以让系统更安全。这样，就可以在规模较小、修复成本较低的情况下发现并修复问题，在灾难发生前消除问题，并创造出组织性学习氛围。同时，我们应该把失败和事故的发生视为宝贵的学习机会，而不是惩罚和责备的理由。 及时发现问题： 在安全的工作系统中，我们要不断地对设计和假设进行验证。目标是更早、更快、以尽可能低的成本、从尽可能多的维度增加系统的信息流，并尽可能清晰地确定问题的前因后果。能排除的假设越多，定位和解决问题的速度就越快，从而提高我们的顺应力、敏捷性以及学习和创新能力。 在源头保障质量： 做决策的地方一般远离执行工作的地方，这导致审批流程的有效性有所下降。这样做不仅降低了决策质量，而且还增加了决策周期，进而减弱了因果关系之间反馈的强度，降低了在成功和失败中学习的能力。 在技术价值流中，我们通过为运维而设计来为下游工作中心做优化，包括运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。 持续学习与实验原则 技术价值流的核心是建立高度信任的文化。它强调每个人都是持续学习者，必须在日常工作中承担风险；通过科学的方式改进流程和开发产品，从成功和失败中积累经验教训，从而识别有价值的想法，摒弃无用的想法。另外，所有局部的经验都会快速转化为全局性的改进，从而帮助整个组织尝试和实践新技术。 1）建立学习型组织和安全文化：组织包括病态型、官僚型、生机型； 2）将日常工作的改进制度化：通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。可以在每个开发周期的间歇中预留一段时间，或者安排改善闪电战（kaizen blitze）时段，让工程师通过自组团队的方式来解决他们感兴趣的问题。 3）把局部发现优化改为全局优化（推广）：一旦在局部范围内取得了成果，就应当把它分享给组织里的其他人，让更多的人从中获益。换句话说，当单个团队或个人获得了独有的专业知识或经验时，我们的目标是把这些隐性知识（即很难通过文档或沟通的方式传递的知识）转换为显性知识，从而帮助其他人吸取这些专业知识并在实践中应用。 4）在日常工作中注入弹性模式：通过加入一定程度的随机变量不断试验，提高产能，进而达到抗脆弱性 5）领导层强化学习文化：为团队创造条件，让团队能在日常工作中感受到这种卓越，共同的努力，每个人都相互依存，缺一不可。这些目标条件构成了科学实验的框架：清晰地描述出要解决的问题，对解决方案所做的假设，验证假设的方法，对结果的解释，以及如何利用经验进行下一个迭代。领导者可以使用下列问题来帮助和辅导实验者。 虽然培养持续学习与实验的文化是第三步原则，但是它与第一步和第二步的工作方法密不可分。换句话说，要实现工作的快速流动和快速且持续的反馈，需要使用迭代和实验的方法，包括设立目标条件，说明设想的解决方案，设计和进行实验，以及评估结果。 第二部分：选择合适的价值流作为切入点：想清楚赢的逻辑 1）软件项目分为绿地项目与棕地项目：绿地项目是指在未开发的土地上建设的项目，而棕地项目则是指在以前用于工业生产的土地上建设的项目，这样的土地可能受到有毒物质或污染物的侵蚀。在城市的发展过程中，许多因素使得绿地项目比棕地项目更容易实施——前者既不需要拆除建筑，也不需要清除有毒物质。 2） 兼顾记录型系统和交互型系统 记录型系统：交易和数据的正确性比较突出，变化速度比较慢，需要做的正确 交互型系统：面向员工和客户的可交互系统，变化速度比较快，需要快速响应。 3）从最乐于创新的团队开始 4）从扩大Devops的范围 阶段一：发现创新者和早期采用者； 阶段二：赢的沉默的大多数； 阶段三：识别钉子户。 理解、可视化和运用价值流 1）确定创造客户价值所需的团队：包括产品负责人、开发团队、QA团队、运维团队、安全团队、发布经理、价值流经理 2）针对团队工作绘制价值流图：目标不是记录所有的步骤和细节，识别阻碍价值流快速流动的环节，缩短前置时间与提高稳定性，注意A需要等待时间较长的工作；引发和处理重大返工的工作。 3）组建转型团队： A.拥有共同的目标：确定产生价值的小目标，以迭代，增量开发； B.保持小跨度的改进计划：在短期内获得可以度量的改进结果或者可用数据； C.20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能性需求：清理技术债务 D.提高工作的可视化程度 工具强化预期行为：开发人员和运维人员不仅有着共同的目标，而且还有同一份任务列表。共享队列的另一个好处是统一了任务列表，每个人都能从全局的角度思考优先级最高的事情，选择对组织最有价值的工作，或能最大限度地偿还技术债务的工作 参考康威定律设计组织结构 康威定律：软件的架构和软件团队的结构是一致的，说白了就是‘如果让4个团队开发同一个编译器，那么编译器最后会有4个执行阶段’。 组织的原型：职能型、矩阵型、市场型 组建市场型的的团队： 理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。 这种规模限制有以下4个重要作用。 （1）它确保团队成员对系统有清晰、相同的理解。当团队规模变大时，如果要让所有人都了解系统状况，需要沟通的信息量就会成倍增加。 （2）它限制正在开发的产品或服务的增长率。通过限制团队的规模，系统的发展速度也受到限制，这也有助于保证团队成员对系统有相同的理解。 （3）它分散权力并实现自主。每个“双比萨”团队都尽可能地自主工作。团队负责人直接向管理层汇报，由他决定团队负责的关键业务指标（又称适应度函数），并将其作为团队实践的总体评估标准。然后，团队能够自主采取行动来最大限度地提升该指标。 （4）领导“双比萨”团队是让员工获得领导经验的一种方式。在这样的环境中，即使失败了也不会有灾难性后果。亚马逊的策略有一个关键要素，即“双比萨”团队的组织结构与面向服务架构之间的联系。 第8章，讲运维融入日常开发 创建共享服务，提高开发生产力：创建一套集中式的平台和工具集服务，让所有开发团队都能够通过使用这套平台和服务来提高生产力，例如搭建类生产环境、部署流水线、自动化测试工具、生产环境遥测控制台等。 将运维工程师融入服务团队：他们将参加开发团队的相关讨论，如计划会议、每日站会以及新特性的演示，并帮助决定可以交付哪些特性。随着开发团队对运维知识和能力的需求逐渐降低，运维工程师就可以转移到其他的项目或者工作中，接着按照以上模式进入下一个团队以及相应产品的生命周期。 为每个团队分配运维联络人：给每个产品团队指定一位运维联络人，职责：新产品的功能、如何工作、可扩展性和监控能力、怎么监控和收集指标、是否对基础设施有额外的要求，特性的发布计划。 邀请运维工程师参加开发团队会议：包括每日站会、回顾会议、使用看板工作法。 第三部分：技术实践 第一步流动的技术实践 第9章： 1）按需搭建开发环境、测试环境、生产环境： 复制虚拟化环境（如VMware虚拟机镜像、执行Vagrant脚本，以及启动Amazon EC2虚拟机镜像文件）； ❏ 构建“裸金属物理机”的自动化环境搭建流程（例如，使用PXE方式通过基线镜像进行安装）； ❏ 使用“基础设施即代码”的配置管理工具（例如Puppet、Chef、Ansible、SaltStack、CFEngine等）； ❏ 使用操作系统自动化配置工具（例如Solaris Jumpstart、Red Hat Kickstart和Debian preseed）； ❏ 使用一组虚拟镜像或容器（例如Vagrant和Docker）搭建环境； ❏ 在公有云（例如Amazon Web Services、Google App Engine和Microsoft Azure）、私有云或其他PaaS（平台即服务，如OpenShift和Cloud Foundry等）中创建新环境。 2）应用统一的代码仓库： ❏ 应用的所有代码和依赖项（例如库、静态内容等）； ❏ 任何用于创建数据库模式的脚本、应用的参考数据等； ❏ 上一节描述的所有用于搭建环境的工具和工件（例如VMware或AMI虚拟机模板、Puppet或Chef配置模块等）； ❏ 任何构建容器所使用的文件（例如Docker或Rocket的定义文件和compose文件等）； ❏ 所有支持自动化测试和手动测试的脚本； ❏ 任何支持代码打包、部署、数据库迁移和环境置备的脚本； ❏ 所有项目工件（例如需求文档、部署过程、发布说明等）； ❏ 所有云平台配置文件（例如AWS CloudFormation模板、Microsoft Azure Stack DSC文件，以及OpenStack HEAT模板文件）； ❏ 创建支持多种基础设施服务（例如企业服务总线、数据库管理系统、DNS区域文件、防火墙配置规则和其他网络设备）所需的任何其他脚本或配置信息。 3）使基础设施的重建更容易：一旦出现问题，便可以快速进行构建，而不必花时间修复。变更为了杜绝不受控制的配置差异，可以禁止远程登录生产服务器，或定期删除和替换生产环境中的实例，从而确保移除手动变更。这会促使所有人都通过版本控制系统用正确的方式进行变更。这些措施能系统地减少基础设施偏离已知良好状态的可能性 4）运行在类生产环境里才算“完成”：最好在预生产环境中使用与生产环境相同的工具，如监控工具、日志记录工具和部署工具等。这样做能让我们积累经验，熟悉如何在生产环境中顺利部署和运行代码，以及诊断和解决问题。通过让开发团队和运维团队共同掌握代码和环境互动的方式，并尽早频繁地实施代码部署，生产环境的部署风险得以显著降低。这也避免了在项目的最后时刻才发现架构问题，并完全消除了这一类安全隐患。 第10章：实现快速可靠的自动化测试 1）对代码和环境做持续构建、集成、测试：开发过程中的持续集成（continuous integration, CI）通常是指将多个代码分支持续集成到主干中，并确保它们都会通过单元测试。然而，在持续交付和DevOps中，持续集成还要求在类生产环境中运行应用，并且通过集成测试和验收测试。 部署流水线的第一个环节是提交阶段，这个阶段完成代码构建和打包，运行自动化单元测试，并执行其他各种验证，如静态代码分析、测试覆盖率分析、重复代码检查以及代码风格检查等。如果成功，就会进入验收阶段，自动地把在提交阶段创建的包部署到类生产环境中，再执行自动化验收测试。 当版本控制系统检测到代码变更后，将一次性生成软件包。接下来，软件包将在整个部署流水线中使用。这种方式保证了集成测试环境、类生产环境，以及生产环境的代码一致性，可以有效减少难定位的下游错误（例如，所使用的编译器、编译器标志参数、库版本或配置不一致）。 因此，对于开发流程来说，部署流水线基础设施和版本控制系统同等重要。部署流水线还存储了每一份代码的构建历史，包括某次构建执行过哪些测试，测试结果如何，以及部署到了什么环境中。结合版本控制系统中的历史信息，可以快速地找到导致部署流水线失败的原因和可能的修复方法。 这些信息还有助于审计和合规历史数据（证据在日常工作中自动生成）。 有了部署流水线基础设施之后，还必须有持续集成实践，这需要以下3个方面的配合： ❏ 全面且可靠的自动化测试套件，用于验证可部署状态； ❏ 一种在验证测试失败时，可以“停掉整条生产线”的文化； ❏ 开发人员在主干上工作，并小批量提交变更，而不是在生命周期很长的特性分支上工作。 单元测试：通常独立测试每个方法、类或函数。它的目的是确保代码按照开发人员的设计运行。由于诸多原因（如需要进行快速和无状态的测试），通常会使用打桩（stub out）的方式，隔离数据库和其他外部依赖（例如，把函数修改为返回静态的预定义值，而不是调用数据库）。 ❏ 验收测试：通常整体测试应用，确保各个功能模块按照设计正常工作（例如符合用户故事的业务验收标准，API能正确调用），而且没有引入回归错误（即没有破坏以前正常的功能）。Jez Humble和David Farley认为单元测试和验收测试的区别在于：“单元测试的目的是证明应用的某一部分符合程序员的预期……验收测试的目的则是证明应用能满足客户的愿望，而不仅仅是符合程序员的预期。”在构建的版本通过单元测试后，部署流水线就对其执行验收测试。任何通过验收测试的构建版本通常都可用于手动测试（例如探索性测试、用户界面测试等）和集成测试。 ❏ 集成测试：保证应用能与生产环境中的其他应用和服务正确地交互，而不再调用打桩的接口。Jez Humble和David Farley写道：“大部分系统集成测试工作都是在部署应用的新版本，并使它们能正常协作。在这种情况下，冒烟测试通常是指针对整个应用进行的一组成熟的验收测试。”只有通过了单元测试和验收测试的构建版本才能执行集成测试。因为集成测试通常是脆弱的，所以应该尽量减少集成测试的次数，并且要在单元测试和验收测试期间，尽可能多地找出缺陷。 第11章：应用和实践持续集成 1）小批量开发与大批量合并 2）应用基于主干的开发实践 这些代码通过一键式流程在主干上创建，并已通过自动化测试。 第12章：自动化和低风险发布 1）自动化部署流程： 部署流水线：用相同的方式处理所有环境的部署：对所有的环境进行相同的部署机制，提高生产部署的成功率。 对部署执行冒烟测试：在部署过程中，测试所有的依赖系统是否能正常访问 维持环境的一致性：保持开发环境、测试环境、生产环境共同的搭建机制，保证搭建的方式是一致的。 构建：部署流水线必须基于版本控制系统构建可部署到任何环境（包括生产环境）的软件包。 测试：任何人都应该能够在他们的工作站上或测试系统中运行任何一个自动化测试套件。 部署：任何人都应该能够将这些软件包部署到具有访问权限的任何环境，通过执行（已提交到版本控制系统中的）脚本来完成部署。 如果代码部署过程是自动化的，就能将其变成部署流水线的一部分。 第13章：将部署与发布解耦 基于环境的发布模式 1）蓝绿部署：蓝绿部署是3种模式中最简单的一种。在这种模式下，我们有两个生产环境：蓝环境和绿环境。 在发布新版本的服务时，先把它部署到非在线环境，以便在不影响用户体验的情况下执行测试。在确信一切都正常以后，再把客户流量切换到蓝环境，用这种方式来交付新版本。之后，蓝环境就变成了生产环境，绿环境则变为预生产环境。通过把客户流量再重定向回绿环境，还可以实现回滚。 2）金丝雀发布： 在金丝雀发布模式下，我们会监控软件在每个环境中的运行情况。一旦出现问题，就回滚；否则就在下一个环境中进行部署。 基于应用的发布： 1）特性升级 基于应用的发布模式主要是通过特性开关来实现的。特性开关机制使我们能在不进行生产环境代码部署的情况下，选择性地启用和禁用特性。通过特性开关，可以将应用的特性向某些特定用户（例如内部员工和某些客户群）开放。 特性开关的实现机制通常是用条件语句封装应用逻辑或用户界面元素，并根据保存在某处的配置信息启用或禁用某个特性。可以使用简单的应用配置文件（例如JSON或XML格式的配置文件）存储配置信息，也可以通过服务目录来配置，甚至可以专门设计用于管理特性开关的Web服务。 轻松地回滚：只需更改特性开关的设置，就可以在生产环境中，快速安全地禁用出了问题或造成服务中断的特性。在非频繁部署的情况下，它的价值更大——关掉某一个特性通常要比回滚整个版本容易得多。 缓解性能压力：当服务遭遇极高的负载时，通常需要扩容系统；更糟糕的是，可能导致生产环境中的服务中断。不过，可以使用特性开关来缓解系统的性能压力。换句话说，可以通过减少可用的特性，来支持更多的用户（例如，减少使用某特性的客户数量，禁用推荐等CPU密集型特性，等等）。 采用面向服务架构提高恢复能力：即便某个特性依赖于还没有上线的服务，仍然可以将这个特性部署到生产环境中，然后用特性开关把它先隐藏起来。当它所依赖的服务上线后，就可以启用这个特性。同样，当所依赖的服务中断时，也可以关闭该特性，这样做不但可以和下游的故障服务隔离，同时还可以保持应用的其余部分正常运行。 2）黑启动 特性开关实现的效果是，将特性部署到生产环境中，但暂时使其不可用。它使黑启动技术成为可能——先把所有特性都部署到生产环境中，然后对客户不可见的特性执行测试。对于大规模或高风险的变更来说，黑启动过程往往持续数周，从而保证在正式发布之前使用类生产负载安全地进行测试。 13章：降低发布风险的架构 1、能提高生产力、可测试性和安全性的架构 紧耦合架构不仅会降低生产力，还会影响安全变更的能力。接口定义清晰的松耦合架构则与之相反，它优化了模块间的依赖关系，提高了生产力和安全性，让小型且高产的“双比萨”团队可以执行小的变更，并能安全和独立地进行部署。因为每个服务都有一个定义明确的API，所以更容易测试，团队之间的服务等级协议条款也更容易确定。 2、架构原型：单体架构与微服务 大多数DevOps组织都曾深深地被紧耦合的单体架构困扰。虽然单体架构非常成功地帮助这些组织实现了产品与市场的高度契合，但是当组织规模扩大后，这样的架构却成了很大的隐患（例如，eBay在2001年的单体C++应用、亚马逊在2001年的单体Obidos应用、Twitter在2009年的单体Rails前端，以及LinkedIn在2011年的单体Leo应用）。 第14章 建立能发现并解决问题的遥测系统 1、建设集中式监控架构 在业务逻辑、应用程序和环境层收集数据 负责存储和转发事件和指标的事件路由器 2、建立生产环境的应用程序日志遥测 调试级别：此级别的信息是相关应用程序中发生的所有事件，最常用于调试的时候。通常，调试日志在生产中是禁用的，但在故障诊断期间要暂时启用。 信息级别：此级别的信息包括用户触发的或系统特定的操作（例如“开始信用卡交易”）。 警告级别：此级别的信息告诉我们可能的出错情况（例如，调用数据库花费的时间超过某个特定时长）。可能会因此而触发报警和故障诊断过程，而其他日志消息会有助于更好地理解事件的原因。 错误级别：此级别的信息侧重于错误状况（例如，API调用失败，内部出错）。 致命级别：此级别的信息告诉我们何时发生了中断情况（例如，网络守护进程无法绑定网络套接字） 3、使用遥测指导问题的解决 4、将建立生产遥测融入日常工作 5、建立自助访问的遥测和信息辐射器 通过使监控信息可以快速、方便地获取到，并且把数据完全集中化处理，价值流中的所有人都可以对现状有所了解。这通常意味着将生产度量指标显示到一个由中央服务器（比如Graphite）或上一节中提到的任何其他技术实时生成的网页上。 我们希望生产监控指标具有高度的可见性，这意味着要将其放置在开发和运维人员工作区域的中心，从而使所有感兴趣的人都能看到服务的现状。这至少要包括价值流中的每一个人，比如开发、运维、产品管理和信息安全。 6、发现和填补遥测的盲区 业务级别：示例包括交易订单的数量、产生的营业额、用户注册数、流失率、A/B测试的结果等。 应用程序级别：示例包括事务处理时间、用户响应时间、应用程序故障等。 基础架构级别（如数据库、操作系统、网络、存储）：示例包括Web服务器吞吐量、CPU负载、磁盘使用率等。 客户端软件级别（如客户端浏览器上的JavaScript、移动应用程序）：示例包括应用程序的出错和崩溃、用户端的事务处理时间等。 部署流水线级别：示例包括构建流水线状态（例如：各种自动化测试套件的红色或绿色状态）、变更部署前置时间、部署频率、测试环境上线状态和环境状态。 第15章 分析遥测数据以更好地预测故障和实现目 用均值和标准差识别潜在问题 异常状态的处理和告警 非高斯分布遥测数据的问题 第16章 应用反馈实现安全部署 1、通过遥测使部署更安全 2、开发和运维共同承担值班工作 3、让开发人员跟踪工作对下游的影响 4、让开发人员自行管理生产服务 第17章 将假设驱动的开发和A/B测试融入日常工作 1、在功能测试中集成A/B测试 2、在发布中集成A/B测试 3、在功能规划中集成A/B测试 第18章 建立评审和协作流程以提升当前工作的质量 1、变更审批流程的危险 2、“过度控制变更”的潜在危险 3、变更的协调和排程 4、变更的同行评审 5、人工测试和变更冻结的潜在危害 6、利用结对编程改进代码变更 第19章 将学习融入日常工作 1、建立公正和学习的文化 2、举行不指责的事后分析会议 3、举行不指责的事后分析会议 4、降低事故容忍度，寻找更弱的故障信号 5、重新定义失败，鼓励评估风险 6、在生产环境注入故障来恢复和学习 7、创建故障演练日 第20章 将局部经验转化为全局改 1、使用聊天室和聊天机器人自动积累组织知识 2、软件中便于重用的自动化、标准化流程 3、创建全组织共享的单一源代码库 4、运用自动化测试记录和交流实践来传播知识 5、通过确定非功能性需求来设计运维 6、把可重用的运维用户故事纳入开发 7、确保技术选型有助于实现组织目标 第21章 预留组织学习和改进的时间 1、偿还技术债务的制度化惯例 2、让所有人教学相长 3、在DevOps会议中分享经验 4、传播实践的内部顾问和教练
二零一九年读完的第九十八本书，很大一部分是在飞机上读完的，鉴于之前对DevOps体系有一定的了解，所以读起来还是挺顺利的，暂时还没有遇到不可理解的点，至于在实践中能否全部用上那就得看环境的配合了，道理我都懂只是条件不成熟的时候只能选择走次优的路。看完这套书以后有计划去考一个DevOps认证的证书来玩玩，看看自己是不是真的懂了。😄
DevOps是基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论，把这些最可信的原则综合地应用到IT价值流中，就产生出DevOps这样的成果。 DevOps工作法三原则：流动原则、反馈原则、持续学习与实验原则 DevOps四个技术实践： 1、流动的技术实践； 2、反馈的技术实践； 3、持续学习与实验的技术实践； 4、集成信息安全、变更管理和合规性的技术实践
想要学习了解DevOps，可以从这本书开始。DevOps是一种管理实践的大融合，包括精益、敏捷、持续集成与交付等，并且能够与ITIL和信息安全结合，所以我们现在称为DevSecOps。 :) DevOps的三步工作法： 第一、正向的流动原则(Flow)：利用Could和Docker/K8S等技术简化基础设施搭建，使用自动化代码检查、自动化测试、持续集成和持续部署/发布来加快能力的交付。 第二、反向的反馈原则：利用日志和监测技术监控系统健康，再结合统计分析能力预测问题，以及利用A/B测试快速试错与创新。 第三、持续学习与实验原则：建立学习的文化和制度，推动组织内的信息共享，预留日常工作改进的时间。 而信息安全，则要结合进已经建立的各种流程和工具中，而不是在上线前才整改。
这是我读的第一本devops方面的书，书中的很多东西跟我们公司日常用的是一样的，通过书籍让我知道了业界的通常做法，从而对现有的实践也有了信心。 另一部分，则为我提供了新知，比如故障演练日，减少新技术的使用，单一源代码库，这是一本学习之后，可以直接在工作中用起来的书。 后续还会看其他这方面的书，并在“娜姐文集”上分享书单和简介。
精彩纷呈。
不是技术书，概念理论书。看大公司发展和历史，当看故事了解。不适合小公司。具体还得变通没有实操。
比起故事性的渐进式引人入胜，叙述性的方法论总是需要耐心需要时间进入状态。 理论很丰满，实践出真知。
书中除了理论研究也附带了很多实践案例，可以作为工具书，时不时拿来翻翻，慢慢领悟其中内涵，将来会受益匪浅。
DevOps 开发，运维。 持续集成、持续部署、持续反馈。
无技术含量
评分，3/5，偏理论了，但就纯理论方面，是比较全面覆盖了DevOps的事务，是本入门级系统性的参考书籍。适合作为其他实战DevOps书籍的理论指导。
书中举例etsy的各种实践场景看着神乎其神，但在网上一搜该公司却在2015年陷入了经营困境。除此之外其他举例的部分公司均出现了不同程度的困境。 devops可以用于IT管理能力上的优化，但一家公司核心还是商业模式和经营能力。 正如这本书自己写的“做正确的事，然后等着被开除”。
这本书是应试用的。 凤凰项目是基础。我只看了三个工作法，这部分两本书基本内容是一样的。 说实话这不是我现在需要的书……
最近公司在严抓代码质量+需要学习自动化集成与测试。 感觉Devops是一种趋势，相信随着历史的推进，一个越来越讲究质量的时代即将到来。而且精益理念不仅仅应用在IT行业，人生成长也应该敏捷、快速迭代。 一、Devops的三原则。 内容：回顾DevOps的发展史，探讨了DevOps组织转型的三步工作法：流动原则、反馈原则和持续学习与实验原则。 1. 流动： 使工作可见、限制数量、减少批量大小，减少交接次数，持续识别改善约束点，消除价值流中的困境和浪费。 2. 反馈原则 建立快速的反馈机制，对于实现技术价值流中高质量、可靠性和安全性至关重要，要在问题发生时识别问题、群策群力解决问题并构建新的知识，在源头控制质量，并且不断为工作重心做优化。 3. 持续学习与实现 接收系统中会发生故障的实时，并鼓励讨论任何问题，以建立一个安全的工作系统，还要求将日常工作的改进制度化，把局部成果转化为可供组织全局使用和学习的恶知识以及不断向日常工作注入张力。 二、Devops实践: 内容：DevOps转型的多个方面，包括选择切入点，理解架构与组织的关系，以及组建转型团队，还探讨了如何将运维工作融入开发团队的日常工作。 1. 选择合适的切入点 谨慎得选择切入点，选择不会对组织造成巨大影响的团队，选择有开拓精神的团队选择有多领域知识的人，选择和各部门有良好关系的人。 2. 通过绘制价值流图了解到了向客户交付价值所要做的工作。 3. 运用康威定理设计组织架构 4. 将运维融入日常开发工作 三、流动技术实践: 内容：实现了使工作从开发到运维快速流动的架构和技术实践，从而快速、安全地向客户交付价值。 1. 构建从开发到运维的快速工作流，需要确保任何人都能按需获得类生产环境。通过让开发人员在软件项目的最初阶段就使用类生产环境，可以显著降低生产环境出现问题的风险。为实现全面自动化测试奠定了基础 2. 创建了一组全面的自动化测试，用来确保构建始终处于绿色的可部署状态。我们在部署流水线中组织好了测试套件和测试活动，还建立了规范，要求无论谁的代码变更导致自动化测试失败，大家都要竭尽全力地将系统恢复到绿色状态。 3. Puppet Labs的《2015年DevOps现状报告》表明，基于主干的开发方式能带来更高的生产力、更好的稳定性，甚至更高的工作满意度和更低的职业倦怠率。 4. 将发布和部署融入日常工作，能够把部署时间从几个月缩短到几分钟，使组织能够快速地向客户交付价值，同时避免意外事故和服务中断。此外，开发人员和运维人员的紧密合作，能使运维工作变得人性化。 5. 使工作从开发到运维快速流动的架构和技术实践，从而快速、安全地向客户交付价值。 四、反馈技术实践: 内容：通过实施反馈回路，可以让每个人都为实现共同的目标而协作，当发生问题时及时发现问题，并通过快速检测和恢复的机制，保障所有功能不仅能按照设计在生产环境中运行，而且还实现了组织目标和组织学习。我们还研究了如何让开发和运维共享目标，从而提高整个价值流的健康程度。 1. 在问题发生时就能发现问题是多么地重要，这样才能及时地找出原因，并迅速补救。 2. 本章探讨了几种用于分析生产环境遥测数据的统计技术，通过它们能更早地发现和解决问题，并且能在问题较小的时间予以解决，从而避免造成灾难性后果。这些技术使我们能识别出那些微弱的故障信号，并及时采取行动，从而建立一个更安全的工作系统，同时提高实现目标的能力。 3. 反馈机制，它使得我们可以在日常工作的每个阶段改进服务，不管是将变更部署到生产环境，在出现问题时请求工程师修复代码，让开发人员跟踪下游工作，建立非功能性需求来帮助开发团队编写更优的生产就绪代码，还是将有问题的服务交回给开发团队自己管理。 4. 成功不但需要快速地部署和发布软件，还要在实验方面超越竞争对手。采用假设驱动的开发、定义和度量客户获取渠道，以及A/B测试等技术，能够安全、轻松地进行用户实验，从而让员工发挥出创造力和创新能力，并进行组织性学习。 5. 本章讨论了一些要整合到日常工作中的技术实践，它们能够提高变更的质量，降低部署出错的风险，减少对审批流程的依赖。GitHub和塔吉特的案例研究表明，这些实践不仅改善了工作成果，而且还极大地缩短了前置时间，并提高了开发人员的生产力。这些工作需要高度信任的文化。 五、打造持续学习性组织技术: 内容：探讨了在组织中创造学习和实验文化的实践。当我们在复杂系统中工作时，从事故中学习，创建共享代码库和共享知识是必不可少的，这有助于工作文化更公正，系统更安全、更具弹性。 1. 不指责的事后分析会议和在生产环境中注入故障都强化了这样一种文化：每个人都应该坦然面对失败，承担责任，并从失败中学习。事实上，当事故数量大幅降低时，容忍度同时也下降了，从而让我们能够继续学习。正如Peter Senge所说：“组织唯一的可持续竞争优势就是比对手更快的学习能力。” 2. 通过主动和广泛地传播新知识来实现这个目标，例如采用聊天室、架构即代码、共享源代码库、技术标准化等方法。这样做不仅能提升开发和运维团队，更能提升整个组织，因此组织中的每个工作者都在为积累集体经验添砖加瓦。 3. 本章描述了如何建立一系列惯例，来帮助强化终身学习以及重视在日常工作中改进日常工作的文化。具体实现方法是：预留偿还技术债务的时间；创建论坛，使大家能够在组织内部和外部互相学习和指导；通过辅导、咨询，或者仅仅设置一段面谈时间，让专家能够为内部团队提供帮助。 六、集成信息安全、变更管理、和合规性的技术实践： 内容：探讨了如何将DevOps原则应用于信息安全，帮助我们实现目标，并确保安全是所有人日常工作的一部分。更好的安全性确保了我们能防护数据、理智地对待数据，能在安全问题酿成灾难以前恢复。最重要的是，我们可以让系统和数据的安全性变得比以往更好。 1. 通过将安全控制集成到已经创建的机制中，确保所有按需环境都处于加固的低风险状态，以及通过将安全测试集成到部署流水线中，确保在预生产和生产环境中创建安全遥测系统。这样，我们可以在提高开发和运维效率的同时，提高整体安全性。 2. 让每个人都承担信息安全责任的实践，将所有的信息安全目标都纳入价值流中每个人的日常工作。这样显著提高了控制的有效性，能更好地预防安全漏洞，更快地检测到安全漏洞并从中恢复。此外，还大大减少了准备和通过合规审计的工作时间。
Devops指南读书笔记 价值流：一个组织基于客户的需求所执行的一系列有序的交付活动； 流动原则 第一步，流动原则：通过持续加强工作内容的可视化，减少每批次大小和等待时间，内建质量以防止缺陷向下游传递，从而增强流动性。通过加速技术价值流的流动，可以缩短满足内部客户和外部客户的需求的前置时间，进一步提高工作质量。具体的目标：缩短代码从变更到生产环境的。 提升价值流的流动性的手段： 1）限制在制品数：准确评估团队的任务承载量，同时严格限制同时并行的任务； 2）减小批量大小：缩短前置时间和提高交付物质量，应该持续不断追求小批量模式；最小的批量定义为单件流，每次操作只执行1个单位产品的处理； 3）减少交接次数：一项工作在团队之间交接时，需要大量的沟通——请求、委派、通知、协调，而且经常需要排优先级、调度、消除冲突、测试和验证，实现自动化。 4）持续识别和改进约束点：环境搭建、代码部署、测试的准备和执行、紧密耦合的架构。 5）消除日常中的困境：半成品、额外工序、额外功能、任务切换、等待、移动、缺陷、非标准或手动操作、填坑侠。 反馈原则 通过在整个价值流和组织中建立快速、频繁、高质量的信息流，包括反馈和前馈回路，可以让系统更安全。这样，就可以在规模较小、修复成本较低的情况下发现并修复问题，在灾难发生前消除问题，并创造出组织性学习氛围。同时，我们应该把失败和事故的发生视为宝贵的学习机会，而不是惩罚和责备的理由。 及时发现问题： 在安全的工作系统中，我们要不断地对设计和假设进行验证。目标是更早、更快、以尽可能低的成本、从尽可能多的维度增加系统的信息流，并尽可能清晰地确定问题的前因后果。能排除的假设越多，定位和解决问题的速度就越快，从而提高我们的顺应力、敏捷性以及学习和创新能力。 在源头保障质量： 做决策的地方一般远离执行工作的地方，这导致审批流程的有效性有所下降。这样做不仅降低了决策质量，而且还增加了决策周期，进而减弱了因果关系之间反馈的强度，降低了在成功和失败中学习的能力。 在技术价值流中，我们通过为运维而设计来为下游工作中心做优化，包括运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。 持续学习与实验原则 技术价值流的核心是建立高度信任的文化。它强调每个人都是持续学习者，必须在日常工作中承担风险；通过科学的方式改进流程和开发产品，从成功和失败中积累经验教训，从而识别有价值的想法，摒弃无用的想法。另外，所有局部的经验都会快速转化为全局性的改进，从而帮助整个组织尝试和实践新技术。 1）建立学习型组织和安全文化：组织包括病态型、官僚型、生机型； 2）将日常工作的改进制度化：通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。可以在每个开发周期的间歇中预留一段时间，或者安排改善闪电战（kaizen blitze）时段，让工程师通过自组团队的方式来解决他们感兴趣的问题。 3）把局部发现优化改为全局优化（推广）：一旦在局部范围内取得了成果，就应当把它分享给组织里的其他人，让更多的人从中获益。换句话说，当单个团队或个人获得了独有的专业知识或经验时，我们的目标是把这些隐性知识（即很难通过文档或沟通的方式传递的知识）转换为显性知识，从而帮助其他人吸取这些专业知识并在实践中应用。 4）在日常工作中注入弹性模式：通过加入一定程度的随机变量不断试验，提高产能，进而达到抗脆弱性 5）领导层强化学习文化：为团队创造条件，让团队能在日常工作中感受到这种卓越，共同的努力，每个人都相互依存，缺一不可。这些目标条件构成了科学实验的框架：清晰地描述出要解决的问题，对解决方案所做的假设，验证假设的方法，对结果的解释，以及如何利用经验进行下一个迭代。领导者可以使用下列问题来帮助和辅导实验者。 虽然培养持续学习与实验的文化是第三步原则，但是它与第一步和第二步的工作方法密不可分。换句话说，要实现工作的快速流动和快速且持续的反馈，需要使用迭代和实验的方法，包括设立目标条件，说明设想的解决方案，设计和进行实验，以及评估结果。 第二部分：选择合适的价值流作为切入点：想清楚赢的逻辑 1）软件项目分为绿地项目与棕地项目：绿地项目是指在未开发的土地上建设的项目，而棕地项目则是指在以前用于工业生产的土地上建设的项目，这样的土地可能受到有毒物质或污染物的侵蚀。在城市的发展过程中，许多因素使得绿地项目比棕地项目更容易实施——前者既不需要拆除建筑，也不需要清除有毒物质。 2） 兼顾记录型系统和交互型系统 记录型系统：交易和数据的正确性比较突出，变化速度比较慢，需要做的正确 交互型系统：面向员工和客户的可交互系统，变化速度比较快，需要快速响应。 3）从最乐于创新的团队开始 4）从扩大Devops的范围 阶段一：发现创新者和早期采用者； 阶段二：赢的沉默的大多数； 阶段三：识别钉子户。 理解、可视化和运用价值流 1）确定创造客户价值所需的团队：包括产品负责人、开发团队、QA团队、运维团队、安全团队、发布经理、价值流经理 2）针对团队工作绘制价值流图：目标不是记录所有的步骤和细节，识别阻碍价值流快速流动的环节，缩短前置时间与提高稳定性，注意A需要等待时间较长的工作；引发和处理重大返工的工作。 3）组建转型团队： A.拥有共同的目标：确定产生价值的小目标，以迭代，增量开发； B.保持小跨度的改进计划：在短期内获得可以度量的改进结果或者可用数据； C.20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能性需求：清理技术债务 D.提高工作的可视化程度 工具强化预期行为：开发人员和运维人员不仅有着共同的目标，而且还有同一份任务列表。共享队列的另一个好处是统一了任务列表，每个人都能从全局的角度思考优先级最高的事情，选择对组织最有价值的工作，或能最大限度地偿还技术债务的工作 参考康威定律设计组织结构 康威定律：软件的架构和软件团队的结构是一致的，说白了就是‘如果让4个团队开发同一个编译器，那么编译器最后会有4个执行阶段’。 组织的原型：职能型、矩阵型、市场型 组建市场型的的团队： 理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。 这种规模限制有以下4个重要作用。 （1）它确保团队成员对系统有清晰、相同的理解。当团队规模变大时，如果要让所有人都了解系统状况，需要沟通的信息量就会成倍增加。 （2）它限制正在开发的产品或服务的增长率。通过限制团队的规模，系统的发展速度也受到限制，这也有助于保证团队成员对系统有相同的理解。 （3）它分散权力并实现自主。每个“双比萨”团队都尽可能地自主工作。团队负责人直接向管理层汇报，由他决定团队负责的关键业务指标（又称适应度函数），并将其作为团队实践的总体评估标准。然后，团队能够自主采取行动来最大限度地提升该指标。 （4）领导“双比萨”团队是让员工获得领导经验的一种方式。在这样的环境中，即使失败了也不会有灾难性后果。亚马逊的策略有一个关键要素，即“双比萨”团队的组织结构与面向服务架构之间的联系。 第8章，讲运维融入日常开发 创建共享服务，提高开发生产力：创建一套集中式的平台和工具集服务，让所有开发团队都能够通过使用这套平台和服务来提高生产力，例如搭建类生产环境、部署流水线、自动化测试工具、生产环境遥测控制台等。 将运维工程师融入服务团队：他们将参加开发团队的相关讨论，如计划会议、每日站会以及新特性的演示，并帮助决定可以交付哪些特性。随着开发团队对运维知识和能力的需求逐渐降低，运维工程师就可以转移到其他的项目或者工作中，接着按照以上模式进入下一个团队以及相应产品的生命周期。 为每个团队分配运维联络人：给每个产品团队指定一位运维联络人，职责：新产品的功能、如何工作、可扩展性和监控能力、怎么监控和收集指标、是否对基础设施有额外的要求，特性的发布计划。 邀请运维工程师参加开发团队会议：包括每日站会、回顾会议、使用看板工作法。 第三部分：技术实践 第一步流动的技术实践 第9章： 1）按需搭建开发环境、测试环境、生产环境： 复制虚拟化环境（如VMware虚拟机镜像、执行Vagrant脚本，以及启动Amazon EC2虚拟机镜像文件）； ❏ 构建“裸金属物理机”的自动化环境搭建流程（例如，使用PXE方式通过基线镜像进行安装）； ❏ 使用“基础设施即代码”的配置管理工具（例如Puppet、Chef、Ansible、SaltStack、CFEngine等）； ❏ 使用操作系统自动化配置工具（例如Solaris Jumpstart、Red Hat Kickstart和Debian preseed）； ❏ 使用一组虚拟镜像或容器（例如Vagrant和Docker）搭建环境； ❏ 在公有云（例如Amazon Web Services、Google App Engine和Microsoft Azure）、私有云或其他PaaS（平台即服务，如OpenShift和Cloud Foundry等）中创建新环境。 2）应用统一的代码仓库： ❏ 应用的所有代码和依赖项（例如库、静态内容等）； ❏ 任何用于创建数据库模式的脚本、应用的参考数据等； ❏ 上一节描述的所有用于搭建环境的工具和工件（例如VMware或AMI虚拟机模板、Puppet或Chef配置模块等）； ❏ 任何构建容器所使用的文件（例如Docker或Rocket的定义文件和compose文件等）； ❏ 所有支持自动化测试和手动测试的脚本； ❏ 任何支持代码打包、部署、数据库迁移和环境置备的脚本； ❏ 所有项目工件（例如需求文档、部署过程、发布说明等）； ❏ 所有云平台配置文件（例如AWS CloudFormation模板、Microsoft Azure Stack DSC文件，以及OpenStack HEAT模板文件）； ❏ 创建支持多种基础设施服务（例如企业服务总线、数据库管理系统、DNS区域文件、防火墙配置规则和其他网络设备）所需的任何其他脚本或配置信息。 3）使基础设施的重建更容易：一旦出现问题，便可以快速进行构建，而不必花时间修复。变更为了杜绝不受控制的配置差异，可以禁止远程登录生产服务器，或定期删除和替换生产环境中的实例，从而确保移除手动变更。这会促使所有人都通过版本控制系统用正确的方式进行变更。这些措施能系统地减少基础设施偏离已知良好状态的可能性 4）运行在类生产环境里才算“完成”：最好在预生产环境中使用与生产环境相同的工具，如监控工具、日志记录工具和部署工具等。这样做能让我们积累经验，熟悉如何在生产环境中顺利部署和运行代码，以及诊断和解决问题。通过让开发团队和运维团队共同掌握代码和环境互动的方式，并尽早频繁地实施代码部署，生产环境的部署风险得以显著降低。这也避免了在项目的最后时刻才发现架构问题，并完全消除了这一类安全隐患。 第10章：实现快速可靠的自动化测试 1）对代码和环境做持续构建、集成、测试：开发过程中的持续集成（continuous integration, CI）通常是指将多个代码分支持续集成到主干中，并确保它们都会通过单元测试。然而，在持续交付和DevOps中，持续集成还要求在类生产环境中运行应用，并且通过集成测试和验收测试。 部署流水线的第一个环节是提交阶段，这个阶段完成代码构建和打包，运行自动化单元测试，并执行其他各种验证，如静态代码分析、测试覆盖率分析、重复代码检查以及代码风格检查等。如果成功，就会进入验收阶段，自动地把在提交阶段创建的包部署到类生产环境中，再执行自动化验收测试。 当版本控制系统检测到代码变更后，将一次性生成软件包。接下来，软件包将在整个部署流水线中使用。这种方式保证了集成测试环境、类生产环境，以及生产环境的代码一致性，可以有效减少难定位的下游错误（例如，所使用的编译器、编译器标志参数、库版本或配置不一致）。 因此，对于开发流程来说，部署流水线基础设施和版本控制系统同等重要。部署流水线还存储了每一份代码的构建历史，包括某次构建执行过哪些测试，测试结果如何，以及部署到了什么环境中。结合版本控制系统中的历史信息，可以快速地找到导致部署流水线失败的原因和可能的修复方法。 这些信息还有助于审计和合规历史数据（证据在日常工作中自动生成）。 有了部署流水线基础设施之后，还必须有持续集成实践，这需要以下3个方面的配合： ❏ 全面且可靠的自动化测试套件，用于验证可部署状态； ❏ 一种在验证测试失败时，可以“停掉整条生产线”的文化； ❏ 开发人员在主干上工作，并小批量提交变更，而不是在生命周期很长的特性分支上工作。 单元测试：通常独立测试每个方法、类或函数。它的目的是确保代码按照开发人员的设计运行。由于诸多原因（如需要进行快速和无状态的测试），通常会使用打桩（stub out）的方式，隔离数据库和其他外部依赖（例如，把函数修改为返回静态的预定义值，而不是调用数据库）。 ❏ 验收测试：通常整体测试应用，确保各个功能模块按照设计正常工作（例如符合用户故事的业务验收标准，API能正确调用），而且没有引入回归错误（即没有破坏以前正常的功能）。Jez Humble和David Farley认为单元测试和验收测试的区别在于：“单元测试的目的是证明应用的某一部分符合程序员的预期……验收测试的目的则是证明应用能满足客户的愿望，而不仅仅是符合程序员的预期。”在构建的版本通过单元测试后，部署流水线就对其执行验收测试。任何通过验收测试的构建版本通常都可用于手动测试（例如探索性测试、用户界面测试等）和集成测试。 ❏ 集成测试：保证应用能与生产环境中的其他应用和服务正确地交互，而不再调用打桩的接口。Jez Humble和David Farley写道：“大部分系统集成测试工作都是在部署应用的新版本，并使它们能正常协作。在这种情况下，冒烟测试通常是指针对整个应用进行的一组成熟的验收测试。”只有通过了单元测试和验收测试的构建版本才能执行集成测试。因为集成测试通常是脆弱的，所以应该尽量减少集成测试的次数，并且要在单元测试和验收测试期间，尽可能多地找出缺陷。 第11章：应用和实践持续集成 1）小批量开发与大批量合并 2）应用基于主干的开发实践 这些代码通过一键式流程在主干上创建，并已通过自动化测试。 第12章：自动化和低风险发布 1）自动化部署流程： 部署流水线：用相同的方式处理所有环境的部署：对所有的环境进行相同的部署机制，提高生产部署的成功率。 对部署执行冒烟测试：在部署过程中，测试所有的依赖系统是否能正常访问 维持环境的一致性：保持开发环境、测试环境、生产环境共同的搭建机制，保证搭建的方式是一致的。 构建：部署流水线必须基于版本控制系统构建可部署到任何环境（包括生产环境）的软件包。 测试：任何人都应该能够在他们的工作站上或测试系统中运行任何一个自动化测试套件。 部署：任何人都应该能够将这些软件包部署到具有访问权限的任何环境，通过执行（已提交到版本控制系统中的）脚本来完成部署。 如果代码部署过程是自动化的，就能将其变成部署流水线的一部分。 第13章：将部署与发布解耦 基于环境的发布模式 1）蓝绿部署：蓝绿部署是3种模式中最简单的一种。在这种模式下，我们有两个生产环境：蓝环境和绿环境。 在发布新版本的服务时，先把它部署到非在线环境，以便在不影响用户体验的情况下执行测试。在确信一切都正常以后，再把客户流量切换到蓝环境，用这种方式来交付新版本。之后，蓝环境就变成了生产环境，绿环境则变为预生产环境。通过把客户流量再重定向回绿环境，还可以实现回滚。 2）金丝雀发布： 在金丝雀发布模式下，我们会监控软件在每个环境中的运行情况。一旦出现问题，就回滚；否则就在下一个环境中进行部署。 基于应用的发布： 1）特性升级 基于应用的发布模式主要是通过特性开关来实现的。特性开关机制使我们能在不进行生产环境代码部署的情况下，选择性地启用和禁用特性。通过特性开关，可以将应用的特性向某些特定用户（例如内部员工和某些客户群）开放。 特性开关的实现机制通常是用条件语句封装应用逻辑或用户界面元素，并根据保存在某处的配置信息启用或禁用某个特性。可以使用简单的应用配置文件（例如JSON或XML格式的配置文件）存储配置信息，也可以通过服务目录来配置，甚至可以专门设计用于管理特性开关的Web服务。 轻松地回滚：只需更改特性开关的设置，就可以在生产环境中，快速安全地禁用出了问题或造成服务中断的特性。在非频繁部署的情况下，它的价值更大——关掉某一个特性通常要比回滚整个版本容易得多。 缓解性能压力：当服务遭遇极高的负载时，通常需要扩容系统；更糟糕的是，可能导致生产环境中的服务中断。不过，可以使用特性开关来缓解系统的性能压力。换句话说，可以通过减少可用的特性，来支持更多的用户（例如，减少使用某特性的客户数量，禁用推荐等CPU密集型特性，等等）。 采用面向服务架构提高恢复能力：即便某个特性依赖于还没有上线的服务，仍然可以将这个特性部署到生产环境中，然后用特性开关把它先隐藏起来。当它所依赖的服务上线后，就可以启用这个特性。同样，当所依赖的服务中断时，也可以关闭该特性，这样做不但可以和下游的故障服务隔离，同时还可以保持应用的其余部分正常运行。 2）黑启动 特性开关实现的效果是，将特性部署到生产环境中，但暂时使其不可用。它使黑启动技术成为可能——先把所有特性都部署到生产环境中，然后对客户不可见的特性执行测试。对于大规模或高风险的变更来说，黑启动过程往往持续数周，从而保证在正式发布之前使用类生产负载安全地进行测试。 13章：降低发布风险的架构 1、能提高生产力、可测试性和安全性的架构 紧耦合架构不仅会降低生产力，还会影响安全变更的能力。接口定义清晰的松耦合架构则与之相反，它优化了模块间的依赖关系，提高了生产力和安全性，让小型且高产的“双比萨”团队可以执行小的变更，并能安全和独立地进行部署。因为每个服务都有一个定义明确的API，所以更容易测试，团队之间的服务等级协议条款也更容易确定。 2、架构原型：单体架构与微服务 大多数DevOps组织都曾深深地被紧耦合的单体架构困扰。虽然单体架构非常成功地帮助这些组织实现了产品与市场的高度契合，但是当组织规模扩大后，这样的架构却成了很大的隐患（例如，eBay在2001年的单体C++应用、亚马逊在2001年的单体Obidos应用、Twitter在2009年的单体Rails前端，以及LinkedIn在2011年的单体Leo应用）。 第14章 建立能发现并解决问题的遥测系统 1、建设集中式监控架构 在业务逻辑、应用程序和环境层收集数据 负责存储和转发事件和指标的事件路由器 2、建立生产环境的应用程序日志遥测 调试级别：此级别的信息是相关应用程序中发生的所有事件，最常用于调试的时候。通常，调试日志在生产中是禁用的，但在故障诊断期间要暂时启用。 信息级别：此级别的信息包括用户触发的或系统特定的操作（例如“开始信用卡交易”）。 警告级别：此级别的信息告诉我们可能的出错情况（例如，调用数据库花费的时间超过某个特定时长）。可能会因此而触发报警和故障诊断过程，而其他日志消息会有助于更好地理解事件的原因。 错误级别：此级别的信息侧重于错误状况（例如，API调用失败，内部出错）。 致命级别：此级别的信息告诉我们何时发生了中断情况（例如，网络守护进程无法绑定网络套接字） 3、使用遥测指导问题的解决 4、将建立生产遥测融入日常工作 5、建立自助访问的遥测和信息辐射器 通过使监控信息可以快速、方便地获取到，并且把数据完全集中化处理，价值流中的所有人都可以对现状有所了解。这通常意味着将生产度量指标显示到一个由中央服务器（比如Graphite）或上一节中提到的任何其他技术实时生成的网页上。 我们希望生产监控指标具有高度的可见性，这意味着要将其放置在开发和运维人员工作区域的中心，从而使所有感兴趣的人都能看到服务的现状。这至少要包括价值流中的每一个人，比如开发、运维、产品管理和信息安全。 6、发现和填补遥测的盲区 业务级别：示例包括交易订单的数量、产生的营业额、用户注册数、流失率、A/B测试的结果等。 应用程序级别：示例包括事务处理时间、用户响应时间、应用程序故障等。 基础架构级别（如数据库、操作系统、网络、存储）：示例包括Web服务器吞吐量、CPU负载、磁盘使用率等。 客户端软件级别（如客户端浏览器上的JavaScript、移动应用程序）：示例包括应用程序的出错和崩溃、用户端的事务处理时间等。 部署流水线级别：示例包括构建流水线状态（例如：各种自动化测试套件的红色或绿色状态）、变更部署前置时间、部署频率、测试环境上线状态和环境状态。 第15章 分析遥测数据以更好地预测故障和实现目 用均值和标准差识别潜在问题 异常状态的处理和告警 非高斯分布遥测数据的问题 第16章 应用反馈实现安全部署 1、通过遥测使部署更安全 2、开发和运维共同承担值班工作 3、让开发人员跟踪工作对下游的影响 4、让开发人员自行管理生产服务 第17章 将假设驱动的开发和A/B测试融入日常工作 1、在功能测试中集成A/B测试 2、在发布中集成A/B测试 3、在功能规划中集成A/B测试 第18章 建立评审和协作流程以提升当前工作的质量 1、变更审批流程的危险 2、“过度控制变更”的潜在危险 3、变更的协调和排程 4、变更的同行评审 5、人工测试和变更冻结的潜在危害 6、利用结对编程改进代码变更 第19章 将学习融入日常工作 1、建立公正和学习的文化 2、举行不指责的事后分析会议 3、举行不指责的事后分析会议 4、降低事故容忍度，寻找更弱的故障信号 5、重新定义失败，鼓励评估风险 6、在生产环境注入故障来恢复和学习 7、创建故障演练日 第20章 将局部经验转化为全局改 1、使用聊天室和聊天机器人自动积累组织知识 2、软件中便于重用的自动化、标准化流程 3、创建全组织共享的单一源代码库 4、运用自动化测试记录和交流实践来传播知识 5、通过确定非功能性需求来设计运维 6、把可重用的运维用户故事纳入开发 7、确保技术选型有助于实现组织目标 第21章 预留组织学习和改进的时间 1、偿还技术债务的制度化惯例 2、让所有人教学相长 3、在DevOps会议中分享经验 4、传播实践的内部顾问和教练
二零一九年读完的第九十八本书，很大一部分是在飞机上读完的，鉴于之前对DevOps体系有一定的了解，所以读起来还是挺顺利的，暂时还没有遇到不可理解的点，至于在实践中能否全部用上那就得看环境的配合了，道理我都懂只是条件不成熟的时候只能选择走次优的路。看完这套书以后有计划去考一个DevOps认证的证书来玩玩，看看自己是不是真的懂了。😄
DevOps是基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论，把这些最可信的原则综合地应用到IT价值流中，就产生出DevOps这样的成果。 DevOps工作法三原则：流动原则、反馈原则、持续学习与实验原则 DevOps四个技术实践： 1、流动的技术实践； 2、反馈的技术实践； 3、持续学习与实验的技术实践； 4、集成信息安全、变更管理和合规性的技术实践
想要学习了解DevOps，可以从这本书开始。DevOps是一种管理实践的大融合，包括精益、敏捷、持续集成与交付等，并且能够与ITIL和信息安全结合，所以我们现在称为DevSecOps。 :) DevOps的三步工作法： 第一、正向的流动原则(Flow)：利用Could和Docker/K8S等技术简化基础设施搭建，使用自动化代码检查、自动化测试、持续集成和持续部署/发布来加快能力的交付。 第二、反向的反馈原则：利用日志和监测技术监控系统健康，再结合统计分析能力预测问题，以及利用A/B测试快速试错与创新。 第三、持续学习与实验原则：建立学习的文化和制度，推动组织内的信息共享，预留日常工作改进的时间。 而信息安全，则要结合进已经建立的各种流程和工具中，而不是在上线前才整改。
这是我读的第一本devops方面的书，书中的很多东西跟我们公司日常用的是一样的，通过书籍让我知道了业界的通常做法，从而对现有的实践也有了信心。 另一部分，则为我提供了新知，比如故障演练日，减少新技术的使用，单一源代码库，这是一本学习之后，可以直接在工作中用起来的书。 后续还会看其他这方面的书，并在“娜姐文集”上分享书单和简介。
精彩纷呈。
不是技术书，概念理论书。看大公司发展和历史，当看故事了解。不适合小公司。具体还得变通没有实操。
比起故事性的渐进式引人入胜，叙述性的方法论总是需要耐心需要时间进入状态。 理论很丰满，实践出真知。
书中除了理论研究也附带了很多实践案例，可以作为工具书，时不时拿来翻翻，慢慢领悟其中内涵，将来会受益匪浅。
DevOps 开发，运维。 持续集成、持续部署、持续反馈。
无技术含量
评分，3/5，偏理论了，但就纯理论方面，是比较全面覆盖了DevOps的事务，是本入门级系统性的参考书籍。适合作为其他实战DevOps书籍的理论指导。
书中举例etsy的各种实践场景看着神乎其神，但在网上一搜该公司却在2015年陷入了经营困境。除此之外其他举例的部分公司均出现了不同程度的困境。 devops可以用于IT管理能力上的优化，但一家公司核心还是商业模式和经营能力。 正如这本书自己写的“做正确的事，然后等着被开除”。
这本书是应试用的。 凤凰项目是基础。我只看了三个工作法，这部分两本书基本内容是一样的。 说实话这不是我现在需要的书……