如今的互联网时代，运维早已不再是被动的那一方。过去的运维，由于种种限制，工作繁重、复杂，效率低下，很难适应目前互联网产品快速的迭代节奏。而如今，随着虚拟化、容器技术以及持续构建技术的成熟，运维工作的模式有了很大的变化，通过自动化技术的应用使得更少的人为参与，有更高的效率。为了确保项目高质量的快速迭代，必须构建一套高效的可持续构建的运维管理体系。
互联网项目最大的特点是版本迭代节奏快(同一个系统一天上线数次都有可能)，需求变化频繁，且每天可能都有项目新增、服务维护、运维架构调整等需求。而常见的运维体系难以提供高效、稳定、一致性强的可持续构建服务，需要探寻出一种项目和服务器松耦合的项目部署方案。
为了满足同时管理大量项目的代码维护、差异化代码构建、多级别服务器(开发、测试、演示和生产)环境管理，我们自主研发了运维平台：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设计之初，就考虑了系统的扩展性，所有模块都可以分布式部署。目前，单节点部署下已经可以支持上百个项目的开发、测试、演示、生产环境的运维管理工作，通过分布式部署可以无限扩展支撑更多的项目。
