构建前端安全生产体系,给前端同学「稳稳」的幸福

本文涉及的产品
应用实时监控服务-应用监控,每月50GB免费额度
性能测试 PTS,5000VUM额度
应用实时监控服务-用户体验监控,每月100OCU免费额度
简介: “前端安全⽣产”专注于前端研发全链路的⾼质量交付,在前端应⽤开发、发布、线上运⾏三个关键阶段,通过⼀系列的⾃动化流程机制,控制前端代码⻛险,保障线上业务运⾏稳定,⽤机制保护⼈,不给前端同学引发线上故障的犯错机会,最终规避损失或者降低损失。

作者:戊子

image.png

始于十八世纪中期的工业革命至今催生了传统工业的数百年繁荣,安全生产便是一个在传统工业领域提的比较多的概念,在传统的生产、制造、建筑行业,我们随处可见安全生产相关的口号。近二十年来,伴随互联网行业的高速发展,互联网已成为一个国家重要的基础设施,出自基础设施的任何一个故障,都可能对国计民生产生重大的影响。回到国内大型互联网公司的内部,以阿里集团为例,2018年以来,集团内部高危故障频发,稳定性形势严峻,于是集团成立了安全生产委员会,一是运用技术手段提升能力,控制风险,保障业务稳定;二是明确行为准则,用机制保护人,减少犯错,降低损失;三是打造安全生产文化,确保人人重视、有持续性的提升。而这便是互联网行业安全生产的由来。

什么是前端安全生产?

而最近⼗年来,随着前端专业化分⼯的诞⽣、前端专业技术的发展,前端研发在整个互联⽹ Web 应⽤研发⼯程链路上扮演着越来越重要的⻆⾊,前端安全⽣产的责任也随之放⼤,在前端应⽤开发、发布、线上运⾏的不同阶段,如何让前端⼯程师产出的代码更加靠谱,不带着问题发布,即便在线上发现前端故障后也能及时⽌⾎?这便是“前端安全⽣产”需要解决的问题。

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

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

前端安全生产大图

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

  • 前端版本变更前:静态代码扫描、⾃定义⼯程规范校验、单元测试 ;
  • 前端版本变更中:UI回归测试、迭代变更⻛险评估、灰度监控报告;
  • 前端版本变更后:1 分钟发现问题、5 分钟定位问题、10 分钟修复问题。

image.png

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

前端安全体系的建设

三个发展阶段

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

单点安全生产保障阶段:线上前端监控

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

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

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

image.png

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

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

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

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

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

核心能力

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

变更发生前 CI 卡口能力

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

变更过程中的灰度卡口能力

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

image.png

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

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

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

image.png
(图片来源网络)

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

三个最强扩展

基于CI卡口、灰度卡口、线上监控三项核心能力,本年度我们重点打造了三个最强扩展能力,主要涉及前端迭代变更⻛险评估、前端灰度监控报告以及 5 分钟快速定位问题。

前端迭代变更⻛险评估

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

  • 开发同学明确本次迭代相对于上⼀次迭代的显示&隐式变更;
  • 开发同学明确哪些项⽬⽂件将会受到所有这些变更的影响,并且能够看到具体的影响路径;
  • 开发/测试同学能够看到更加全⾯、有理有据的回归功能点。

image.png

前端灰度监控报告

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

image.png
image.png

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

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

image.png

展望未来

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

  • 前后端联动的应用研发全链路安全生产;
  • 借力 Cloud IDE 普及后自动集成的前端安全生产能力受益;
  • 前端安全生产自动化免测版本比例提升带来的效率提升和成本下降;
  • 从提供错误信息到更智能的专家级诊断、主动风险预警、故障自动恢复。

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


image.png
关注「Alibaba F2E」
把握阿里巴巴前端新动向

