唔哩：从敏捷开发到敏捷运维，提升产品质量不是传说

Posted 2021-04-25 听云

“唔哩”最初来自于网络流行语“wuli”，在韩语里是“我们”的意思。这个画风相当二次元的词是90后的基本语汇。用这个词来打造一款服务90后年轻一代的新闻资讯App，唔哩团队一直致力于以优质内容为基础，以互动分享与个性化设置为特色，加入场景阅读新元素，满足用户任何时间和状态下轻松愉快的阅读需求，这面对容忍度很低的年轻一代，唔哩团队在用户体验方面的压力可想而知。

作为一款时尚、流行的APP，产品上线之后一直了保持较快的增长速度。自2016年3月份上线以来，4个月后注册用户已达400万、日均活跃用户数为25万人次。持续快速稳定的增长不仅与产品本身的话题性、强大功能密不可分，也得益于唔哩技术团队对用户体验的足够重视，同时也离不开敏捷开发/敏捷运维为产品提供的有力技术支撑。

1

重视持续集成，提升代码质量

对于创业公司来说，缺乏完善的流程规范和技术平台，许多开源的技术方案并不能很好的解决面临的困难，导致产品上线之初各种坑都踩了一遍。比如版本升级后，依赖模块调用版本不对，已知bug再次复现，数据错误等等都是会出现的问题，为此唔哩设置了4种环境(Dev+Test+Stage+Prod)。

1、Dev环境用于各模块的功能开发，mock接口

2、Test环境用于集成测试，集成测试通过之后，可以提交新版本到Stage环境运行

3、Stage环境是非常接近生产环境的，使用的数据是从生产环境同步过来的，在Stage环境运行无异常后，最终提交新版本到Prod环境。

四个环境的操作系统版本和配置参数及环境变量及服务器架构都是一致的，尽量规避因环境不一致产生新的Bug到生产环境。

有了环境，接下来就可以做持续集成了。唔哩采用的比较流行方案：GitLab+Jenkins，GitLab做版本控制，Jenkins做代码自动构建、测试和打包以及把代码自动布署到开发环境。

a) 分支模型. GitLab主要分支有两个：master和develop。

master分支保持用于线上环境的代码。

develop分支保持下一个Release版本最新的代码，当develop分支的代码达到Release稳定要求时，将develop分支的所有变化合并到master分支并对master打上一个TAG(Release版本号)。

feature分支用于开发新功能，从develop分支分出来，新功能开发完成之后合并到devleop分支，合并之后就可以删除此分支了。

Release分支主要用于大版本之后发布一些小的改动(如果有大的功能调整需要从develop分支一个feature分支开发)，从develop分支分出来，然后再合并到master分支。合并之后就可以删除此分支了。

bugfix分支用于bug修复，从主分支创建，然后合并到master分支和develop分支。合并之后就可以删除此分支了。

GitLab基本不用太多的配置，需要在GitLab上创建一个用户能Pull需要做持续集成的项目，然后在项目的setting里设置web hooks，URL为Jenkins生成的GitLab CI Service URL，trigger可以选Push events/Tag push events/Merge Request events，这样当向项目Push代码或merge请求的时候就会触发Jenkins的构建job，也可以在Jenkins里配置轮询的方式，每过多长时间检查一下，如果条件符合触发构建任务。

b) Jenkins需要安装一些插件：如Junit、Cobertura、GitLab Merge Request Builder等。

GitLab Merge Requests Builder允许在GitLab上提交merge request时候触发Jenkins上配置的相关的构建任务，即在slave上将某个分支合并到另一个分支上，合并之后如果构建成功，就将打包好的文件scp到集成环境的主机上进行布署，最后生成测试报告，并发送邮件到相关的邮件接收人。如果一切正常则可以code review，这样可以提高code review的效率，然后在GitLab上真正合并分支。下面是Jenkins构建项目的主要项配置截图：

参数化构建过程：添加4个String Parameter,名字分别为gitlabSourceRepository、gitlabSourceName、gitlabSourceBranch、gitlabTargetBranch ；

