116 lines
8.5 KiB
Markdown
116 lines
8.5 KiB
Markdown
# 03 | 持续交付和DevOps是一对好基友
|
||
|
||
现在很多人都在困惑持续交付和DevOps到底是什么关系，有什么区别，或许你也感觉傻傻分不清楚。那么今天，我就来和你聊聊持续交付和DevOps，以及它们到底是什么关系。
|
||
|
||
## 持续交付是什么？
|
||
|
||
我在专栏的第一篇文章中，已经跟你很详细地分享了持续交付是什么，为了加深你的印象，并与DevOps形成对比，我在这里再从另外一个角度给你总结一下：
|
||
|
||
> 持续交付是，提升软件交付速率的一套工程方法和一系列最佳实践的集合。
|
||
|
||
它的关注点可以概括为：持续集成构建、测试自动化和部署流水线。
|
||
|
||
那么，DevOps又是什么呢？其实一直以来，学术界、工业界都对DevOps没有明确的定义，所以造成了大家对它的看法也是众说纷纭，也难免片面。
|
||
|
||
在我给出我个人的认识之前，我先给你讲讲DevOps是怎么被发明的吧。
|
||
|
||
## DevOps的诞生
|
||
|
||
DevOps的故事，要从一个叫帕特里克 · 德博伊斯（Patrick Debois）的IT咨询师讲起。2007年，帕特里克参与了一个政府下属部门的大型数据中心迁移的项目。
|
||
|
||
在这个项目中，帕特里克发现开发团队（Dev）和运维团队（Ops）的工作方式和思维方式有巨大的差异：
|
||
|
||
* Dev的工作是，为软件增加新功能和修复缺陷，这要通过频繁的变更来达到；
|
||
* Ops的工作是，保证系统的高稳定性和高性能，这代表着变更越少越不容易出错。
|
||
|
||
因此，Dev和Ops长久以来，都处于对立和矛盾的状态。
|
||
|
||
2009年6月23日，Flickr公司的运维部门经理约翰 · 阿斯帕尔瓦（John Allspaw）和工程师保罗 · 哈蒙德在Velocity 大会上做了一个轰动世界的演讲：《每天部署10次以上：Flickr公司的Dev与Ops的合作》（10+ Deploys Per Day: Dev and Ops Cooperation at Flickr）。
|
||
|
||
这个演讲中提出了DevOps的核心观点：Dev和Ops的矛盾可以通过技术升级和文化构建来解决，这标志着DevOps的诞生。
|
||
|
||
帕特里克也在网上看到了这个演讲，并且十分兴奋，因为这就是长久以来他所想解决的问题。于是，他开始筹备自己的 Velocity 大会。
|
||
|
||
2009年10月，帕特里克的Velocity大会在比利时顺利召开，他把会议命名为DevOpsDays。他本来想用 DOD作为 DevOpsDays 的缩写，以提醒自己“死在交付上”（Dead On Delivery），但不知什么原因，他最后没有这么做。
|
||
|
||
这届大会出人意料的成功，许多开发工程师和运维工程师参加了这次大会，甚至还有各种IT管理人员参加。人们开始在 Twitter上大量讨论DevOpsDays的内容。
|
||
|
||
由于Twitter对内容长度的限制是140个字符，所以大家在Twitter上讨论时去掉了“Days”，只保留了 “DevOps”。**于是， DevOps这个名称正式诞生。**
|
||
|
||
## 持续交付的姗姗来迟
|
||
|
||
在DevOps的这段编年史里，持续交付又在哪里呢？
|
||
|
||
2006 年，杰斯 · 亨布尔（Jez Humble），克里斯 · 里德（Chris Read）和丹 · 诺斯（Dan North）在 Agile 大会上发表了一篇名为《部署生产线》（Deployment Production Line）的文章，这也是第一篇描述持续部署核心内容的会议文章。
|
||
|
||
在后面的三年里，又有一系列“持续部署”的文章被发表。2009年，这一些系列的文章被编成为了一本叫作《持续交付：发布可靠软件的系统方法》的书，这一年也正是帕特里克举办DevOpsDays的那一年。
|
||
|
||
2010 年，《持续交付：发布可靠软件的系统方法》的作者之一杰斯参加了第二届的 DevOpsDays，并做了 关于“持续交付”的演讲，在这一年“DevOps”与“持续交付”终于有了交集。
|
||
|
||
从本质上说，帕特里克最初遇到的问题，在《持续交付：发布可靠软件的系统方法》一书中找到了最佳实践。如果这本书可以早两年问世，或许今天就不会有DevOps了。
|
||
|
||
然而，**DevOps 的概念一直在向外延伸，包括了：运营和用户，以及快速、良好、及时的反馈机制等内容，已经超出了“持续交付”本身所涵盖的范畴。而持续交付则一直被视作DevOps的核心实践之一被广泛谈及。**
|
||
|
||
这么看来，持续交付真是打了一个大盹儿。
|
||
|
||
## 认识 DevOps
|
||
|
||
DevOps这几年一直在不断地演化，那么它到底是什么呢？
|
||
|
||
**目前，人们对DevOps的看法，可以大致概括为DevOps是一组技术，一个职能、一种文化，和一种组织架构四种。**
|
||
|
||
**第一，DevOps是一组技术，包括：自动化运维、持续交付、高频部署、Docker等内容。**
|
||
|
||
但是，如果你仅仅将DevOps认为是一组技术的集合的话，就有一些片面。任何技术都是为了解决某些问题而被创造出来的。比如Docker，就是为了解决 DevOps 所提倡的“基础设施即代码”这个问题，而被创造出来的。
|
||
|
||
从这个角度来看的话，DevOps的范畴应该远远大于一组技术了。
|
||
|
||
其实，DevOps是一组技术这个观点，还是只站在了工程师角度去思考问题而得出的结论。虽然“DevOps”中“Dev”和“Ops”这两个角色都是工程师，但是其本质还是希望跳出工程师的惯性思维来看待问题。
|
||
|
||
**第二，DevOps是一个职能，这也是我在各个场合最常听到的观点。**
|
||
|
||
你的公司有没有或者正准备成立一个叫作DevOps的部门，并将这个部门的工程师命名为DevOps工程师？至少在各大招聘网站上，是随处可见这样的职位，而招聘要求往往就是：会Ops技能的Dev，或者会Dev技能的Ops；或者干脆叫全栈工程师。
|
||
|
||
“DevOps是一个职能”这个观点，源于设施的日趋完善，云服务的流行，以及各类开源工具的广泛使用，使传统Ops的工作重心发生了变化，使企业产生了不再需要Ops的错觉。
|
||
|
||
但这个观点也是错误的，原因就是忽略了Dev与Ops本质上是不同的，也就是他们掌握的技能是不同。
|
||
|
||
虽然在DevOps看来，Dev和Ops的最终目标是一致的，都是为了快速向客户提供高质量的产品，但其达到目标的手段和方法是不一样的。比如，Ops 往往需要更多的在线处理问题的经验，而这未必是Dev所具备的。
|
||
|
||
所以，简单地把DevOps看做是一个职能，是一个彻底错误的观点。
|
||
|
||
**第三，DevOps是一种文化，推倒Dev与Ops之间的阻碍墙。**
|
||
|
||
DevOps是通过充分的合作解决责任模糊、相互推诿的问题和矛盾。在著名的演讲《每天部署10次以上：Flickr公司的Dev与Ops的合作》 中，就明确的指出工具和文化是他们成功的原因。
|
||
|
||
其实，DevOps通常想要告诉我们的是：什么行为是值得被鼓励的，而什么行为需要被惩罚。通过这样的方法，DevOps可以促使我们形成良好的做事习惯，也就是DevOps文化。
|
||
|
||
所以，我们可以发现引入DevOps的组织，其实都是希望塑造这样的一种：信任、合作、沟通、学习、分享、共担等鼓励协作的文化。
|
||
|
||
**第四，DevOps是一种组织架构，将Dev和Ops置于一个团队内，一同工作，同化目标，以达到 DevOps文化地彻底贯彻。**
|
||
|
||
这看起来确实没有什么问题，而且敏捷团队往往都是这么去做的。但是，从另一方面来看，Ops作为公司的公共研发资源，往往与Dev的配比是不成比例。所以，虽然我们希望每一个敏捷团队都有Ops，但这可能是一种奢求。
|
||
|
||
但是，敏捷团队也说了，不一定是要有一个专职Ops人员，只要有负担这个角色职责的成员存在即可。这当然也讲得通，但可能真正的执行效果就没有DevOps所设想的那么好了。
|
||
|
||
所以，DevOps是一种组织架构，这种说法，也对也不对，主要视组织的具体情况而定。
|
||
|
||
## 总结
|
||
|
||
今天，我和你一起回顾了DevOps产生的历程。同时，也顺便带你回顾了一下爱打盹儿的持续交付。我希望通过这篇文章，你可以理清持续交付和DevOps的关系：
|
||
|
||
1. DevOps的本质其实是一种鼓励协作的研发文化；
|
||
|
||
2. 持续交付与 DevOps 所追求的最终目标是一致的，即快速向用户交付高质量的软件产品；
|
||
|
||
3. DevOps的概念比持续交付更宽泛，是持续交付的继续延伸；
|
||
|
||
4. 持续交付更专注于技术与实践，是 DevOps 的工具及技术实现。
|
||
|
||
|
||
## 思考题
|
||
|
||
DevOps大潮袭来，企业是不是真的就不需要Ops这个岗位了呢？
|
||
|
||
欢迎你给我留言。
|
||
|