转载

视频访谈：赵安全：传统企业如何顺利进行DevOps转型

下载
Android app

17:19

个人简介 赵安全，博云BoCloud解决方案部的负责人,以前是在华为有比较长的工作经验，后来就在BoCloud博云一直在负责云方面的事情。

视频访谈：赵安全：传统企业如何顺利进行DevOps转型 QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

赵安全： 我赵安全，博云BoCloud解决方案部的负责人，我们这个部门还负责一些除了受训和咨询方面的一些工作。我以前是在华为有比较长的工作经验，后来就在BoCloud博云一直在负责云方面的事情。

赵安全： 传统企业它其实这么多年下来一直是在做这些传统的业务，为什么到现在会产生痛点，业务驱动是一个重要原因，实际上传统企业还是希望做互联网化或者移动化。比如银行，从面相营业厅办理业务，变成了面向个人用户，那么自然而然，他对系统要求就不一样了。其实传统银行，现在大部分都会有一个部门，叫互联网金融部或者网络金融部，它跟原来的组织架构也好，流程体系也好，要求也好都不一样了，但是它的个人的意识、架构都没有发生变化，所以它会比较难受，是这样的，这是它的一个最大的痛点。

赵安全： 我们最近的一个案例，是一个非常大的央企的案例，实际上这个案例本质上来讲是有一个非常强的业务需求，但是在它原来体系里，很难去做这些改进的东西的，它成了一个需要团队来做的事情。当然过程非常痛苦，但是最终还是取得了一定的效果。

4. 您认为它为什么能成功？

赵安全： 我觉得要强调一点，其实我们做的其他领域也是一样的，这中间的转型是非常痛苦的，对所有的人都是很痛苦的，其实即便是开发人员说我想做微服务，但是真正拉开做的时候，它中间的反弹是非常大的。这个案例中一个非常大的优点实际上是有一个比较强势的要求和领导来推动，保证大家必须要把这个事做成，没有前面这个动力，很多事情我估计可能做不成，这是一个非常大的重点。当然，作为开发人员也好，作为软件行业的我们这些同仁也好，都希望去做一些这样比较新的东西，这个是没有问题的，但是过程其实没有这种应用比较强的触动，包括业务需求，这个非常难成功，但实际上也是一步一步做起来的，而不是说一下子能搞定。

5. 最终转型成功之后会给公司带来什么样收益？

赵安全： 大致上来讲是这样的，就是我们刚刚说的业务方面，业务视角这个事情本质上来讲，比如我们做好的一个银行的案例，他们其实已经每两周一个迭代了，它最大的痛苦也来自于这两周一个迭代，他们实际上是非常辛苦，而且这个失败率非常高，整个的变更上线的失败率非常高，经常容易失败。更极端的一个例子是，有一个我们的客户他每周都要上线，但每周他必须要熬一次通宵，所以他实在接受不了这个事情，最终我们这个事情落地下来之后逐步的够把这个事情给缓解了。

赵安全： 现在目前来说也是一个行业逐步的共识，传统行业跟互联网都觉得它非常好，高并发、高可用、弹性好，但是当我们说要怎么走到这一步的时候，就变成一个非常难的事情，因为他们不知道这一步该怎么走。

本质上来讲，我们看到做得比较成功的，实际上还是药拿一个东西来尝试，包括团队、架构、应用都是拿这个东西来试。这个应用最好是有实际业务需求的，因为传统企业跟互联网企业有个很大的区别，互联网企业强调试错，但是传统企业是不能错的，错了之后问题就比较大，所以要找一个应用本身有需求，但是又不能错了之后出问题，这个选择比较重要。

第二，我们看到成功的几个案例，根据我的经验，绝大多数情况下都是找一个比较脱离开传统企业的团队来做这个事情更容易成功，这样实际上是给其他的所有人多了一个试点，告诉他，我们是能干这个事的，这样后边可以逐步推进。我没有经历过传统企业目前全面的转向互联化的，可能会有但是我目前还没看到，应该还是比较少的，大部分都是在路上。我相信从未来来看最终可能会出现一个中间派，就是在传统企业里，所谓双模的中间派和互联网不一样的一个情况会体现在这里。

