DevOps实践

出版者:电子工业出版社

作者:Joakim Verona

页数:216

译者:高清华

出版时间:2016-10-1

价格:69

装帧:平装

isbn号码:9787121298127

具体描述

《DevOps 实践》介绍了DevOps 的起源和概览，并通过一个贯穿全书的例子，从架构开始，到代码的存储、构建、测试、部署、监控，直至流程的跟踪，推荐了许多可用的工具和可行的示范，是一本DevOps实践方面不可多得的参考书籍。

《DevOps 实践》面向愿意承担更大责任的开发人员和系统管理员，也很适合愿意更好地支持开发人员的运维人员。无须任何DevOps 知识即可快速上手！

作者简介

Joakim Verona是一位擅长持续交付和DevOps的咨询师。自1994年以来，在系统开发的所有方面他都曾工作过。他积极地在诸如web系统、多媒体系统和软硬件混合系统等复杂的多层系统上做出了领导实践者的贡献。自2004年以来，他广泛的技能兴趣把他导向了新兴的DevOps领域。

Joakim在林雪平理工学院完成了计算机科学的硕士学位。他也曾作为咨询师工作在各种各样的工业领域上，例如银行和财务、电信、工程、印刷和排版，还有游戏开发。他也对敏捷领域感兴趣，是一位Scrum认证的敏捷教练、Scrum产品负责人并拥有Java认证。

目录信息

前言 XIII
1 DevOps 和持续交付简介 1
DevOps 简介 1
多快才算快？ 3
敏捷之轮 4
敏捷不只是形式 5
DevOps 和ITIL（信息技术基础架构库） 7
总结 8
2 洞察全局 9
DevOps 流程和持续交付——概览 9
开发人员 10
版本控制系统 12
构建服务器 13
工件库 13
包管理器 13
测试环境 14
预发布/生产 15
发布管理 15
Scrum、看板和交付流水线 16
圆满结束——一个完整的例子 17
识别瓶颈 18
总结 18
3 DevOps 如何影响架构 19
介绍软件架构 19
单块系统场景 20
架构经验法则 21
关注点分离 21
内聚原则 21
耦合 22
回到单块系统场景 22
一个真实例子 22
三层系统 23
表示层 23
业务层 24
数据层 24
处理数据库迁移 24
滚动升级 25
Liquibase 的Hello world 26
变更记录文件 27
pom.xml 文件 27
手动安装 29
微服务 30
小插曲——康威定律 31
如何保持服务接口向上兼容 32
微服务和数据层 33
DevOps、架构和弹性 33
总结 34
4 一切皆代码 35
源代码控制的必要性 35
源代码管理历史 36
角色和代码 37
哪一个源代码管理系统？ 38
源代码管理系统迁移之言 39
选择分支策略 39
分支问题域 41
工件版本命名 42
选择一个客户端 43
创建一个基本的Git 服务器 44
共享认证 45
托管Git 服务器 45
大的二进制文件 46
尝试不同的Git 服务器实现 47
中场休息，插播Docker 48
Gerrit 49
安装git-review 包 49
历史修正主义的价值 50
拉请求模型 52
GitLab 52
总结 54
5 构建代码 55
我们为什么要构建代码 55
构建系统的各个方面 56
Jenkins 构建服务器 57
管理构建依赖 60
最终工件 61
用FPM 取巧 62
持续集成 63
持续交付 64
Jenkins 插件 64
托管服务器 66
构建从机 66
主机上的软件 67
触发器 68
任务链和构建流水线 68
Jenkins 文件系统结构概览 69
构建服务器和基础设施即代码 70
按依赖顺序构建 70
构建阶段 71
可选的构建服务器 72
校验质量指标 72
构建状态可视化 73
严肃对待构建错误 74
健壮性 74
总结 75
6 测试代码 77
人工测试 77
自动化测试的优缺点 78
单元测试 80
一般的JUnit 和特殊的JUnit 81
一个JUnit 的例子 82
Mocking 82
测试覆盖率 83
自动化集成测试 84
在自动化测试中使用Docker 84
Arquillian 85
性能测试 85
自动化接受测试 86
自动化GUI 测试 88
在Jenkins 中集成Selenium 测试 89
JavaScript 测试 90
测试后端集成点 91
测试驱动开发 93
REPL（交互式命令行）驱动开发 93
一个完整的自动化测试场景 94
人工测试web 应用 94
运行自动化测试 97
查找缺陷 98
测试巡礼 98
用Docker 处理棘手的依赖 102
总结 103
7 部署代码 105
为什么有这么多的部署系统 105
配置基础操作系统 106
描述集群 107
为系统交付包 107
虚拟化栈 109
在客户端执行代码 111
有关练习的注意事项 111
Puppet 服务器和Puppet 代理 112
Ansible 113
PalletOps 117
用Chef 做部署 117
用SaltStack 做部署 118
从执行的模型来比较Salt、Ansible、Puppet 和PalletOps 120
Vagrant 121
用Docker 做部署 123
对比表 124
云计算解决方案 124
AWS 125
Azure 126
总结 126
8 监控代码 127
Nagios 127
Munin 134
Ganglia 138
Graphite 142
日志处理 144
客户端日志类库 145
ELK 147
总结 149
9 问题跟踪 151
用问题跟踪器做什么？ 151
工作流和问题的一些例子 152
我们需要从问题跟踪器里得到什么？ 154
问题跟踪器激增所带来的问题 157
所有的跟踪器 158
Bugzilla 158
Trac 164
Redmine 172
GitLab 问题跟踪器 178
Jira 181
总结 183
10 物联网和DevOps 185
IoT 和DevOps 简介 185
从市场的角度看物联网的未来 188
机器到机器的通信 190
物联网的部署影响软件架构 191
物联网部署的安全性 191
好啦，但是DevOps 和物联网有什么关系？ 192
DevOps 的物联网设备动手实验室 193
总结 199
· · · · · · (收起)

