共计 4859 个字符，预计需要花费 13 分钟才能阅读完成。
前言
我的项目研发的过程中经验了需要评审、开发评审、代码编写、测试用例评审、我的项目测试、产品和 UI 验收等一系列流程，其中投入了大量的人力和精力。
然而最初的上线阶段，总是存在诸多不确定性和可变性，往往在测试阶段测 N 次都没有丝毫问题，一上线就会呈现 Bug（几乎是墨菲定律的咒骂）。
通过多年的经验总结和残暴教训，咱们将这些已知的或潜在的危险点具体梳理进去，心愿每个我的项目的上线都能够踏踏实实、十拿九稳、顺顺利利。
本文，咱们将从三个方面来防备上线危险：操作防备、双岗 & 自查、监控告警。
一、操作防备
次要蕴含了四大类别的防备：研发防备、配置防备、运维防备和审批防备。
1.1 研发防备
1.1.1 通用层
- Loading/Confirm 对立标准化
- 谬误页 / 骨架屏 / 无数据 / 网络异样兜底标准
- 布告、弹窗标准
1.1.2 代码层
- 应用 https、禁止非 jd 源、验证外网可用
- 环境切换通过零碎变量辨别
- Commit 标准
▪ 单次提交独立性能代码
▪ 所有研发代码提交 Coding
- 对立 IDE 和脚手架
- 开发环境 node.js、npm、joyer、taro 等版本对立
- 对立通用组件
▪ 沉迷式导航
▪ 共用组件，检测版本反对及容错解决
▪ 云梯组件
▪ 加密防刷：AKS，AAR
▪ 风控设施指纹
▪ 奇点埋点
▪ 下载唤起组件
▪ 分享组件以及金口令
- 数据处理
▪ 分页加载防止申请死循环
▪ 网关层错误码解决
▪ 服务端接口层错误码解决
▪ 主性能接口异样是跳转谬误页 / 弹窗重试等必要解决
▪ 兜底计划
1.1.3 UI 层
- 是否有动效
- 音视频是否兼容性
- 是否存在性能卡顿
1.1.4 平安层
- 编码问题：是否通过 eslint
- 兼容问题：编码语法、办法属性、组件库最低反对版本等解决
- 逻辑性能：代码逻辑是否与预期性能统一
- 异常情况：是否思考降级 / 容错 / 超时等异常情况
- 用户体验：新增或者批改性能对性能或者体验是否不良用户体验影响
- 平安：密文传输、防刷、脚本注入等
- mock：是否正确处理了 mock 数据的展现
- 敏感数据：对数据处理是否存在潜在客诉危险等
1.2 配置防备
1.2.1 研发配置
- 内容配置平台配置已上线的配置再次操作要留神不影响线上，尽量新增配置
- 配置数据类型不反对工夫控件，禁止在下面配置工夫或工夫戳等数据
- 配置前的数据校验（例如：链接格局是否正确，数据长度是否须要限度等）
- 数据容错解决，若为重要数据需设置为必填项 “required”: true；
1.2.2 经营配置
- 流动上线前，所有生产配置必须都实现
- 已上线的配置，再次操作需与产品及研发确认；经营外部双岗确认
- 预发环境验证，数据和生产保持一致（奖品类型、券类型、秒杀工夫、工作类型等 )
- 处分、券或工作等需验证可失常发放或支付后再配置展现到前端
- 在流动支付利益点到其余流动页应用，需保障二级流动页面内应用利益点失常
1.2.3 环境配置
- 所有新我的项目对立应用 joyer 脚手架初始化
- 命令对立，本地环境、打包、公布各环境等
- vconsole、正文等仅在非生产包中配置
- 每个我的项目必须有 mock 环境，应用 mock 数据去验证各类状况，而不是批改或正文代码
- 老我的项目是否采纳 webpack、vue-cli 对立标准
1.3 运维防备
1.3.1 域名解析操作
- ip 是不在利用下存在
- 实例上是否具备可拜访我的项目
- 找运维配合查看是否我的项目可拜访
- 确保告知运维工单受理告诉开发人员及时验证
1.3.2 CDN 操作
- 确保源站域名和减速域名不统一
- 确保上传的减速内容与散发形式相匹配（图片、大文件、视频、直播流）
- 确保减速域名下的文件为动态资源（思考是否须要做动静拆散）
- 确保源站 IP 是否正确
- 申请接入后只代表 CDN 已实现后还留神需配置 DNS 解析变更
- 查问输出域名查看全国各地区解析是否失效
1.3.3 HSTS 操作
- 确保客户端或利用是否 https 或开启 https 强跳是否有问题
- 对于 vip 下有多个利用或域名要告诉各方确认是否有影响
1.3.4 http2 操作
确保域名为 https 才可开启
1.3.5 ddos 操作
CDN 域名暂不必接入
1.3.6 扩容操作
- 机器审批实现确认执行后果全副胜利
- 确保新扩容机器配置及我的项目部署
- 对于混合部署有多个利用存在须要所有利用都实现部署并验证（可让运维配合）
- 混合部署利用确保每个利用都要走复用工单
- 确保扩容操作实现后重启机器操作
1.3.7 缩容操作
- 确保 CDN 域名解析的为内网 VIP（如果为 rip 须要走变更 VIP 工单流程）
- 混合部署确保每个利用都要走工单
- 预发机器须要补充预发域名反向代理变更工单
1.3.8 下线操作
- 确保下线机器是否影响线上（独立部署某个我的项目）
- 留神摘流量 - 摘机器等步骤实现才可下线
1.3.9 回滚操作
- 应用 JDOS 点击回滚操作
- 回滚抉择的包要仔细检查是否是上次上线的
1.3.10 堡垒机操作
- 容器必须失常启动
- dockerfile 构建的镜像，只能申请 root 权限且 22 端口必须关上
- 公共镜像，只能申请 root 权限且 22 端口必须关上
1.4 审批防备
- 是否通过测试节点审批
- 是否由 leader 审核
- 开发与审批权限是否离开
二、双岗 & 自查
上线前的双岗自查，是咱们制订的一项规范流程。要求研发人员在上线前必须依照上面的清单，并寻求其余共事的帮助进行我的项目代码的排查（当局者迷，旁观者清）。
2.1 前端
2.1.1 环境查看
- 域名是否接入 CDN
- jen 配置是否统一
- jen 是否全副在线
- 是否开启 gzip
- 部署机器数量与预期是否统一
2.1.2 专用组件
- 是否接入 AAR
- 是否接入 AKS
- 是否接入风控
- 是否增加 SGM 监控
2.1.3 需要查看
- 本次上线资源是否蕴含非本次产品需要迭代内容
- 页面引入资源是否都是本次上线内容
- 本次上线资源是否为预发已测试版本
2.1.4 代码查看
- 是否有第三方代码注入
- 是否存在敏感字段
- 是否去掉 log/mock/Vconsole 等调试工具
- 我的项目中是否存在 http 域名资源
- 服务端接口是否为线上
- 检测所有资源域名是否为线上外网域名
- 包资源文件 hash 是否由生产部署
- 仓库 master 代码是否是最新的
- 对于混合部署利用，本次上线是否只更新以后利用代码
- 对于通天塔自定义组件，本次改变是否思考低版本，是否影响其余我的项目中援用的模板
2.1.5 回归查看
- 应用 4G/5G 验证
- 上线后操作 CDN 资源是否是最新上线的
- 上线后验证。对于混合部署的我的项目，最新分支是否合并到 master
2.1.6 流程工单
- 双岗查看确认通过
- UI 走查通过并确认
- 风控验收通过并确认
- 平安测试工单提交并实现
2.2 服务端
2.2.1 监控检查点
- 业务监控
◦ 订单
◦ 日志异样
◦ SQL 异样
◦ SQL 耗时
◦ 业务耗时监控
◦ 业务状态异样监控
◦ 异样流程监控
- 根底监控
◦ 第一类运维：利用零碎所依赖的硬件、虚拟机、网络等
◦ 第二类运维：操作系统层面，比方 cpu, 内存，硬盘，IO 等
◦ 第三类运维：中间件层面的，比方数据库，缓存，tomcat, ningx 等
◦ 第四类运维：利用自身的，比方 JVM 监控, 日志归集等
◦ 第五类运维：新性能上线操作和日常应急演练工
2.2.2 通用自查点
- 上线程序类
◦ 外部存在多个利用上线，依赖关系及上线程序，是否曾经思考过
◦ 利用上线前，是否需先创立好了相干表构造，注册 mq，rpc 等操作
◦ 本次版本上线，是否波及内部利用，是否须要别的模块配合，上线是否有程序要求
- 安全类
◦ 是否要思考外网平安问题，比方 SQL 注入，XSS 攻打，敏感信息加密，账号爆破等
◦ 是否思考接口通信安全问题，加签验签，秘钥治理等
◦ 各种拜访是否思考要减少白名单或者证书或者短信
◦ 数据库敏感字段是否加密
- 防刷，防重类
◦ 防重机制，哪几种状态和场景下容许反复发送订单
◦ 否有限度容许同一秒承受多笔同样的订单
◦ 平台惟一 ID 生成是否会有反复的可能
◦ 所有申请入口，定时器和 API 申请是否应用乐观锁。思考并发反复解决问题，并且要判断更新影响条数
- 异样解决类
◦ 是否解决了各业务的主分支以外的异样分支
◦ 具体异样栈别吃掉
◦ 三方交互的是否实现
▪ 须要抓取 IOException 做解决
▪ IOException 须要打印 URL 不便报警排查问题
▪ 须要设置连贯超时和读取超时工夫
▪ 是否须要通过代理出网
▪ 是否须要再三方增加白名单
▪ 三方是否有最大数限度
▪ 正当设置 http 连接数和敞开连贯
- 日志标准类
◦ 日志打印是否有本人的业务标准，有助于日志巡检
- 定时工作类
◦ 业务定时器是否有浪打浪，反复解决的状况，并发配置是否设置成 false
◦ 定时工作中解决的数据量是否有预期的执行 size，是否会出现异常状况下，解决的 size 越来越多的状况
- SQL 类
◦ 是否应用了惟一索引
◦ 惟一索引的应用是否正确，例如多个字段做为联结惟一索引，是否存在字段为 null 状况
◦ update 和 select 语句是否有预期的执行 size
◦ 是否防止应用简单 sql
◦ sql 是否查看过执行打算，是否能命中索引，一段时间业务增长是否存在慢 sql 的可能性
- 缓存的应用
◦ 缓存应用，是否设置超时工夫，超时工夫设置是否正确，是秒单位，还是毫秒单位
◦ 缓存同步问题解决方案的评估（数据库乐观锁 + 事物 + 排序、redis 乐观锁、CAS）
◦ 分明 redis 的应用场景
- 事务的应用
◦ 代码中应用事务的须要思考死锁场景
- 治理后盾
◦ 治理后盾下载，查问等性能是否有条数限度和频次限度
- 类型转换
◦ 类型转换是否正确，是否先判空再进行转化
- 连接数，线程数
◦ 线程的创立是正当地否限度了线程数量
◦ 相干中间件的连接池数量设置是否正当
- 返回码解析
◦ 解析响应码是否正确，特地是对于网络异样、catch 异样、无此订单等非凡状况
◦ 响应吗解析 - 网络异样 / 订单不存在 (网络异样导致和查问早于交易导致)，非明确失败，不能够设置失败
- 零碎设计问题
◦ 异步转同步，如果后端异步局部组件宕机或重启，导致同步 dispatch 数据统一被阻塞
◦ 是否存在单节点
◦ 是否要反对分布式部署
◦ 乐观锁避免并发批改，乐观锁
- 超时工夫设置
◦ 任何 RPC 调用中央是否设置连贯超时和响应超时工夫, 包含 HTTP、redis、数据库等
- 金融属性
◦ 记账类性能须要思考余额和散失是否在并发状况下精确
◦ 金额单位，精度是否正确
◦ 金额类型转换是否正确
- 工夫写法
◦ 工夫格局，精度是否有问题，是否会呈现写库后四舍五入的状况，导致查问不匹配
◦ 数据库工夫配置问题，是否设置东八区，流动是否对工夫应用东八区格局
- 配置文件
◦ 线上配置文件是否独自抽离上线包，是否已提前在平台独自配置
◦ 若存在不抽离的配置文件，随代码提交的配置文件，是否已查看是正式环境的配置信息
2.2.3 资源反对项
- 是否要经营提供额定反对，比方经营后盾参数配置等事项
- 是否要运维提供额定反对，比方配置网络环境、增加证书秘钥、创立文件目录、增加和删除 jar 包等事项
- 是否要 DBA 提供额定反对，比方新增模块增加数据库拜访白名单等事项
三、监控告警
监控告警是上线后的危险治理必要机制，一旦呈现告警，咱们能够第一工夫排查和解决，避免更多的客诉产生。
- RPC 层监控
◦ 超时监控
◦ 异样报错
◦ 可用率
- CACHE 监控
◦ redis 连贯异样
◦ r2m 可用率
◦ r2m 容量
◦ r2m 主从切换
- MQ 监控
◦ MQ 接管反复
◦ MQ 发送失败
◦ MQ 内解决失败
- Task 监控
◦ 定时工作未执行
◦ 定时工作超时
◦ 定时工作执行异样
- 业务异样监控
◦ 获取锁异样
◦ AKS 和防刷未通过异样
◦ 工作领奖 / 接取等异样
◦ 人群没有权限
- JVM 监控
◦ fullGc 日志与告警
◦ jvm 监控告警
- 容器监控
◦ 实例存活
◦ CPU 负载 & 使用率
◦ 机器内存
- DB 监控
◦ DB 层 CRUD 执行异样
◦ cleverBD 慢 SQL 定期巡逻
◦ DB 查问操作工夫超长
◦ 线上环境（利用、数据库、配置等）审批负责人是否为以后 leader
- 利益点监控
◦ 营销发奖失败
◦ 库存有余
◦ 流动未开始 / 已完结
◦ 被风控
◦ 防重失败
◦ 单个用户支付利益数量超过配置的警戒线
◦ 流动整体发放量超过配置的警戒线
◦ 其余异样失败
- 业务响应码监控
◦ 第三方接口失常码和异样码配置来监控可用率
- 配置校验
◦ 获取配置异样
◦ 配置中该配应配字段未配置
◦ 配置中字段配置类型异样
◦ 没有合乎以后工夫的配置
◦ 流动已完结但依然有大量用户拜访
◦ 多个配置的工夫点抵触
◦ 配置的处分 Id/ 工作 Id 等在第三方接口未查问到
◦ 每次经营批改配置，批改项通过告警发送到研发，对告警分等级
- 流动资格校验
◦ 绕开某个校验告警
◦ 应是老用户领奖但新用户通过前置校验进入领奖流程
作者：京东科技 胡骏
起源：京东云开发者社区 转载请注明起源
