在赛博朋克2077玩后感中，我提到，即便是在严谨的机制下，依然可能出现让人匪夷所思或是贻笑大方的问题。
那么今天，就以后端程序员的视角，盘点下从设计开发到上线的常见问题，看看大家中过几个。
01
设计与开发
1.权限控制
如果是暴露到互联网的接口，要控制数据权限，避免被暴力爬库。
例如：getData(Long id)，没有校验当前登录用户是否有查询该数据的权限，结果被对方用程序暴力爬库。
2.熔断
如果上游服务经常故障不可用，可以加入熔断机制。
和业务方确定好熔断规则（失败次数、超时时间等），还可以额外加一个是否启用熔断的开关。
3.任务状态
任务状态扭转时一定要形成闭环，不能有中间状态挂起，同时异常情况需要考虑补偿。
例如：某定时任务逻辑如下，且没有其他补偿任务。
// a.将数据状态从[初始化]->[处理中]
// b.一些业务逻辑
// c.将数据状态从[处理中]->[成功]/[失败]在任务执行时发生系统崩溃或系统重启，这些数据就停滞在[处理中]了。
4.重试与幂等
任务失败或异常后要有重试，注意重试逻辑要考虑到幂等，保证数据准确性。
例如：上述的定时任务可以拆成两个，保证单个定时任务的职责为仅转换一次状态；或是增加一个补偿任务，用于检索处于[处理中]的异常数据并处理。
另外，幂等性可以通过唯一标识、锁、数据库唯一索引、先查询再操作等方式实现。
5.循环与异常
是一条数据失败/异常就全流程结束并回滚？还是可以忽略掉并继续执行其他数据？根据实际情况确定清楚。
同时，循环要检查好出口，避免死循环。
6.并发
使用多线程要考虑各种极端情况，最好都加上锁。
7.缓存
老生常谈的雪崩与穿透问题，使用缓存+数据库时，避免缓存同时过期造成雪崩，也要避免特殊情况下能绕过缓存打到数据库。
使用缓存锁要设置合理的过期时间，防止死锁。
8.接手新系统
仔细斟酌，不懂多问。
-
未使用的代码
有些代码看上去没问题，但实际并未在生产运行，调用时要多留个心眼。
例如：一个没有调用者的服务，里面是对一张表的查询。使用这个服务，测试环境没问题，上线就出问题了，原因是线上压根没有这个数据源的配置。（蚌埠住了）
-
重复的组件或框架
因历史原因，同一个组件或框架在代码里存在多个。
例如：项目中存在两个同名枚举类、AOP 切面、工具类，调用时使用了错误的那个。
9.语言细节
以 Java 为例，String 的比较，BigDecimal 初始化、比较，NPE、集合框架常见问题等等，这块就纯粹是看基础是否扎实了。
10.异常处理
根据业务流程，判断代码中的异常是该往外抛还是自己处理掉。
11.日志打印
-
不多打
正常请求、文件流，打印出来浪费资源。
-
不少打
异常时的错误信息、关键字段，打印出来可快速排查问题。
例如：代码上线后，因将文件流打印到日志，且流量较大，过一会儿运维就电话过来了，反馈机器磁盘空间不足。（恐怖故事：上线一段时间后来电话）
12.Tid
多线程下使用 Tid 要额外处理，避免所有线程共用一个 Tid 或 Tid 丢失的问题。
13.单元测试
按规范写单元测试，不要过于随意，例如在 Controller 层写个接口来测试，可能引发安全问题。
14.影响范围
哪怕是一行代码，也可能牵一发而动全身，仔细评估影响范围，并将改动点和测试交代清楚。
例如：改动一行代码，看似已经检查了所有使用者，结果由于其身处设计模式或 Spring Bean 中，还有其他间接使用者，就评估漏了影响范围。
02
CI / CD
1.Maven
-
依赖问题
Maven采用最短最先声明优先原则，如果随意使用可能会依赖到我们不想要的版本，最好还是手动做依赖排除。
-
代码推包
在 Deploy 前，确认版本号是否需要升级，避免代码因随意推包而被带上线或是覆盖他人代码。
例如：开发A将某XML文件删除，开发B虽然 Pull 了最新的代码，但本地的 target 文件夹下依然有该XML文件，未升级版本号进行 Deploy ，结果将该文件又推了上去，从而引发问题。
-
版本控制
当存在多个开发中的需求时，需要特殊处理。
例如：线上版本1.0，正在开发的的版本1.1，此时加入紧急需求并上线使用了1.2，那么在紧急需求上线后，最好将原来开发的版本从1.1直接升到1.3，如果还沿用1.2，可能导致包被带上线。
2.GIT
-
代码合并
主要看团队的分支管理规范，有时因存在多个开发中的分支，容易误合被带上线。
-
代码推送
例如：口口声声说合了代码，结果只合并到了本地分支，没有推送到远程仓库。（搞笑呢）
3.启动参数
-
合理的内存配置
-
权限
如果应用需要操作文件，那么它启动参数的用户应该要有操作文件的权限。
4.灾备问题
服务对接时，如果一方是双活，一方是单活冷备，需要注意请求是否会走到冷备那边。
例如：某应用作为 MQ 生产者是双活部署，结果 MQ 消费者的应用是单活，那么自然而然其冷备所在环境的 MQ 就没法消费。
03
数据库
1.迁库
-
通知下游
提前梳理好所有使用方，最好让 dba 看下流量来源，并将这些应用的数据源配置整改好，迁移时直接改数据源地址然后重启。
例如：评估漏了使用方，结果都迁移一周了对方反馈无增量数据才知道。。
-
代码修改
有些时间函数语法是相同的但是时间单位不同，不会报错也不易发现，迁移时需格外注意。
2.上线 SQL
-
索引
没有确认 SQL 在线上的执行计划，导致慢 SQL。
-
评估影响范围
如果会造成锁表、增加主从同步时间等，需要评估对业务和其他读从库的系统的影响，确定好执行时间并通知相关方。
3.修数时
-
先验证
先修一笔的验证逻辑，确认无误再全量修。
例如：没有验证就全量修数，结果未达到预期并造成了更复杂的局面，花了更多的时间处理。
-
执行顺序
注意 SQL 执行的先后顺序，以及对当前业务有哪些影响。
例如：先插入了待执行的任务，再修改的其他数据，结果任务插入后立刻被程序执行，但实际其他数据还未准备完毕，又花了更多的时间处理。
04
定时任务
1.路由策略
把分片广播的配置成了单机，效率低下，当然反过来如果没有幂等也一样有问题。
2.阻塞处理策略
单机串行可能重复执行，丢弃后续调度可能漏执行，要根据实际业务逻辑选择。
3.Cron 表达式
-
时间
例如某些固定在每月某天执行的，可以通过工具确认下次运行时间。
-
依赖
如果任务有前置依赖，应该在代码里检查前置是否执行完成，或延后任务的执行时间。
4.任务参数
填写错误，例如数字类型填成了字符串类型。
05
配置文件
1.不要手敲
采用手敲而非复制，导致值不正确。
例如：经典 oO0D、2zZ、1Il。
2.确认发布
未发布配置便投产应用，导致应用启动找不到配置。
3.确认值
线上直接使用测试环境的值（测试同学随便配的），开发没有去核实该配置，导致有问题。
最好是规范到产品接入表格里，让业务提供准入参数。
4.配置还原
配置在临时调试、处理问题后，要还原本来正常的值。
例如：扣款时间在9点，由于9点至10点上游异常，临时改动到11点扣款，处理完成之后，忘记将时间改回去。
06
网络
1.确认网络
确认网络策略开通后再发布应用，以免代码提前运行报错影响业务。
2.白名单
通常网络策略和白名单是配套的，注意找网络同学要最新的对外出口白名单。
3.安全访问
HTTPS 访问 HTTP 会被浏览器拦截，导致无法访问。如果代码暂时整改不了可以写一个浏览器配置操作手册发给使用方。
07
文件
1.权限
应用是否有处理文件的权限，有时得到的路径可能是相对路径，权限和路径也挂钩，需要注意。
2.区分
文件要检查是否能通过文件夹或文件名来区分，否则可能只有一个文件在不断被覆盖。测试时可能只测一笔数据，不会测到。
08
上线验证
1.谨慎对待
业务流程、日志、监控告警、数据库多层次验证，不要随便看下没问题就溜了。重大变更要有详细的上线步骤、验证步骤。
文章推荐：程序员工作中常见问题，你遇到过几个？
原创不易，点个关注不迷路哟，谢谢！
文章推荐：
1228
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
