设计技术实现方案时，需要考虑的一些问题

yuyanggo

已于 2022-02-09 21:55:45 修改

阅读量2.1k

点赞数 1

分类专栏：业务实践经验文章标签：后端

于 2021-12-09 11:41:18 首次发布

本文链接：https://blog.csdn.net/yuyanggo/article/details/121790981

版权

业务实践经验专栏收录该内容

6 篇文章 1 订阅

订阅专栏

tips：文档会继续完善，也欢迎读者评论补充完善

一、技术方案设计的思考原则

1. 如何预防出错

2. 出错时，及时发现并迅速解决

只要我bug修复的够快，就等于没有bug，事故单就追不上我
在这里插入图片描述

3. 完善的异常处理预案，确保不会造成重大资损

4. 如果我可以做的更好来避免或者降低风险，但是没有做，那么我是负有责任的

在前公司，当出现事故时，是图和追责的？
找到事故链条上的所有相关方，评估他们有无责任的依据是：如果可以做的更好，来避免或者降低事故资损，但是却没有做，那么就要背负相应的责任，只不过责任有大有小。
所以在前公司设计技术方案时，会更多的从整个业务全局去考虑，目标是整个业务能顺利运转，而不仅仅是自己负责的那块没有问题，出事了不背锅（实际上，在这个追责制度下，出事不背锅很难）。

对于产品设计，应当去想想需求是否合理，技术角度上有无风险和缺漏
应当去想想，如何降低运营人员的使用成本，让他们用起来更加方便和不容易出错，而不仅仅是能用，比如加预览、流程关键点做提醒等等
应当自己多做自测，毕竟代码使我们自己写的，有些隐蔽的问题，只有我们自己才知道，而不能一味依赖qa同学，等到出事了，qa说开发写的bug，开发说qa没测试全

二、监控

监控的有效性很重要，不要做一些根本不会看、没办法看、无意义的监控。

做监控的时候，有个比较容易忽略的点：如果是检测异常的监控，那么即使没有异常，也应当发送一个监控消息。
这么做的目的，是为了确认监控逻辑是否在正常生效。你一直没收到异常通知，不一定是没异常，有可能是监控逻辑压根没正常运行。

监控主要分以下几个类型：

1、业务侧-业务指标监控

内容
主要监控的是各个业务指标，用于了解当前业务的进展情况。
比如现在有个抽奖的需求，那么可以监控下每天参与抽奖的有多少人、各个奖品被抽取了多少等等。
目标用户
参与业务的所有人，包括产品、开发、运营等等。
作用
及时跟踪业务进展。如果业务数据出现异常，各个参与方可以及时知晓并进行相应处理。同时，可以用于业务复盘，指导业务下一步发展。
汇报、装逼时，关键业务指标是必不可少的。

2、技术侧-业务巡检

内容
主要监控的是业务数据是否存在逻辑异常，以及关键的技术性指标。
业务逻辑存在异常：比如有个用户做任务领取奖励的需求，可以每天检查一下用户账户总额和奖励获取明细是否能对应上，如果对应不上，那就说明有bug了，需要开发去处理。
目标用户
所有开发人员
作用
及时发现潜藏的bug并解决，减小资损。（只要bug修复的比用户发现、反馈还要快，那么就没有bug）
对需求进展中的技术指标做到心中有数，在技术方案设计无法支撑业务发展时，能及时感知到并提前做好技术迭代升级。
汇报、装逼时，指标数据必不可少。

3、技术侧 - 异常

内容
主要是针对关键业务的异常情况进行监控。
目标用户
相关开发人员
作用
开发侧及时感知到线上的异常信息，并排查修复、减小损失。

三、安全

1、权限

数据查看权限、操作权限等等，权限泄露的问题就不展开详细聊了。

2、恶意攻击

常见的恶意攻击方式

构建请求参数
攻击者抓包拿到接口，然后自己构造请求参数。
如果数据逻辑校验是由前端来做的，后端不做校验，就存在被别人抓包平获取接口改参数攻击的可能。
重复发送请求
攻击者保留某次正常接口请求，然后
sql注入
老生常谈了，不多说
xss（跨站脚本攻击）
具体介绍可以看这里：链接
核心宗旨就是：不能将从前端传递过来的脚本数据，又返回给前端。
理论上，前端向后端传递的所有数据，都是不可信的。但是如果是后端拼接好的脚本给到前端，这是确定可信的。