对于有志于从事devops相关职业的人，学东西的过程中要如何去实践？

这个问题很不错，自己从事DevOps有3年了，并且会一直从事下去，作为自己的事业深耕。这里不只是为了回答题主的问题，也是为了自己对以后如何去更好的实践DevOps有个梳理。

从工具做起，培养DevOps思维

做任何行业都会有起步阶段，起步的时候我们不可能看的远，理解的也不够深。可能听别人说过DevOps或者从网上看过类似的介绍，就认为DevOps就是把工具做好，让研发更快。对于初学者的确是这样，就是为了把某个工具做好，或者利用现有的工具提高企业内部的研发效率。比如，搭建了一个jenkins就实现了自动化的持续集成，搭建了一个gitlab就能够将企业内部代码统一托管起来，搭建Nexus服务器，实现依赖包的统一管理，搭建Zabbix监控服务器，实现应用服务的监控和告警。这些都是具体的工具，对于初学者，不管是负责开发还是运维，这些工具的使用都是必须的。另外，还要会开发语言，java，python，shell等，自己开发DevOps相关系统。通过具体工具的开发和使用，就会遇到用户的各种问题，这些问题是非常宝贵的财富，每一个问题都会引导你去思考这些工具在哪里没有满足用户需求，为什么？如何去满足？

专注部分更要有全局视角

DevOps的范围是非常广泛的，初始阶段的工具建设是基础，但也只是冰山一角。在做DevOps实践时，我们要专注某一个领域，比如敏捷开发，版本控制，持续交付，运维监控等，每一个领域如果深究，都有很多东西需要学习，都有不断优化的地方。初此之外，我们还有对整个DevOps全貌有个了解，要清晰的知道自己所从事的这个阶段在整个DevOps里处于什么样的位置，我的未知领域是什么？这样我们看到的不只是冰山一角，而是整座冰山。

理论要联系实际

实践出真知。在如今互联网各种知识泛滥的年代，我们缺少的不是获取知识，而是实践的机会。互联网发展20多年，作为软件开发人员的我们，架构师都是未来努力的方向，看过好多《如何成为一名合格的架构师》，对着技术的发展，新框架封装的越来越好，开发人员只需要几个简单的步骤就能使用强大的功能，对于哪些经历过从零打造一个框架的机会，经历过日访问量上亿的系统的改造的机会，经历过阿里双11的架构师又有几个。DevOps也是一样，只有真正去做了，做过了，痛苦过了，回头再去读哪些DevOps书籍的时候才能与作者产生共鸣，里面的每一句话，每一个字才能彻底理解，因为这些都是日常工作中遇到的问题。

DevOps认证，能力的证明

认证是自己能力的证明。这个有肯定比没有好。我们说自己很牛，拿什么来证明呢？现实就是这样，拿着清华大学的毕业证去找工作就是好找。DevOps也是一样，昨天看到一个文章，DevOps举办的一个活动，要求有DevOps相关的认证，这就是敲门砖。就跟上大学一样，既然去上了，拿个毕业证也算是给自己一个交代。

DevOps是属于软件工程垂直领域，如今，都在讲长板原理，要把自己的优势变得越来越强，你就是成功者。

以上是自己的理解，欢迎留言交流！

DevOps哪些厂家技术好？

实施DevOps的核心目标是加速团队、企业的IT精益运行，从根本上提升IT的生产效率，加速部门、企业的业务创新能力。

是的，DevOps的优势很明显。那为什么它这么好，但这些年下来实际落地的企业却这么少。除了作者提到的容器、微服务等相关的『环境因素』外，还有哪些内在因素？普元在这方面又有哪些经验和案例？InfoQ就这些问题对普元的主任架构师顾伟进行了采访（文末有嘉宾二维码，扫码加入微信群）。

受访嘉宾简介

顾伟，毕业于东南大学，现任普元公司主任架构师；先后参与和带领了华为BME、中信银行CBJUP、工商银行CTP、中航信RI、阿里云ACE、普元云计算平台、普元The Platform等大型项目的交付；长期致力于IT技术研究、产品设计、架构咨询等工作，擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术；对DevOps、自动化运维、微服务架构有着浓厚的兴趣。

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计划，好像这都是部门经理的事情。说白了就是缺乏自我管理能力。现在的人确实受打扰太多，但这不是执行不力的借口。建议大家制定计划时，要短期不要长期，要实践而不是停留在概念。

DevOps是如何实现效率的提升？

What is DevOps ?

DevOps 是一组用于促进开发和运维人员之间协作的过程、方法和系统的统称。

Wikipedia对DevOps的定义是：

DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。 ...... DevOps并不仅仅关注软件部署，它是部门间沟通协作的一组流程和方法。

DevOps是Development和Operations的组合，是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运营之间的壁垒和鸿沟。

从下图中，可以看到Dev 和Ops 关注的点是不同的，并且有各自的利益和关注点，沟通必然存在障碍。一个想快速迭代，一个想稳定；一个不关心怎么部署运维，一个不清楚开发架构；由此带来的就是效率的低下，以及相互的抱怨，但是完整的项目并不是仅仅代码写完就完事了，质量/稳定/运维才是更重要的。

DevOps 提倡通过一系列的技术和工具降低开发和运维人员之间的隔阂，实现从开发到最终部署的全流程自动化，从而达到开发运维一体化。通过将 DevOps 的理念引入到整个系统的开发过程中，能够显著提升软件的开发效率，使得各个团队减少时间损耗，更加高效地协同工作，缩短软件交付的周期，更加适应当今快速发展的互联网时代。下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。