云栖TechDay31期，来自Docker公司的Devops理念的领军人物和布道者John Willis带来DevOps的三种方式的主要演讲。本文主要从为什么要用DevOps开始谈起，接着分享DevOps的三种方式，着重分析第一种方式，包括Immutable Service Delivery的Devops (Faster)、Docker (Effective) 、Supply Chain (Reliable)，最后浅谈了第二种方式。
以下是精彩内容整理：
图为美国的一家金融机构所犯的错误，这个金融机构是美国第二大金融结构，他们经常在做一些高频交易、算法交易，所以需要进行非常大额的股票等等方面的金融交易，而在有一次的交易当中，由于他们的操作员手动更新了其中的一个交易系统，随后45分钟之内他们就损失几十亿、数千亿，在24小时之后导致了这家美国最大的金融交易公司倒闭，如果犯错就可能会导致严重错误，所以在我们使用Docker的时候，我们要非常认真的去对待自己的每一步。
在这里可以看到美国这家期货公司整个的报告，对于他们这次犯错进行了一个详细的分析，可以看到他们具体如何操作导致了严重的后果，所以我们要非常严肃对待交易系统。
为什么要用DevOps？
DevOps具体是讲文化、自动化、衡量还有分享，其实它是一个环路，看公司的文化到底是怎样的，是否具有分享的意识，是否容易接受失败、拥抱失败，是否有合作的氛围。另外大家在公司里工作的方式又是怎样的，是否是有计划的，是否会对这些结果进行不断的核实和修正，在这里我们就用这样的一个图片来阐述理念，也就是说公司里面怎样能够从一个初试的构想来到最终使得我们的客户为我们的服务来支付费用，以及在此过程当中会产生怎样的障碍，我们如何来突破障碍，如何能够让我们的产品更快的上市，更快的为客户提供服务。
DevOps的三种方式
在这本书里面我们主要包括三种方式，一种方式是如何来实现从左到右的过程，也就是说如何讲一些想法，一些构思最快的最终实现交付给客户；第二种方式，要把反馈的流程能够最大化，如果我们能够快速的得到反馈的话，我们就能够更好的改进，更加速的得到我们的结果，有一些公司他们如何去接受失败，是否对失败持有开放的态度，同时我们知道有一些大的公司甚至有意制造一些失败，从中快速的学习；第三种方式，一种文化，持续的去试验和不断的学习这种文学，在这本书当中我们有很多的例子都是来自于日本的，非常多的公司在工作当中进行了多次的改进，这是不断的学习过程。
The first way
从左到右如何尽快的实现这种持续交付的模式，其实在持续交付方面有很多书都已经写到过，我们列出了以下几点：
- Build quality in as early as possible（尽可能在早期时候考虑整个系统的质量问题）
- Find bugs as early as possible（尽早找到bugs）
- Everything gets tested（所有代码都需要进行测试）
- If it hurts, bring the pain forward（尽早的进行测试，以防止之后产生一些失败而造成更大的影响）
- Create fast feedback（更快的反馈模式）
- Version control tests（进行版本控制等等各方面的测试）
- Continuous testing ensures continuous improvement（持续测试确保持续改进）
关于持续交付方面的八个原则，具体如下：
1. Create a repeatable, reliable process for releasing software
2. Automate almost everything
3. Keep everything in version control
4. If it hurts, do it more frequently, and bring the pain forward
5. Build quality in
6. Done means released
7. Everybody is responsible for the delivery process
8. Continuous improvement
其实在DevOps Handbook书里面我们讲到了很多持续交付方面的内容，比如一定要把质量放在我们工作当中首要的位置，在持续交付方面其实这是一种思维模式的转变，它能够简单的从项目的角度，从产品的角度去转变思维，变成持续不断服务，而这个服务是永远不会停止的，除非服务已经不再提供，或者说公司已经倒闭了，在过去开发人员可能会觉得产品开发完就是完成工作，但是现在我们认为你的产品开发完交付到客户手中，客户不断的去使用才是一种完成，或者说你不断的去提供服务，它是一种一直持续的状态。
第一种方式有个概念，我称之为可免疫的交付，可以避免其他过程对于这个产品所产生的影响，开发人员可以在电脑上面开发产品，在生产交付之后会一直保持原来的状态，不会被改变的，所以这就是给我们交付软件时带来的一大优势，开发人员非常清楚所开发的程序、产品的状态，因为它是可免疫的，当你去开发、测试甚至到后面的生产过程中，你仍然对产品所开发的部分内容是非常清楚的。
如果我们使用可免疫的服务交付模式，就能够做到三点，也就是Devops (Faster)、Docker (Effective) 、Supply Chain (Reliable)，谷歌公司在打造供应链方面做了非常出色的工作，如果大家把这三点都做对的话，就会得到一个非常好的结果。
Faster
其实在过去的6年里面，我们一起做了一个研究，采用心理学的机制来进行的一份调查问卷的研究，在这个研究当中我们想要找到几方面的信息，一是在你们工作的环境当中是否愿意分享，你们是否能够拥抱接受失败的，你们之间是否有合作；另外，还有其他问题是针对软件开发者的，看一看你们开发产品情况是如何部署的，在产品发生变化的时候，做修改的时候成功率又是多少等等一系列的调研。我们发现在那些公司文化属于分享、合作、愿意拥抱失败的环境之下，这部分的人他们在解决问题方面要比那些其他的人快24倍，而他们在软件交付方面要快2500多倍，他们的动作更加快，而且更具有顺应力。
在这种三角状态之下，你是非此即彼的，你只能获得其中一个，要么更快，要么更好，或者有一些情况之下，开发者想要更快的去开发产品，而我们的员工希望不要那么快的进行改变，进行更好的工作，但是有一些统计数据和案例证明了其实我们并不是这种非此即彼的关系，这几点都是可以同时达到的，建立起自动化跟随它操作的模式，统计证明，这种效果不仅仅能够做得更快，而且有更高的顺应力，能够更好的适应变化。
如果回到六年之前，当时也是DevOps刚刚开始的时候，我在那个时候去说服那些美国公司为什么DevOps是如此的重要，其中只有3%的IT人士是了解DevOps的好处的，97%的其他IT人士是不了解其中奥妙的，而现在美国，使用DevOps的程度已经达到了百分之四五十，而中国其实或许只有3%，因为很多的竞争对手并不了解其中的原理，我们的调研结果和书都能够告诉各位为什么DevOps能够更好。
大家可以看到，图中是DevOps自动化部署的产品线，可以看到整个流程是这样子的，开发人员一个交付团队怎样来进行工作，这里有流程进行软件开发，而我们知道第二步版本控制应该是强制性的做了一些工作，之后还要进行一些接受度测试等等，最后才能进行产品的发布，整个过程当中还会有很多的反馈进来，会有一些错误发生，比如说代码不对或者采用的标准不对，或者有一些安全扫描来查找漏洞再退回。但是当我们能够更早的得到反馈，就能够把那些原来会在后端出现的问题在前端先找出来，能够解决这个问题付出的代价就更小了，也就是持续交付概念，它能够帮助各位做得更快并且有更强的适应力。
比如谷歌每一天就要做一亿次的测试来寻找各种问题，他们还使用单一的资源数等等各种方法，亚马逊也是进行快速部署的一家公司，其实很多美国公司在这方面都是采用了DevOps，使得交付软件速度非常快。
很多百年公司在五年前采用了DevOps模式进行操作，这些公司有一些是大型的零售商，有一些是保险公司，有一些是制造企业，比如：
- Ticketmaster - 98% reduction in MTTR
- Nordstrom - 20% shorter Lead Time
- Target - Full Stack Deploy 3 months to minutes
- USAA - Release from 28 days to 7 days
- ING - 500 applications teams doing devops
- CSG - From 200 incidents per release to 18
这里面各种故事都是在告诉我们，由于这些公司采用了DevOos的原则，使用了Docker工具来帮助他们更好更快，并且更具有顺应力。
effective
Docker在DevOps模式之下，能够解决其中很多问题，Docker是一个非常好的工具，它能够开发可免疫的产品交付，可以对服务进行测试，再用容器的方式进行运行，我们可以保证在生产过程当中开发的内容不会被破坏，还可以把他们做成集群，Docker还有一个数据中心，这方面也是跟阿里巴巴做了非常紧密的合作。
为什么要选择Docker？
DOCKER有几种特性：Isolation、Lightweight、Simplicity、Workflow和Community。Docker的特别之处在于建立了一个工作流程，我们可以部署它管理、存储，甚至进行各样各样的处理。有几家大的公司，在这方面工作做得非常好，比如：
- Riot Games：1.25 Million Builds a Year，10,000 - 14,000 Containers A Week，120 Build Jobs An Hour，30% of all Environments are Containerized；
- Uber：4,000 upgrades per week，3,000 builds per week，300 rollbacks per week，Managed more than 600 services in the system。
可以看到每周更新的情况，他们使用Docker之后所带来的一些效果。
Reliable
图中可以看出TOYOTA是如何来胜出它的竞争对手通用的，可以看到它在两个车型对比方面，TOYOTA的供应商方面比通用高16%，而他们增加了50%自己生产的部分，那么，TOYOTA如何对它的供应链进行更加精益的管理，如何使用DevOps来提升他们的管理效率？
其实并不是针对某一个产品，而是针对理念方式。谷歌在使用DevOps方面是非常遵守原则的，而且他们也是非常的谨慎，将他们的各种供应商进行严格控制，另外TOYOTA在它的系统里面，比如说物料，很多信息都是放在Docker容器里面的，所以当我们有几百万的清单，就可以从Docker可免疫的容器当中非常容易的找到，假如汽车公司有一些产品问题需要去召回，使用Docker会非常容易的找到几百万台售出去的汽车在什么地方，从而进行更好的处理。
我们也探讨了三种交付模式：Divergence、Convergence和Congruence。
- 第一种交付模式，在这种模式之下设立起系统打造APP，然后随着时间的迁移，这些原来的内容就变得不一致了，它是一种非常混乱的状态来管理的；
- 第二种交付模式，它会对系统进行更新，采用一些自动化方式的模式对系统进行更新，我们知道；
- 第三种模式之下，也是最好的一种模式，当你去开发的时候，设计就把它固定成一种模式，除非有意识的去更新才会发生变化，这种模式解决阐述了Docker现在的模式，这种免疫性的开发模式。
Aetna是一家非常大型的保险公司，这家保险公司采用了我们的系统之后，在过去几年里面对他们的调查显示，他们在一万行的代码当中缺陷率从原来的10K里面有10个，一直降到了0.1，他们也是采取了非常好的谷歌模式，还有一些公司甚至降到了0，一万行代码里面没有一个错误的，所以这里其实是非常具有激情的，我们的模式是非常奏效的，成千上万的人并不了解我们，所以使用这种模式能够让你们变得更加有竞争力。
我们在可免疫服务交付的模式之下，如果你使用DevOps就能够让你变得更快，使用Docker就能够让你更加的有效，而在供应链里面能够使你更加的可靠。
The Second Way
The Second Way – Goals：Right to Left、Find and Fix Fast和Shorten and Amplify Feedback。
在整个过程当中产生更多更快的反馈来促进工作的进行，我们的设计是为了解决失败，解决故障而产生的，在一些案例里面，它会有一些讲述公司如何故意去关闭一些数据中心等等采用各种方式制造混乱的。而开发人员会知道这种情况的发生，在你的规模扩大了之后很有可能200毫秒salt就是一场灾难，所以他们做了很多的测试，整个测试过程当中，产生了最终的一个体系，让你们了解问题到底是出在什么地方的。
The Second Way - Right to Left：
- Creating a Service Reliability Culture
- Fast Feedback
- Understanding Monitoring
- Understanding Complexity
