@gaoxiaoyunwei2017
2018-04-02T11:17:05.000000Z
字数 2052
阅读 542
白凡
分享:洪烨-哈尔滨银行
编辑:白凡
大家好我是洪烨,来自哈尔滨银行。今天主要讲两个事情,一个是通过一个小故事讲一下我的理解,为什么DevOps从2009年提出到现在突然开始火起来的一个思考。第二个,传统企业究竟怎么样实践和尝试DevOps。
小王创业项目是去学校给学生做盒饭,他要打造了一个团队保证把每天的午饭送到学校。两部分,一个是构建团队一个是交付及运营团队。
构建团队做的事情就是买原材料,由厨师把这些东西做成一个产品。交付及运营团队把这个东西进行包装,把已经包装好的产品运送到客户手里。最终由客服人员收到客户的一些反馈意见,然后再给前面做一个改进。这个其实是大多数做传统或者做实业这种公司生产和交付体系。
半年之后,小王之前餐饮做的挺好的,其他的企业也觉得挺需要这种服务的。
小王业务就发生了一次扩展,小王除了之前的学校的业务以外又谈了一家医院的餐饮以及一家银行的餐饮,这样不同的客户有不同的需求,要求送餐时间不一样,份数不一样,额外需求不一样,地点也不一样。这样就跟原来的交付情况发生了一些区别,在日常工作中,交付运营团队发生了很多接到投诉或者是发生了一些困惑。
在这里我们把这个问题大概整理了一下。比如说他遇到的问题有哪些,这些问题究竟由哪些团队负责?
企业发展必须解决这些问题,所以小王做了几件事:
首先把原来的大并发改成一个小并发并行生产。他把交付团队进行了拆分,这样保证每一个产品都能及时的送到客户手里。
第二个打造一个流程,并且在里面建立了很多反馈的体系。在每个流程之间比如说采购会去检查土豆是否有问题,去切土豆丝检查土豆丝切的是否合理,整个流程下来保证交付的质量。
第三有很多自动化的工具,小王他们也采购了很多这种工具来去保证整个生产的交付。大家想想为什么我要讲这种可能跟DevOps听起来关系并不大的一个故事?
讲这个事情本身也是想让大家去思考DevOps本身在商业中的价值。像十年前比如我们用一个Office和Word,发布颁布之后我们只需要下载装上,没有持续交付的过程。但是随着现在商业以及大环境的变化,对于客户来讲他的软件直接面对客户,比如说现在传统银行里,微信银行、手机银行这种应用越来越多。它需要去做DevOps这方面转型才能保证客户的一点点需求变化就快速的推到客户手里。
但是传统银行里有另一类用户,包括这可能不光是传统银行,哪怕互联网银行也面临同样的问题,就是监管的需求,每天或者每个月要给一些监管机构发一些报表,这种应用它的质量或者标准可能更重要,而不是说快速交付更重要。这类应用也不一定完全适合DevOps这种场景。
之所以讲这个故事还是希望大家能去思考什么时候、什么场景或者什么应用下,我们需要建立一个DevOps的流水线,以及去把DevOps用的更好。
整个传统软件交互的流水线按照实际使用情况分成三层。
最开始传统银行更多的是用VM的大机小机,2014年左右逐渐的把一些系统往X86、PC服务器上做一些迁移。再之后,源流PC服务器、物理机用的越来越少了,更多的逐渐向虚拟机演变。目前也是很多银行应用逐渐往容器里去做一些迁移。但是这个更多的还是停留在应用层面,数据层面走的还是相对慢一些。不管是原来的传统关系型数据库还是大数据的数据存储,更多的还是跑在物理机上面。
对于传统企业或者传统银行这种稳定胜于快速交付的行业或者企业来讲,怎么样保证交付标准是重要的一个话题。标准从何而来?从两方面去汇总成现在使用的一个标准。
这些标准一部分是行业里提出的一些标准,包括现在信通院也发布了一些官方标准。这种标准是大而全,它在方方面面都是考虑到了。我们把这种行业标准作为一个框架。第二个就是我们日常生活中遇到的问题,这个问题作为整个框架中的“血肉”,最终填充出各个企业适合的标准。
整理一些数据库开发规范代码开发规范,自己建设一个审核和运维工具以及平台。直接通过图像化操作快速对这些需求和标准进行审核,有问题也及时修正,大量减少生产过程中发生的问题和隐患。
运维最终是运维到运营的转变。究竟什么是运营?需要从企业业务的角度或者企业价值角度出发。这个就是开源看板平台页面——基于业务分析平台,这上面每天可以看到很多业务当天的运营情况。
总结:实践1:通过虚拟化容器技术逐步向弹性资源平台快速交付演化。
实践2 建立反馈标准语自动化运维平台。
实践3 建立自动化发布流程与工具链。
实践4 建立运营看板,由运维向运营的转变,降低时间上的损耗以及资源上的损耗,能提高效率节约我们的时间成本。
我今天的分享就到这儿,谢谢大家!