一次大促项目的生与死

前言

自从每年的天猫双十一成了商家和剁手一族的狂欢节，大促也逐渐成为各大电商的常规操作。一次大促既是商家和剁手族的狂欢，同时也是一场包括运营、产品、技术、销售、法务、UED、风控、客服大规模的团队协作。这里我主要从工程师的角度来带大家一窥这项超级大工程，主要是谈一谈我自己的一些看法和经验，当然我的经历和层级的有限性可能存在一定的偏差。

项目管理

在这样一个各类人员纵横交错的协作系统中，各方人数几百、上千、甚至是数万人，在一到两个月内为了那一两天的成功一起努力，项目管理的好坏很大程度上决定了项目的成功与否，因此在内部阿里对大促的项目管理也非常重视。

其实在阿里内部没有严格意义上的PMO或者项目经理这个岗位，当然也可能是我接触的部门没有。每个项目会有专门的Project Manager(简称PM).每个项目的技术PM通过周报来汇报项目进度，但是并没有管理上的关系，项目里的成员还是向原有的团队向上管理。

阿里的内部并没有非常专业的项目管理工具来完成这个事情，因此每个PM一般都会用自己的项目管理方式来进行项目推进。项目管理其实是个非常个人化的事情，每个公司和每个团队在长期的实践中都会形成自己的一些经验或者潜规则，这里不过多讨论。

需求收集

在确定了总的技术PM、运营PM、产品PM（包括执行PM）后，运营内部会根据每次的业务目标划分子PM，每个运营也会产出自己的目标并给出对应的玩法，之后运营会向PD提需求，PD内部同样会有各个子PM。在PD整理完具体的需求后，会统一把需求转给技术执行PM，这时候技术根据不同的需求不同团队的职责范围来划分技术子项目PM。

阿里的技术PM有个特点：重后端，因此导致很多的技术总PM一般都是后端，虽然前端、客户端也有自己的PM但一般都是后端的PM来做总负责。

需求收集会有一个开始时间，同样的也会有需求收集结束时间，在结束时间后技术很大程度上就不会再允许提新的需求了，特别是在做完技术评审和资源确定后，只有经过各方邮件同意后才允许需求新增和变更。

我个人认为这是个非常重要的措施，因为运营总是不满足的，运营百分九十是在做“不靠谱”的事情，某种程度上他们是在试错，所以总是倾向于更多的需求和变化。没有这样的措施PD和技术很大程度上就会陷入慌乱中。

需求评审

需求收集完成之后，PD会拉上需要协同的各方开会进行统一评审。需求评审在我看来既是各方对需求达成共识的过程，同时也是风险管理中非常重要的一步。不管是作为开发还是子项目PM，我在这个阶段都会非常小心，因为不合理或者有误解的需求很容易在项目后期造成非常大的风险。

很多人觉得PD、运营、技术存在着很多的矛盾或者冲突，然而阿里的风格给予了技术很大的空间和权利，那就是技术只要给出合理的说明就可以拒绝需求。这就造成了一个多方博弈的局面，运营必须要拿出足够的业务目标诱惑力才能说服开发同学投入更多的时间。所以提需求的人一般要求能够给出具体的业务目标，比如购买用户比上次大促增加20%，同时还要说明怎么实现这个增长，有哪些逻辑和资源可以实现这个增长。

对于各方的疑问、没能在现场解决的问题、需要会后去解决的行动点会有一个人专门来记录会议纪要，然后在会后通过邮件发出来跟进解决。

会议要达成的共识：业务的具体目标、需求的具体功能、功能的优先级等

技术设计与评审

每个技术团队在每次大促中基本都有自己的技术目标，可能是完成基本的功能支持就可以了，也可能是在支持功能的同时沉淀出自己的系统以便下次大促不需要重复建设。这个技术目标取决于工程师和自己主管的沟通，当然也会受PD和运营同学的影响。不同的技术目标下产出的设计方案是不一样的，因为有些团队负责的是非常业务化的东西，短时间内没法既满足业务需求又沉淀出自己的系统来。这时候就需要从成本、质量、优先级等等各方面做考虑。

做完技术设计后技术PM会拉上前后端、客户端、测试、算法等各方同学进行一次项目总体技术方案评审，各方在对接方案上达成一致，并且跟各方确定大概的排期。