读后感

拿到此书还是感觉太薄了。作者是个咨询顾问，在此书中没有体现DevOps的CALMS（文化精神），从技术角度看每一个技术都能写成一本书，例如书中写到的Pupper、Ansible、Docker、云化DevOps解决方案、AWS DevOps解决方案。 老李建议作为一个概要了解书，并且对于CALMS中的A表述的不...  

我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看过了 我看...

拿到此书还是感觉太薄了。作者是个咨询顾问，在此书中没有体现DevOps的CALMS（文化精神），从技术角度看每一个技术都能写成一本书，例如书中写到的Pupper、Ansible、Docker、云化DevOps解决方案、AWS DevOps解决方案。 老李建议作为一个概要了解书，并且对于CALMS中的A表述的不...  

1、虚拟化技术：docker、KVM 2、版本控制：git、svn 3、自动构建：Jenkins 4、自动化测试：JUnit 5、自动化运维：ansible、puppet 6、监控：zabbix、nagios 7、日志处理：splunk、ELK 8、问题追踪器：trac  

通篇都是一些概念的说明，且说明的内容还比较散乱，不连贯，全书没有一完整的例子，干货少，书薄，卖得还贵。感觉就是各种技术或工具的大纲，每种都介绍一下但不深入，还不如网上资料来得清晰，相当失望，上当了，不推荐。已无力吐槽，以下省略。。。。。。。。。。。。。。。...  

用户评价

坦白说，我是在一个非常混乱的DevOps引入期接触到这本书的。我们公司听说了DevOps的好处，盲目地采购了一堆工具，结果就是工具装了一堆，效率没怎么提升，反而增加了维护的复杂度——大家都在用工具，但没人真正理解它们背后的理念。这本书对我最大的价值在于，它是一剂强力的“去工具化”清醒剂。它没有花大篇幅去教你某个工具的CLI语法，而是深入探讨了DevOps哲学中的“测量”和“反馈”这两个核心支柱。比如，书中对DORA指标（部署频率、变更前置时间、平均恢复时间、变更失败率）的阐述，让我一下子明白了我们过去只盯着代码提交速度，却忽略了系统稳定性的荒谬之处。作者非常强调“价值流图”（Value Stream Mapping）在识别瓶颈中的作用。我们过去总是在猜测哪里慢，读了这本书后，我们组织了一次价值流梳理会议，通过可视化的方式，清晰地看到了从需求提出到用户价值实现过程中，那些漫长且毫无价值的等待时间都藏在哪里。这本书真正教会我的不是“怎么做”（How），而是“为什么这么做”（Why），它把工具的使用提升到了战略决策的高度。

作为一名IT管理者，我一直面临着一个严峻的挑战：如何平衡开发团队对速度的渴望和运维团队对稳定性的坚守。在我看来，传统的组织架构和KPI设定，天然地在鼓励“推诿责任”。读完《DevOps实践》后，我感觉我的管理思路有了一个重大的转变。这本书中关于构建“共同所有权”（Shared Ownership）的概念描绘得极为生动和具有说服力。它让我意识到，真正的DevOps不是让开发人员去学习运维的活，而是要建立一种机制，让“构建者”和“运行者”对最终结果负责。书中关于“Blameless Postmortems”（无指责事后回顾）的介绍，对我触动极大。过去出故障，我们总是忙于找“人”的错误，这只会让团队变得保守和隐瞒。这本书引导我们关注流程和系统的缺陷，将每一次事故都转化为宝贵的学习机会。这套方法论的引入，极大地改善了我们团队间的信任度。管理层需要理解，速度和质量并非零和博弈，而是通过正确的流程设计和文化引导可以同时达成的目标。这本书为我提供了一套将理论转化为可执行的组织变革方案的蓝图。

