Sato ：虽然我在职业生涯的大部分时间中都是作为一名开发者度过的，但我在技术方面的第一份有偿工作其实是在大学时为学校的Linux网络担任系统管理员，这种 背景让我对于软件的运维方面始终保有兴趣：软件不仅仅在于编写代码，还在于如何让它运行起来，并且在生产环境中保证持续运行。我在工作中总是帮助我的团队 诊断构建问题、搭建CI以及部署管理、设置基础设施、对部署进行自动化。因此我选择在我的第一本书中涵盖DevOps的主题是再自然不过了。

Sato：在与客户开会和交谈的过程中，我发现他们虽然能够理解持续交付与其原则所带来的益处，但在如何实践方面却遇到了一些困难。我的指导风格一直以来都是通过解决问题来传授知识，如果你对于某个问题有所了解，那么学习一种能够解决这一问题的技术就变得简单许多了。

我编写这本书的目的，是为了与整个社区分享一种在实现持续交付与DevOps方面具有高度实践性与大量的动手实验示例的一种尝试。

Sato ：引入流程的目的通常是作为一种避免重犯之前的类似错误的一种途径。举一个典型的例子：“ 我们上次在部署 X 系统时出现了一个问题，因为我们忘了更新数据库配置 ”，为此我们加入了一个新的流程步骤，要求对任何配置方面的改动在白板上进行审查与批准，然后才准许进入生产环境。这种方案的目的是为了避免出现重复性的 问题，但具体的实现方式也带来了其它问题。流程的增加会降低部署的频率，因而造成了每次发布中的变更数目的增多，最终提高了引入问题的风险。从系统思考的 角度来看，这是一种恶性循环。

而如果你能够将精力放到对发布软件的流程进行自动化，而不是让流程变得官僚与形式化上，你就能够打破这一怪圈。而这正是DevOps实践体现其 能力的良机：你可以更频繁地部署，因而减少了每次发布中的变更数量，最终降低了每次发布的风险。一旦出现问题，由于变更的面积减少了，要找到问题的根源也 变得容易许多。

Sato ：DevOps是旨在打破开发团队与运维团队之间的壁垒的一次尝试，这两者对于成功的软件交付来说都是必不可少的，但他们通常会被划分在不同的组织单元 中，并有着相互抵触的目标。在开发者负责交付新特性以及对变更承担责任时，运维人员则试图保持所有功能平稳运行，而避免变更正是降低风险的一种有效手段。 DevOps专注于以自动化和评估的方式作为降低风险的手段，并通过收集数据以改进交付流程，但它的本质远不止于只是一门新的工具这么简单。

DevOps的本质在于让不同背景的人共同协作，以实现快速可靠的软件发布。这一点也是许多人产生误解的部分：他们没有努力让众人团结在一起，而是创建了一个新的“DevOps团队”，这种做法等于是在整个组织中建立了一个新的壁垒，反而让事情变得更糟了。 ThoughtWorks在Tech Radar刊物中就将“分离DevOps团队”这一实践归属为“把持住” ，以突显这种方式所带来的风险。成功的DevOps实施会对公司的整个文化产生影响，其影响力甚至超出了技术的范畴。

Sato ：一个简单的实践是 将所有东西放在源代码控制系统中 ，这样可使应用程序与基础设施的变更可审计、可追踪。同时要通过自动化测试验证这些变更的质量，通过验证后才可发布到生产环境中。

为应用程序的 构建与部署过程实现自动化 同样也是十分重要的，它不仅能加快整个流程的运行，还能够降低将软件部署到生产环境时产生人为错误的风险。

还有一种实践是我希望在团队中实现的，即 搭建一种与生产环境相似的本地环境 。通过减少开发与生产环境的差异，让开发者能够更快地找到问题所在。我所见过的会造成问题的差异有这样一些例子：在Windows机器上开发、而在生产环境中的Linux服务器上部署；基于不同的数据库系统或应用服务器运行软件；使用不同版本的库及依赖。

Sato ：通常来说我把DevOps与持续交付实践看做是一回事，因为在我进行软件交付时，这两者是紧密关联的。不过，有一种关键的实践会巩固CD流程，即 部署管道 。它的作用不仅仅体现在通过某个CI服务器对每次代码变更重新构建并测试你的应用， 部署管道 是整个交付流程的一个模型，包含了从提交到投入生产环境的全部过程。

Sato ：这些实践中有很大一部分依赖于自动化，它能够打破我之前所提到的怪圈。自动化会带来更频繁的部署与更短的循环周期，这些指标对于理解你的IT组织的绩效 是相当有用的。而高绩效的IT组织在当今的市场上能够在竞争中取得先机，因为越来越多的企业依赖于通过技术与客户联结在一起。

Sato：传统的流程需要人们手动地连接到某台服务器上，对操作系统进行配置，安装基础的包，再部署应用程序及其依赖，而这种方式能够让你通过代码表现这 些操作步骤。然后你可以进一步使用Chef、Puppet、Ansible或Salt等工具对设置流程进行自动化。一旦你将基础设施代码化，你就能够使用 版本控制对基础设施的变更进行追踪。你还可以在部署管道中加入质量检查的步骤，以实现将软件从开发至生产环境的整个发布流程的自动化。

Sato ：持续改进是一种通过科学方式进行的演练，它首先创建某种假说，然后在不断地实验中收集数据，以验证或否决这种假说，这是一个循环式的过程。在 DevOps实践中，你能够提高部署的频率，因而能够更快地执行这一循环。通过更好的自动化、更好的测试与更好的监控等手段，可以有更多的机会对交付流程 进行重新评估并加以改进。

DevOps实践能够为持续改进带来有价值的数据的地方还体现在监控与指标上，通过对生产环境中软件的行为的相关数据进行收集，例如有哪些特性被使用过、哪些功能反应迟缓、哪些功能是用户投入时间最多的，你就能够改善为客户交付的软件或服务。

Sato ： 这方面的优秀资源已经很多了（我的这本书当然也是其中之一 J）。阅读与观看演讲视频也是开始学习的好方法，但我觉得通过动手实践进行学习的方式效果要好得多。从你目前的现状开始着手，应该有许多地方能够引入某些 DevOps实践。以下是可以让他们进行思考的几个点子：

• 将所有人都集中在一个房间里，画出将一行代码的变更部署到生产环境并投入运行的现有流程。并思考整个过程的周期有多长？如何让它成为一个非事件？怎样能够让这一过程的运行尽量加快，同时无需对质量进行妥协？
• 部署一个紧急修复的现有流程是怎样的？它与部署一个“普通”发布的流程是完全不同的吗？考虑一下能否将它们合并为一个单一的流程，并保证高速与可靠性？