DevOps 与持续交付实践

Danilo Sato 表示：DevOps 是旨在打破开发团队与运维团队之间的壁垒的一次尝试，这两者对于成功的软件交付来说都是必不可少的。他的新作《实战DevOps：可靠的自动化软件交付》（DevOps in Practice: Reliable and automated software delivery）以一种动手实验的风格帮助读者了解如何实现持续交付与DevOps 实践。

InfoQ 的读者们可以下载《DevOps 实战》的一个样例章节，对本书有一个大致的印象。

InfoQ 有幸采访了 Danilo Sato，谈及的内容包括为何各种流程最后总是倾向于变得官僚，你又该怎样避免出现这一点；他对 DevOps 的观点；DevOps 与持续交付的实践；对基础设施的部署实现自动化；持续改进；以及开发者、测试人员与运维人员如何学习 DevOps 实践，从而找到能够让他们的合作更密切的工作方式。

InfoQ：是什么原因促使你编写这样一本有关于 DevOps实践的书籍呢？

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

InfoQ：本书选择了一种“动手实验”的风格，对于安装与配置过程提供了非常详细的描述。可否请你详细地说明一下为什么会选择这种风格吗？

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

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

InfoQ：你在书中提到一点，随着时间的推移，部署过程会倾向于变得越来越官僚化。为什么会产生这一现象，是否又有什么办法可以防止这一现象的出现呢？

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

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

InfoQ：你认为 DevOps是什么、不是什么？可否为我们分享一下你的观点？

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

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

InfoQ：你对于团队如何进行 DevOps实践有什么建议，可否给出一些示例？

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

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

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

InfoQ：那么对于持续交付呢，你对于实施持续交付的团队该采用何种实践有什么建议吗？

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

InfoQ：怎样才能够体现出这些实践的价值？

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

InfoQ：你在书中提到“基础设施即代码”，也就是将基础设施的配置进行自动化。具体要怎么做才能够实现这一点，可否请你给出一些示例？

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

InfoQ：对于在 DevOps中实现持续改进，你有什么建议吗？

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

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

InfoQ：开发者、测试人员与运维人员如何学习 DevOps实践，从而找到能够让他们的合作更密切的工作方式？

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

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

关于本书作者

Danilo Sato是一位具有超过 14 年行业经验的技术专家。从 2008 年起，他在 ThoughtWorks 担任顾问，并承担多种不同的角色，例如开发者、培训师、架构师以及教练。目前，Danilo 是 CTO 办公室中的一员，也是数据方面的全球倡议领导。他帮助 ThoughtWorks 公司的客户实施各种实践，通过云、DevOps 与持续交付等方式让产品的概念、实现及至在生产环境中运行的整个过程变得更简短。Danilo 是《实战 DevOps：可靠的自动化软件交付》一书的作者，也是一位国际性大会的演讲者，曾在 QConSP、RubyConfBr、AgileBrazil、Agile 以及 XP 等会议及研讨会中发表过演讲。他同时也是 Coding Dojo @ São Paulo 的创办人。

查看英文原文： Practices for DevOps and Continuous Delivery