前语
项目研制的过程中阅历了需求评定、开发评定、代码编写、测验用例评定、项目测验、产品和UI检验等一系列流程，其中投入了很多的人力和精力。
然而最后的上线阶段，总是存在诸多不确定性和可变性，往往在测验阶段测N次都没有丝毫问题，一上线就会呈现Bug（简直是墨菲定律的诅咒）。
经过多年的经验总结和严酷经验，咱们将这些已知的或潜在的危险点详细梳理出来，期望每个项目的上线都能够踏踏实实、满有把握、顺顺利利。
本文，咱们将从三个方面来防备上线危险：操作防备、双岗&自查、监控告警。
一、操作防备
首要包含了四大类别的防备：研制防备、装备防备、运维防备和批阅防备。
1.1研制防备
1.1.1 通用层
1.Loading/Confirm共同规范化
2.过错页/骨架屏/无数据/网络反常兜底规范
3.公告、弹窗规范
1.1.2 代码层
1.运用https、禁止非jd源、验证外网可用
2.环境切换经过体系变量区别
3.Commit规范
▪单次提交独立功用代码
▪一切研制代码提交Coding
4.共同IDE和脚手架
5.开发环境node.js、npm、joyer、taro等版本共同
6.共同通用组件
▪沉浸式导航
▪共用组件，检测版本支撑及容错处理
▪云梯组件
▪加密防刷：AKS，AAR
▪风控设备指纹
▪奇点埋点
▪下载引发组件
▪分享组件以及金口令
7.数据处理
▪分页加载避免恳求死循环
▪网关层过错码处理
▪服务端接口层过错码处理
▪主功用接口反常是跳转过错页/弹窗重试等必要处理
▪兜底计划
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耗时
◦事务耗时监控
◦事务状况反常监控
◦反常流程监控
2.基础监控
◦第一类运维：运用体系所依靠的硬件、虚拟机、网络等
◦第二类运维：操作体系层面，比方cpu,内存，硬盘，IO等
◦第三类运维：中间件层面的，比方数据库，缓存，tomcat, ningx等
◦第四类运维：运用自身的，比方JVM监控, 日志归集等
◦第五类运维：新功用上线操作和日常应急演练工
2.2.2 通用自查点
1.上线次序类
◦内部存在多个运用上线，依靠联系及上线次序，是否已经考虑过
◦运用上线前，是否需先创立好了相关表结构，注册mq，rpc等操作
◦本次版本上线，是否涉及外部运用，是否需求别的模块合作，上线是否有次序要求
2.安全类
◦是否要考虑外网安全问题，比方SQL注入，XSS攻击，灵敏信息加密，账号爆炸等
◦是否考虑接口通信安全问题，加签验签，秘钥办理等
◦各种拜访是否考虑要增加白名单或许证书或许短信
◦数据库灵敏字段是否加密
3.防刷，防重类
◦防重机制，哪几种状况和场景下允许重复发送订单
◦否有约束允许同一秒接受多笔同样的订单
◦渠道仅有ID生成是否会有重复的可能
◦一切恳求入口，守时器和API恳求是否运用乐观锁。考虑并发重复处理问题，并且要判别更新影响条数
4.反常处理类
◦是否处理了各事务的主分支以外的反常分支
◦详细反常栈别吃掉
◦三方交互的是否完结
▪需求抓取IOException做处理
▪IOException需求打印URL便利报警排查问题
▪需求设置衔接超时和读取超时时刻
▪是否需求经过代理出网
▪是否需求再三方增加白名单
▪三方是否有最大数约束
▪合理设置http衔接数和关闭衔接
5.日志规范类
◦日志打印是否有自己的事务规范，有助于日志巡检
6.守时使命类
◦事务守时器是否有浪打浪，重复处理的状况，并发装备是否设置成false
◦守时使命中处理的数据量是否有预期的履行size，是否会呈现反常状况下，处理的size越来越多的状况
7.SQL类
◦是否运用了仅有索引
◦仅有索引的运用是否正确，例如多个字段做为联合仅有索引，是否存在字段为null状况
◦update和select语句是否有预期的履行size
◦是否避免运用复杂sql
◦sql是否查看过履行计划，是否能命中索引，一段时刻事务增长是否存在慢sql的可能性
8.缓存的运用
◦缓存运用，是否设置超时时刻，超时时刻设置是否正确，是秒单位，仍是毫秒单位
◦缓存同步问题解决计划的评价（数据库失望锁+事物+排序、redis失望锁、CAS）
◦清楚redis的运用场景
9.事务的运用
◦代码中运用事务的需求考虑死锁场景
10.办理后台
◦办理后台下载，查询等功用是否有条数约束和频次约束
11.类型转化
◦类型转化是否正确，是否先判空再进行转化
12.衔接数，线程数
◦线程的创立是合理地否约束了线程数量
◦相关中间件的衔接池数量设置是否合理
13.返回码解析
◦解析呼应码是否正确，特别是关于网络反常、catch反常、无此订单等特殊状况
◦呼应吗解析-网络反常/订单不存在(网络反常导致和查询早于交易导致)，非清晰失利，不能够设置失利
14.体系规划问题
◦异步转同步，如果后端异步部分组件宕机或重启，导致同步dispatch数据共同被堵塞
◦是否存在单节点
◦是否要支撑分布式布置
◦乐观锁避免并发修正，失望锁
15.超时时刻设置
◦任何RPC调用地方是否设置衔接超时和呼应超时时刻,包含HTTP、redis、数据库等
16.金融特点
◦记账类功用需求考虑余额和流失是否在并发状况下准确
◦金额单位，精度是否正确
◦金额类型转化是否正确
17.时刻写法
◦时刻格局，精度是否有问题，是否会呈现写库后四舍五入的状况，导致查询不匹配
◦数据库时刻装备问题，是否设置东八区，活动是否对时刻运用东八区格局
18.装备文件
◦线上装备文件是否独自抽离上线包，是否已提前在渠道独自装备
◦若存在不抽离的装备文件，随代码提交的装备文件，是否已查看是正式环境的装备信息
2.2.3 资源支撑项
1.是否要运营供给额外支撑，比方运营后台参数装备等事项
2.是否要运维供给额外支撑，比方装备网络环境、增加证书秘钥、创立文件目录、增加和删除jar包等事项
3.是否要DBA供给额外支撑，比方新增模块增加数据库拜访白名单等事项
三、监控告警
监控告警是上线后的危险治理必要机制，一旦呈现告警，咱们能够第一时刻排查和解决，避免更多的客诉产生。
1.RPC层监控
◦超时监控
◦反常报错
◦可用率
2.CACHE监控
◦redis衔接反常
◦r2m可用率
◦r2m容量
◦r2m主从切换
3.MQ监控
◦MQ接纳重复
◦MQ发送失利
◦MQ内处理失利
4.Task监控
◦守时使命未履行
◦守时使命超时
◦守时使命履行反常
5.事务反常监控
◦获取锁反常
◦AKS和防刷未经过反常
◦使命领奖/接取等反常
◦人群没有权限
6.JVM监控
◦fullGc日志与告警
◦jvm监控告警
7.容器监控
◦实例存活
◦CPU负载&运用率
◦机器内存
8.DB监控
◦DB层CRUD履行反常
◦cleverBD慢SQL定期巡查
◦DB查询操作时刻超长
◦线上环境（运用、数据库、装备等）批阅负责人是否为当时leader
9.利益点监控
◦营销发奖失利
◦库存不足
◦活动未开始/已结束
◦被风控
◦防重失利
◦单个用户收取利益数量超越装备的警戒线
◦活动整体发放量超越装备的警戒线
◦其他反常失利
10.事务呼应码监控
◦第三方接口正常码和反常码装备来监控可用率
11.装备校验
◦获取装备反常
◦装备中该配应配字段未装备
◦装备中字段装备类型反常
◦没有符合当时时刻的装备
◦活动已结束但仍然有很多用户拜访
◦多个装备的时刻点冲突
◦装备的奖赏Id/使命Id等在第三方接口未查询到
◦每次运营修正装备，修正项经过告警发送到研制，对告警分等级
12.活动资格校验
◦绕开某个校验告警
◦应是老用户领奖但新用户经过前置校验进入领奖流程
作者：京东科技 胡骏
来历：京东云开发者社区 转载请注明来历