我是一个对技术细节有极高要求的工程师，读技术书籍时，我最讨厌的就是那种浮于表面的描述，恨不得每一个流程图背后都有详细的配置截图和日志分析。这本书在满足我这种“技术细节控”的同时，又没有陷入泥潭，拿捏得非常到位。它在讲解面向“可观测性”（Observability）的架构设计时，简直是教科书级别的范例。它深入探讨了“日志、指标、追踪”这三驾马车如何协同工作，确保系统在高速迭代下仍能被完全理解。我之前对分布式追踪系统（如Zipkin或Jaeger）的应用一直停留在理论层面，这本书通过一个高并发微服务场景的实例，详细剖析了请求在不同服务间流转时，如何通过上下文传递和数据埋点，实现端到端的延迟分析。这种细致入微的讲解，让我对微服务治理的复杂性有了更深刻的认识，也明白为什么需要一套系统化的可观测性方案来支撑DevOps的持续反馈闭环。总的来说，这本书的深度足以让资深从业者受益匪浅，同时它的结构化叙述，又确保了即便是初学者也能循序渐进地构建起自己的知识体系。

我本职是做系统架构的，一直以来，我对软件交付的“最后一公里”——从代码提交到生产环境上线的全过程——都抱有一种近乎偏执的完美主义追求，但现实往往是充满妥协和返工的。阅读《DevOps实践》的过程，更像是一次对我固有工作流程的“外科手术式”审视。我尤其欣赏它对“质量内建”的强调。这本书并没有把测试环节视为交付流程的终点，而是把它巧妙地融入到每一个代码提交的瞬间。书中对自动化测试金字塔的构建，从单元测试到端到端测试的比例分配，给出了非常务实且可执行的建议。我特别关注了其中关于“特性开关”（Feature Toggles）的应用部分，这彻底颠覆了我过去对“灰度发布”的理解。过去我们总是在一个固定的维护窗口期小心翼翼地进行全量切换，风险巨大。但书中描绘的通过特性开关实现无缝、低风险的业务迭代，让我看到了技术如何能真正服务于业务的敏捷性。这本书的行文风格非常冷静和专业，它不煽动情绪，而是用清晰的逻辑和成熟的架构思维，解构了构建高可靠、高速度交付流水线的每一个关键节点。对于那些已经在摸索自动化，但总感觉效率提不上去的中高级技术人员来说，这本书提供的视角是极其宝贵的。

啊，这本《DevOps实践》真是让人眼前一亮！说实话，我最近刚开始接触敏捷开发和持续集成/持续部署（CI/CD）的概念，心里总有点飘忽不定，感觉理论知识和实际操作之间隔着一层纱。读了这本书，感觉就像是有人牵着我的手，一步步把我带入了那个传说中的高效协作世界。它没有那种高高在上、充斥着晦涩术语的理论说教，而是真的从一个“过来人”的角度，把那些听起来很玄乎的工具链——Jenkins、Docker、Kubernetes——是如何串联起来，形成一个流畅自动化流程的，讲得清清楚楚。特别是关于“基础设施即代码”（IaC）的那几章，我之前总觉得Terraform或者Ansible有点复杂，但作者通过几个贴近实际的案例，把配置管理和环境部署的自动化描述得非常直观。最让我惊喜的是，它并没有把重点仅仅放在工具的堆砌上，而是反复强调文化和沟通的重要性。在企业内部推行DevOps转型，往往阻力最大的是部门间的壁垒和思维定势，这本书里关于如何建立跨职能团队、如何进行有效的反馈循环的探讨，简直是我的“救命稻草”。读完后，我立刻信心大增，感觉自己手里握住了一份实实在在的“行动路线图”，而不是一堆漂浮在空中的口号。强烈推荐给所有想从“瀑布式”泥潭中挣脱出来的团队。

啥都有，啥都不精，只能随便翻翻。2017-9-3 借于苏州图书馆

等电脑装系统的时间，从头翻了一遍，内容有点乱，基本主流的技术和工具都提及了，但也只能作为简介看了，具体实践和操作部分很少

泛泛的过了一遍devops的一些工具和概念， 不建议购买，还不如自己谷歌

泛泛的过了一遍devops的一些工具和概念， 不建议购买，还不如自己谷歌

20分钟。