devops

一、扯皮

VUCA这个术语源于军事用语并在20世纪90年代开始被普遍使用。宝洁公司（Procter & Gamble）首席运营官罗伯特·麦克唐纳（Robert McDonald）借用一个军事术语来描述这一新的商业世界格局：“这是一个 VUCA 的世界。“VUCA 指的是不稳定（volatile）、不确定（uncertain）、复杂（complex）、模糊（ambiguous）。

映射到互联网行业，在很多的项目、场景里面，我们会发现其实用户的需求本身是存在非常大的不确定性和易变性的。

当年乔布斯说过一句话，他说“消费者并不知道自己需要什么，直到我们拿出自己的产品，他们就发现，这是我要的东西”。但是大家都不是乔布斯，我们经常遇到的情况是什么？当我们没有发布产品之前，用户可能不知道自己需要什么；但是当我们发布产品以后，用户终于知道了自己不想要什么。

因为客观规律是：人的认知是需要随着时间不断升级的，我们很难一次性把事情想清楚，是需要在不确定的环境中持续迭代的。

而作为软件的交付过程来讲，需求是源头，如果需求都是易变、不确定性的，那么整个交付过程会面临的复杂性、模糊性，以及各种挑战就更多了，所以我们认为VUCA是当前我们所处环境的新常态。

avatar

软件产品要想满足快速增长的用户需求，高效、快速的迭代转型必不可少，面对时刻发生改变的互联网及业务模式需求，搭建高效的交付流水线更是势在必行。

we didn’t do anything wrong , but somehow , we lost.

常言说，“工欲善其事，必先利其器”。

通过建立一套持续交付实践框架和一条可靠可重复的流水线,让整个交付做到可配置，可重建，可追溯，服务化，可视化和自服务。

二、看一下devops的发展：

2007 年：比利时，一个沮丧的独立IT咨询师

DevOps的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做Patrick Debois，他喜欢从各个角度研究IT组织。
2007 年，Patrick参与了比利时一个政府下属部门的大型数据中心迁移的项目。在这个项目中，他负责测试和验证工作。所以他不光要和开发团队（Dev）一起工作，也要和运维团队（Ops）一起工作。他第一天在开发团队跟随敏捷的节奏，第二天又要以传统的方式像消防队员那样维护这些系统，这种在两种工作氛围的切换令他十分沮丧。
他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异：开发团队和运维团队生活在两个不同的世界，而彼此又坚守着各自的利益，所以在这两者之间工作到处都是冲突。作为一个敏捷的簇拥者，他渐渐的明白如何在这种状况下改进自己的工作。

2008 年 6月：美国旧金山，第一届 Velocity 大会和 The Agile Admin博客

2008 年，在美国加州旧金山，O’Reilly出版公司举办了一场名为Velocity的技术大会，这个大会的话题范围主要围绕Web应用程序的性能和运维展开。这个会议被设计用来分享和交换构建和运维Web应用的性能、稳定性和可用性上的最佳实践。
这一年是 Velocity 大会举办的第一年，这个大会吸引了来自Austin的几个系统管理员和开发人员。他们对大会中分享的内容十分激动，于是记录下了所有的演讲内容，并决定新开一个博客分享这些内容和自己的经验。他们同样也意识到敏捷在系统管理工作中的重要性。于是，一个名为 The Agile Admin 博客诞生了。

2008 年 8月：加拿大多伦多，Agile Conference 2008 大会埋下了DevOps的种子

同年 8月，在加拿大多伦多的 Agile Conference 2008（敏捷大会）上，一位名为Andrew Shafer 的人提交了一个名为“Agile Infrastructure”的临时话题。由于对这个临时话题感兴趣的人不多，Andrew 认为没人会对如何跨越 Dev 和 Ops 的鸿沟这个话题感兴趣。所以当这个话题时间开始的时候，作为话题提交人的 Andrew 并没有出现。
但是话题开始的时候，仅有一个人出席。这个人就是上文提到的IT咨询师 Patrick 。Partrik 在这次会议上分享了自己的话题：如何在运维工作中应用 Scrum 和其它敏捷实践。他十分想把这些经历和别人分享。
最终，Patrick 在会议厅的走廊里找到了 Andrew，并进行了一场漫长的讨论。他们意识到在这次会议之外会有很多的人想要继续探讨这个广泛而又系统化的问题。
尽管在这次会议中，持续集成的流行已经使敏捷实践慢慢走向部署了。可是这仍然把运维工作和开发完全割裂开。于是他俩决定在 Google Group 上建立了一个 Agile System Adminstration 的讨论组继续这个话题。虽然有一些话题和参与者，但是访问者寥寥。

2009 年 6月：美国圣荷西，第二届 Velocity 大会上一个轰动世界的演讲

这一年的 Velocity 大会最大的亮点是一个名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲，几乎所有的和 DevOps 相关的资料都会把这个演讲作为 DevOps 的引用。这个演讲的内容可以作为 DevOps 萌发的标志。这个演讲提出了了 DevOps 的“一个中心，两个基本点”——以业务敏捷为中心，构造适应快速发布软件的工具（Tools）和文化（Culture）。
Patrick 在网上看到了这个视频后很兴奋，因为这就是他一直致力于的领域。于是他在Twitter 上问如何才能参加 Velocity 大会。
其中有个人回复: 嘿，Patrick，你想在比利时召开自己的 Velocity 吗？我们都会去参加，这一定会很棒。

2009 年 10月：比利时根特，DevOpsDays 和 DevOps

