为什么DevOps很好，但80%的公司却无法落地？
前段时间，我们有发过一篇题为《炒了8年的概念，到底该如何理解DevOps这个词》的文章，文中作者就DevOps的概念、价值、目标、挑战做了梳理，如作者所说，实施DevOps的核心目标是加速团队、企业的IT精益运行，从根本上提升IT的生产效率，加速部门、企业的业务创新能力。是的，DevOps的优势很明显。那为什么它这么好，但这些年下来实际落地的企业却这么少。除了作者提到的容器、微服务等相关的『环境因素』外，还有哪些内在因素？普元在这方面又有哪些经验和案例？InfoQ就这些问题对普元的主任架构师顾伟进行了采访（文末有嘉宾二维码，扫码加入微信群）。InfoQ：请介绍下您的技术背景和目前负责的项目？能否回顾总结并阶段性地介绍下您的技术成长经历？顾伟： 大家好，我是顾伟，专注于DevOps和云计算领域，擅长CI/CD、前端、OSGI、容器等技术，对各类自动化、智能化有着浓厚的兴趣。目前负责普元The Platform云平台产品的设计工作，兼顾DevOps、CaaS、IaaS等外部实施工作。到目前，我的职业生涯中经历的领域和技术栈比较杂，大体分为以下四个阶段：· 06年-07年：以项目实施为主，参与了华为BME项目的多期建设，熟练掌握了包括Java、Web、数据库等基本技能。· 07年-10年：主要参与了两款产品研发，一款是基于Ext的所见即所得的UI产品，一款是基于Eclipse插件开发的IDE平台，熟练掌握了主流UI框架和Eclipse的大部分源码。回过头来看，学习优秀框架设计的经历，为今后的架构之路奠定了较好的基础。· 10年-12年：以大型企业级平台实施为主，参与了工商银行、中信银行的统一平台项目，也主导过中航信RI等创新项目。在加固已有知识的同时，这段经历使我掌握了诸多企业级中间件（比如IBM MQ、ILOG、BMC CMDB等）的使用和扩展，同时也开始接触了如云计算、大数据领域的新技术。· 13年-16年：从与阿里云ACE合作云产品开始，先后历经了普元IaaS（OpenStack），CaaS（Kubernetes + Docker），DevOps领域等产品设计及研发工作。这段时间，拥抱开源并实践于企业级产品中，算是正式走进了企业云计算领域。InfoQ：您曾经提到过您很关注DevOps和自动化运维。能否简要介绍下您对这两者的理解和未来趋势的看法？DevOps给运维部分带来了哪些变化？顾伟：在我的理解里，DevOps其实是包含了自动化运维的。只是现在这两种概念都很常见，所以我分开提及的。大家肯定都能感觉到，DevOps、微服务、容器等概念已经越来越热了。这让我想到了3年前OpenStack的状态，各大社区、创业公司、传统企业，纷纷投入到OpenStack怀抱；而现在，虽然是有一些公司存活下来了，但总的来看谁也没赚到多少钱，也没有哪家公司如预想般把VMware给替代了。过热的后果是反而把市场秩序给弄得一团糟，产品低价竞争，人员漫天要价。我觉得现在的DevOps也到了这个岔路口，有很多公司在热炒DevOps的概念，并纷纷宣布转型成功；而从实际市场、尤其企业市场的反馈来看，客户对此的评价几乎众口一词：“DevOps很好，但我们很难做到”。究其原因，最缺乏的是DevOps方案提供公司真正到深入到企业里面，沉下心来，结合实际情况进行实施实践，从而帮助客户切实地做到横向协作打通、纵向工具链打通。所以我觉得，市场到今年底前还是会充斥着很多概念炒作；但从明年开始，大家会逐步看到，这个领域中真正的脱颖而出的，将会是那些已经将DevOps实际落地的企业和服务商。DevOps给运维带来的变化，主要体现在运维工具的打通，但是单单从这个角度看影响并不很明显。如果能够从企业、部门、团队多维角度结合来看，才能发现DevOps独特的地方。DevOps本质上是一个持续优化的过程，一般需要从组织、技术、流程三个维度考虑，目标是加速IT的精益运营。 DevOps推崇的是让开发、测试、运维友好协作，倡导大家都能为各自的上下游提供便利，形成演进回环，有效的支撑业务创新。InfoQ：你提到，DevOps很好，但也很难落地。你认为难点在哪里？如果说要突破这些挑战，你认为团队负责人应该重点从哪些方面入手？顾伟：我觉得DevOps最大的难点并不是所谓的文化或组织（因为这个不是说改变或打破就能改变或打破的），而是各家公司的流程和工具都是有差异的，每家都会有自己的特色与特殊部分，很难有所谓的通用产品能解决所有问题。举个代码库工具使用方式的例子，之前在我们微信群里还单独拿出来讨论的，有的企业是主干开发、分支release；有的企业是分支开发、分支release，接着再往下细，都是分支开发并release的企业，同一个产品版本，有的是开发环境、测试环境、生产环境对应的分支物理上是不同的，也有开发测试环境相同、生产环境不同的，还有从开发到最终上线就一个分支的。而且每家做法都有很充分的理由……想突破这种问题，对于一个团队负责人来说，要能在一定的条件下，有效组织团队、逐步优化流程。这里说的“一定的条件”涉及很多方面，比如不要试图按理想情况去打通部门，这是永远不可能的，再比如想让团队每个人都有一样的高度、理解力、责任感也是很难实现的。所以对于一个团队负责人来说，想实施好DevOps，需要理清现状，统一概念模型，制定阶段性目标，激发团队热情，有效规避风险；而不是一上来就是要用什么技术，要有多好的理念之类。InfoQ：你如何看不可变基础设施？顾伟：看到这个问题，首先想吐吐槽：初次听到不可变的基础设施时，我当时不知道为什么，还想起了另外一个概念：基础设施即代码，虽然这两者没有特别的强关联，但第一感觉就是，现在市场上很喜欢拿基础设施来说事。我以前做过IaaS、PaaS，也参与过运维工作，基础设施在我的理解里是一个底层、重、固化的东西。随着一切皆服务、一切皆代码、无状态这些概念起来，让我觉得市场上的任何词，都可以变成“怎么说都有理”的理念。回归正题，我认为要像不可变的基础设施的目标前行，有两点比较重要：· 从使用者的角度来看，基础设施最好是无差异无感知的，所谓的无差异或无感知是说无论下面是什么样的异构硬件、不同系统等，对上层业务的服务提供方式都是统一的；· 从提供者的角度来看，基础设施从建立之初就不要再变更，只有新建与替换，粒度很重要，这也是很多人甚至会提到消除SSH的想法的原因。对于不可变基础设施的未来，我认为是个长期的目标。随着容器、DevOps能力的逐步落地，给了这个目标一个可实现路径，但真的要做到完全不变，我觉得是很难的，因为生态还没有起来，很多层的能力或接口还没有统一和规范，差异化永远是不可变的最大拦路虎。InfoQ：这两天又有人提出了OpsDev的概念，你怎么看？顾伟：这个我之前也看到了，看到第一句解释后我就没再看下去，因为从来没有人说过DevOps到底是Dev2Ops还是Ops2Dev，为什么？因为无论是Dev还是Ops，都应该将对方视为可标准的对象，同时为对方提供足够可规范的便捷（主动的尝试着去适应对方），这本来就不是一个单向的过程。所以我认为无论是叫DevOps，还是叫OpsDev，大家的目标都是一样的，切勿认为词语上的谁先谁后，就意味着谁主动谁被动。在不失规范与流程的前提下，打通上下游、双向协作才是DevOps的真谛。InfoQ：您即将在CNUTCon全球容器技术大会上和我们分享《基于微服务架构的容器云之实践》，可否先大概介绍下你们的容器云？顾伟： 其实普元的主要目标是落地DevOps，在技术实现上，只是底层默认使用了CaaS作为支撑（当然平台也兼容IaaS）。平台在原有的基础能力之上，实现了容器+微服务的部分，并不断版本迭代演变至今。第一个版本花费约半年多时间。这次，为了契合容器大会主题，我选择了底层CaaS部分的实践进行分享。目前我们的容器云既可以运行于私有云（OpenStack、VMware），也可以支持在公有云（阿里云）上运行。平台以微服务架构为支撑，使用了Kubernetes + Docker的组合，以CoreOS、Flannel、SkyDNS等作为支撑选件，集成了包括MySQL、Redis、GIT、Nexus、Jenkins、Docker Registry等基础服务，形成了一款用于支撑企业DevOps的容器云平台。平台最终架构图（含DevOps能力）如下：InfoQ：这套容器+微服务实现的DevOps方案，您认为哪类行业的企业可以借鉴参考？传统企业可以在哪种情况下，开展怎样的尝试？又该如何拆分传统应用？顾伟： 这套方案相对来说，比较适合有一定规模的企业或互联网公司。因为如果团队较小、业务较简单（比如只有极少数量的App），那首要的问题还不在精益化上，通过人来做管理配置，也不会特别复杂。对于传统企业来说，我的建议是尝试需要首先从这两方面开始：· 持续发布能力：这是打通开发测试与运维的最佳着手点，也是业界目前方案成熟度较好的模块。· 自服务能力：自助和自动，是打通上下游、提升运营效率的有效手段，自服务能力强调的正是这一点。至于提及微服务化是如何进行单块应用拆分，我觉得是这之后的事情：没有配套的运营支撑平台，何谈微服务架构。InfoQ：您提到过目前的这个方案在13年的时候普元就有提出过。当年是在什么样的情况下想到的呢？为什么当时没有落地这样的想法？顾伟： 翻翻历史，这个点子是13年的时候，我们董事长刘亚东先生提出的，当时他指出：“数字化未来会将企业每个人、每台机器都变成一个节点，企业信息平台需要具备打通供应链、资金链、物流链、销售链、服务链等能力，这就需要企业在未来竞争中找到自己的位置，就必须用数字化企业云平台”。至于为什么当时没有落实下来？我个人觉得，毕竟当时董事长提出的无论数字化、还是连接一切等概念还比较前沿，我们团队的积累和认知不是很够等种种原因吧，没有在当时真正执行起来。现在回过头来看，算是在给当时的愿景圆梦吧！InfoQ：为什么微服务的架构要采用容器做默认承载？如果不采用容器技术，您认为微服务化会面临怎样的难题？除了微服务化架构的实现，普元还有在其他情况下使用过容器技术吗?顾伟： 首先我的观点是，微服务架构和容器没有任何关系，大家也可去翻一翻Martin Flower的文章。那为什么现在大家看到的文章中，提到微服务就会提容器，或者提DevOps，本质上是因为以下两点：其实很多公司的现状是仅仅实现了容器管理，但是又想接下来向微服务化靠拢，于是就出现了强关联的概念。 事实上，现在也确实存在很多企业把两者结合在一起使用。无意中让大家误会了两者的关系。 但是这只是说明了两者相伴相生的现象，并不意味着强因果关系。容器的优势在于：轻量化、原子化、可移植性、快速集成等，而这与微服务所倡导的松耦合、高内聚有着异曲同工之处。 在实际使用中，往往容器+微服务确实可发挥 1+1>2 的功效。容器可以作为默认承载，但要支撑企业级系统，不能只有默认承载。因为容器的相关技术完备性现在还不足以完全支撑业务，像容器的存储方案、有状态服务方案这些生态技术还并不太成熟。如果不采用容器技术，传统VM技术、或者说IaaS，甚至纯物理机架构，照样可以支撑微服务架构，只是在管理上稍微复杂些。在普元，我们是通过统一的环境管理（内部系统叫SEM），来屏蔽底层基础设施差异的，大家可参考我们异构环境下的统一概念模型：目前容器技术的使用主要在这款数字化云平台里，其他地方用的较少，只在一些客户试点项目中有过尝试。InfoQ：相比较历史系统的DevOps，基于容器技术的DevOps具有哪些特点和优势，适用于哪些情况？您是否认同“容器改变DevOps”这种观点？顾伟： DevOps有时会让人觉得很遥远，也有很多企业会觉得先做到自动化运维就足够了，大家对于这个概念其实褒贬不一。技术方案上，也是层出不穷，近期看到一些微信群、公开课、沙龙在讨论DevOps实现：有用容器的；有基于Puppet、SaltStack延伸的；还有一些生于Cloud Foundry、OpenShift这些传统PaaS之上。换而言之，DevOps其实并不局限于任何具体技术，只是容器技术在实现DevOps时有一定的优势：· 灵活：DevOps的一项重要工作是“编排”工具链，要求能够对“原子活动”进行快速串接，而容器本身对于原子化及编排能力就有很好的支撑。· 集约：DevOps的一大价值是资源集约管理，容器相对于传统VM，在资源利用上就有很大优势，其资源长短生命周期皆宜的特征，对于像开发测试云这样的需求尤其合适。· 标准：以镜像为粒度的管理模式，相比于零散脚本、多变介质、各种小工具等规范度不高的传统开发运维，给了实施者一定的标准。伴随着配置、服务状态等生态技术的补充，容器实施DevOps的方案会变得更完善。您提到的“容器改变DevOps”说法，我认为偏绝对；我更倾向于“容器让DevOps更容易”。InfoQ：对于容器的运维，您认为有哪些需要特别注意的问题呢？能否详细谈谈的双模架构（模态1：传统技术，模态2：容器技术）的自动化运维？顾伟： 我认为对于容器本身的运维，其实和传统的运维没有太大差别。要说容器运维有什么特别注意点，我觉的下面大家可关注以下3点：选择一个合适的框架，不要什么都自己研发：目前业界很好的框架并不多，K8S、Mesos、Docker本身的一些，选择您觉得和你们理念最一致的，作为你的基础框架。避免惯性思维：很多做过传统运维的同学，在遇到容器时，第一想法还是用既有知识和习惯管理，所以大家会发现，现在很多企业把容器当VM用，或者宿主系统一定要XXX，这个往往束缚了容器运维的优势。要向上抽象：毕竟容器还不能完全替换企业既有，那资源、中间件、应用的运维和容器的运维是不是可以统一，这就要求在运维角度抽象一层模型，便于后续的一体化运营平台的建设。对于双模架构的自动化运维，核心问题就在于能否抽象出一套兼容的模型，屏蔽各种异构差异化，可从以下四个方面考虑：· 环境：主机、存储、网络、容器的差异化。· 配置：应用配置与环境配置，动态配置与静态配置。· 仓库：三方仓库、部署包仓库、镜像仓库等。· 流程：编译流程、部署流程、故障流程等。InfoQ：您说这个点子成功在于：”市场上的客户反馈和内部的能力驱动”。能否将这两个方面进行详细的展开论述？顾伟： 不仅仅是这个点子，我认为任何点子的成功都离不开这两方面：客户反馈：反馈的核心价值在于驱动产品向正确的方向演进，比如小米，从设计之初就笼络了一群发烧友，请他们来提建议，帮助做设计。换个时髦的词叫MVP，意思和快速推出试错试对，这与管理学中的PDCA质量环有着想通的理念。我们要做大设计小版本，进而通过Inside-out & Out-inside的有效配合，基于反馈快速迭代，才能推出符合市场需求的产品。能力驱动：这个也可以讲成康威定律，我更倾向于称之为康威定律+，团队一定程度上决定了业务架构，拥有一个全栈的团队，对于一些创新类点子有着非常重要的作用。在一个点子形成之初，原型、场景、计划、设计、迭代模式、技术预研等，环环相扣，任何决定都对后期的发展有着的重要影响，所以我一直认为：有什么样的基因，做什么类型的事情。有什么能力的团队，做什么规模的事情。InfoQ：最后一个问题：技术变革日新月异的今天，对于立志在技术领域中长久发展的年轻人，您有什么建议和忠告？顾伟：忠告不敢当，结合我带新人的经验谈谈一些想法吧。首先，技术是学不完的，以前是，现在更是。对于刚开始工作的同学，在精不在广。任何有一定规模的技术框架，都有很多值得深入学习的地方，别人为何这么设计，相比同类产品有什么优势。多思考，多总结。不要一味的只管调试代码，fix bug……学技术之外，也要学做人。技术再牛，如果无法融入团队，那还是没用。此外，新同学必须要有自主性。现在很多新同学有个通病，遇到问题就问导师。不是说不能问，关键在于问之前你有没有真正的花精力尝试过，或者试着问题缩小到一定范围，不能说一遇到个坎就找人帮忙，会让团队的人觉得事情交给你很不放心。最后就是执行力很重要。很多同学都会定目标定计划，但却很少有人制定对应的check计划，好像这都是部门经理的事情。说白了就是缺乏自我管理能力。现在的人确实受打扰太多，但这不是执行不力的借口。建议大家制定计划时，要短期不要长期，要实践而不是停留在概念。（顾伟原创）
页:
[1]