在复杂业务体系中DevOps理论及方法的实践

刚刚说过,大家在不同的行业里面,在不同的业务里面,它对应的发布方式还不一样,我相信目前我们在座的,系统里面也有一些人是用手工发布的方法上线.我知道一个比较大的公司,它的部署也是很落后的方式,因为它前面有负载均衡,它布的时候还是要登一些脚本,把负载均衡上的东西剔除,然后再更新,它需要更新多个脚本,这是很浪费时间和精力的过程.

看看我们以前面临的问题.这是我们的某个平台,主要是支付相关的.大家知道我们除了游戏服务器之外,还有相关的登录、认证和计费的平台.我们第一个选取的案例是在支付平台这边做的一些 DevOps 实践.

随着公司业务的发展,日积月累,你这个模块可能会越来越多,部署了之后会有测试,测试了之后交给运维,但是测试的模块名和运维的模块名可能是不一样的,这里面存在一个协调的问题.因为有人工协调的过程,不然导致这个部署需要排期,原来部署和测试系统是割裂的,它们之间没有对应的关系.

?

我们是怎么改进的呢?现在已经做的工作是：

• 第一,我们建立在部署流水线上不同环节的模块对应关系,首先把它映射好.比如说测试和运维这边的部署系统,它们之间的对应关系要映射到数据库里面去,这样就可以实现从前端出发的部署动作.
• 第二,后端的部署系统,它需要提供对应的功能接口.比如说它需要上游的系统提供一个模块对应哪些服务器的接口,当上游需要部署某个模块的时候,它就知道在测试环境里面需要部署哪些服务器,在正式环境,灰度发布的时候需要先部署哪些,再部署哪些.
• 第三,建立对应的授权机制,我们可以把部分模块的授权前置给开发上线,或者是由运维从内部平台直接部署上线,取得的效果是非常明显的.在2016年12月份的时候我们做了一个统计,当时有900多次的部署,其中50%以上通过新平台自动部署,大约10%的模块可以由开发自主上线,不涉及到核心功能的,开发简单测试一下就直接上去了.非核心模块的部署,我们可以在5分钟内完成,不再需要一些配置管理员进行上线的排期和编排.

这是我们部署的系统的界面,它会选择对应的版本,选择你是灰度发布,还是部署到生产环节里面,这个动作很多情况下已经不需要运维去做了,直接测试完成之后就可以上线了,这时候就把运维的工作解放出来了.

这是我们的部署过程,对于自动部署,银行和金融机构有要求,开发和运维要分离,我们现在做的是让开发和测试都可以上线.

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!