于是，Patrick 就想通过 Twitter 召集开发工程师和运维工程师在比利时举办一个类似于 Velocity 的大会。但如果要召开一个会议，就得有一个名字。Patrick 首先就想到了Dev和Ops，由于这个会议会持续两天，所以他加上了 Days，于是就有了 DevOpsDays。由于 Twitter 上有140个字符的限制，因此他想用 DOD 作为 DevOpsDays 的缩写以提醒自己“死在交付上”（Dead On Delivery），但不知什么原因，最后没有这么做。
虽然这是一届“社区版 Velocity 大会”，但这届大会出乎意料的成功。人们从世界各地蜂拥而至，除了开发工程师和运维工程师，还有各种IT管理人员和工具爱好者。两天的会议已经结束后，参与 DevOpsDays 的人们把这次会议的内容带回到了世界各个角落。
然而， DevOpsDays 的讨论仍在 Twitter 上继续着。由于 Twitter 140个字符的限制，大家在 Twitter 上去掉了 DevOps 中的 Days，保留了 DevOps。
于是， DevOps 这个称谓正式诞生。

2010 年：The Agile Admin博客发表“ What is DevOps ”

在 DevOpsDays 之后，DevOps 被越来越多的人所熟知并迅速得到了大多数人的认可。人们认为这正是IT部门的正确运作方式，DevOps 成为了一种促成开发运维合作的运动。人们在各种场所和活动中不断分享自己的经验和见解，并催生了很多工具和实践的产生。但是，每个人对 DevOps 的理解都有所不同，争议在所难免。
这些争议促社区统一化 DevOps 的见解的需要。于是 The Agile Admin 发表了“ What is DevOps ”这篇文章。该文给出了详细 DevOps 的定义，并且依据敏捷的体系构造出了DevOps 的体系: 它包括一系列价值观、原则、方法、实践以及对应的工具。并且梳理了 DevOps 的历史和对DevOps 的一些误解。
现在通过Google 搜索 DevOps，“ What is DevOps”仍然排在搜索结果的第二位（第一位是维基百科对DevOps的解释）。

2010 年：德国汉堡，第二届DevOpsDays：对不起，《持续交付》来晚了

2010 年，《持续交付》的作者Jez Humble参加了第二届的 DevOpsDays 并做了 “持续交付”的演讲。
从本质上说《持续交付》中所提到的实践给 Patrick 和 Andrew 最初所遇到的问题给出了最佳实践。如果《持续交付》早两年问世，也许不会出现 DevOps。然而，随着 DevOps 理念的传播，DevOps 的概念的外延越来越广，已经超出了《持续交付》本身所涵盖的范畴。
“持续交付”是“持续集成”的延伸，而这点恰恰和2008年敏捷大会中的观念一致。但由于发生时间的先后关系，“持续交付”被看作是敏捷以及 DevOps 文化的产物。而今，持续交付仍然被作为DevOps的核心实践之一被广泛谈及。

三、什么是devops

DevOps (a clipped compound of “development” and “operations”) is a software development and delivery process that emphasizes communication and collaboration between product management, software development, and operations professionals. It supports this by automating and monitoring the process of software integration, testing, deployment, and infrastructure changes by establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

DevOps是Development和Operations的组合词，它是一组过程、方法、与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障部门之间的沟通、协作与整合。它的出现时由于软件行业日益清晰的认识到，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。—维基百科

DevOps，很多人理解为就是让研发部门做运维的事，或者运维部门做研发的事情，但实际上DevOps在国外的定义更宽泛一点。DevOps的思想更多的是说把整个开发流程的界限打通，产品有的时候也要干一些研发的事，研发有时候把这个信息要很快的反馈给这个产品，开发和运维或者QA和运维之间的界限也打通。所以现在去搜DevOps的图片，会发现IBM这些人都在讲圈圈，说以前是产品研发都是一条线直着来，而现在都是转圈的，这就是DevOps理论.

avatar

下面引用一组数据

2017年《DevOps 现状调查报告（State of DevOps）》有这样一份数据（报告来自对 3200 名 IT 专业人士、开发人员以及高层管理者的调查，北美的受访者人数最多（54％），欧洲和俄罗斯为 27％，亚洲为 10％。科技公司仍然领先（34％），其次是金融服务（14％），其次是教育、零售、电信和政府机构，达到 6-8％）。

高绩效 vs 低绩效团队的对比该报告区分了高绩效和低绩效的团队，并阐述了他们之间的差异。与去年类似，绩效指标如下：

部署频率 - 部署到生产的频率
改变的交付时间 - 如何快速地将新的变化推向生产
平均恢复时间（MTTR） - 从故障中恢复的平均时间（中断）
更改故障率 - 更改导致部署管道故障的频率

与上一年相比，高绩效者在所有指标上有所改善。它们的代码部署频繁 46 倍，MTTR 快 96 倍。不过，与上一年相比，表现较差的人员在多项指标方面也有所改善。

通过与 2016 年的调查结果进行比较，Puppet 报告发现高成效团队与低成效团队在代码生成量（包括部署频率与变更速度）方面的差距有所缩小，但稳定性（平均恢复时长与变更故障率）则进一步扩大。

avatar

在分析中得到了另外一个结论，高绩效者的手工作业明显少于低绩效者，而自动化程度也明显高于后者。自动化是组织的一个重要红利，通过自动化，高绩效者的生产力更多地被解放用于实现那些能给组织带来更多价值的创新上，比如一个很好的例子是惠普公司的实践，他们通过DevOps实践，对自动化进行改善达到了非常好的结果。

高/中/低效能者手工作业的比率如下所示：

avatar