论坛6 | 云时代的运维与安全 徐桂林 「如何用DevOps实践最大化释放云生产力」



  • 时间: 2016年7月28日
    发言人: 徐桂林|FIT2CLOUD 技术布道总监
    主题: 如何用DevOps实践最大化释放云生产力


    首先非常感谢大家下午来到这里听我跟大家沟通一下,关于我们对DevOps的一些体会,同时也非常感谢Roy的介绍,他是我的偶像,很早就听说过他的故事,他的故事可以写一部传奇的书了。我今天的主题是如何用“DevOps实践最大化释放云生产力”,简单来说我在FIT2CLOUD这家创业公司,主要是做云管理和DevOps实践,非常细分的领域,之前在阿里云待过两年时间,再之前在一家外企Autodesk,2008年把公司的业务往AWS上迁。我们客户主要是金融、保险、证券、制造业,我们也是青云的合作伙伴,是最早的一批基于青云API做开发的第三方。

    我今天想讲的一些内容是这些,我们的主题是利用DevOps实践最大化释放云生产力,这里面有两个词,一个是云生产力,大家每天都在说云,但是云在企业业务中的生产力体现在什么地方?能给生产力带来多大的价值?我们要把云生产力在完整业务中释放出来,有哪些挑战?DevOps和云的关系,新DevOps模式的出现,该模式在国外非常多的大型公司在采用,效果非常好。最后讲一点,就是在云+DevOps的模式下,不同模式下的角色应该怎么转型。

    云这个词就不用说了,这里有个欧美调查结果,大家可能觉得云应该是中小企业使用最多的,但是在欧美,一千人以上的大型企业在云上的投入比中小企业要多得多。这些企业越大IT越重,越需要云来做一些变革。为什么云普及地这么快?大家回顾传统IT,不温不火,过去二三十年,甲骨文数据库、微软、英特尔芯片都是这样,过去20年如果说传统IT有变化,唯一一个比较大的变化就是虚拟化的诞生,产生了剧变。但是云的出现非常吓人,不到10年时间,已经让那么多传统的巨头感觉到腹背受敌了。

    云这么快的普及,不仅仅是因为云产品的原因,更重要是业务模式的变化。就是互联网化的敏捷业务模式需求,对企业的基础IT产生重大的变革,提出了更高的要求,而这直接导致了很多企业不得不向云转移,因为你对手用更敏捷的方式在生产他的业务了,这是核心问题。
    从这个角度来讲,我们云能够提供更好的敏捷性支持,更好的支持互联网业务。这个敏捷性到底体现在什么地方?

    第一点,你不用管云数据中心了,也不用管基础运维工作了,不用雇管网络连线的人了。

    第二点,很大的变化是按需付费,这个词说了很多遍了,大家可能都很麻木了。我们是一家初创公司,我们最开始启动的资金不是特别大,我们用青云作为我们的开发测试环境,我们在2014年一年,在青云上有一万多台虚机,八千个公网IP,总成本不到两千块钱,青云是按秒计费的,大家可以想象,这是非常吓人的一件事情。所以按需付费是很大的变化,最大的变化就是让传统大型企业对IT的垄断削减了,因为你不需要那么多的前期投入了。

    第三点是自助服务,美国技术标准委员会对云的规定,第一条就是自助服务。自助购买,第二不要审批,第三不设门槛,一点门槛都没了。你支付宝买件衣服五十块钱,在青云上五十块钱也可以买一个服务器。

    最后一条是可编程,传统IT里面基本上可编程仅仅停留在对于资源的管理者。比如说你是管理者你可以通过一些API方式申请对机器释放,但是从来没有把硬件基础设施的可编程能力开放给终端用户,现在云计算可以让终端用户通过API获得一台虚机,可以通过API随时获取网络IP,私有子网,这些服务都可以API化,这个东西的变革是非常大的,过会儿会详细讲这个为什么这么重要。

    如果把这几个分类的话,会发现前面两类是共享经济带来的优势,后面其实才是企业云生产力要能得到足够释放的核心所在,非常关键的所在。你上公有云或者购买了私有云,某种程度上自然会获得前一类收益。但是后面两个是很多人用了云之后,其实没有从中把红利发挥出来的关键所在。所以,如果希望最大化自己的云生产力,最重要的是要应用可编程和自助服务这两个特征。

    这两个特征是是放在企业业务当中,大企业、小企业,中型企业都包括。大家知道都很好,但是为什么用不上?过去一年多我们服务了将近20多家的传统企业,各个行业都有,也有互联网企业。我们做了一些总结:

    1.资源交付流程的问题,传统企业资源交互是认为IT是成本中心,不是创业中心,我们重要的职责是省钱,传统企业当中有非常多的人这样考虑问题。我宁愿牺牲资源的使用便利性都得把钱控制好,因为IT是稀缺资源。所以在这种情况下,再加上传统IT的设计基本上没有一些自动化的东西来帮助IT 中心把自动化能力开放给终端用户,业务用户,所以传统IT设计思路是什么?就是集中式审批制的IT。可是在互联网公司大家感觉不到,银行、保险、制造业基本上都是这么做的。我们服务过一个全国非常知名的银行,他们的口号是科技兴行为本,就这样,他们的获取一台虚机需要两天,一个内容 IP 需要一天,这三天时间已经是最快的了。但其实人力资源更稀缺,人更重要,怎么把人的生产力释放出来,而不是整天被硬件绑住。

    企业IT使用应该交由业务团队计划,不是完全由集中管控的IT部门管理。资源交付也变成可编程了,因为你业务环境可以通过API做事情了,自助交互是最基本的原则。但是这个东西跟传统的管理思维是不匹配的,传统流程中需要审核、集中管理,你说你要自服务,每个业务都自己弄。这个冲突在企业里,最后体现出两个结果。第一个云平台退化,这是最典型的,很多公司有私有云,发现私有云上获取一台机器还是要一两天,自助式的原则一台机器创建和初始化应该15分钟之内,一个集群业务的创建和上线,基本部署完成应该1小时之内,这是业内公认的一个标准,但是你申请一个虚机还要半个小时等等,这就导致了第一个问题。

    第二系统架构设计问题。大家提的比较多的是系统架构的设计,传统IT基本上是垂直伸缩,不断升级机器。负载稳定,为什么传统IT负载稳定?因为传统IT的终端用户不是你的最终用户。你有很多业务支撑用户,比如说是运营商,你最终用户是打电话的人,实际上你系统的用户是你柜台的操作员,所以两个不一致性导致了很大的不一样。集中式的部署架构是常见的,通过提升单点可靠性来提升系统可用性。而互联网化IT系统架构特征强调水平伸缩,需要强弹性,弱一致性,分布式部署架构,强调Fail-Over,不依靠单点可靠性,对传统架构有很大的挑战。

    这就带来了一个问题,很多企业为了上云,架构没办法改,有些架构特别老,有些东西要改要很长时间。那我把云平台搬上去作为更好的IDC去用,云上的水平伸缩,云上的自动化,云上分布式的架构优势都发挥不出来了,这是一个老大难的问题。这在很多企业用户里,甚至我们曾经碰到一个做ERP的厂商,他们告诉我们他们架构是无解的,他们要上云是无解的,说除非从头设计。为什么在很多垂直领域会出现很多像PaaS、SaaS服务出来,因为很多东西要重新设计,让传统厂商很难受。

    第三个是传统研发组织方式。我就说一点,你们公司开发测试部门和生产部门工具量是千差万别的,两个可能是不搭边的。部门划分也很严格,开发测试人员哪怕瞄一眼设计人员都不行的。开发人员代码写完,比如说金融行业用IBM RTC一放就不管了,我验证一下就不管了,找别人去上线吧。另外是互联网化,我们到了那家非常知名的银行里去,他们最大的反馈就是我现在很有钱,也要向互联网化转型。5年前运维人员,开发人员比例1:1,现在比例是1:5,未来可以到1:10,这么一拨人根本不知道怎么组织互联网化的生产和开发。这里面要强调一点,在互联网化强调业务的垂直性,这一点非常重要。全站、全流程的自动化,信息一定要汇总在同一平台做流通。你构建会产生不一样的包,整个团队,测试、开发、生产团队都应该是可见的,这是很重要的。这叫做垂直整合型的生产方式。你会发现很多公司上云之后研发没有任何变化。原来我是怎么组织生产、研发,我仍然这么组织生产、研发,生产人员、开发人员各有各的云账号,从来不协作,这同样限制了生产力的发展。

    这里总结一下,以上这些挑战都现实存在在企业里,如果我们回过头来看会发现它们不是技术的挑战,很多都是观念的挑战和业务组织关系的挑战。我们上云的同时,非常重要的一点是我们要建立云使用能力,这不仅仅是把基础设施替换一下。当然云替换基础设施是有价值的,但是我们应该更好的释放它的能力。

    我们认为DevOps能力建设是提高企业云使用能力的最好抓手和实践通道!如果你要建设你的云使用能力,DevOps建设是最好的突破口,而且这也是有章可循的突破口。很多时候讲云的生产力很虚,但是DevOps是做好了,很多地方就会自然通了,这是非常好的突破点。DevOps这个理念在10年前就出现了,但是真正让它飞入寻常百姓家是靠云完成的。DevOps跟云相比有多么重要?大家知道非常知名的公司Gartner,他们对云会做评价,下图这是他们评价的指标。

    0_1470889840850_upload-b94b57c4-8d80-4dd5-9824-37bfdf05e7b7

    应用开发、批量计算、原生云应用、通用企业应用,可以看到DevOps比重高得吓人,分别是30%、14%、40%、10%,为什么DevOps这么重要?DevOps跟云是卵生兄妹。你用了云,如果你DevOps实践好的话可以把云生产力大幅度释放出来,效率会大幅度提高。如果你把它仅仅看成传统IT,你很多生产力是释放不出来的。

    青云在这方面在国内做得非常领先。我们做多云管理,对接很多云,发现青云做的是非常好的。

    接下来讲一下DevOps和云,DevOps的定义就不展开说了,大家提了很多。我们理解DevOps里面就三样东西,一样东西比较虚一点,但是需要很多企业去思考,就是企业的组织架构和文化。这个东西不是你整天去开会就可以的,而是你通过第二件事(一系列工程最佳实践)、第三件事(落实DevOps最佳实践的工具和平台)来影响,形成一个正循环。如果我们讲DevOps文化,就跟讲中国足球是体制问题一样,永远没解的,你一定要踢一脚,把球开起来才能往前推。

    这个领域里有一家公司Puppet labs每年都会做调查,他们提了一个词是持续交付能力。交付质量、交付效率他分成了两个指标,大家可以自己评分。不同环境里升级,包括之前的打包、代码,这个流水线很明显。但是里面有很多问题,比如说DevOps要求开发测试、准生产和生产环境一致性,在云上很简单,首先单机模板标准化,第二是基础设施创建自动化,就是你创建机器,创建集群不应该是人去做,而应该变成一个模板化的东西自动做。

    0_1470889877193_upload-c15ee0c6-06a2-4938-bde1-3a4f770da226
    青云的可视化编排的界面

    第三个基础设施编排自动化,这也是青云QingCloud 推出的一个服务,可以严格保证在不同环境里编排出来的东西是完全一样的,这个产品非常棒。自动化之后还可以把自动化的东西变成一个个模板,变成一个个新的文件,这个文件还可以放回到你的版本管理系统里做。比如说版本1.0生成文件是这样的,需要两台机器后面加IP,后面业务代码升级之后,我需要三台机器,增加一台,所有基础设施原来是冷冰冰的机器,但是现在基础设施变成了一组文件,这个文件可以跟着你的版本往前走,所以基础设施完全可以像代码一样管理。如果你在云上做的更好的话,这是第四步。最后一步就是版本化。 首先1、标准模板,2、机器创建自动化,3、集群编排化,4、编排模板化,5、模板的版本化,如果你把这几个做完之后,做到每个环境的基础设施完全一样,一点不差,这其实就是云上非常好的最佳实践。

    第二个最佳实践是基础设施到最终服务的全站自动化,你基础设施创建好了,上面要部业务,你开发环境这么做,测试环境这么做,业务过程中又涉及到很多手动工作,经常会出现不一致性,经常会出现问题,云在这方面也提供了非常好的实践。主机内部自动化,在云平台上有一个服务叫Userdata和Metadata以及云主机角色授权服务,在国内这两种服务是青云最先推出的,别的云平台最近才出来,这两个服务非常重要。比如你启动一台机器,需要在机器上部署应用,但是这个机器你进不去,Userdata和Metadata这两个东西就提供一个口,让你的业务可以通过这个口,通过云平台分发下去,到里面接管机器。大家感兴趣可以看青云的文档,云主机内部自动化,部署也可以自动化,业务可以持续部署自动化,业务发布自动化,在云上完全可以自动化,不需要运维人员整天去工作了。

    0_1470889917381_upload-e0520bc9-d6e3-4d24-bebb-97d497643689

    0_1470889923412_upload-6b2d0733-1936-4571-9b07-2a2208f093ea

    我截了几个图,这是青云提供Metadata的情况,Userdata上面可以自己写一段脚本,机器可以自动执行,可以做任何事情。好处是不需要向青云保留任何用户密码,是云平台提供的这个功能。这也是我们提供的一个功能,就是基于云平台提供的。

    前面讲了云上的实践,DevOps和云的结合,可以帮助你建立DevOps能力,建立DevOps的能力同时把云生产力自助、可编程这些发挥出来。最后,我们提一个云+DevOps的生产模式,这个生产模式大概在2010年在国外正式被提出来。

    0_1470890024676_upload-a0138d3f-f76a-42c5-b685-4122e3b27d25

    你如果看上图这三个模式,传统开发模式从业务、需求、采购往下走,云开发模式业务采购,安装机器不用做了,其他的其要做。基于DevOps的话,后面一个阶段,结合你自己的自动化工具,能把整个应用生命周期建立出一个非常快的迭代周期。我在这边提了云+DevOps的几个特点:

    • 优先选择云平台作为业务承载基础设施
    • 以业务交付为目标组织资源
    • 强调应用全生命周期的自动化
    • 建立通畅的产品反馈和迭代通道

    你一旦自动化起来之后,会发现你整个产品迭代速度上去了,产品的反馈就会快很多,这是非常重要的一个事情。其实很多公司整天讲我要快速迭代,但是他就是说口号,没办法迭代起来,发布一个新版本还要两个星期,用户都走掉了。

    对于云+DevOps我们提了几个建议:

    第一个是客观面对多云(混合云)的基础设施,在多云的情况下一定要避免一个问题,就是认为多云战略就等于我是多云架构,一定要在应用到业务架构上 。不是的,多云是个战略,开发环境在青云上,生产环境在本地也可以,找到最适合你业务的架构就好,不要死抠。对于企业来讲多云是战略,是保证你企业IT安全的,但是对于每个业务来讲不一定非要多云架构。

    我们总说私有云,青云也做私有云。我们的观点很简单,企业应不应该关心私有云?应该关心,因为是很好的企业IT。千万不要把共有云和私有云对立起来,这里面提到一个企业的上云过程 。所以企业应该关注私有云,私有云是比传统IT更好的东西,不要把私有云、共有云进行对立,该上共有云上,上不了的选择私有云,比传统IT更好。

    第二,建立企业内部统一的资源交互平台,自助式的,企业内部一定会多公有云,私有云,还有虚拟化环境。如果不整合到一块,一会儿到这儿,一会儿到那儿也很难,自助式服务目录是很好的产品形态。服务目录不仅仅是信息系统,要自动化创建整个资源。服务目录可以对接你的OA流程,但是尽量不要所有东西都审批,比如说开发测试环境不用每个都审批。

    第三,IT职能部门的服务化改造,这个不展开说,每个IT职能部门,你是安全部门,都要思考怎么让自己技能服务化,未来一定是API连接整个流水线和交互的,你不应该整天人家给你发工单、邮件,这不是很合理的。
    第四,打造持续交付的高速公路。端到端地打通从代码到最终服务;全链条自动化为标准构建(人工干预是例外);开放接口对接交付链上的不同阶段、不同职能部门。

    第五,合理关心云平台费用,这跟主题关系不是很大,但是有人会问公有云是不是比较便宜。从一次性预算向持续性优化转移,从事前审批向事中管控和事后审计转型,你优化省一块钱,第二天你就少付一块钱,这是非常好的。从刚性成本构架向成本感知构架转变,我用贵的还是便宜的机器?我成本太高不做了,这是可能的,可以自动化的。每天周一到周五启动不同的机器,因为不同机器在不同负载下成本优势是不一样的,完全可以做调度系统来实现。

    这是DevOps能力建设的核心,刚才讲要建立DevOps能力释放你的云平台,DevOps能力就是两个,一个是自服务的能力,不仅是你基础设施服务,你的专业技术服务,安全部门服务能力。第二个是持续交付能力,如果这两条能力都建设好了,其实就是典型的DevOps团队。当然不同的企业可能现在处理不同的区域,大家回去想一想可以做评估,看按照什么路径来走。

    新生产模式下的角色转型

    0_1470890106348_upload-59d752d1-95a1-43de-97b7-38c3ec6241a9

    各位当中有公司IT经理的话,我非常建议大家看这张图。2012年美国一个研究团队说的,说从IT经理向Cloud经理的转变,这可能是你职业生涯中,过去20年来最主要的变化,就是IT经理的一个转变过程。

    建立Cloud Native与 DevOps 思维模式,架构首先是云就绪,然后到云友好,最典型的就是你有组件可以直接用云了,最后到云原生,水平扩展。应用研发,就是API化,自动化,每天想怎么把自己东西API化,哪些东西会被人家API掉,这是很重要的。传统方式你是把功能做好,而不是把API做好。最后讲建立应用运维中心的运维体系,你换硬盘等等都不用做了,之后是企业文化,你自己的事自己做,别人管不了,就讲这么多,谢谢大家!


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待