前言

项目研发的过程中经历了需求评审、开发评审、代码编写、测试用例评审、项目测试、产品和 UI 验收等一系列流程，其中投入了大量的人力和精力。

然而最后的上线阶段，总是存在诸多不确定性和可变性，往往在测试阶段测 N 次都没有丝毫问题，一上线就会出现 Bug（简直是墨菲定律的诅咒）。

经过多年的经验总结和残酷教训，我们将这些已知的或潜在的风险点详细梳理出来，希望每个项目的上线都可以踏踏实实、万无一失、顺顺利利。

本文，我们将从三个方面来防范上线风险：操作防范、双岗&自查、监控告警。

一、操作防范

主要包含了四大类别的防范：研发防范、配置防范、运维防范和审批防范。

1.1 研发防范

1.1.1 通用层

  1. Loading/Confirm 统一标准化

  2. 错误页/骨架屏/无数据/网络异常兜底规范

  3. 公告、弹窗规范

1.1.2 代码层

  1. 使用 https、禁止非 jd 源、验证外网可用

  2. 环境切换通过系统变量区分

  3. Commit 规范

▪ 单次提交独立功能代码

▪ 所有研发代码提交 Coding

  1. 统一 IDE 和脚手架

  2. 开发环境 node.js、npm、joyer、taro 等版本统一

  3. 统一通用组件

▪ 沉浸式导航

▪ 共用组件，检测版本支持及容错处理

▪ 云梯组件

▪ 加密防刷：AKS，AAR

▪ 风控设备指纹

▪ 奇点埋点

▪ 下载唤起组件

▪ 分享组件以及金口令

  1. 数据处理

▪ 分页加载避免请求死循环

▪ 网关层错误码处理

▪ 服务端接口层错误码处理

▪ 主功能接口异常是跳转错误页/弹窗重试等必要处理

▪ 兜底方案

1.1.3 UI 层

  1. 是否有动效

  2. 音视频是否兼容性

  3. 是否存在性能卡顿

1.1.4 安全层

  1. 编码问题：是否通过 eslint

  2. 兼容问题：编码语法、方法属性、组件库最低支持版本等处理

  3. 逻辑功能：代码逻辑是否与预期功能一致

  4. 异常情况：是否考虑降级/容错/超时等异常情况

  5. 用户体验：新增或者修改功能对性能或者体验是否不良用户体验影响

  6. 安全：密文传输、防刷、脚本注入等

  7. mock：是否正确处理了 mock 数据的展示

  8. 敏感数据：对数据处理是否存在潜在客诉风险等

1.2 配置防范

1.2.1 研发配置

  1. 内容配置平台配置已上线的配置再次操作要注意不影响线上，尽量新增配置

  2. 配置数据类型不支持时间控件，禁止在上面配置时间或时间戳等数据

  3. 配置前的数据校验（例如：链接格式是否正确，数据长度是否需要限制等）

  4. 数据容错处理，若为重要数据需设置为必填项 "required": true；

1.2.2 运营配置

  1. 活动上线前，所有生产配置必须都完成

  2. 已上线的配置，再次操作需与产品及研发确认；运营内部双岗确认

  3. 预发环境验证，数据和生产保持一致（奖品类型、券类型、秒杀时间、任务类型等)

  4. 奖励、券或任务等需验证可正常发放或领取后再配置展示到前端

  5. 在活动领取利益点到其他活动页使用，需保证二级活动页面内使用利益点正常

1.2.3 环境配置

  1. 所有新项目统一使用 joyer 脚手架初始化

  2. 命令统一，本地环境、打包、发布各环境等

  3. vconsole、注释等仅在非生产包中配置

  4. 每个项目必须有 mock 环境，使用 mock 数据去验证各类情况，而不是修改或注释代码

  5. 老项目是否采用 webpack、vue-cli 统一规范

1.3 运维防范

