理解 DevOps 和它所涉及的开发、运维和业务

Dan Zentgraf 是 Ascendant Technology 公司的一名领域架构师。他的工作是帮助顾客采用 DevOps 和敏捷实践。作为一位咨询师和产品经理，他在软件领域拥有 12 年从业经验。他结合自己的实际项目经验和对 DevOps 的深入分析，分享了自己的DevOps 的理解，以及研发、运维和业务三者之间的关系。

Dan 首先分析了 DevOps 的诞生背景：

敏捷开发的一般原则是开发团队应该一直以可持续的速度不断地交付软件。与此同时，基于相关的虚拟化和云计算，许多新的操作工具和基础设施已经可以为我们所用。虽然很多研发团队已经主动采取了敏捷开发的方法，但是他们开发的软件常常不能被用户接受，因为他们的程序充满了缺陷、易出错的手工任务或者和运维相关的延迟。同时，竞争日益激烈的市场环境给业务主管带来了巨大的压力，因此他们要求在更短的周期里把新软件和特性交到客户手里。敏捷开发、新运维技术和市场需求导向这三个因素正在使人们重新思考应该如何看待软件开发。这三种趋势的共性是变化的速度增加了。那种把用户所需要的软件功能搁置几个月再去开发的做法已经无法被接受了。软件只有使用的时候才有价值，快速的得到那种价值在今天的市场上显得尤为重要。这种转变使人们质疑团队开发软件的种种假设，而质疑的结果就是 DevOps 的问世。

为了总体上理解软件交付，尤其是用 DevOps 进行软件部署，Dan 认为理解以下两点很重要：

• 首先，对 DevOps 以及各种利益相关者对它感兴趣的原因有一个清晰和正确的理解是十分必要的；
• 其次，当我们尝试应用 DevOps 时，理解软件部署的假设是如何变化很重要。

当这些理解了这些之后，才有可能了解支持 DevOps 的可执行部署的框架。

Dan 指出，DevOps 这个术语，由英文单词 development 和 IT operations 组合生成，一般指的是一种利用所有各种规则统一软件系统的相关工作的方法，，从而以业务部门要求的速度将更改交付给系统。它通常与进行快速而小的改变的敏捷开发结合起来，目的是注意力集中于高价值的工作，最小化由大的变化所产生的缺陷风险，减小由于工程完工后软件特性与商业要求的严重背离而带来的软件价值偏移。另一方面，运维的观点是指将变化视作不稳定性的成因。不稳定性必然会导致宕机，这是运维当中最严重的负面事件。因此，运维团队常常抵制变化。然而，DevOps 常常被视为一种改变，因为在绝大多数的开发团队中，开发、运维和市场三者之间有着一系列的的冲突行为和回报，从而导致无数的不当行为。市场给进行新特性开发和追求变化的开发团队以回报，但是却因为宕机而处罚运维团队。因此，开发团队迫切要求运维人员进行更多的部署；运维团队则要求开发人员的交付模块包含更多结构和更高的精确度。这些矛盾在很多开发团队中已经根深蒂固，并且因为各自团队成熟度的固有不同而更加严重。DevOps 力图消除这些障碍，为这些竞争团队搭建一个共同合作的平台，从而把他们集中到同一个目标上。为了实现这个目的，理解每一个团队的心态非常的重要。

接着，Dan 从开发、运维和业务三个方面阐述了自己的理解。

开发

开发通常被认为更加的接近市场需求。《敏捷宣言》已经问世十多年了。从某种程度上说，该宣言是早期极限编程、结对编程和实践的结果。公平地说，这个难题的软件部分被视为是很容易实现的目标（它很容易改变，但理论上独立于基础设施和平台之上）。基础设施习惯上被认为是一种很难被改变的昂贵资本支出，并且有很长的摊销周期。不幸的是，复杂的软件需要很多的基础设施，并且要求基础设施和软件本身同步发展。这种联系就是为什么早期 DevOps 有时被称作“敏捷运维”。无论人们怎么称呼它，如果科技与市场需求保持同步的话，坚持软件和基础设施分开的想法是不可持续的。这迫使研发团队接受维持复杂基础设施生产的现实。

运维

幸运地是，一些新的科学技术已经成为运维领域的最前沿，从而帮助运维更加的符合市场需求。运维领域最主要的颠覆性技术是便宜的硬件商品虚拟化的广泛普及。这产生了新的系统管理方法，当然还有云计算。这种科技由于能让开发团队快速而容易地整合他们未被充分使用的计算资源从而直接产生价值，因而快速流行起来。美国 Gartner 咨询公司估计现在 50% 的应用在虚拟环境中运行。然而，简单的整合只是一种有限地回收价值、缩减开支的的办法。虚拟化技术也使基础设施具有了一定的可变性，让运维团队在不影响稳定性的前提下以以前不可能达到的速度改进基础设施。虚拟化利用技术常常在与云计算有关的项目中出现。这些新兴的技术给了运维团队一条同研发团队一样敏捷并且能切合市场需求的途径。

业务

对业务主管们来说，他们已经明白了理解和利用技术来实现目标相比以往更加的关键。根据 IBM2012 年的 CEO 调查（这个调查建立在对 64 个国家 1700 个首席执行官进行访谈的基础上），技术因素是影响开发团队排名第一位的因素。2004 年技术因素只在九个因素中排名第六，此后，这个排名稳步地上升。因此业务主管注意到响应顾客需求的能力是一种竞争优势。由此可以推断，糟糕的技术执行力是对业务的一种内在威胁。这种威胁不会一夜之间就成为现实，但是它已经一触即发。同样的调查还讨论了调查对象如何权衡理解客户的需求和用更短的交付时间来满足他们的需求。最后，这是一种和过程现实相冲突的业务压力。这种过程现实就是研发和运维的技术规程过去是如何运作以及激发将商业做的更好的讨论。