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

我们的底层部署是通过配置一些项目,比如说模块对应的目录、配置文件、执行脚本,对应的用户,这个用户主要是指启动程序时的用户,以及对应的某个模块在不同的服务器上的IP列表,这些都会在系统里面进行相关的配置,这样配置之后就可以对前面的系统进行相关调用.

这个案例也告诉我们一点,我们在进行部署设计的时候,暗含了对架构的要求.

这里简单介绍三点：

• 第一,模块化,可独立部署,微服务有一个类似的概念.如果你是一个大一统的体系,你很难集中发布这个东西,你还要协调很多资源,如果你做成模块化,你自己上线,不影响他人,通过接口去调用,对自动部署是非常有好处的；
• 第二,重试机制.作为一些后端的服务,它在部署的时候,不应该影响前端的调用服务,前端的调用服务必须有一些重试机制,失败的时候要能够重连,这应该集成在调用方的架构设计里面,如果没有重试机制,肯定是会影响业务的,这也没办法达到高质量交付的目的；
• 第三,负载均衡与多实例的应用.这里也讲到,如果你的某一个功能只有一个模块,你在部署的时候,不管它的时间窗口是什么,你必然会影响业务,有些请求会丢掉或者是失败.通过负载均衡和多实例的方法,就可以包括你在部署部分服务器的时候不影响前面调用的结果.

总结

DevOps 的目的是打造持续增量的价值流并杜绝浪费.我曾经有一句话「任何不以消除浪费为目的的 DevOps 实践都是假的 DevOps」,我们实践 DevOps 的目的,是实现从一个想法到真正把这个想法形成产品、形成服务,提供给用户去用的流程.

缩短这个过程的时间,提高这个过程的效率是 DevOps 实践的一个最重要的目的.我们要让每一个步骤,每一个过程的价值都是递增的,而不是说产生等待,或者说产生依赖,比如对配置管理的依赖,对人员的依赖,这都是有悖于这个目的的.

所以我把这句话送给大家：DevOps 的目的,最重要的一点就是加速高质量的交付,提升用户价值.但是在实践过程中,我们可以从各个子环节的自动化流程作为一个起点,很多时候你可能没办法一次性把整个部署流水线构建那么完美,我们就可以分析是不是在每个子环节里面已经实现了足够程度的自动化.

比如说自动化发布,现在是不是还是要靠人工去操作,这些是最基本的动作,做好这些之后,你才有能力或者有条件和上下游进行对接.只有完成的每个环节的自动化之后,我们才有可能去构建整个部署流水线.

也就是说我们在落地的时候可以想想整个业务流程里面的痛点,比如说你是部署没有完成自动化,还是测试没有完成自动化,导致了这个流水线没有办法流传下去.然后以每个环节的自动化作为一个开始,然后把它们集成起来,就可以实现整个价值流的快速交付.

文章来自微信公众号：高效运维

（编辑：ASP站长网）