1.3.1 域名解析操作

  1. ip 是不在应用下存在

  2. 实例上是否具有可访问项目

  3. 找运维配合查看是否项目可访问

  4. 确保告知运维工单受理通知开发人员及时验证

1.3.2 CDN 操作

  1. 确保源站域名和加速域名不一致

  2. 确保上传的加速内容与分发方式相匹配（图片、大文件、视频、直播流）

  3. 确保加速域名下的文件为静态资源（考虑是否需要做动静分离）

  4. 确保源站 IP 是否正确

  5. 申请接入后只代表 CDN 已完成后还注意需配置 DNS 解析变更

  6. 查询输入域名查看全国各地区解析是否生效

1.3.3 HSTS 操作

  1. 确保客户端或应用是否 https 或开启 https 强跳是否有问题

  2. 对于 vip 下有多个应用或域名要通知各方确认是否有影响

1.3.4 http2 操作

确保域名为 https 才可开启

1.3.5 ddos 操作

CDN 域名暂不用接入

1.3.6 扩容操作

  1. 机器审批完成确认执行结果全部成功

  2. 确保新扩容机器配置及项目部署

  3. 对于混合部署有多个应用存在需要所有应用都完成部署并验证（可让运维配合）

  4. 混合部署应用确保每个应用都要走复用工单

  5. 确保扩容操作完成后重启机器操作

1.3.7 缩容操作

  1. 确保 CDN 域名解析的为内网 VIP（如果为 rip 需要走变更 VIP 工单流程）

  2. 混合部署确保每个应用都要走工单

  3. 预发机器需要补充预发域名反向代理变更工单

1.3.8 下线操作

  1. 确保下线机器是否影响线上（独立部署某个项目）

  2. 注意摘流量 - 摘机器等步骤完成才可下线

1.3.9 回滚操作

  1. 使用 JDOS 点击回滚操作

  2. 回滚选择的包要仔细检查是否是上次上线的

1.3.10 堡垒机操作

  1. 容器必须正常启动

  2. dockerfile 构建的镜像，只能申请 root 权限且 22 端口必须打开

  3. 公共镜像，只能申请 root 权限且 22 端口必须打开

1.4 审批防范

  1. 是否经过测试节点审批

  2. 是否由 leader 审核

  3. 开发与审批权限是否分开

二、双岗&自查

上线前的双岗自查，是我们制定的一项标准流程。要求研发人员在上线前必须按照下面的清单，并寻求其他同事的协助进行项目代码的排查（当局者迷，旁观者清）。

2.1 前端

2.1.1 环境检查

  1. 域名是否接入 CDN

  2. jen 配置是否一致

  3. jen 是否全部在线

  4. 是否开启 gzip

  5. 部署机器数量与预期是否一致

2.1.2 公用组件

  1. 是否接入 AAR

  2. 是否接入 AKS

  3. 是否接入风控

  4. 是否添加 SGM 监控

2.1.3 需求检查

  1. 本次上线资源是否包含非本次产品需求迭代内容

  2. 页面引入资源是否都是本次上线内容

  3. 本次上线资源是否为预发已测试版本

2.1.4 代码检查

  1. 是否有第三方代码注入

  2. 是否存在敏感字段

  3. 是否去掉 log/mock/Vconsole 等调试工具

  4. 项目中是否存在 http 域名资源

  5. 服务端接口是否为线上

  6. 检测所有资源域名是否为线上外网域名

  7. 包资源文件 hash 是否由生产部署

  8. 仓库 master 代码是否是最新的

  9. 对于混合部署应用，本次上线是否只更新当前应用代码

  10. 对于通天塔自定义组件，本次改动是否考虑低版本，是否影响其他项目中引用的模板

2.1.5 回归检查

  1. 使用 4G/5G 验证

  2. 上线后操作 CDN 资源是否是最新上线的

  3. 上线后验证。对于混合部署的项目，最新分支是否合并到 master

