随着前端技术的发展，加上前端代码主要运行在客户设备上的特性，导致前端稳定性问题层出不穷，稍有不慎就可能会给用户带来巨大损失。我们如何系统化地搭建前端安全生产体系，保障前端安全生产？

阿里提出“前端安全生产”概念，在前端应用开发、发布、线上运行的不同阶段，通过自动化流程机制，让前端工程师产出的代码更加靠谱，不带着问题发布，即便线上发现前端故障也能及时“止血”，旨在完成前端研发全链路的高质量交付。

荣先乾（戊子）是阿里巴巴高级前端技术专家，现任阿里巴巴设计中台 & 业务平台前端中台技术负责人。他也是 GMTC 北京 2020 “前端安全生产”专题的出品人。InfoQ 在会前采访了戊子老师，请他介绍什么是前端安全生产，阿里在搭建前端安全生产体系时遇到的挑战，以及如何搭建自己的前端安全生产体系等问题。

InfoQ：阿里首次提出“前端安全生产”这一概念，我们应如何理解？

戊子：近⼆⼗年来，伴随互联⽹⾏业的⾼速发展，互联⽹已成为⼀个国家重要的基础设施，出⾃基础设施的任何⼀个故障，都可能对国计⺠⽣产⽣重⼤的影响。而最近⼗年来，随着前端专业化分⼯的诞⽣、前端专业技术的发展，前端研发在整个互联⽹ Web 应⽤研发⼯程链路上扮演着越来越重要的⻆⾊，前端安全⽣产的责任也随之放⼤，在前端应⽤开发、发布、线上运⾏的不同阶段，如何让前端⼯程师产出的代码更加靠谱，不带着问题发布，即便在线上发现前端故障后也能及时⽌⾎？这便是“前端安全⽣产”需要解决的问题。

今天我们所讨论的“前端安全⽣产”不同于传统的“前端安全”这个领域，前端安全关注前端领域的线上安全攻防问题，⽽“前端安全⽣产”的定义显然更⼤，“前端安全⽣产”专注于前端研发全链路的⾼质量交付，当然，也包含不要带着“前端安全”问题去交付。

讨论到这⾥，我们也有了“前端安全⽣产”的⼀个基本定义。“前端安全⽣产”专注于前端研发全链路的⾼质量交付，在前端应⽤开发、发布、线上运⾏三个关键阶段，通过⼀系列的⾃动化流程机制，控制前端代码⻛险，保障线上业务运⾏稳定，⽤机制保护⼈，不给前端同学引发线上故障的犯错机会，最终规避损失或者降低损失。

InfoQ：为了保障前端安全⽣产，阿⾥做了哪些工作？其中最典型的是什么？

戊子：回顾过去历史上的重⼤故障，以及盘点过去的故障列表，我们发现绝⼤部分故障都是由变更引起的，前端安全⽣产也不例外，也是从触发故障的源头变更流程开始切⼊。在前端版本变更前、变更中、变更后，我们通过⼀系列的措施去提升前端代码质量、控制发布⻛险、及时发现问题。这其中的关键过程包含：

前端版本变更前：静态代码扫描、⾃定义⼯程规范校验、单元测试；

前端版本变更中：UI 回归测试、迭代变更⻛险评估、灰度监控报告；

前端版本变更后：1 分钟发现问题、5 分钟定位问题、10 分钟修复问题。

从上图可以发现，前端安全⽣产并⾮⼀个全新的领域，更多的是组合现有的分散在不同系统的能⼒，包括前端⼯程体系、前端 CI/CD 系统、前端测试系统、前端监控系统，让我们更体系化保障前端研发全链路的⾼质量交付。

InfoQ：建⽴前端安全⽣产体系之初遇到哪些问题？针对这些问题我们是如何去解决的？

戊子：整个前端安全⽣产体系涉及到的⼤部分能⼒都是整合现有的前端相关系统等，整合过程中我们重点补⻬了多项核⼼能⼒。接下来我将挑三个有代表性的⽅向给⼤家介绍，主要涉及前端迭代变更⻛险评估、前端灰度监控报告以及 5 分钟快速定位问题。

前端迭代变更⻛险评估

在回归测试阶段，我们需要明确知道本次前端版本迭代所造成的影响点，以供开发同学⾃测或者是测试同学重点回归相应部分，⽆论是⼈⾁测试，还是⾃动化回归，到很依赖这个关键信息。另外⼀种常⻅的场景是，前端代码本身没做任何改动，但是由于依赖的⼆⽅/ 三⽅包⾃动升级，导致某些场景出现⽆法预料的问题。这些都是因为前端迭代影响点⾃⾏评估不全⾯可能触发故障的典型场景。为了解决前端迭代中⽆法准确给出回归点的问题，我们提供了迭代影响点评估⼯具，重点提供以下能⼒：

开发同学明确本次迭代相对于上⼀次迭代的显示 & 隐式变更；