相关实践学习
通过云拨测对指定服务器进行Ping/DNS监测
本实验将通过云拨测对指定服务器进行Ping/DNS监测,评估网站服务质量和用户体验。
相关文章
|
23天前
|
JavaScript 前端开发 Docker
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
在使用 Deno 构建项目时,生成的可执行文件体积较大,通常接近 100 MB,而 Node.js 构建的项目体积则要小得多。这是由于 Deno 包含了完整的 V8 引擎和运行时,使其能够在目标设备上独立运行,无需额外安装依赖。尽管体积较大,但 Deno 提供了更好的安全性和部署便利性。通过裁剪功能、使用压缩工具等方法,可以优化可执行文件的体积。
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
|
12天前
|
监控 前端开发 JavaScript
探索微前端架构:构建可扩展的现代Web应用
【10月更文挑战第29天】本文探讨了微前端架构的核心概念、优势及实施策略,通过将大型前端应用拆分为多个独立的微应用,提高开发效率、增强可维护性,并支持灵活的技术选型。实际案例包括Spotify和Zalando的成功应用。
|
16天前
|
前端开发 JavaScript API
前端框架新探索:Svelte在构建高性能Web应用中的优势
【10月更文挑战第26天】近年来,前端技术飞速发展,Svelte凭借独特的编译时优化和简洁的API设计,成为构建高性能Web应用的优选。本文介绍Svelte的特点和优势,包括编译而非虚拟DOM、组件化开发、状态管理及响应式更新机制,并通过示例代码展示其使用方法。
32 2
|
17天前
|
前端开发 API UED
深入理解微前端架构:构建灵活、高效的前端应用
【10月更文挑战第23天】微前端架构是一种将前端应用分解为多个小型、独立、可复用的服务的方法。每个服务独立开发和部署,但共同提供一致的用户体验。本文探讨了微前端架构的核心概念、优势及实施方法,包括定义服务边界、建立通信机制、共享UI组件库和版本控制等。通过实际案例和职业心得,帮助读者更好地理解和应用微前端架构。
|
23天前
|
前端开发 API UED
拥抱微前端架构:构建灵活、高效的前端应用
【10月更文挑战第17天】微前端架构是一种将前端应用拆分为多个小型、独立、可复用的服务的方法,每个服务可以独立开发、部署和维护。本文介绍了微前端架构的核心概念、优势及实施步骤,并分享了业界应用案例和职业心得,帮助读者理解和应用这一新兴架构模式。
|
28天前
|
存储 监控 前端开发
掌握微前端架构:构建未来前端应用的基石
【10月更文挑战第12天】随着前端技术的发展,传统的单体应用架构已无法满足现代应用的需求。微前端架构通过将大型应用拆分为独立的小模块,提供了更高的灵活性、可维护性和快速迭代能力。本文介绍了微前端架构的概念、核心优势及实施步骤,并探讨了其在复杂应用中的应用及实战技巧。
|
17天前
|
监控 前端开发 JavaScript
前端技术探索:构建高效、可维护的Web应用
【10月更文挑战第23天】前端技术探索:构建高效、可维护的Web应用
34 0
|
29天前
|
JSON 前端开发 JavaScript
构建现代前端应用的基石
【10月更文挑战第13天】构建现代前端应用的基石
|
29天前
|
前端开发 JavaScript 开发工具
从零开始:构建、打包并上传个人前端组件库至私有npm仓库的完整指南
从零开始:构建、打包并上传个人前端组件库至私有npm仓库的完整指南
215 0
|
29天前
|
JavaScript 前端开发 Docker
拿下奇怪的前端报错(二):nvm不可用报错`GLIBC_2.27‘‘GLIBCXX_3.4.20‘not Found?+ 使用docker构建多个前端项目实践
本文介绍了在多版本Node.js环境中使用nvm进行版本管理和遇到的问题,以及通过Docker化构建流程来解决兼容性问题的方法。文中详细描述了构建Docker镜像、启动临时容器复制构建产物的具体步骤,有效解决了不同项目对Node.js版本的不同需求。