文章目录

一、技术方案设计的思考原则
- 1. 如何预防出错
- 2. 出错时，及时发现并迅速解决
- 3. 完善的异常处理预案，确保不会造成重大资损
- 4. 如果我可以做的更好来避免或者降低风险，但是没有做，那么我是负有责任的
二、监控
- 1、业务侧-业务指标监控
- 2、技术侧-业务巡检
- 3、技术侧 - 异常
三、安全
- 1、权限
- 2、恶意攻击
四、各种异常场景处理
- 1、业务异常
- 2、技术侧异常
五、技术坑
- 1、并发编程
- 2、读写分离模式下的主从延迟
- 3、前端大整数误差
六、流程关键点
- 1、事前提示
- 2、事后提示
七、其他
- 1、定时任务执行时间要随机

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

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

1. 如何预防出错

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

只要我bug修复的够快，就等于没有bug，事故单就追不上我

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

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

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

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

二、监控

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

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

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

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

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

2、技术侧-业务巡检

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

3、技术侧 - 异常

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

三、安全

1、权限

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

2、恶意攻击

常见的恶意攻击方式

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

四、各种异常场景处理

1、业务异常

业务异常，指的是程序功能没问题，但是业务流程上存在异常。
比如进入app需要登录，但是新人需要先进入app才能注册拥有账号。

2、技术侧异常

主要就是程序代码异常了，比如调用第三方接口失败了、数据库挂了、有bug等等。

五、技术坑

1、并发编程

所有的不可重复操作，都必须考虑并发的问题。不能因为从业务流程上看，不存在并发问题，就可以不处理。
理由如下：

恶意攻击，故意用脚本重复并发请求的
前端因为业务需要或者存在bug，在代码流程中并发请求
因为网络延迟等原因，导致请求并发

2、读写分离模式下的主从延迟

常见的读写分离，比如mysql、redis等等
主要影响场景：写后立即读，会读取不到

3、前端大整数误差

前端js对于大整数是存在一个精度值的，如果将一个超大整数作为参数传递给前端，然后前端在传递回后端，这个值可能就不一样了。
常见出错的场景，用随机生成的超大整数来作为唯一id，用于前后端数据交互。

六、流程关键点

1、事前提示

比如每周热搜，需要运营在每周一之前编辑配置好，然后周一之后展示给用户看。
那么可以在每周日的时候，去check下是否已配置，如果没有配置，就给运营告警。

2、事后提示

比如每周热搜，运营每周一之前配置好数据，周一之后展示给用户看。
那么可以在每周一的时候，提示运营去线上看看，配置热搜展示效果是否正确。

七、其他

1、定时任务执行时间要随机

一般定时任务设置执行时间时，或系统默认，或自己喜好，普遍会设置成整点触发。
这样的问题是，可能会在同一时间执行很多定时任务，如果这些定时任务是高耗资源的，可能会把服务给拖垮，影响到正常业务。
所以，养成个好习惯，定时任务的触发时间设置随机一点，不要都设置成整点。

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

设计期权套期保值方案时应注意的问题
企业在进行期权套期保值方案设计时,需要格外注重交易计划的细节.细节决定成败,无论是应用期货工具还是采用期权工具进行套期保值,都应该有一套较为完整的套期保值制度和方案设计流程. 就期权套期保值方案设计流 ...
设计计算机配置方案技术参数,广西科学技术信息技术七年级上册_《设计计算机配置方案》教案1...
广西科学技术信息技术七年级上册_<设计计算机配置方案>教案1 (6页) 本资源提供全文预览,点击全文预览即可全文预览,如果喜欢文档就下载吧,查找使用更方便哦! 9.9 积分 <信息技 ...
ntp校时器（网络对时服务器）自动化系统技术应用方案
ntp校时器(网络对时服务器)自动化系统技术应用方案 ntp校时器(网络对时服务器)自动化系统技术应用方案京准电子科技提供资料前言随着计算机和网络通信技术的飞速发展,各行业自动化系统数字化.网络 ...
报告论文：汽车GPS调度系统车载终端设计技术方案
汽车GPS调度系统车载终端设计技术方案背景: 随着科技的发展,GPS民用化的趋势越来越让人期待.因为芯片小型化技术的日趋成熟,使得GPS芯片组在缩小体积或是降低耗电量等方面都有很大的突破. 这样,高 ...
设计「业务」与「技术」方案
三天研发,两天设计: 01 [优先做设计方案] 职场中的那些魔幻操作,研发最烦的是哪个? 作为一个数年且资深的互联网普通开发,可以来说明一下为什么是:缺乏设计: 面对业务需求的时候,可能都听过这样一句 ...
老龄人口公交出行_在设计技术时要考虑到老年人口
老龄人口公交出行 Abstract - The senior user base, which we will define as sixty-five years or older, is ofte ...
海格里斯货架厂：设计阁楼式货架方案时必知三要素
随着现代仓储行业的兴起及发展,我们可以看到阁楼式货架对库房的空间的应用于率是极高的,而阁楼式货架也是轻小货物仓库采购货架时优先考虑的仓储货架,不过如何设计一个更好的阁楼式货架方案也是每个企业或者说每个 ...
Redis高可用详解：持久化技术及方案选择
文章摘自:https://www.cnblogs.com/kismetv/p/9137897.html 前言在上一篇文章中,介绍了Redis的内存模型,从这篇文章开始,将依次介绍Redis高可用相关 ...
redis作用_Redis高可用详解：持久化技术及方案选择
本文将先说明上述几种技术分别解决了Redis高可用的什么问题,然后详细介绍Redis的持久化技术,主要是RDB和AOF两种持久化方案.在介绍RDB和AOF方案时,不仅介绍其作用及操作方法,同时还会介绍 ...

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