唔，突然就年中大促了啊

唔，突然就年中大促了啊

5月26日晚8点，618第一波预售活动正式开始，虽然各家都在紧锣密鼓的准备这个年中大促，但说到底活动的玩法、套路营销手段都是市场部等业务方制定的，作为技术人，究竟在大促活动中承担一个什么样的角色？以及大促活动究竟能带来什么改变，确是值得我好好考虑下的。

大促状态下的业务与技术

对于电商业务，既然有大促活动，肯定就会有日常状态，那么大促和日常究竟有什么区别？

相较于日常零碎的需求，大促的需求会更成体系，理想状态下，日常的需求基本上是各个产品经理在自己的盘口里反复横跳。搜索类的产品日常情况下只会提搜索相关的需求，推荐类的产品只会提推荐相关的需求。一旦到了大促，就需要各个盘口相互合作，以内容业务为例，往往是供给、用增、消费、搜索、公私域等盘口的联动，这时日常可能需要2-3个人日的需求就会变成可能需要40-50人日的团队作战。

由于业务需求更成体系，对于技术来说，就需要让整个迭代流程更加合理，无论是方案设计还是人力分配，这就很考验技术PM的经验与能力了。几乎所有的大促需求的时间是倒排的（大促开启时间是确定的），开发时间是十分有限的，因此一开始就要做足准备，可能涉及的上下游通知清楚，模块的边界划分事先明确，临时方案与通用方案的抉择，这些都是和日常态的区别。

也正是因为这些区别的存在，对技术也有着和日常不一样的要求。

全局意识

刚才说了因为需求更成体系，所以技术设计方案的时候也要更加合理。而想让方案更加合理就需要技术能真正的理解整个活动的玩法是什么样的。甚至可以说，技术应该要做到比业务更加了解业务（毕竟写代码的是技术不是业务）。只有做到这一点，才能真的站在更高的维度去看整个需求，才能知道如何规划系统，如何对齐资源，如何梳理上下游依赖关系，哪里可能会有坑，风险会在哪。

更加高效

对于一个技术团队来说，一个很重要的指标是效率。如何提高整个团队的效率是每个领导者需要关注的问题。现阶段我也只是一个大头兵，如何提高团队效率暂时不是我的命题。但有一点是确定的，只有团队里每个人更加高效了，整个团队才会更加高效。因此，如何在技术开发中变得高效就是每个技术人应该探索的命题了。

工具

首先是工具的使用。这里的工具不单单是开发工具，也包含一些效率工具。对于人类社会来说，生产工具的进步标志着生产力水平的提升。生产力最终是通过生产工具在人的作用下转换为产品的。这是生产过程必不可少的一环。

落实到每个人头上，最直观的表现就是一个好的工具可以给你节约非常多的时间。你现在还会使用netbeans去开发Java吗？

在这次618大促的开发过程中，有几个工具极大的提高了我的工作效率。滴答清单的子任务、语雀的小记、mindnode的脑图等。开发工具就更多了，首当其冲的肯定是idea，排查问题的Arthas，以及一众集团内部的工具与平台。

熟练的基本技能

正所谓技多不压身，多一项技能，在关键时刻往往会救你一命。

不熟悉git命令，怎么快速解决冲突？不熟悉jstack命令，如何快速定位问题？arthas命令不会用，怎么抓包排查问题？

为什么会出现OOM？为什么机器的线程数飙升？为什么机器会被限流？频繁ygc和fgc会给整个系统带来什么后果？在准备面试背八股文的时候大家都烂熟于心，但只有真的在现实场景下遇到才会意识到这些平时记得八股文是真的有用。

在掌握了一些技能与工具之后，如何沉淀出排查问题的方法论就是一个值得深究的命题了。哪些问题可以用什么工具排查，可以用什么方案解决，这些就要靠平时的积累了。记得多请教周围的师兄。

时间的合理分配

这就要说到另一个需要好好探索的命题了。如果单位时间内能做的事情已经到上限了，如何让一段时间里做到更多的事情？也即如何实现全局的最优解？

对于这种情况，我们可以将一些计算机科学的理论落实到实际生活中。

我们通常不喜欢被打断做事的节奏，此时如果把人比作一个计算机，那就是一个单核的计算机，这时你要做的就是不要频繁的切换上下文。

同样的，如果你只能做到单线程，做什么改进才能提高效率？一个很好的参考就是NodeJS的异步I/O模型。

有了这个输入，不妨考虑一下怎么把消息队列的生产者/消费者模型运用到人际交往中。

自1945第一台计算机诞生以来，为了让计算机拥有更高的效率，每年有无数的人才前赴后继投入到计算机科学的发展中，在更快更强上，计算机是多少天才智慧的结晶，可谓是提高效率最好的参照物。

更加健壮

代码

虽然做科研的一直流传着“凡是能靠怼硬件拿到结果的，就别做程序优化”的言论，但到了工业界，还是需要考虑成本的。无论多复杂的系统，都是靠一行行代码实现的，因此如何让系统更加健壮、稳定，最原子化的代码健壮一定是必不可少的。为了让VSCode拥有最高的运行效率，其开发团队几乎没有使用什么开发框架。虽然在现实场景下，我们的业务代码可能并不需要这么高的效率，但是清晰的逻辑、边缘case的全覆盖仍是我们该考虑的问题。

将代码写得像诗一样优雅应该是每一个技术人追求的目标。

架构

代码写的优雅，执行的高效，下一步就应该就是如何让架构变得更加合理了。

虽然“没有什么是靠增加一个中间层解决不了的”，但增加了一个中间层，虽然减少了耦合，却也意外的引入了一个不稳定因素，尽可能减少无用的依赖，合理的选择中间件，减少系统潜在的风险，DDD似乎是一个比较好的选择。

但是「没有银弹」也告诉我们没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性。因此架构的抉择本质上是一种取舍的艺术。

监控/预警

不存在没有bug的系统，只有还没发现的bug。如何做好监控与预警，如何实现问题的溯源、现场复原、快速响应在大促中尤为重要。

如果涉及权益、资产，对账监控怎么做？面对灰产、盗刷，怎么快速报警？面对大促时的尖刺流量，技术如何快速响应？真的出现问题，是止血还是启动应急预案？这些都应该是在大促开始前就要考虑清楚的问题，只有这样才能临危不乱。

（当然最好就别出现危险情况，325警告⚠️）

前台体验

对于一个toC的业务，就算真的系统出问题了，也不应该让用户感知。

以抽奖这个场景为例，如果抽奖QPS过高，导致服务端限流了（或者其他的什么原因导致服务请求失败），是告诉用户「前方道路拥挤」合适还是「很遗憾，未中奖」合适？答案不言而喻。

这里说一些题外话，从2021年开始，仿佛刮来了一股用户体验的风，各个头部产品都开始卷体验了，虽然这对于消费者来说确实是一件好事，但也从侧面反映了一些问题。如果不是真的没有东西可以卷了，谁会没事做去卷用户体验？（不过看起来天猫还是没学到教训，这次的活动又是复杂的很……）

更加乐观

做大促，真的会让人抑郁。尤其是在如今这种大裁员的背景下，外面人心惶惶，内部歌舞升平，似乎互联网马上就要完蛋似的。可说到底，大家追求的不过是碎银几两，乐观面对总好过日日碎念。