赵安全： 这个也是我们经常去讲的，首先传统企业里面这个双模是必然长期存在的，而且也是完全没有必要，很多业务完全没有必要去做微服务化，或者DevOps这种转型的。

首先这里有一点，说到传统企业，我刚刚说的传统企业大部分都是比较大的，有自己的开发人员，但是很多小的传统企业根本就没有自己的开发人员，它没有DevOps、微服务这些开发的能力，它没有开发人员，没有必要做这个事情。

第二点它也没有太多的业务需求，很多的业务实际上是没有真正的业务需求去做高并发、高弹性的业务，只要保证它是稳定可靠的就OK了，其他的事情则是完全没有必要做的，主要还是业务需求驱动。

8. 您觉得在转型的时候，应该首先选择哪类的业务居多？

赵安全： 首先业务需求是非常重要的，我们也有这样的案例，客户想适应新技术，但是他选了一个没有真正业务需求的这个应用来做这个事情，那么本身结果就是最后虽然用上了，但是所有人都没有感觉。这事我感觉是非常糟糕的，当然虽然客户付了钱了，但是这事，它对企业也好，对我们也好都是没有帮助的事情。

如果业务需求很重要，它肯定是找一个接近互联网化的业务做C端的大并发的业务，这样的业务来做是比较重要的。传统行业不能错，这个应用最好不要非常核心，比如说拿银行的核心系统来做这个事情明显是不可以的。最好是一旦出了问题，大家还是可以能承得住相应的责任也是非常重要一个点。

赵安全： 其实呢，人员培训这个事情可以举个例子，最近我们一个案例里面，我们培训至少超过五次，而且我们有人专门帮他们去解决各种各样的问题，说实话，培训功能还是非常大的。除了培训本身可能还要去手把手的教一些事情，帮他去解决问题，否则反弹非常大。至于磨合周期，我看到的真正磨合好的有半年起的，但是真正能把这个事做起来三四个月应该也差不多，大家会拐到一个相对正确的路上。

赵安全： 我们案例几乎都不太一样，因为传统企业肯定是开发一个部门，测试一个部门，运营一个部门，但是呢，最近一个案例，是银行的一个互联网部门，首先他们本身基础比较好，它开发和测试是分开的，开发人员负责运维，他已经把运维和开发合并在一起了，这是一个非常好的一个点，这两个合并比开发测试的合并要难。

这两个做了之后，我们做得事情是这样：把测试也合并进来了，那么这个鸿沟本身会存在，组织架构最大难点在于，真的是会打破业务的权力的这个状态，比如开发主管、测试主管，实际上阻力非常大的，在任何企业都会有这个问题。所以说，纵向的你还是主管，但是横向的我们需要以一个业务部门来做这个事情，首先把这个事降到最低，我们刚刚说的这个案例里边，过了半年了之后，在这方面的争议都存在，有的主管就说：你看我说，你不让我管它出问题了。这样的说法都会存在的，他一直会讲这个事情。

把开发测试做完之后还有一个点，我觉得可能非常难做，有的案例推进多了一些，有的案例推不大动，或者说只是有人来接这个职，就是产品经理。我不确认是否所有的传统企业都是没有产品经理的，目前我看到所有传统企业都没看到有产品经理这个角色，没有产品这个角色就代表什么呢？业务需求过来，开发人就开始开发，那么其实不管是做敏捷也好，做DevOps也好，需求管理做不好，后边的所有事情都会有问题，包括微服务也是一样的，那么这个产品经理这个角色非常重要。但是实际上，突然插进去这么一个没有定义的岗位实际上也是比较难的，刚说的那个案例银行里边，最后由项目经理来承担这个职责，我们把这个职责付给他，让他来做这个事，等于说有些效果，但是我觉得这个事情也是需要传统企业去考虑的，一个长期研究院产品没有产品经理是一个非常大的问题。

