案例背景：
今天一大早用户打电话来讲昨天上传的银行的forex payment return file好像没有被处理到，我一听就觉得纳闷，因为昨天晚上operator也没有给我打电话啊（如果有job failure的话，operator会电话通知 officer in charge）。想到事态可能比较严重，所以我立马放下手里的工作，开始紧急处理这个问题。
首先，我去查昨天晚上的job process， 确定相应的 job 没有被trigger， 所以肯定用户所提到的文件确实没有被处理到。
其次，去查文件是否有被传送到unix server 和windows NT server，很快确定文件存在NT server但是没有到达unix server。说明：用户以及外面其他的系统会把文件（voucher，journal等）SFTP 到NT server， 然后在晚上的时候所有的文件会再被FTP到unix server 做处理。到目前为止，初步怀疑是FTP的job 出了问题，在查看FTP job log 后确定问题发生在这里。
到目前为止，我们知道发生了什么问题，那就是昨天晚上所有的文件都没有被处理到，而且有的文件可能已经被新的文件覆盖掉了，所造成的影响是部分付款延迟一天，以及journal晚process一天，asset晚create一天，等等，当然，还有一点是我们的user会收到很多投诉。
跟PM阐明事态严重后，赶紧召开紧急会议，商讨如何应对。我的主张是：
1.告知用户现在有这个问题，以及我们即将采取的措施。
2.所有的文件应该赶紧transfer到unix server， 在确保文件传送无误的情况下把所有的文件 （voucher， journal，bank return file 等等）先process 处理到一定的阶段， 这个过程可能需要4-5个小时。
3.获取SFTP log， 找出那些已经被覆盖（overwriten）的文件，通知用户重新传送过来。
4. 我们必须采取紧急措施，在下一个batch开始之前（晚上8:30）完成所有的recovery action。
有个风格非常细心的同事提出了很多假设性的问题（what if ....），而且提议先拿到文件，分析后再做决定。最后都被我们否决，因为在这样紧急的关头，确实没有那么多的时间给你去讨论，让你去分析，因为时间拖的越久，所造成的影响越大，而且，可能会影响到晚上的night batch，并且，那些假设性的问题发生的概率几乎是微乎极微。最后的事实证明，我们的策略是对的，所有的文件在预定的时间内完成，后面需要面对的，就是用户的刨根问底了。
感悟：
在处理情况的时候，究竟是应该很周密的想到每一种情况还是应该当机立断快刀斩乱麻这完全取决于在什么样的情况下，如果是要设计／更改一个功能，这时候你有足够的时间，那当然是需要很仔细的想到每一个情况，即便发生的概率微乎其微也应当考虑进来，但是如果问题是需要马上就解决的，恐怕就由不得你在哪里深思熟虑了，因为，时间不等人，事故不等人啊。当然，当机立断的前提是你要对整个事件（系统内／系统外）有足够的理解，对自己对解决方案有足够的信心。