开发同学明确哪些项⽬⽂件将会受到所有这些变更的影响，并且能够看到具体的影响路径；

开发 / 测试同学能够看到更加全⾯、有理有据的回归功能点。

前端灰度监控报告

前端灰度监控的核⼼⽬的是让前端灰度发布的结果有据可依。在灰度发布期间，监控会重点关注前端灰度环境和线上环境对⽐后⻚⾯访问速度变化、JS 错误率变化、新出现的 JS 异常以及 API 成功率变化，⾃动⽣成灰度监控报告，同时也会通过灰度流量⻚⾯覆盖率、API 覆盖率来判定是否需要延⻓灰度时⻓或加⼤灰度流量⽐例。

应⽤全链路的 5 分钟快速定位问题

通过前端⽣成 traceId 并透传到后端业务调⽤链路的⽅式，打通应⽤从前端到后端全链路问题追踪，从前端发现的 API 错误问题，可以通过 traceId 关联直达后端监控系统，⼤幅减少涉及到应⽤全链路的问题定位时间，⾄此前端同学发现 API 相关问题后不再“甩锅”到后端，⽽是给后端同学提供诊断问题的有效线索。

InfoQ：目前，阿里的前端安全⽣产体系的现状如何？

戊子：整个前端安全⽣产体系的建设在我们部⻔内部⼤致分为三个阶段，⽽直到第三个阶段，我们才真正意义上完成了整个体系的 1.0 建设。这三个阶段分别是：单点安全⽣产保障、多烟囱独⽴安全⽣产保障、体系化的前端安全⽣产保障。

单点安全⽣产保障阶段：线上前端监控

2015 年 8 ⽉，我们启动了前端监控系统 retcode 的建设，通过线上实时监控⻚⾯访问速度、JS Error、API 成功率核⼼的三板斧能⼒，为前端应⽤的运⾏态稳定性保驾护航。2016 年底， retcode 成⻓为阿⾥集团内部使⽤最⼴泛的前端监控产品，这个阶段内，我们核⼼还是依靠线上前端监控的单点能⼒去保障前端的安全⽣产。为了持续修炼前端监控产品的核⼼能⼒，在 2017 年中我们启动了 retcode 的上云计划，进⼊前端安全⽣产建设的第⼆个阶段。

多烟囱独⽴安全⽣产保障阶段：云化前端监控 + 其他保障

2017 年 9 ⽉，retcode 升级为阿⾥云 ARMS 前端监控，开启全⽹公测。在直⾯⾏业竞争对⼿的同时，我们的多项核⼼能⼒得到极⼤提升，这其中包括⾯向全球化业务的国际极致性能、JS Error 出错时⽤户⾏为回溯、API 接⼝快照以及打通前后端的全链路追踪等等，前端监控平台也经历了从“错误数据展示”到“专家级问题诊断”的升级，整个平台每天处理的⽇志条数也超过了百亿级别。

这个阶段内，除了前端监控平台在阿⾥云上的产品能⼒升级助⼒前端安全⽣产，在我们部⻔内部，也开始借助⼀系列其他的能⼒来保障前端安全⽣产，如静态代码扫描、TDD、UI ⾃动化回归等，这些可以保障前端安全⽣产的单点能⼒越来越多，但是⼤多是独⽴烟囱服务模式，各个保障流程节点之间并未完全打通。

在阿⾥集团内部，也缺乏⼀套集团层⾯体系化的前端灰度发布流程，表现在前端发布与后端上线存在流程割裂、后端灰度发布时前端⽆感、整个应⽤灰度阶段⼤多是⼈⾁前端验证或者验证缺失。

体系化的前端安全⽣产保障阶段：前端安全⽣产从 0 到 1

为了解决前端安全⽣产各个保障节点的孤岛问题，同时结合集团后端正在⼤⼒推进安全⽣产的时机，前端安全⽣产的体系化建设也应运⽽⽣。当前我们部⻔整个前端安全⽣产体系刚刚完成从 0 到 1，正在电商核⼼的基础交易链路、⼤促稳定性保障、业务稳定性基线⽇常治理等项⽬中落地。

举⼀个实际的场景例⼦，阿⾥历年双 11 稳定性保障依赖的最核⼼能⼒之⼀便是全链路压测和验收。我们都知道全链路压测重点关注 API 级别的稳定性，在全链路压测过程中 API 上的各种异常表现，并不能体现到前端 UI 层⾯上，这个时候前端同学并不清楚后端 API 异常和降级后，前端 UI 层⾯的表现是否符合预期。借助前端 UI ⾃动化回归测试，我们将交易核⼼链路上的核⼼功能全部增加了测试⽤例，在后端开启全链路压测时候，前端同时开启回归测试，便形成了前端的全链路压测和验收。进⽽，我们会借助前端安全⽣产体系打造的前端变更时卡⼝能⼒，在每次前端⽇常变更时⾃动触发前端回归测试，降低核⼼交易链路上每次前端版本变更的⻛险。

