简介

精彩点评

• 

  rex

  推荐

  想要学习了解DevOps，可以从这本书开始。DevOps是一种管理实践的大融合，包括精益、敏捷、持续集成与交付等，并且能够与ITIL和信息安全结合，所以我们现在称为DevSecOps。 :) DevOps的三步工作法： 第一、正向的流动原则(Flow)：利用Could和Docker/K8S等技术简化基础设施搭建，使用自动化代码检查、自动化测试、持续集成和持续部署/发布来加快能力的交付。 第二、反向的反馈原则：利用日志和监测技术监控系统健康，再结合统计分析能力预测问题，以及利用A/B测试快速试错与创新。 第三、持续学习与实验原则：建立学习的文化和制度，推动组织内的信息共享，预留日常工作改进的时间。 而信息安全，则要结合进已经建立的各种流程和工具中，而不是在上线前才整改。

• 

  浩生

  推荐

  书中举例etsy的各种实践场景看着神乎其神，但在网上一搜该公司却在2015年陷入了经营困境。除此之外其他举例的部分公司均出现了不同程度的困境。 devops可以用于IT管理能力上的优化，但一家公司核心还是商业模式和经营能力。 正如这本书自己写的“做正确的事，然后等着被开除”。

• 

  foward

  推荐

  非专业人事评论。。 因为工作和兴趣考虑，想做一个了解，总体可以达成目标，对devops有一个全方位的了解，但囿于翻译等原因... 像极了之前一本AB测试原理的书... ---------------------------------------- 用得到的时候再翻阅，暂时当做扫盲书。

• 

  李雄

  推荐

  对于devops理论和一些案例介绍感觉挺好的，适合想系统学习的人。读完了一遍，打算后面工作有问题再回过头来翻一翻

• 

  Terence 叶

  推荐

  好书，做运营的兄弟肯定可以收获不少。我是琢磨应该用什么方法来引导三同步建设的时候过了一遍这本书，挺有借鉴意义。 这哥们写的两本书都挺有意思，而且这书里引用的几本其他的书也建议看看

• 

  JerryMin

  推荐

  书中除了理论研究也附带了很多实践案例，可以作为工具书，时不时拿来翻翻，慢慢领悟其中内涵，将来会受益匪浅。

• 

  梦中花开

  推荐

  这是我读的第一本devops方面的书，书中的很多东西跟我们公司日常用的是一样的，通过书籍让我知道了业界的通常做法，从而对现有的实践也有了信心。 另一部分，则为我提供了新知，比如故障演练日，减少新技术的使用，单一源代码库，这是一本学习之后，可以直接在工作中用起来的书。 后续还会看其他这方面的书，并在“娜姐文集”上分享书单和简介。

• 

  顧꯭崢꯭嶸꯭ᴋɢs

  推荐

  这本书是应试用的。 凤凰项目是基础。我只看了三个工作法，这部分两本书基本内容是一样的。 说实话这不是我现在需要的书……

• 

  文标 Billgo

  推荐

  二零一九年读完的第九十八本书，很大一部分是在飞机上读完的，鉴于之前对DevOps体系有一定的了解，所以读起来还是挺顺利的，暂时还没有遇到不可理解的点，至于在实践中能否全部用上那就得看环境的配合了，道理我都懂只是条件不成熟的时候只能选择走次优的路。看完这套书以后有计划去考一个DevOps认证的证书来玩玩，看看自己是不是真的懂了。😄

• 

  机智的狮老师1.1

  推荐

  最近公司在严抓代码质量+需要学习自动化集成与测试。 感觉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. 让每个人都承担信息安全责任的实践，将所有的信息安全目标都纳入价值流中每个人的日常工作。这样显著提高了控制的有效性，能更好地预防安全漏洞，更快地检测到安全漏洞并从中恢复。此外，还大大减少了准备和通过合规审计的工作时间。