博信信息网小红书-2022冬奥活动总结
引用自产品文档：
结合冬奥营销节点，抓准冬奥期间国民对于冰雪运动的高关注度，主打小红书的内容差异化优势，在11月底-2月初期间，产出一系列品牌传播物料，并进行线上线下的整合营销活动，对外构建“玩冰雪，上小红书”的品牌认知，提升运动垂直人群对小红书的好感度，全网用户对小红书运动的认知度。
二、技术实现
(以下只提一些有意思的点，而不会全盘介绍整个技术实现内容，纯业务内容也没啥好介绍)
1、总览1.1 技术调研
确定某些功能设计能否实现、如何实现、耗时多少。比如要在app端搞个冬奥活动的挂件，因为当前没有现成或者类似的，所以就要和客户端团队聊聊能不能实现。和依赖方确认，能否抗住冬奥带来的新增流量。比如冬奥活动页面需要查询笔记信息，那么需要和笔记团队确认，新增的这部分活动流量能否支撑的住。1.2 技术方案设计
在这个环节，需要很细致的把所有需要开发的功能点都罗列出来，针对每个功能点，需要：技术实现方案、流程图、风险点等等。
之所以要做的这么细致，主要原因是活动很重要，所以务必要把该考虑的地方都考虑到，避免开发中返工耽误进度，或者上线出问题；次要原因则是，在技术评审时，众多大佬在场，不能出纰漏。
1.3 技术评审
这个环节就是众多大佬在场，一起审验你的技术方案是否完善，风险点处理是否妥当。
在评审之前，技术方案最好就要做的完善点，到了评审上，就基本不要出问题了，毕竟大佬当面，留下坏印象可不好。
1.4 资源评估与保障
自己：评估下qps大概是多少，需要多少机器资源依赖方：mysql、redis等存储服务：具体到每个sql和操作指令，数据量是多少、qps是多少，需要申请什么配置（是否使用读写分离，要多少实例等）第三方应用服务：冬奥流量下，需要增加多少机器配置才能扛得住因为临近春节，一来大家都在做活动，对于云服务器的需求比较旺盛，二来因为过年放假，云服务的人也放假去了，所以量大的机器资源要在过年前提前敲定好，最好不要临时去采购。
2、监控2.1 业务指标监控专门建了一个报数群，定时播报业务指标信息，样例如下：
奖品兑换情况：
抽奖券: 前15分钟兑换x, 总兑换：xxx
数字藏品: 前15分钟兑换x,
为什么要专门创建一个群，在群里播报消息，而不是给每个人单独发消息？
主要是因为，如果对于数据有问题，那么相关人员可以直接在群里就地讨论，但是给每个人单发消息的话，就没有这么方便了。
2.2 技术指标监控需要监控的技术指标，比如每个表的数据量、接口qps等等
这个直接私发给所有开发人员的，示例如下：
[2022-02-21 00:05:01] 数据库表数据量统计
--olympics_xxxx: xxxx
--olympics_xxxx: xxxx
--olympics_xxxx: xxxx
[2022-02-21 00:05:03]
主要作用是为了在技术侧，对业务发展进度心里有个谱，防止出现业务发展太快，当前的技术设计无法支撑的情况。
次要作用，则是做汇报的时候挑些好看的数据装逼用（装逼是人类的永恒需求）。
2.3 数据逻辑巡检主要作用是校验数据逻辑的正确性，及时发现问题并修正，比如检测用户账户的碎片总额，与任务完成明细是否匹配等。
示例如下：
[2022-02-21 00:41:41] 累计获取碎片数与任务完成明细不一致的用户数:xxx
用户采样:[xxxx]
(ps：实际业务运行中，这个数据逻辑巡检，确实也发现存在数据不匹配的异常情况，还好影响范围不大)
2.4 异常监控在关键逻辑（比如任务完成入账）出现异常时，直接企微消息发送异常信息给相关人员（不过要控制频率，不要就成信息轰炸了）。
主要目的，是为了在关键逻辑出现异常时，能更快速的感知并排查、修复。在实际业务运行过程中，也确实发现了一些奇奇怪怪的问题，还好影响都不大。
示例如下：
冬奥活动异常通知:
--异常类型:xxxx
--异常次数:xxxx
--异常信息:xxxx
--上次触发异常时间:yyyy-MM-dd HH
版权声明
本文仅代表作者观点，不代表博信信息网立场。
作者文章
- 拨号VPS需要手动换IP吗？ 1年前 (2024-06-25)
- 如何搭建VPS远程拨号服务器？ 1年前 (2024-06-25)
- 如何为拨号VPS搭建最佳代理？ 1年前 (2024-06-25)
- 如何利用VPS进行拨号连接？ 1年前 (2024-06-25)
- 日本VPS拨号动态IP：解锁网络新境界 1年前 (2024-06-25)