本文整理自 DevOpsDays2017上海站演讲实录《海外传统企业 DevOps 转型的若干案例》

从瀑布式的模型逐步转到 DevOps，各家企业有各自转型的做法。那么有没有一个通用的可以直接拿来用的转型路线图呢？ 今天我们将通过分析几个海外金融行业的相关案例并引入一个模型（Cynefin）来带大家探寻企业 DevOps 的转型确实可行的路线图。

前言

在给客户培训DevOps的时候会尽量把整个DevOps体系，包括流程、文化、 技术实践，和业务IT的关系等等传递给客户。但是企业要想从头开始实施 DevOps ，有没有一个转型的路线图，从现在的状态一步一步地转到 DevOps 的状态？这是客户经常会问到的一个问题。从我的直觉上来判断，由于每个企业所处的情况不同，是没有一个通用的转型路线图的。但是一般还是有人会追问，所以我今天做一个系统的分析，来看看到底有没有企业 DevOps 转型的路线图。

先来看一个案例。

Nationwide（互惠保险）的案例

Nationwide（互惠保险），是财富500强里排名第69的一家公司，全球有3.3万名员工，客户遍及美国的各个州。

他的 DevOps 转型是怎样开始的呢？开始还没有 DevOps 运动这个事情。互惠保险是从敏捷转型开始，主要是先从一个瀑布的模型逐渐地转型到CI/TDD，随后在几个团队里面实现了全栈式的敏捷开发，成为公司的标杆团队。

第一阶段：从3个敏捷团队发展到200个敏捷团队

之后一年敏捷团队成熟了，然后开始规模化敏捷。从三个团队开始，一直发展到整个公司绝大多数开发团队都能做到成熟的敏捷实施。这一过程花了五、六年的时间 。因为公司规模大，所以看他们的成绩也是很不错的，从质量、开发速率、系统稳定性等多方面取得了很好的成绩，这是第一阶段的成功。

第二阶段：新的痛点

但是互惠保险又遇到新的问题，公司发现整个交付是上图这样一个曲线。通过这个曲线可以看到中间的设计、开发、测试都做得不错了，速度跑的很快了。但是敏捷之前有一个瓶颈，就是从一个商业的想法开始、到包括需求分析、年度项目预算等对 IT 的整体发布速率来讲是一个巨大的瓶颈，这个瓶颈占到整个开发流程总时间的60%。

而另外一个比较严重的瓶颈就是开发之后一直到产品上线又花了大量的时间，公司现在发现只做敏捷是不够的。所以就开始按照解决这两个瓶颈的思路去解决问题。

解决新痛点的方法

公司领导用了一个典型的价值流图去展示整个流程，并分析这个价值流图。首先解决的是产品代码开发以后到上线的环节，就是持续交付阶段，重点要解决的问题，代码写好怎样上线，整个环节都是在优化这个部分。

同时以公司还引入了很多新的工具，包括github、new relic，splunk， 同时也进行了一些架构方面的优化 。

Nationwide（互惠保险）转型

上面是Nationawide的转型全景图。横轴是时间维度，通过时间的推移怎样转型的，纵轴是能力，或者说是企业员工对变革的感受。把相关实践放到这个曲线的各个阶段上，就形成了Lewis—Parker转型曲线，任何一个组织都会经历这样的曲线。你会从早期的成功中获得兴奋，但是遇到新的问题你的期待值和感受会再次低落，然后通过解决问题取得新的更大的成功。

另外我把企业在DevOps转型过程中会应用到的实践总结为 DevOps 思想屋（图中间部分），大家如果学 Lean 的话，可以看到与它相似的精益思想屋。这个DevOps思想屋也是我自己被训课程的基本架构。

上图左边的柱子是与持续交付相关的技术实践，该部分是自下而上的，很多的实践是技术团队发起再演进的。而右边的柱子是组织文化相关的，需要领导层推动的，所以他的箭头是自上而下的。

思想屋的地基部分围绕企业级交付流水线，就是一个idea产生到上线整个的流程，这里面涉及到规范敏捷，轻量级的ITSM等实践，而精益是流程实践的根本。

企业转型的期望模式

成功转型的企业会延续这样的曲线。但是这里有一个问题，我们看到思想屋和转型曲线，能否得出一个企业的转型定律？比如通过Nationwide这个例子得出来你应该先做敏捷，然后大规模敏捷，然后是精益，再然后是DevOps呢？ 我觉得不能。

