《DevOps的前世今生（3） DevOps的目标和手段》要点：
本文介绍了DevOps的前世今生（3） DevOps的目标和手段，希望对您有用。如果有疑问，可以联系我们。

本文经授权转载简书作者：顾宇

原文：http://www.jianshu.com/p/c6573e63c752

前言

在#DevOps的前世今生# 2. Dev和Ops矛盾缘何而来 ?一文中,通过Dev和Ops的历史发展总结出了Dev和Ops矛盾的历史渊源,以及 Dev 和 Ops 的核心矛盾：

Dev 和 Ops 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾.

但这个矛盾最先 John Allspaw 和 Paul Hammond在 “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” 提出,并以“Cooperation”作为整个演讲的核心,讲述了他们解决这个矛盾的实践经验.这个演讲中：

重新定义Ops的工作目标

在一个组织中,如果相关利益者的利益不一致,在既定流程的进行中一定会碰到诸多阻力.而在这一点上,首先做得就是把 Dev 和 Ops 的利益一致化,从而减少Ops对软件交付的阻力.在演讲中,John Allspaw 和 Paul Hammond 首先挑战的是对 Dev 和 Ops 的传统观点.

传统的观点认为Dev和Ops的工作是不同的：

Dev的工作是增添新的功能

Ops的工作是保证站点的稳定和高性能

他们认为,保证站点的稳定和高性能不是 Ops 的工作目标.

Ops的工作目标应该是激活业务(enable the business ),而这一点和Dev是一致的.

理想往往是美好的,现实往往是残酷的.激活业务会带来更多的变更,而更多的变更会引起故障!

面对这样的问题,就需要做出一个选择：为了保障稳定性减少变更,还是及时按需变更?

阿拉伯有一个谚语：“你若不想做,会找到一个借口.你若想做,会找到一个方法.”

Flicker 并没有屈服于压力,他们选择让问题向目标妥协,而不是目标向问题妥协.他们的手段是：

构建相互合作的工具和文化

降低变更风险的关键就是在于提高可靠性,这不仅仅是Dev在软件开发中,也需要Ops把可靠性通过非功能性需求(性能要求,扩展性,安全性等)注入到软件开发过程中.通过系统交付过程中的质量內建而不是事后检验来提升交付质量.

而 Dev 和 Ops 的具体矛盾点表现在以下两方面：

在价值流下游的 Ops 评审认为价值链上游的 Dev 软件非功能质量不满足要求,因此阻止变更.

在价值流上游的 Dev 无法获得价值链下游的 Ops 的真实运行环境,因此无法提升交付质量.

于是,逐渐陷入了“无法提升质量”和“ 非功能质量不满足要求 ”的死循环中.

由于在 Dev 环节关心的是功能性需求,往往忽略了非功能性需求,而 Ops 更关注的是非功能性需求.所以通过质量內建,把运维加入开发反馈环.在开发环节中增加非功能性的需求的实现和验收,让 Ops 担任最终的 QA 的角色.从而提升了交付质量,也提升了反馈速度.

首先,他们通过基础设施自动化(Automated infrastructure )提升了基础设施准备的质量和效率.

其次,他们搭建了Dev和Ops 交付的桥梁：共享版本控制(Shared Version Control )并且通过功能开关(Feature flags )管理功能发布.

然后,通过一步构建和部署(One step build and deploy )以及频繁进行小变更(Small frequent changes)提升单向价值流速度并降低部署风险.

最后,采用共享运维指标(Shared metrics ),和即时消息工具集成(IRC and IM robots )提升沟通效率以做到及时反馈并进行改进.

但仅仅有这些是不够的,还需要构建出合作的文化.合作的文化的构建关键在 Dev 和 Ops 之间的尊敬,相互信任,以及面对失败的改进而非指责的态度.

第一届 DevOpsDays 在继承了这些思想的方向上则走的更远.第一届 DevOpsDays 吸引了更多关注于这一领域的人群,它们甚至都不具备技术背景.

DevOps的目标——提升软件交付的质量內建以加速流程

在第一次 DevOpsDays 会议后,作为 DevOpsDays 活动的发起人和 DevOps 这个词的创始人,Patrick Debois 随后总结并写下了“Charting out devops ideas”一文,他把第一届 DevOpsDays 这也成为后续 DevOps 运动的理念基石.在这篇文章里,Patrick从第一届DevOps活动中有了两个重要的观察,分别是：

1. DevOps 是在业务、交付流程和运维之间反馈环中增加了一个反馈环.

2. 因为有了这样一个环节,我们可以提升质量以加速流程.

简而言之,DevOps 是把运维(Ops)加入到了价值流的反馈环中.并且通过提升软件交付的质量內建以加速价值链端到端的反馈效率.

而要实现这一目标,要通过一些手段.

DevOps的手段——技术升级和流程管理

于此同时,Patrick 发现, DevOpsDays 的所有话题都围绕着两条主线：技术(technologies)和流程管理(process management),而这些话题又相互交织在一起形成了四个不同的反馈环,如下图所示.其中蓝色气泡代表技术,黄色气泡代表过程管理：