赵安全： 框架选型我认为最重要的一个点，实际上是社区的活跃度，因为你一旦选错了，就代表你整个全错了，没法改。包括我们做容器也好，在容器行业里，一开始选Swarm，现在你不得不去转K8S，这是第一个点。

第二个重要点实际上是大规模的应用，这方面Spring cloud和Dubbo都没问题。

第三个点还是一些业务需求，我们最近做过一个案例就是，因为Spring cloud和Double都是Java体系的，他要求做C的，这个就会有些问题，我们就用GRPC来做，用GRPC来做就是没有完整的服务治理框架，比较差，你要再自己搭一个东西，这个事还是比较麻烦，所以说我觉得整个来讲，现在Spring Cloud和Dubbo两个都是可选的比较好的方案。

赵安全： 这两个都是非常难的东西，分布式事务和服务治理。我想重点说下服务治理，服务治理我觉得翻译过来就是微服务情况下的运维管理，它最大的难点在于首先它监控非常难，虽然现在监控这个事已经基本上用开源的东西就能搞定了。

另外一个难点是在于故障处理，故障处理难的点哪？首先出了问题，到底问题出在哪里？这个是需要去好好考虑的，没有一个很好的工具支撑可能根本找不到，尤其是现在不光是应用是微服务架构的，下边的框架都是Docker的，Paas层是Docker的，底下的还有IAAS层的虚拟化，网络也是整个虚拟化架构，当一个点出了问题的时候，它可能是因为这个架构有好处，出了问题可能根本就没有任何影响，但是它坏处是真的出了问题，你要一层一层找下去也并不容易。

从微服务本身来讲，故障处理除了软件框架来支撑之外，从无业务逻辑上也是需要去考虑一些容错的事情。举个简单的例子，我今天的计划我要去旅行，但是如果说今天我买不到机票了，那么这就是需要你去想办法来处理的，我要多另外一条路，我要换火车，这个在微服务设计里边业务角度就需要考虑了，因为别的服务就有可能会出问题，我是直接让我的业务停掉不用了，还是说我是降级，或者说我去有些别的方法来处理，从业务逻辑上就需要考虑到这个点。

这个我感觉大家都是在尝试摸索阶段，还是一个长期需要引进的过程，阿里、腾讯他们可能会讲些这样的案子，具体的呢，在我们实际落地的时候，因为跟业务有直接相关性，需要业务人员在这个整个过程中大家一起去摸索、改进它，这个点跟技术有关系，需要有些设计的原则和方法，另外跟业务也有比较强的关系，这个比框架技术要难的多。

赵安全： 刚刚我们说的两个驱动，第一个驱动是业务需求，第二个需求是我们要跟踪行业发展趋势。

第二个驱动很多我们的企业的客户并不是很认可，他们说我们没有业务需求为什么要去跟踪行业趋势？这个问题在哪？当形成趋势之后，现在我们的软件很多是单行架构的，都是这么用的，也并不一定产生很多的问题，但是后边当这个软件要更新换代的时候，它一定会从分布式架构去改进，如果你不去做理解，不去了解它，不去做一些储备，后边你的工作就很难去开展了。包括云也是这样，我们现在很多新的应用，很多新的应用直接就是调用K8S接口，自动就把它部署完了，包括我们最近看区块链它也会提供一些便捷，Hadoop也会在做，Oracle也在做。后边可能提供的应用本身就是一个云化的软件系统，如果你不去管他，不去响应这个趋势，不去研究它、理解它，那后边想要升级的时候，可能连升级都没法做了，升完级之后，连恢复都恢复不了，这个肯定要处理的。

我的建议是，如果有业务需求，还是要尽快去做，如果说我们发现其实也没有特别强的业务需求，还是应该做一些技术储备，尽量有几个人先去了解它，去学习它，等我真正有需求出现，比如说Web构建，出现这些事情之后我们能去搞定它，这是一个比较重的事情，我觉得还是不能忽视它，或者忽视这个趋势。

原文 http://www.infoq.com/cn/interviews/interview-with-zhaoanquan-talk-devops

正文到此结束