2.1.6 流程工单

  1. 双岗检查确认通过

  2. UI 走查通过并确认

  3. 风控验收通过并确认

  4. 安全测试工单提交并完成

2.2 服务端

2.2.1 监控检查点

  1. 业务监控

◦ 订单

◦ 日志异常

◦ SQL 异常

◦ SQL 耗时

◦ 业务耗时监控

◦ 业务状态异常监控

◦ 异常流程监控

  1. 基础监控

◦ 第一类运维：应用系统所依赖的硬件、虚拟机、网络等

◦ 第二类运维：操作系统层面，比如 cpu,内存，硬盘，IO 等

◦ 第三类运维：中间件层面的，比如数据库，缓存，tomcat, ningx 等

◦ 第四类运维：应用本身的，比如 JVM 监控, 日志归集等

◦ 第五类运维：新功能上线操作和日常应急演练工

2.2.2 通用自查点

  1. 上线顺序类

◦ 内部存在多个应用上线，依赖关系及上线顺序，是否已经考虑过

◦ 应用上线前，是否需先创建好了相关表结构，注册 mq，rpc 等操作

◦ 本次版本上线，是否涉及外部应用，是否需要别的模块配合，上线是否有顺序要求

  1. 安全类

◦ 是否要考虑外网安全问题，比如 SQL 注入，XSS 攻击，敏感信息加密，账号爆破等

◦ 是否考虑接口通信安全问题，加签验签，秘钥管理等

◦ 各种访问是否考虑要增加白名单或者证书或者短信

◦ 数据库敏感字段是否加密

  1. 防刷，防重类

◦ 防重机制，哪几种状态和场景下允许重复发送订单

◦ 否有限制允许同一秒接受多笔同样的订单

◦ 平台唯一 ID 生成是否会有重复的可能

◦ 所有请求入口，定时器和 API 请求是否使用乐观锁。考虑并发重复处理问题，并且要判断更新影响条数

  1. 异常处理类

◦ 是否处理了各业务的主分支以外的异常分支

◦ 详细异常栈别吃掉

◦ 三方交互的是否完成

▪ 需要抓取 IOException 做处理

▪ IOException 需要打印 URL 方便报警排查问题

▪ 需要设置连接超时和读取超时时间

▪ 是否需要通过代理出网

▪ 是否需要再三方添加白名单

▪ 三方是否有最大数限制

▪ 合理设置 http 连接数和关闭连接

  1. 日志规范类

◦ 日志打印是否有自己的业务规范，有助于日志巡检

  1. 定时任务类

◦ 业务定时器是否有浪打浪，重复处理的情况，并发配置是否设置成 false

◦ 定时任务中处理的数据量是否有预期的执行 size，是否会出现异常情况下，处理的 size 越来越多的情况

  1. SQL 类

◦ 是否使用了唯一索引

◦ 唯一索引的使用是否正确，例如多个字段做为联合唯一索引，是否存在字段为 null 情况

◦ update 和 select 语句是否有预期的执行 size

◦ 是否避免使用复杂 sql

◦ sql 是否检查过执行计划，是否能命中索引，一段时间业务增长是否存在慢 sql 的可能性

  1. 缓存的使用

◦ 缓存使用，是否设置超时时间，超时时间设置是否正确，是秒单位，还是毫秒单位

◦ 缓存同步问题解决方案的评估（数据库悲观锁 + 事物 + 排序、redis 悲观锁、CAS）

◦ 清楚 redis 的使用场景

  1. 事务的使用

◦ 代码中使用事务的需要考虑死锁场景

  1. 管理后台

◦ 管理后台下载，查询等功能是否有条数限制和频次限制

  1. 类型转换

◦ 类型转换是否正确，是否先判空再进行转化

  1. 连接数，线程数

◦ 线程的创建是合理地否限制了线程数量

◦ 相关中间件的连接池数量设置是否合理

  1. 返回码解析

