我们好，我是老三，转眼间，团队的技能专家B哥，已经离任一年了，我还时不时会想起他，由于他留下的j技能规划模版，我觉得真的很好用，根本上涵盖了规划需求考虑的方方面面。接下来，以一个CRM项目的用户触达模块为例，给我们分享一下。
一、CRM_技能规划文档_音讯触达模块
| 项目名称 | CRM体系 |
|---|---|
| 项目负责人 | 三分恶 |
| 模块名称 | 用户触达模块 |
| 模块负责人 | 三分恶 |
老三说：榜首部分首要阐明项目或许模块的概略，这一部分尽管不太重要，可是是有必要的。
二、修订记载
| 版别 | 修订人 | 修订内容 | 修订日期 |
|---|---|---|---|
| V1.0 | 三分恶 | 创立 | 2022-12-23 |
老三说：技能规划不是原封不动的，经常会随着事务的变化，或许依据遇到的一些问题，进行完善和优化，可是每一个版别，都应该留下记载和备份。
三、需求/布景
产品文档：xxxx
为了完结用户的精细化运营，经过多种途径，向用户发送音讯告诉……
老三说：这一部分便是结合产品文档，把需求/布景简单提炼一下，有必要，但不是要点。
四、规划方针
老三说：规划方针一般分为两部分：
- 完结功用：这一部分便是便是剖析需求，把产品文档里的东西，拆解成一个个的功用，也便是CRUD。
- 规划指标：CRUD也有差异，一把梭，随意写也能完结功用，可是咱们CRUD也得有点追求，并且面向C端用户的体系，也根本上会有一些功用、可用性之类的要求，比方接口呼应均匀多少多少毫秒以下、单机QPS1000、体系几个9可用……
4.1.完结功用
- 多种途径给用户推送音讯，首要包括站内和站外两大部分：
- 站内：
- 站内信
- 弹屏
- 站外：
- 邮件
- 短信
- push
- 微信
- ……
- 触达使命管理
- 支撑守时/延时音讯发送
- 支撑触发型音讯发送
- 支撑用户分群发送
……
老三说：功用点比较多的话，这一部分还能够用思维导图的方法来收拾。
老三说：这一部分评定的时分必定要拉上产品司理或许相关的事务方，确认功用点没有错漏。
4.2.规划指标
- 功用要求
- 百万级音讯分钟级发送完结
- xx接口，功用指标：单机1000并发，95%呼应<=200ms
……
老三说：一般C端的服务都是有比较严厉的功用要求的，究竟假设体系呼应慢的话，用户的流失率就会变高。当然，用户触达，其实首要在于推，用户主动查会少一些，音讯的推送通常也会要求速度，比方，有个网红，九点钟要在app上直播，直播开端的时分，要做一个推送，那就要求尽或许快地把音讯推送给每个用户，不能说比及十二点直播完了，有的用户才收到音讯。
- 可用性
- 触达模块99.9%可用
- 音讯推送成功率80%以上
……
老三说：C端体系的可用性比较重要，究竟挂一会，影响的用户或许都是以万计，所以，规划的时分，也要考虑可用性，剖析体系的瓶颈在哪里，流量突然上来，哪里或许顶不住，是要扩容，仍是要限流、熔断降级……
- 扩展性
- 选用策略方式+装备，新增音讯途径，只需少数代码+代码即可完结
- 引入规则引擎，同一音讯类型的不同途径，能够经过规则调整，无需发版
……
老三说：这一部分也是规划中应当考虑的，不能一味求快，不然很容易堆屎山。
- 兼容性
- 接口xxx向前兼容app 1.9.0版别，低版别需强制更新
……
老三说：C端体系的开发，有时分比较麻的是低版别app的兼容，尽或许前期规划的时分，就考虑或许的扩展，假设真实无法兼容，那就只能app强制更新，当然这种用户体会就十分欠好了。
- 可观测性
- 接入Prometheus和Grafana，对服务和事务进行监控
- 服务监控：经过控制面板调查服务的内存、CPU、JVM、接口QPS、接口RT……
- 事务监控：经过埋点上报，搜集用户触达数据，经过面板能够分设备、途径查看用户触达到功率……
老三说：这一部分也很重要，咱们一般上班的榜首件事，便是看监控面板，剖析有没有什么异常的地方。服务的可观测性，一般公司都是用一些开源的或许付费的监控渠道，大厂一般都会自研监控渠道。服务的监控很多是经过插桩来完结，事务的监控一般都需求打埋点。
- 告警
- 经过PrometheusAlert完结服务的告警，告警信息分级别，进行飞书告诉、电话告诉，告警类型分为服务告警和事务告警
- 服务告警：内存、CPU占用过高，接口QPS过多，接口RT过长，触发告警
- 事务告警：用户触达到功率过低告警
老三说：告警通常也是和监控在一起的，究竟开发人员也不或许二十四小时盯着告警，一般开源的、付费的、自建的监控体系，都支撑装备告警规则，并经过不同的方法，邮件、短信、电话之类的途径进行告诉。
五、概要规划
老三说：概要规划，便是做个大约的体系全体规划。
5.1.规划思路
- 数百万音讯段时间发送完结，流量较大，对数据存储功用要求较高，需求选用高功用DB，对存储压力也比较大，一起需求必定削峰处理
- 守时/延时音讯发送选用音讯行列完结，对MQ的消费要求较高，并发度要高，批量消费
- ……
老三说：这一部分首要是收拾一下全体的开发规划思路，把一些零星的主意收拾成点或许面，前期我们的评论能够收拾在这里。
5.2.技能选型
- 存储：TiDB
- 缓存：Redis
- 音讯行列：事务RocketMQ，埋点Kafka
- 注册中心：Nacos
- 装备中心：Nacos
- RPC：Dubbo
- 网关：Gateway
- Push通道：自建
……
老三说：这一部分便是大约定一下技能选型，其实要是整个项目做好了选型，这一部分也能够不做，一般需求高级技能人员或许架构师，来全体地进行掌握，当然，很多时分选型也没好选的，根本便是主流的那些，并且一般一个团队，都是一致的技能选型，便利保护。
5.3.事务架构
老三说：这一部分便是大约对功用分分层，分分块，把大约的功用切一切。
5.4.技能架构
老三说：技能选型+事务架构，其实一个大约的技能架构就出来了。
老三说：技能架构图类型，其实也没有特别固定的方法，首要是图能达意，我这个图是经过draw.io画的，还有一些其它的还用的工具，比方我们应该都听过“PPT架构师”，用PPT画也是能够的。当然这个图是我顺手画的。
5.5.体系环境
- JDK版别：11
- 布置环境：k8s+Containerd，单pod8核CPU+4G内存，服务集群32个pod
- 数据库：
- 事务数据：TiDB 64核CPU+128G内存
- 离线数据：Hbase……
- ……
老三说：假设是项目初建，一般还需求对体系的环境进行评价，依据技能选型、数据容量、体系QPS等等，来选择体系的环境，这一部分一般评定的时分会拉上运维同学，提前确认好体系环境，和运维同学对齐需求和排期。
六、具体规划
老三说：具体规划，便是具体指导开发的规划部分了，包括流程啊、数据模型啊、具体用到的算法、和客户端的接口，等等，这一部分很重要，假设没做好，没对齐，那么搞欠好就要返工，耽搁进度。
6.1.流程规划
- push流程
老三说：用户触达，事务流程根本比较简单，关于一些买卖类的，比方付出，或许B端的体系，比方ERP，在开端开发之前，流程必定要收拾清楚，一般经过流程图、时序图来描绘事务流程。给我们看一下我之前对接alipay画的简单的时序图：
6.2.算法规划
- 途径分流：同一音讯类型，多种途径，支撑按比例分流，选用加权随机算法完结
- ……
老三说：算法设置不必定数据结构相关的算法，代码里的一些涉及到一些需求进行逻辑核算的，都能够称之为算法，这一部分也能够先收拾一下。
6.3.数据模型规划
- crm_user_toutch_tash：用户触达使命表
| 字段 | 描绘 | 数据类型 |
|---|---|---|
| id | 主键 | bigint |
| task_no | 使命编号 | bigint |
| comment | 描绘 | varchar |
| …… |
老三说：数据模型规划十分重要，能够说是体系规划的根基，假设没有规划好，开发和保护起来真的很苦楚，每个公司应该都有必定的数据库规划标准，根本便是结合事务和标准来规划了。
具体用什么工具规划呢？事务比较简单的C端体系，其实直接拿表格也行，之前也试过PdMan，还行吧。
6.4.接口规划
| 接口名称 | 添加付出使命 |
|---|---|
| 接口文档地址 | yapi.com/xxx |
| 入参 | |
| 入参描绘 | comment：使命描绘 |
| 出参 | |
| 出参描 |
老三说：这一部分也是重量级，凡是涉及到客户端，或许其它服务的，这一部分都少不了，一般能够经过YApai之类的接口工具，可是主张我们仍是在文档里做个重复工作，把入参出参之类的描绘一下，有些地方标标要点，由于有些人真的不怎样会看文档。
接口规划的时分必定要和相关的同学对齐，不要怕花时间，后期改接口，是一件很苦楚的工作。
6.5.异常处理
- 体系中的不确认异常，进行一致处理，呼应“Network Error”
- 埋点异步发送，不影响首要功用
- ……
老三说：异常处理也是需求考虑的地方，哪些异常能够吞掉降级，哪些无法处理，怎样给客户端展示，怎样打日志，都需求考虑。
七、危险评价
老三说：其实每一次上线都伴随着危险，从规划，一直到上线之前，都要对存在的危险进行评价，上线了要要点调查危险点，也要提前规划好回滚或许处理方案，一旦发现不对劲，及时回滚和处理。
7.1.已知危险
- 对数据相关服务压力较大，用户分群、用户画像等数据服务崩溃危险
- MQ存在堆积危险，导致用户收到音讯推迟
- QPS较高，数据库CPU飙升危险
- ……
7.2.或许危险
- 场景类音讯推迟，或许会影响买卖相关流程，拉低转化率和成交率
……
八、测验主张
老三说：需求评定阶段、规划评定阶段，最好都拉上测验同学，测验同学要对全体的功用，还有功用，都有比较清楚的了解。可是啊，假设只看功用的话，或许便是表面的点点点，具体完结逻辑，仍是开发比较清楚，所以说给测验同学提一些测验主张，给测验的测验用例提供参阅。
一起，我个人觉得，从测验的角度进行考虑，也能有效削减写代码的bug。
8.1.功用测验
| 功用 | 测验过程 | 预期成果 |
|---|---|---|
| 守时音讯发送 | 创立守时音讯 | 音讯守时发送 |
| …… |
老三说：这一部分根本便是结合规划方针的完结功用，列一下测验过程和预期成果
8.2.功用测验
- xxx接口压测，预估单机QPS1000
这一部分根本便是压测了，很多时分，体系的压测没那么简单，尤其是链路长的时分，压一次都得兴师动众。
九、上线准备
- 运维建立环境
- 数据初始化
- 添加装备
- 音讯行列创立
- 依赖服务上线
- 服务上线
老三说：这一部分算是上线的备忘吧，有些wiki类的工具，支撑在文档里建使命，把上线前需求做的工作列出来，有不知道你经历过“测验环境猛如虎，上线一看原地杵”没？或许便是上线准备没做好，缺了什么，少了什么。
十、评定及定见
| 评定定见 | 提出人 | 提出日期 | 处理定见 | 处理人 | 处理日期 |
|---|---|---|---|---|---|
| xxx接口需求考虑一下兼容性，主张xx字段，从object改为list | 老六 | 2023年1月1日 | 修正字段类型 | 老三 | 2023年1月1日 |
| …… |
老三说：规划文档不是写完，啪，丢出去就完事了，还要上规划评定会，评定的时分，通常相关同学会提出一些评定定见，这些都应该记载下来，处理完了之后，再次评定，直到评定经过，然后就能够开端CRUD了。
好了，看完这个模板，想必你对技能规划也有必定的认识了，老三实际上没怎样触摸过用户运营相关的东西，所以内容我们随意看看，首要看模板。
当然模板是相对固定的，可是规划是灵活的，做技能规划的时分，也不用拘泥于固定的方法，依据具体的需求，考虑到需求考虑的点，能做到规划指导开发就够了。
那么，假设你已经能做好技能规划……
可是——
老板：三某，这个需求，三天能不能搞定？
老三：或许不太……
老板：这个需求很急，并且我不能不急，你懂我的意思吧？
老三：没问题，三天够了！
并且——
老板：呦，三某的文档写的很清晰，代码也很高雅，今年公司绩效欠好，找个实习生把他替了吧。
……
参阅：
[1].用户运营：触达体系应该怎么建立:www.woshipm.com/user-resear…)
[2].一个实时精准触达体系的自我涵养:/post/684490…