源码管理：勾选Git

构建触发器：勾选Gitlab Merge Requests Builder,Gitlab Project Path填上你的项目路径(比如：groupName/projectName), Crontab line 配置H/5 * * * * 即可;

Build：RootPom参数为pom.xml,Goals and options参数为clean cobertura:cobertura package ；

Post Steps：如下图

2

持续布署，每次变更加入跟踪统计

在面对生产环境时，唔哩比较谨慎，目前采用的是人工干预的方式来发布到生产环境。利用Jenkins自动构建测试之后，将打包好的文件存放到版本仓库中，然后利用SaltStack布署到生产服务器上。在这个过程中，唔哩用Python写了一个web平台来管理发布流程。

首先定义一个流程，由开发人员提交版本需求，并描述具体变更说明；然后由运维人员操作布署，只需在web界面点击一下按钮，后台自动上线并实时展现日志；接下来由测试人员进行测试，并产生测试报告；最后流程由PM结束，PM决定一次版本上线是否结束，还是需要回退到历史的版本；版本回退的流程也是一样的过程，流程的每个节点都有相应的邮件描述说明，方便下一步的人员查看。具体流程及流程的每个节点执行哪些job都是可配置的，功能扩展很方便。

在做这个发版的平台主要是基于两个方面考虑:

1、一个是有一些web应用前面都是nginx做代理，布署后端服务时需要先在Nginx上剔除，布置完后端服务再添加回来，这个需要一个单独的工具或平台集中管理不然不好控制。

2、另一个考虑是把每次版本发布都归档,包括布署过程中产生的日志信息，方便审计，而且根据对历史发版发布的统计也可以发现版本发布的质量，当然是布署上线的次数越少越好。

在未来，唔哩考虑让平台自动去处理，不用人工干预，也可以配置成定时任务去执行，比如一些需要在夜间时进行的版本发布，这样就会轻松许多。现在我们将一些备份的任务也放到这个平台上面来执行，每天会定时执行并发送执行结果邮件通知。

3

实时监控、持续优化

通过以上敏捷迭代可以在很大程度上能提高生产环境下的代码的质量，避免出现一些Bug。但是凡事都有意外，所以对于生产环境正在运行的业务，做好持续的监控很重要。

唔哩除了使用Zabbix监控CPU、内存、磁盘IO、网络流量IO、进程/端口、TCP连接、日志以及中间件运行状态参数外，还使用了听云的APM监控技术。唔哩运维总监认为：“虽然商业产品需要成本，但是商业产品可以提供完备的服务，总比自已花时间慢慢研究来的直接有效，对于创业公司来说时间成本是巨大的，产品的快速发展需要良好的用户体验，APM的价值对于用户来说促进作用非常大，否则因为产品不稳定导致用户流失损失比成本更大。”

听云APM使用了大数据技术，可以定位分析到每一次函数调用具体情况。以下示例为唔哩Server端监控图例说明：

上图中是对一个登陆的过程进行的分析，点击“web应用过程”，可以查看耗时百分比，响应时间，吞吐率，错误率等。选择“响应时间”左边一栏显示的接口调用及平均响应时间，右侧显示为具体的分解图表信息，可以看到userparter/SELECT这个操作图形占比最高，峰值近500ms，在表格中也可以看到是mysql操作，耗时占比96%，调用次数37,平均响应时间为184ms。有了这些数据信息，如果出现异常就可以快速定位到具体原因，而且对于产品的持续优化也有参考依据。

除了Server端，移动端和网络也使用了听云做了监控。通过听云App对唔哩APP的监控可以很容易查看客户端崩溃、网络请求、劫持分析、错误等。使用听云Network对网络的监控是因为听云能提供用户端的节点探测，比IDC节点监控更接近真实用户的网络环境。

敏捷运维是一种思想，是让软件开发、测试、运维之间建立起沟通协作关系，加强角色间信息互换和共享，统一流程和规范，最终实现运维自动化，共同保证产品的质量。

本文根据唔哩运维团队的分享进行整理