根据最近发生的问题来看，更多的情况不是单个问题导致的，而是系统健壮性很差，经常因为一个小问题导致大问题，甚至影响整个网站，因此诊断、解决起来会比较棘手。具体体现在：
1）个别异常未捕获处理。异常一直向外抛，影响系统资源并影响后续处理，累积后更易产生严重影响；
建议结合sonar，修改所有遗漏的异常捕获。【各开发组检查修改】
2）有些超时设置过长。超时过长，容易引起阻塞。
建议就最近发生的问题处，先减少超时时长，并在页面端对超时情况做友好处理；【各开发组检查修改】
3）缺乏事故阻断机制，发生的问题会引起连锁反应。应就一个事故屏蔽在他的范围之内。
建议 a.在服务层面，对调用异常进行合理处理，不要再占用资源并传递错误，甚至停掉异常的服务。【各开发组检查修改】
b.在流量、资源层面，设置阈值进行监控，对有问题或异常的流量、资源进行告警、控制【运维】
4）在可用性层面，对核心服务要有守护程序，多入口，不能因为某个模块问题导致核心服务不可用 【整体】
建议 识别核心服务，如签到任务、充值提现等，可独立运行，并在流量等资源上予以确保，甚至和起相关的登录也予以保障，和其他应用分开。
核心服务、频繁操作的功能可开设多个入口，不止提高用户体验，也保障高可用性；
5）商家首页流量集中，调用过多，容易产生性能问题 【开发组分析修改】
建议 做分流设计。先不谈业务上应将买家和卖家角色分开，在技术方案上，也因进行分流设计。
a.减少不必要的接口调用，不在首页一次性调用
b.对需要展示的数据，是否可提前计算好置入缓存？
c.了解各接口的实现方式，其在性能上是否存在风险，如何优化？如何隔离？
d.是否有些数据可以延迟加载？
6）缺乏压测的考验。目前只有针对单个服务的压测，缺乏综合场景的压测。需根据压测值估算部署资源。【测试、运维】
7）提升监控系统能力，能够快速发现、诊断问题，结合问题3. 【运维】
8）服务器等资源的横向扩展。目前已可人工快速扩展，以后可做成根据实际压力情况自动扩展。【运维】
9）识别刷子和刷的入口，修改被刷的入口，有快速识别和限制刷子的手段，测试最好也有相应的测试机制【运维、风控、开发、测试】