◦ 解析响应码是否正确，特别是对于网络异常、catch 异常、无此订单等特殊情况

◦ 响应吗解析 - 网络异常/订单不存在 (网络异常导致和查询早于交易导致)，非明确失败，不可以设置失败

  1. 系统设计问题

◦ 异步转同步，如果后端异步部分组件宕机或重启，导致同步 dispatch 数据一致被阻塞

◦ 是否存在单节点

◦ 是否要支持分布式部署

◦ 乐观锁防止并发修改，悲观锁

  1. 超时时间设置

◦ 任何 RPC 调用地方是否设置连接超时和响应超时时间,包括 HTTP、redis、数据库等

  1. 金融属性

◦ 记账类功能需要考虑余额和流失是否在并发情况下准确

◦ 金额单位，精度是否正确

◦ 金额类型转换是否正确

  1. 时间写法

◦ 时间格式，精度是否有问题，是否会出现写库后四舍五入的情况，导致查询不匹配

◦ 数据库时间配置问题，是否设置东八区，活动是否对时间使用东八区格式

  1. 配置文件

◦ 线上配置文件是否单独抽离上线包，是否已提前在平台单独配置

◦ 若存在不抽离的配置文件，随代码提交的配置文件，是否已检查是正式环境的配置信息

2.2.3 资源支持项

  1. 是否要运营提供额外支持，比如运营后台参数配置等事项

  2. 是否要运维提供额外支持，比如配置网络环境、添加证书秘钥、创建文件目录、添加和删除 jar 包等事项

  3. 是否要 DBA 提供额外支持，比如新增模块添加数据库访问白名单等事项

三、监控告警

监控告警是上线后的风险治理必要机制，一旦出现告警，我们可以第一时间排查和解决，防止更多的客诉产生。

  1. RPC 层监控

◦ 超时监控

◦ 异常报错

◦ 可用率

  1. CACHE 监控

◦ redis 连接异常

◦ r2m 可用率

◦ r2m 容量

◦ r2m 主从切换

  1. MQ 监控

◦ MQ 接收重复

◦ MQ 发送失败

◦ MQ 内处理失败

  1. Task 监控

◦ 定时任务未执行

◦ 定时任务超时

◦ 定时任务执行异常

  1. 业务异常监控

◦ 获取锁异常

◦ AKS 和防刷未通过异常

◦ 任务领奖/接取等异常

◦ 人群没有权限

  1. JVM 监控

◦ fullGc 日志与告警

◦ jvm 监控告警

  1. 容器监控

◦ 实例存活

◦ CPU 负载&使用率

◦ 机器内存

  1. DB 监控

◦ DB 层 CRUD 执行异常

◦ cleverBD 慢 SQL 定期巡查

◦ DB 查询操作时间超长

◦ 线上环境（应用、数据库、配置等）审批负责人是否为当前 leader

  1. 利益点监控

◦ 营销发奖失败

◦ 库存不足

◦ 活动未开始/已结束

◦ 被风控

◦ 防重失败

◦ 单个用户领取利益数量超过配置的警戒线

◦ 活动整体发放量超过配置的警戒线

◦ 其他异常失败

  1. 业务响应码监控

◦ 第三方接口正常码和异常码配置来监控可用率

  1. 配置校验

◦ 获取配置异常

◦ 配置中该配应配字段未配置

◦ 配置中字段配置类型异常

◦ 没有符合当前时间的配置

◦ 活动已结束但仍然有大量用户访问

◦ 多个配置的时间点冲突

◦ 配置的奖励 Id/任务 Id 等在第三方接口未查询到

◦ 每次运营修改配置，修改项通过告警发送到研发，对告警分等级

  1. 活动资格校验

◦ 绕开某个校验告警

◦ 应是老用户领奖但新用户通过前置校验进入领奖流程

作者：京东科技  胡骏

来源：京东云开发者社区 转载请注明来源


↙↙↙阅读原文可查看相关链接，并与作者交流