前言

我的项目研发的过程中经验了需要评审、开发评审、代码编写、测试用例评审、我的项目测试、产品和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. 流动资格校验

◦ 绕开某个校验告警

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

作者：京东科技  胡骏

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