那能否从相似的企业当中总结出来共同点，我套一下相关的案例，两三年做转型。看了蛮多的案例我个人的判断是“我觉得应该不是这样做的”。

案例一

这是一个Keybank的例子，它选了三个级重点，Containers，自动化测试，持续集成，然后他先关注这三个的实践，成功再引入另外一个实践。

案例二

CapitalOne 又是另外的一个例子，先从一个团队做CICD，做好以后就做企业级的CICD。相当于先做了一个实践，然后在整个组织推广这一实践。之后引入新的实践，比如从2016年开始做 Measurement，Improvement。

案例三

第三个是巴克莱银行的例子，这是非常成功的例子，跟刚才讲的 Nationwide类似的，先做敏捷，敏捷以后就做 DevOps 。但不同的是他的 DevOps 和精益是结合一起做的 。

从这些案例以后你会觉得是无法得出一个唯一正确的路线。每个企业的情况不同。

下面介绍一个我认为很适用的框架。

转型框架（Cynefin）

那我提一个自己的想法，你要做转型，有没有一个路线图？这里有一个框架，叫Cynefin Framework。Cynefin是一个威尔士语，指的是人隶属于的地方可能是多元的 。你首先要知道你在哪个象限，然后再解决问题。

第一个是显然象限（Obvious）。一个问题因果关系是线性的，只要找到这个原因就能得懂解决方案。什么叫显然的，比如说去麦当劳吃汉堡，汉堡的整个制作流程都是一套严格规定的，不管你是哪一家店，是谁做的汉堡，麦当劳早就固定好了，你的汉堡没到程序是什么，需要几分几秒，所以全世界的麦当劳都一个味道。这里面有一个解决问题的最佳实践，他已经固化下来跟着这个做可以了。

第二个是复杂象限（ Complicated）。问题的原因和结果直接有一定的关系，但并非线性一一对应的。这个原因需要根据当时的情况做判断。举个例子什么叫 Complicated，比如做一顿中餐。比如中餐菜谱里告诉你的是少盐少油，大火。那么这里面没有给一个明确的定量。这需要厨师根据当时用的锅具，材料本身的温度水分、客人的喜好等的情况作一个判断，所以 Complicated 的象限要求专家判断，要分析了以后才可以有适用的问题解决方案。

第三个是复合象限（Complex），这里面因和果没有绝对的关系，比如说日本有一个老人被封为苹果之神。他种苹果不喷农药 。为什么可以呢？他发现原来你要做的是建立一个生态环境，他的果园里面有很多的杂草，有很多的兔子、狐狸，有害虫也有害虫的天敌。这样他建立了一个稳定的生态系统。所以这里面其实就是没有一个明确的因和果，你要建立一个环境系统。

第四个是混乱象限（Chaotic），就是说一个灾难发生的时候，比如地震发生时，刚开始所有的运动都是混乱的，大家在四处跑，没有一个确定的秩序性的东西，这个时候你要做快速处理，在 DevOps 当中，我们要集中在前三个象限，显然的，复杂和复合的。

在技术实践的领域，大多数是在复杂的象限，需要根据现状相应的应用某些实践。

另外，一些复杂的问题可以转化成简单象限的问题。怎样转化的呢？就是通过自动化，如果你能把一个问题自动化掉，就是把复杂的变成了简单的。

流程分析也属于复杂问题领域。先解决这个流程的哪个问题需要专家的判断，每个企业的流程和流程中体现的问题都不一样。因为人不一样，工具不一样，企业架构和规章不一样，有没有严格的监管也不一样。所以你只能分析问题得到答案。如果流程能自动化，那么也相当于把一定的复杂问题变成简单化的问题。

组织文化，因为涉及到人就是复合问题，所谓的复合就是你需要理解这样的环境，就是你要建立这样一个好的环境让大家往一个方向去做。当你有了好的环境以后，就会自然成长到下一个阶段。所以我认为在跟组织文化相关里面，它其实是一个复合或者是复杂的这样一些问题的解决。

复合（Complex）象限：Build-Measure-Learn探索式模型

如果涉及到一个整体，那它就是一个复合的问题，这就是 DevOps 在业务层面上要解决的问题，为什么你要快速地把产品交付到市场上。是因为希望你的客户使用你的产品给你反馈，然后不断地调整产品，

我们没有一个混乱象限的问题，但是如果出现黑天鹅、金融危机，911 的事件，或者是股票市场雪崩，那就变成一个混乱的，那个时候是一个危机处理的方式，这不是我们做 DevOps 转型所要研究的东西。