大部分情况各自都会自己先进行内部的技术方案评审，比如我一般都会在需求评审之后花一天的时间来进行方案设计、产出基本的设计文档，然后拉上团队内的同学进行技术方案评审。这过程我认为是非常必要的，这不仅有利于提升方案的合理性，同时也让团队内的其他内在系统的未来发展上达成共识，便于在人员变化的情况下更好的交接系统。

如果涉及到视觉和交互的变动，在技术评审之前一般都会进行视觉和交互评审，这也让工程师有一小段时间来进行方案设计和排期。

资源排期

需求评审后运营及产品会给出自己的期望上线时间，至于能投多少人或者时间到一个项目很多时候不是某个工程师能决定，而是需要根据你的主管和业务的主管在这个项目的重要性有多少共识。

在这个阶段我如果仅仅只是工程师，那我可能只会把自己工作量评估出来，然后和主管沟通看什么时候投入、投多少时间进去、是不是要砍需求等。而如果作为项目的技术PM，则需要跟进各方的资源评估（前端、客户端、UED、测试），要求各方在什么时间节点给出自己的资源评估，收集完各方的资源评估后整理出最后的时间，并和运营、PD进行沟通是否能接受。如果业务方不能接受一般都会让他们跟有资源问题的主管沟通，沟通后可能是增加投入，当然
也可能是把部分优先级低的需求给砍掉。

正式立项

各方在口头上达成一致之后技术PM一般都会拉上各方人员进行正式的项目KO。确定项目成员及分工，在排期上达成一致，业务方给出明确的业务目标，技术PM预警可能风险。会后发出项目立项邮件，不然后面很容易扯皮。

研发

这个过程中可能会涉及一些需求的变更、资源投入的临时变更等等，对于仅仅是开发的同学可能就是自己的时间管理，但这个过程其实非常考验项目的技术PM的沟通能力和协调能力。

我个人的感觉这是个非常心累的过程，不仅要完成自己的开发任务同时也要参与到各方的扯皮中，非常考验协调能力和向上管理的能力，任何时刻都可能会有突发的问题想你袭来。

风险管理

虽然可能我经历的项目还不足以谈项目风险管理，但我个人认为风险管理在项目管理是至关重要的，决定了项目的质量和生死。

我自己的经验是划为几块：需求风险、技术风险、人员风险、资源（市场、流量等）风险，比如需求风险在前期需求评审就显得尤为重要，研发中的需求变更一定要经过多方同意并抽送变更邮件不要私自答应某一个方。

需求变更、技术风险是遇到比较多的两类，业务方在运营策略上总是存在变化的，技术风险主要来自于有部分同学是第一次接触对应的系统或者第一次开发大促功能在方案设计上存在一定的不合理性。

人员风险和资源风险都相对较少，一是同事都比较给力二是在阿里如果你答应了别人的事情没做到别人会对你甚至你所在的团队有看法。

这里谈下我自己的经验：1.不管是那一类风险作为技术PM一定要抱着积极的心态去和各方沟通积极的去解决问题；2、风险的发现很多时候不在于你自己，而在于执行者，所以要每周和执行者进行沟通进度和风险；3、不要害怕向你的主管或上一层的技术PM反馈问题和风险，他们作为管理者很多时候并不怕有风险而是怕有风险没人提出来，作为管理者往往他们的出面会带来意向不到的效果；4.在沟通协调的过程中要多站在对方或者项目目标的角度来思考问题，和稀泥其实没什么用。

具体的做法：1、设定每周的短时间的站会，各方人员简单沟通进度和风险；2、利用吃饭、偶然的碰面向主管、协同人员沟通风险和进度；3、每周技术PM都要发项目周报，周报包括整体的项目进度，各个线的项目进度，同时要给出风险预警和应对的措施；4、多看各方的（包括运营、产品）的周报便于了解对方的进度，并保持沟通；5.对于出现风险的任何一方一定要让对方明确的给出风险应对方案和解决时间。

功能测试

在研发进行的初期测试同学一般都会给出具体的test case，并和研发、PD一同确定合理性。而在正式的提测之前，测试同学还会给出一系列主要的test case，只有通过这部分test case之后测试才会投更多的时间来进行测试，这个就是内部称的“冒烟测试”。冒烟测试更多是为了减少测试的成本，防止反复的提测。冒烟通过之后才会正式进行测试，测试会通过内部工具向对应的研发提起bug等。

