浅谈运维规模化可持续构建实战

Posted 2020-08-14

 如今的互联网时代，运维早已不再是被动的那一方。过去的运维，由于种种限制，工作繁重、复杂，效率低下，很难适应目前互联网产品快速的迭代节奏。而如今，随着虚拟化、容器技术以及持续构建技术的成熟，运维工作的模式有了很大的变化，通过自动化技术的应用使得更少的人为参与，有更高的效率。为了确保项目高质量的快速迭代，必须构建一套高效的可持续构建的运维管理体系。

 互联网项目最大的特点是版本迭代节奏快（同一个系统一天上线数次都有可能），需求变化频繁，且每天可能都有项目新增、服务维护、运维架构调整等需求。而常见的运维体系难以提供高效、稳定、一致性强的可持续构建服务，需要探寻出一种项目和服务器松耦合的项目部署方案。

为了满足同时管理大量项目的代码维护、差异化代码构建、多级别服务器（开发、测试、演示和生产）环境管理，我们自主研发了运维平台：U-OPS，与另一个自主研发的项目管控和在线技术协同平台UReactor密切配合，不断演进，从而真正做到互联网产品的整个生命周期的无缝管理，可稳定高效地支撑上千个项目的复杂运维管理。

图1   U-OPS登录页

图2  UReactor运维模块

U-OPS运维系统具有实施部署标准化、运维管理自动化、监控分析智能化的优点，在减少大量的工作量、加快系统响应效率的同时，提供标准化的运维流程、精准的运维方案。

 随着业务稳步发展，用户增长，线上服务不断增多，从运维整体支撑架构上，U-OPS并不是一蹴而就，而是在探索中不断前行。从早期的U-OPS 1.0到目前的版本，我们不满足于现状，不断优化产品，现在的U-OPS已逐步趋于成熟。下文详细介绍U-OPS的各个阶段和其中的思考。

1  早期运维架构（U-OPS 1.0）

图3 早期部署架构

在常规运维体系下，每当有项目新建或调整时就一定要经历：创建部署的Job->初始化服务器环境->配置域名解析等一些列工作。但伴随着业务发展，运维部门的工作压力往往会越来越大。并且，随着业务拓展，项目多样性越来越强，架构扩展性差的弱点也越发的凸显。

2  基于Docker的运维系统改进（U-OPS 2.0）

随着Docker虚拟化技术逐渐成熟，适合应用在DevOps和微服务场景，联创工场基于Docker技术，对运维体系进行了全面的改造升级，新的体系兼容性及扩展性更强，为服务多项目打造了坚实基础。

图4 现有基本架构

此架构有很好的扩展性，多台物理服务器形成资源池由Docker Swarm统一调度，因为应用和服务器不再绑定，发布时无需关心使用哪台服务器；新增服务器时，只需简单配置Docker运行环境即可加入资源池，无需再初始化应用环境；而新增项目时，只需要配置job即可实现部署，无需再准备各种环境。

3.   在探索中不断改进U-OPS

3.1 技术改进

U-OPS2.0的基础架构已经稳定，完全可以支撑公司项目的持续交付。但随着Job越多，系统复杂度越高，稳定性越差，维护越来越难。并且，业务方面出现了很多定制化的需求，改造势在必行。秉承着互联网思维，我们对系统进行了迭代调整。然而，由于受限于Jenkins，很多想法无法实现；因此，我们先采用更简单的GitLab CI作为驱动替换掉Jenkins，配合着自有研发的运维系统U-OPS，以更好的服务项目运维工作。

图5 部署配置方式

应用Shell+Docker的方式抽离出公共Job，实现从U-OPS中选择项目的部署方式就能自动部署，真正做到1分钟时间完成之前1~2天完成的事情。

3.2 增加人员管理模块

日常工作中，熟悉的人做熟悉的事往往会带来效率的提升，但一项任务如果只能有特定的人做，会造成资源不均衡。所以，我们将运维部门大胆设想成资源池，一旦有了任务后，资源池里的任意资源都可以处理，而不再是必须由固定的人处理。然而，这也带来了新的问题：最终上线时，需要一次性调整此版本所有的配置和数据库变更，但是操作者如果不熟悉变更过程，很容易造成遗漏，反而最终会影响到线上服务。因此，我们在平台中增加了配置文件和数据库sql管理，依照代码协作进行版本化管理，并与应用的版本迭代对应，记录所有过程。这样在最终上线时，只需执行版本内所有变更即可。