刚才讲到业务的话，我们说是探索式模型，我们讲是 Build—Measure—Learn ，先去建立这样一个版本出来，然后看市场反应，从你的 Measure 结果出来调整产品。

复杂（Complicated）象限：需要更具情景（Context）做出专家决策。没有Best Practice,但有Good Practice。

刚才说的复杂的象限，它是需要根据企业的情况分析，把一些 best practice 变成 good practices 。这里每个领域引用了一些不同的模型，在所有的象限里面其实都有不同的模型，大家理解在这些模型里面其实它是复杂象限的问题，不是简单象限的问题 。

DevOps 的实施应该是自下而上，还是自上而下？

另外一个问题是大家问的 DevOps 是自下而上，还是自上而下的。到底是从底层开始还是上层开始。我认为要转型成功的话一定是自上而下和自下而上结合。但是你在一开始是可以从一些团队开始，你不一定是要等到高层的肯定才会开始你的旅程，但是在随后的某个时间点上是要自上而下结合的。

DevOps 的实施框架推荐（复杂象限问题解决）

刚才讲了一个框架、一个思想屋模型，到底能不能将它整合成一个路线图？下面给出建议。

一个团队会看到这样的一系列活动，首先要做准备，建设你团队的能力，准备知识，然后分步实施做迭代，然后选择你的 Best Practices 然后固化它。迭代的转型包括持续提高。组织也同样需要培训，尤其是中高经理的转型， DevOps 是一个持续的优化，如果领导都不愿意花时间培训自己，说明组织还没有做 DevOps 转型的坚决的意愿。

依据模型制定组织级别和团队级别的转型计划

如果上面这些环节清楚的话，每个企业可以形成自己的一个路线图。路线图的上面是组织层面的，从第一个星期、第二个星期到前几个月的一些活动。同时它也包括了你需要学习的东西，包括你跟团队沟通、如何看观察队工作，也包括领导需要做什么事情啦支持转型。

下面是一个团队计划，团队怎样学习哪些知识，第一、第二阶段实现什么实践，包括选取什么样的项目。

所以每个企业需要绘制自己公司内部的转型路线图，但是这个路线图一定是要结合刚才的框架，然后设计出符合本企业转型的路线图。而不是别人怎么做的我去就把它Copy过来。

总结

原创：许峰

本文整理自 DevOpsDays2017上海站演讲实录《海外传统企业 DevOps 转型的若干案例》

从瀑布式的模型逐步转到 DevOps，各家企业有各自转型的做法。那么有没有一个通用的可以直接拿来用的转型路线图呢？ 今天我们将通过分析几个海外金融行业的相关案例并引入一个模型（Cynefin）来带大家探寻企业 DevOps 的转型确实可行的路线图。

前言

在给客户培训DevOps的时候会尽量把整个DevOps体系，包括流程、文化、 技术实践，和业务IT的关系等等传递给客户。但是企业要想从头开始实施 DevOps ，有没有一个转型的路线图，从现在的状态一步一步地转到 DevOps 的状态？这是客户经常会问到的一个问题。从我的直觉上来判断，由于每个企业所处的情况不同，是没有一个通用的转型路线图的。但是一般还是有人会追问，所以我今天做一个系统的分析，来看看到底有没有企业 DevOps 转型的路线图。

先来看一个案例。

Nationwide（互惠保险）的案例

Nationwide（互惠保险），是财富500强里排名第69的一家公司，全球有3.3万名员工，客户遍及美国的各个州。

他的 DevOps 转型是怎样开始的呢？开始还没有 DevOps 运动这个事情。互惠保险是从敏捷转型开始，主要是先从一个瀑布的模型逐渐地转型到CI/TDD，随后在几个团队里面实现了全栈式的敏捷开发，成为公司的标杆团队。

第一阶段：从3个敏捷团队发展到200个敏捷团队

之后一年敏捷团队成熟了，然后开始规模化敏捷。从三个团队开始，一直发展到整个公司绝大多数开发团队都能做到成熟的敏捷实施。这一过程花了五、六年的时间 。因为公司规模大，所以看他们的成绩也是很不错的，从质量、开发速率、系统稳定性等多方面取得了很好的成绩，这是第一阶段的成功。

第二阶段：新的痛点

但是互惠保险又遇到新的问题，公司发现整个交付是上图这样一个曲线。通过这个曲线可以看到中间的设计、开发、测试都做得不错了，速度跑的很快了。但是敏捷之前有一个瓶颈，就是从一个商业的想法开始、到包括需求分析、年度项目预算等对 IT 的整体发布速率来讲是一个巨大的瓶颈，这个瓶颈占到整个开发流程总时间的60%。

