背景
某日上午，小集购买a产品失败，页面弹出“系统异常，请稍后重试”的报错，便联系了技术团队的开发小成。
“小成，我刚刚尝试买了a产品一直显示系统异常，是不是有什么问题呢？”开发小成街道电话后，迅速招收排查，同时也收到了系统监控平台的警告。
小成立刻登录系统应用服务器，发现交易耗时在8s左右。经过一系列紧张的故障排查和恢复工作，虽然过程艰难，但最后还是成功的恢复了业务。
解决过程
【DAY1】
“交易的耗时为什么会这么久？是不是内存资源不足引起的？”
小成立即查看了应用服务所在的公有的云服务器的资源状态，发现服务器的VM系统大量OOM报错，及时重启Tomcat，也是失败。
“是不是有什么业务层的程序大量报错好资源导致？”
带着这个问题，小成继续一步步排查，半小时左右，小成发现合作机构的前置T应用上有大量的Colse_wait链接，应用提示open too many files。大量的Java的应用报错Java。io.IO.Exception: Broken Pipe.
为了尽快恢复业务，小成尝试重启了Tomcat应用，但错误依旧存在，尝试修改open files和max user processes 参数，未见明显效果。小成又再试着在弹性服务器上分别Telent本地端口和对方端口甚至重启了服务器。这贼都无济于事，错误依然存在。
发现这些常用恢复方式不起作用，小成调整思路，看业务平台是不是有问题。果不其然发现应用平台上持续大量业务报错，报错信息集中在产品中心的捞取数据同步的定时任务。
“难道是这个定时任务的数据量大导致的？”
小成确认了当日的定时任务同步数据的任务量级，发现每分钟一万左右，平均每秒（QPS）300~500之间（与日常调用量持平）。
“既然定时任务的量级微变，为什么会大量报错？”
业务恢复争分夺秒，小成申请停掉可疑的定时任务，发现不见效，尝试业务流量切换到备用集群观察。
流量切换后，问题恢复了。
“切换到备用集群竟然可以恢复，难道是老集群的问题？”
想着定时任务还停着，小成建议恢复定时任务，数据同步定时任务在次被拉起。
这时已经过去了近两个小时。虽然切换新集群业务恢复，定时任务也恢复运行，但根本原因还是没有查明。小成开始复盘整个过程，思考各个疑点。
为什么数据同步定时任务会大量出错？虽然报错，为什么切换到新集群会恢复？
这时小成的电话又响起了：“小成，备用集群也出事了！！”
小成脑子快速闪过，“确定是定时任务的问题了”。
小成申请再次停止数据同步任务，经同意后，立即执行。执行后，业务开始逐渐正常。时间已经到了下午。
小成和团队人员赶紧召开紧急复盘会议，基于业务影响可能性的评估，决策业务主链路进行隔离。当天下午紧急对业务链路进行隔离操作，并且在1个多小时内完成业务流量验证通过 。
不知不觉，一下午时间就这样过去了，小成理了理思路，决定把问题来龙去脉理清楚，于是发起了次日集中问题排查的会议邀约，参与人员涉及到多方技术团队。
半晚，小成切夜难眠。
“数据的问题？定时任务那里出问题了？.......”