图6 配置文件及数据库版本管理

其中配置文件增加对比功能，保证所有变更同步；数据库使用增量版本管理，同一份脚本顺序更新到测试、演示和生产环境，多次验证保证脚本正确；在更新测试库和演示库之前会自动备份数据库，当脚本更新失败时，数据库会自动回滚到更新前状态，线上数据库更新前会自动备份。出于保证数据安全性的考虑，更新失败时不会自动回滚，在给出提示后，需要人为干预处理。目前随着数据越来越多，数据库备份更新需要的时间越来越长，我们正在对备份进行异步改造，独立出一个功能对数据库的备份和恢复进行统一的管理。

3.3 增加资源管理模块

由于加入生产环境的管理，数据都是敏感、重要的，尤其是各种账号和密码，密码变更一次成本很高。我们选择通过WebShell和Jump技术来统一管理服务器，即以系统权限来控制每个用户服务器管理的权限，人员变动就仅需调整系统权限。

图7 服务器管理

具体到开发和测试环境，系统在每个Docker实例中部署了WebShell，同时映射出域名AppDomain-console.xxx.com，此域名可以不经过U-OPS系统直接访问，方便开发联调和QA测试监控日志及服务状态；线上服务考虑到安全行只能通过U-OPS系统进行跳转，鉴权通过后才可以访问。

如果要想彻底解放运维工程师，预警、告警机制是必不可少的，以此由主动运维变为被动。这就需要做好各项监控工作，包括应用的监控和服务器负载监控，我们可以根据历史情况分别配置告警阈值。生产环境中，根据监测情况动态调整Docker实例的数量，满足应用负载情况，当某一个或多个节点出现问题，向运维工程师告警的同时，如果应用压力达到阈值，会自动增加节点数量以保证服务稳定运行；待运维工程师处理完问题后，恢复的资源就会自动加入资源池，等待调度。同时，日志收集模块收集各系统日志，并发送给U-OPS日志模块进行统一查询展示，最终可以根据用户的项目权限控制展示内容。

图8 U-OPS监控体系

4  整体架构与操作展示

通过诸多版本的演进，最终形成了联创工场目前的运维平台。其整体架构如下：

    

图9 UWorks运维架构

图10 UReactor运维模块

图11 U-OPS容器监控

图12  U-OPS项目详情

  在U-OPS投入使用后，日常的运维工作就不再需要资深运维工程师和专业的运维知识，而变为将服务提供给开发工程师和测试工程师，实现自主运维。联创工场将U-OPS打磨为市面上最为专业的运维系统，并与联创工场的项目管理平台UReactor进行深度整合，实现了所有项目参与人员（包括不懂运维技术的项目委托方），都可以通过UReactor平台的简单操作，就可以实现90%以上的运维工作。自此，我们探索出了一条团队整体运维之路，运维工程师目前仅需负责应急事件处理，就可以为几何倍增长的项目提供更加稳定、高效、安全的运维服务。

   U-OPS目前管理着上百个项目的生产环境，所以保证其安全性非常重要。当前版本的产品，需要每个用户绑定手机号，用用户密码与手机验证码双重验证才可登录。并且，系统权限分为“用户角色管理”及“数据权限管理”两个类型，用户的所有操作均有日志记录，多重措施保证数据安全性。U-OPS设计之初，就考虑了系统的扩展性，所有模块都可以分布式部署。目前，单节点部署下已经可以支持上百个项目的开发、测试、演示、生产环境的运维管理工作，通过分布式部署可以无限扩展支撑更多的项目。

关于联创工场

联创工场从提供互联网的技术服务切入，通过平台化的方式实现快速规模化，并在这个过程中不断整合行业资源，构建完整的技术研发的生态体系，联创工场希望有机会重新定义整个软件服务产业。 成立仅一年左右的时间，联创工场通过其特有的项目实施、管控和资源整合能力，完成了近百个互联网类项目的研发，交易额超过2000万，交付成功率百分之百。

本文出自 “12077285” 博客，请务必保留此出处http://12087285.blog.51cto.com/12077285/1860126