而另外一个比较严重的瓶颈就是开发之后一直到产品上线又花了大量的时间，公司现在发现只做敏捷是不够的。所以就开始按照解决这两个瓶颈的思路去解决问题。

解决新痛点的方法

公司领导用了一个典型的价值流图去展示整个流程，并分析这个价值流图。首先解决的是产品代码开发以后到上线的环节，就是持续交付阶段，重点要解决的问题，代码写好怎样上线，整个环节都是在优化这个部分。

同时以公司还引入了很多新的工具，包括github、new relic，splunk， 同时也进行了一些架构方面的优化 。

Nationwide（互惠保险）转型

上面是Nationawide的转型全景图。横轴是时间维度，通过时间的推移怎样转型的，纵轴是能力，或者说是企业员工对变革的感受。把相关实践放到这个曲线的各个阶段上，就形成了Lewis—Parker转型曲线，任何一个组织都会经历这样的曲线。你会从早期的成功中获得兴奋，但是遇到新的问题你的期待值和感受会再次低落，然后通过解决问题取得新的更大的成功。

另外我把企业在DevOps转型过程中会应用到的实践总结为 DevOps 思想屋（图中间部分），大家如果学 Lean 的话，可以看到与它相似的精益思想屋。这个DevOps思想屋也是我自己被训课程的基本架构。

上图左边的柱子是与持续交付相关的技术实践，该部分是自下而上的，很多的实践是技术团队发起再演进的。而右边的柱子是组织文化相关的，需要领导层推动的，所以他的箭头是自上而下的。

思想屋的地基部分围绕企业级交付流水线，就是一个idea产生到上线整个的流程，这里面涉及到规范敏捷，轻量级的ITSM等实践，而精益是流程实践的根本。

企业转型的期望模式

成功转型的企业会延续这样的曲线。但是这里有一个问题，我们看到思想屋和转型曲线，能否得出一个企业的转型定律？比如通过Nationwide这个例子得出来你应该先做敏捷，然后大规模敏捷，然后是精益，再然后是DevOps呢？ 我觉得不能。

那能否从相似的企业当中总结出来共同点，我套一下相关的案例，两三年做转型。看了蛮多的案例我个人的判断是“我觉得应该不是这样做的”。

案例一

这是一个Keybank的例子，它选了三个级重点，Containers，自动化测试，持续集成，然后他先关注这三个的实践，成功再引入另外一个实践。

案例二

CapitalOne 又是另外的一个例子，先从一个团队做CICD，做好以后就做企业级的CICD。相当于先做了一个实践，然后在整个组织推广这一实践。之后引入新的实践，比如从2016年开始做 Measurement，Improvement。

案例三

第三个是巴克莱银行的例子，这是非常成功的例子，跟刚才讲的 Nationwide类似的，先做敏捷，敏捷以后就做 DevOps 。但不同的是他的 DevOps 和精益是结合一起做的 。

从这些案例以后你会觉得是无法得出一个唯一正确的路线。每个企业的情况不同。

下面介绍一个我认为很适用的框架。

转型框架（Cynefin）

那我提一个自己的想法，你要做转型，有没有一个路线图？这里有一个框架，叫Cynefin Framework。Cynefin是一个威尔士语，指的是人隶属于的地方可能是多元的 。你首先要知道你在哪个象限，然后再解决问题。

第一个是显然象限（Obvious）。一个问题因果关系是线性的，只要找到这个原因就能得懂解决方案。什么叫显然的，比如说去麦当劳吃汉堡，汉堡的整个制作流程都是一套严格规定的，不管你是哪一家店，是谁做的汉堡，麦当劳早就固定好了，你的汉堡没到程序是什么，需要几分几秒，所以全世界的麦当劳都一个味道。这里面有一个解决问题的最佳实践，他已经固化下来跟着这个做可以了。

第二个是复杂象限（ Complicated）。问题的原因和结果直接有一定的关系，但并非线性一一对应的。这个原因需要根据当时的情况做判断。举个例子什么叫 Complicated，比如做一顿中餐。比如中餐菜谱里告诉你的是少盐少油，大火。那么这里面没有给一个明确的定量。这需要厨师根据当时用的锅具，材料本身的温度水分、客人的喜好等的情况作一个判断，所以 Complicated 的象限要求专家判断，要分析了以后才可以有适用的问题解决方案。