在这个过程中如果是项目的技术PM就要多和测试同学沟通保持对测试进度的了解，当出现有研发同学修复缺陷不积极的时候要适当提醒，出现严重拖延的时候也不要怕向上反馈。

在测试阶段要在项目周报中把测试进度体现出来，并预警测试进度的风险。

功能预演

预演是为了最后确认需求的实现的还原程度，也让管理者对具体的功能有更多的体感。预演功能的选择主要是项目的PD、运营、研发、测试根据重要性共同决定，并不是每一个小功能都进行预演。

一般的功能预演都是基于测试数据进行，并让测试同学进行操作，这主要是考虑到测试同学作为第三方使用者更有利于还原用户的操作和边界条件。

上线

在功能预演之后测试还会进行最后的回归测试，这个过程可能会经历日常环境、预发环境，之后发布上线。
由于大促功能的特殊性，很多功能上线并不是上线了就开放给用户，所以这个过程需要开发自己做好兼容，不要影响当前的功能使用，也不要让用户提前看到大促的功能。所以发布的时候研发要和测试沟通要回滚的方案，不要影响线上用户。

压测

可以先看看我的另一篇文章《大促压测我们在干什么》

大促的瞬间激增的流量对软件系统的挑战是非常大的，这也在系统的稳定性、可用性、性能上提出了更高的要求。

功能压测

功能压测一般都是单个项目或者单个功能内部的压测，

全链路压测

整个上下游的核心链路压测

性能优化

根据压测的结果和评估出的流量进行优化，首先要要做性能分析判断出性能瓶颈在哪里，分析的过程是一个非常复杂的过程，阿里内部相对完善的工具来进行性能分析。我个人的经验是很多的性能问题虽然是某几代码的问题，但大部分是架构设计上的问题。Full GC的性能问题是我遇到过的最难的，很多时候定位相对困难。

定位出性能瓶颈之后优化则相对较容易，优化之后再次压测即可。

更多内容请看《大促性能优化我们在做什么》

预案

预案不仅是大促不可缺少的一环，一般大促预案分为前置预案和紧急预案。

前置预案主要是为了保证在大促峰值时系统的稳定性和性能提前做的开关预案，比如阿里在大促开始前一天会把离在线混部关掉保证离线任务不会占用在线服务的资源，还有调整系统的日志级别避免频繁的写入。前置预案一般都是无损的，在预期内的，用户是无感知的。这种预案一般通过提前预置一些开关来完成，阿里内部有专门的预案中间件和平台辅助。

紧急预案则在流量远超预期或者链路中的某些系统出现问题的时候执行，比如洪峰把某个系统快压垮了就需要降级或者限流，目的还是希望不要造成雪崩快速恢复系统保证核心功能的正常。往往紧急预案是用户可感知的，比如去年双十一物流地址无法更改的问题。

一般我们都会用脑图列出预案的明细（包括链接等），然后共享给整个技术项目组，方便在第一时间操作。预案的执行一般都会double check和上下游通知、主管审批等避免失误

预热、爆发

预热阶段和爆发阶段要通过监控系统关注系统的各项指标包括流量、性能等等，出现问题时随时准备修复和预案执行。

很多时候当问题来临的时候再处理已经来不及了，特别是大促这种峰值流量非常高的情况下很容易造成雪崩。所以在全链路压测上要多下工作，做好各种准备工作。

复盘

大促结束休息一两天后，就可以进行复盘了。复盘既是总结也是为下次能做得更好积累经验。
复盘一般分技术复盘和业务复盘，不管是技术还是业务复盘从上到下，从项目组到团队都会进行自己的复盘。对照自己设立的技术目标和业务目标进行，分析大促做的好的和不好的，并给出下次改进的措施等等。

复盘不是口号，而是需要数据支撑的，买家提升了多少？性能提升了多少？投诉降低了多少？等等

我自己一般都会产出一些文档和ppt，记录一些数据和问题，方便下次大促使用。

小感悟

大促其实非常考验人，特别如果你是核心开发或者技术PM,不仅要操心自己开发任务还要各种协调，每天会有各种各样的问题向你袭来。大促提升你自己的同时，也会让别人对你影响深刻。

虽然经过很多次大促，既在里面担任过开发，也当过一些项目的技术PM,然而非常遗憾的是在阿里的这几年，其实我并没有真正经历过双十一的交易和主会场的那种几十万笔交易的刺激考验。算是一种遗憾吧！