在复杂业务体系中DevOps理论及方法的实践
|
在构建组织文化过程中有三点：沟通、协作、集成.集成肯定是一种自动化集成,而不是说手工对接的过程.这就要求我们在开发、测试和运维整个链条里面,在每个环节上要能实现一定程度的自动化,不能说没有对应的运维自动化系统来对接前面的需求,完全是通过公开的形式去做发布、部署,其实是不符合快速交付这样一个理念的. 关于自动化运维这一块,我可以简单说一下我们盛大游戏是怎么做的.大家知道盛大游戏目前是国内比较领先的游戏发行公司,它创立的时间比较早,在1999年这个公司就成立了,到目前已经有18年的历史. 它现在面临的问题,在运营方面主要表现为几个：一是服务器操作系统异构；另外一个是我们的服务器数量特别多,在高峰期的时候,我们的服务器达到2万台的规模. 因为每一个游戏代理过来的时候,游戏的开发商(比如说美国、韩国、日本)服务器的偏好不一样,面对这样的挑战,我们在实现自动化集成的过程中,我们是怎么构建自动化运维平台的呢?
从这个图可以看到,我们有一台中央控制机器,它从 CMDB 里面读写数据,根据不同的服务器的类型和操作内容,把这个命令分发到对应的服务器上面去. 我们可以看一下这里面的几个特点： 第一,我们这个平台是采用 BS 架构的,不需要在电脑上装软件,现在在家里都可以操作,完成这个运维任务； 第二,我们使用的是通用的协议来管理着所有的异构系统,比如说我们在 windows 下面,大家知道以前管理 windows 是比较困难的,现在有很多公司在这一块也是依靠手工去操作的,这样会很麻烦,也有可能造成一些遗漏或者是错误的过程. 对于 windows 管理,我们也是采用了 SSH 的方法去做,这样就可以让所有服务器以相同的方式管理起来,比如说它们的安全策略,公钥和私钥的管理,另外还有一些审计,都可以内置在这个操作平台里面. 关于自动化运维平台这一块,还要注意做一些并发的设置,以及超时和重试的机制,都需要考虑到里面去,不能因为一些顺序的执行,某台服务器的故障,或者是连接服务器的问题,导致它无法连接,导致整个任务延迟. 现在我们在做另外一个系统是作业编排系统,如果知道 Ansible ?playbooks 的话,可以看一下它的方式和方法.我们知道 playbooks 是通过声明一些配置项,然后把它编排起来,把所有的人工分类的步骤做进一个配置里面,让它顺序执行. 比如说我们做游戏维护的时候：
通过一些作业编排,就能更大地减少这个运维的重复劳动的过程,它的理念其实是基于场景的自动化运维.我们可以想想在运维过程中有哪些工作可以串联起来,这样你就不需要对着一个文本的东西去做,因为你在对着它做的过程中很容易造成遗漏. 比如说你做游戏维护的时候,没有把前面的关闭,你就直接维护数据库了,这时候可能会导致玩家数据丢失的情况.通过 playbook 编排系统,就可以避免这个事情,它是固化的,没有办法绕过前面的步骤去进行后面的操作. 4、案例研究刚刚说过,大家在不同的行业里面,在不同的业务里面,它对应的发布方式还不一样,我相信目前我们在座的,系统里面也有一些人是用手工发布的方法上线.我知道一个比较大的公司,它的部署也是很落后的方式,因为它前面有负载均衡,它布的时候还是要登一些脚本,把负载均衡上的东西剔除,然后再更新,它需要更新多个脚本,这是很浪费时间和精力的过程.
看看我们以前面临的问题.这是我们的某个平台,主要是支付相关的.大家知道我们除了游戏服务器之外,还有相关的登录、认证和计费的平台.我们第一个选取的案例是在支付平台这边做的一些 DevOps 实践. 随着公司业务的发展,日积月累,你这个模块可能会越来越多,部署了之后会有测试,测试了之后交给运维,但是测试的模块名和运维的模块名可能是不一样的,这里面存在一个协调的问题.因为有人工协调的过程,不然导致这个部署需要排期,原来部署和测试系统是割裂的,它们之间没有对应的关系. ?
我们是怎么改进的呢?现在已经做的工作是：
这是我们部署的系统的界面,它会选择对应的版本,选择你是灰度发布,还是部署到生产环节里面,这个动作很多情况下已经不需要运维去做了,直接测试完成之后就可以上线了,这时候就把运维的工作解放出来了.
这是我们的部署过程,对于自动部署,银行和金融机构有要求,开发和运维要分离,我们现在做的是让开发和测试都可以上线. （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
