我们绞尽脑汁的来拉新，但是当用户走到门口时，却被我们硬生生的挡在了门外，就是进不来。为什么会出现这种情况？如何规避呢？看玉米大人的血泪史......
昨天救火，今天复盘
昨天是救火的一天，早上还没到公司就被告知，我们的产品挂了，用户无法访问。我们的产品是给内部员工使用的工作台，造成的影响就是大家没法正常工作了。
由于是周一，上海的堵车超级严重，我们的技术伙伴还困在路上；看着用户通过各种方式发来的反馈，真的是捉急啊。但是冷静下来，从产品层面该怎么将问题的严重程度降低呢？用户不能工作，那我们就把大家工作中常用的链接和工具收集起来，整理成文档的形式，通过一层层的组织架构，先下发给大家，解决燃眉之急也缓和大家的情绪。
事故原因：
产品缺陷：由于我们数据库连接数设置的较小，导致大批量用户同时访问时，很多用户进不来。
产品经理失职：昨天（周一）是老系统部分功能下线日，而我记错了日期，没有提前做好大量用户涌入的应急方案。
压测延期：我们是提前申请了压测，但是由于中间各种原因，导致压测延期了，直到事发当天晚上，压测报告才发出来。而这个事件，80%的可能是可以通过压测来规避的。
接下来如何规避：
不要偷懒，交给团队其他人的事，一定要及时跟进，及时要反馈；
跨部门协作的项目，里程碑结点一定要记清；
提前列出可能出现的风险和异常，一定要会上讲，引起大家的重视，团队一起讨论方案，并把方案提上日程；一对一面对面的沟通会被大家遗忘的。
重大项目建议申请>2台服务器资源，记得之前有个前辈也提到说，宁可申请多个小空间的服务器，也不要只申请一个大的服务器；
如果调用外部接口较多，自己一定要做缓存，减少对外部的依赖；
提升产品的可替代性，比如上文提到的静态文档，放在404页面或者其他异常错误页面上， 方便用户遇到异常时，直接下载文档找到替代工具，不至于影响正常工作。
半年前犯的错
时间回到半年前，当时做一个年度账单的活动，也是吃了类似的亏。
在我们推文发出后，大量用户同时访问（10分钟内大概涌入近10万人），服务器撑不住啊，导致很多用户无法访问，硬生生的被挡在了门外。
不仅如此，我们没有将活动和主产品的服务器分开，且由于静态资源（图片、音频等）过大，还没有走CDN，加载过程中把公司的网络资源几乎占满了，直接影响到公司正常业务流程无法访问。
还好技术团队给力，及时修复了问题，不过还是损失很大，不仅主业务单量受到了相应的影响，我们活动也没有达到预期的目标。
给自己的建议
个人定位：
之前我一直觉得，我的定位是偏用户端的产品经理，我只要专注于用户研究，产品定位和机会评估、交互体验就可以了，技术方面有master可以托付。正因为如此，我经常性的被鄙视、被忽悠、被打击~~~
如果真的很难提升技术能力，那就多跟技术团队沟通，把自己可预见的风险和问题表达出来，请技术团队帮忙一起解决；不过技术方面的短板也在慢慢的拖垮我，接下来要恶补恶补！！！！
耐心，相信团队：
我是个急性子，做什么都急吼吼的，就像昨天的事故，我虽然尽力的压制着不去催促团队，但是我的表情和行动还是流漏出各种焦躁。
及时跟进，及时获得反馈
一般技术小伙伴都相对内敛，不善于主动表达；分配的任务，产品经理一定要及时跟进，提前了解大家的困难和问题，帮助团队一起去解决问题和风险；
训练团队集体心流：
硅谷有一种团队合作的思考模型“巴士指数”，就是你的团队里有个关键成员被bus撞了（这个假设让人很不舒服），其他人是否可以快速的补上，这个项目是不是还能完成。
虽然小团队内每个人都是不可替代的，但是可以经常沟通和团队活动提升合作度和默契度，面对单个队员的失误，提升其他队员的补位能力。
关注公众号【零点零壹】 ，和玉米大人一起 每天进步一点点；
网友评论