InfoQ：我们如何构建⼀个前端安全⽣产体系呢？在构建的过程中要注意些什么问题。

戊子：通过前⾯的介绍我们已经可以了解到，构建⼀个完整的前端安全⽣产体系需要三项核⼼能⼒。

变更发⽣前 CI 卡⼝能⼒

静态代码扫描、⾃定义⼯程规范校验、单元测试通过率 & 覆盖率均是通过插件能⼒安装到 CI 卡⼝上，这⾥可以根据实际业务场景下的痛点问题扩展更多的插件能⼒，在前端同学每次代码提交后都能及时给予反馈，⽽不⽤将问题拖到测试或者预发甚⾄是线上环境。

变更过程中的灰度卡⼝能⼒

UI 回归测试、前端迭代变更⻛险评估、灰度监控报告也是作为插件能⼒安装到了灰度发布卡⼝上，这⾥同样也是可以根据实际业务场景下的痛点问题扩展更多的插件能⼒，在前端同学每次版本发布前都能及时给予反馈，遇到异常问题时直接中断发布过程。

根据安全⼯程学上的海恩法则“每⼀起严重事故的背后，必然有 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患”，我们在变更发⽣前的 CI 卡⼝、变更过程中的灰度卡⼝都是为了杜绝⼀切可能引发线上故障的潜在因素，不带着有问题的版本上线。

变更完成后的线上实时监控能⼒

线上实时监控是最后⼀个⾮常重要的能⼒，⼀个强⼤的监控系统能够帮忙我们 1 分钟发现问题和 5 分钟定位问题根因，为我们 10 分钟快速修复问题也就是快速回滚提供决策依据。根据安全⼯程学上的瑞⼠奶酪模型，“故障的发⽣是各种防御⾏为失效的累计效应”。在变更发⽣前 CI 卡⼝能⼒和变更过程中的灰度卡⼝能⼒全部都失效后，线上监控是我们的最后⼀道防线，能够帮我们有效的扼制故障范围进⼀步扩⼤，降低损失。

（图片来源网络）

除了上⾯提到的技术⼿段，安全⽣产的⾏为准则和⽂化同样必不可少，如制定变更红线规约、安全⽣产专题分享等等。细⼼的读者可能已经发现，GMTC 深圳 2019 的专题“前端测试”在今年已经升级为“前端安全⽣产”，也是想传递⼀个信号，**我们正在经历从过去被动的由测试同学主导的前端测试⾛向前端同学⼈⼈有责的主动前端安全⽣产保障时代，⽽过去的测试同学也升级为了测试研发同学，正在给我们的前端安全⽣产体系提供强⼤的插件能⼒。

InfoQ：您认为“前端安全⽣产”将是⼀个⼤的趋势吗？未来，它将会有怎么样的发展。

戊子：当互联⽹已成为⼀个国家重要的基础设施，传统⾏业正身处企业数字化转型浪潮之中，互联⽹安全⽣产必将越来越重要，⽽置身其中的前端安全⽣产也肯定会越来越受⼤家重视。从我的⻆度看到的前端安全⽣产未来将会由如下⼏个衍变趋势。

前后端联动的应用研发全链路安全生产；

借力 Cloud IDE 普及后自动集成的前端安全生产能力受益；

前端安全生产自动化免测版本比例提升带来的效率提升和成本下降；

从提供错误信息到更智能的专家级诊断、主动风险预警、故障自动恢复。

还是那句话，前端安全⽣产并⾮⼀个全新的领域，让我们⽤更体系化的系统，去控制⻛险并保障业务稳定，同时让每个⼈都更加重视前端安全⽣产，⽤机制保护⼈，不给前端同学引发线上故障的犯错机会，最终规避损失，让每个程序员都能愉快地发布！

嘉宾介绍

荣先乾，戊子 (花名)，阿里巴巴高级前端技术专家，现任阿里巴巴设计中台 & 业务平台前端中台技术负责人。曾是腾讯 Qzone 移动 Web 端技术负责人，2014 年从腾讯加入阿里，目前专注于前端安全生产、中后台研发效能、设计协同领域。主导阿里内部使用最广泛前端监控系统的建设，并成功在阿里云商业化，在阿里内部倡导线下线上一体化的前端安全生产，在前端应用开发、发布、线上运行关键阶段联动后端一起坚守安全生产木桶理论的“底”。

活动推荐

随着前端专业技术的发展，前端研发在整个 Web 应用研发工程链路上扮演着越来越重要的角色，前端安全生产的责任也随之放大，在前端应用开发、发布、线上运行的不同阶段，如何让前端工程师产出的代码更加靠谱，不带着问题发布，即便线上发现前端故障后也能及时止血？GMTC北京2020前端安全生产专场将详细解答，详情点击GMTC北京2020。

创作场景

构建前端安全生产体系，最快 5 分钟定位故障