第三个是复合象限（Complex），这里面因和果没有绝对的关系，比如说日本有一个老人被封为苹果之神。他种苹果不喷农药 。为什么可以呢？他发现原来你要做的是建立一个生态环境，他的果园里面有很多的杂草，有很多的兔子、狐狸，有害虫也有害虫的天敌。这样他建立了一个稳定的生态系统。所以这里面其实就是没有一个明确的因和果，你要建立一个环境系统。

第四个是混乱象限（Chaotic），就是说一个灾难发生的时候，比如地震发生时，刚开始所有的运动都是混乱的，大家在四处跑，没有一个确定的秩序性的东西，这个时候你要做快速处理，在 DevOps 当中，我们要集中在前三个象限，显然的，复杂和复合的。

在技术实践的领域，大多数是在复杂的象限，需要根据现状相应的应用某些实践。

另外，一些复杂的问题可以转化成简单象限的问题。怎样转化的呢？就是通过自动化，如果你能把一个问题自动化掉，就是把复杂的变成了简单的。

流程分析也属于复杂问题领域。先解决这个流程的哪个问题需要专家的判断，每个企业的流程和流程中体现的问题都不一样。因为人不一样，工具不一样，企业架构和规章不一样，有没有严格的监管也不一样。所以你只能分析问题得到答案。如果流程能自动化，那么也相当于把一定的复杂问题变成简单化的问题。

组织文化，因为涉及到人就是复合问题，所谓的复合就是你需要理解这样的环境，就是你要建立这样一个好的环境让大家往一个方向去做。当你有了好的环境以后，就会自然成长到下一个阶段。所以我认为在跟组织文化相关里面，它其实是一个复合或者是复杂的这样一些问题的解决。

复合（Complex）象限：Build-Measure-Learn探索式模型

如果涉及到一个整体，那它就是一个复合的问题，这就是 DevOps 在业务层面上要解决的问题，为什么你要快速地把产品交付到市场上。是因为希望你的客户使用你的产品给你反馈，然后不断地调整产品，

我们没有一个混乱象限的问题，但是如果出现黑天鹅、金融危机，911 的事件，或者是股票市场雪崩，那就变成一个混乱的，那个时候是一个危机处理的方式，这不是我们做 DevOps 转型所要研究的东西。

刚才讲到业务的话，我们说是探索式模型，我们讲是 Build—Measure—Learn ，先去建立这样一个版本出来，然后看市场反应，从你的 Measure 结果出来调整产品。

复杂（Complicated）象限：需要更具情景（Context）做出专家决策。没有Best Practice,但有Good Practice。

刚才说的复杂的象限，它是需要根据企业的情况分析，把一些 best practice 变成 good practices 。这里每个领域引用了一些不同的模型，在所有的象限里面其实都有不同的模型，大家理解在这些模型里面其实它是复杂象限的问题，不是简单象限的问题 。

DevOps 的实施应该是自下而上，还是自上而下？

另外一个问题是大家问的 DevOps 是自下而上，还是自上而下的。到底是从底层开始还是上层开始。我认为要转型成功的话一定是自上而下和自下而上结合。但是你在一开始是可以从一些团队开始，你不一定是要等到高层的肯定才会开始你的旅程，但是在随后的某个时间点上是要自上而下结合的。

DevOps 的实施框架推荐（复杂象限问题解决）

刚才讲了一个框架、一个思想屋模型，到底能不能将它整合成一个路线图？下面给出建议。

一个团队会看到这样的一系列活动，首先要做准备，建设你团队的能力，准备知识，然后分步实施做迭代，然后选择你的 Best Practices 然后固化它。迭代的转型包括持续提高。组织也同样需要培训，尤其是中高经理的转型， DevOps 是一个持续的优化，如果领导都不愿意花时间培训自己，说明组织还没有做 DevOps 转型的坚决的意愿。

依据模型制定组织级别和团队级别的转型计划

如果上面这些环节清楚的话，每个企业可以形成自己的一个路线图。路线图的上面是组织层面的，从第一个星期、第二个星期到前几个月的一些活动。同时它也包括了你需要学习的东西，包括你跟团队沟通、如何看观察队工作，也包括领导需要做什么事情啦支持转型。

下面是一个团队计划，团队怎样学习哪些知识，第一、第二阶段实现什么实践，包括选取什么样的项目。

所以每个企业需要绘制自己公司内部的转型路线图，但是这个路线图一定是要结合刚才的框架，然后设计出符合本企业转型的路线图。而不是别人怎么做的我去就把它Copy过来。

总结

原创：许峰