技术之外你能够做什么？这是我经常自己问自己的一句话。
不能说卖老，自己也参与了很多大型项目的数据迁移，数据升级和维护工作，从参与进来到主导迁移维护，从技术方案的敲定到最后落地，中间还是有很多的事情和经验需要总结。
每次看起来很简单的操作，如果出了问题那可是很紧急的，比如我在一次迁移中，就是做一些数据类的变更，一个rename表的操作竟然提示失败，在升级的大晚上，众目睽睽之下如何应对。我们在测试环境做了演练，但是在生产环境还是会碰到很多意外的情况，这个时候就得冷静下来，先尽可能把其它的变更都做好，然后再来分析这个问题心理上就有了优势，处理10%的问题，和卡在了10%的问题上给你的心理压力是截然不同的。当然最后发现是因为生产环境中的物化视图日志导致。
要说我印象中最深的一次大型维护项目，真是惊心动魄，迁移演练了不下三次，但是实际数据库升级的时候还是碰到了很多意料之外的问题，比如ORA-00600错误，有限的时间内处理这些问题还是很有压力的，我们很不幸碰到了Oracle的bug,在凌晨准备补丁，但是很不幸补丁竟然没有解决当前处理的问题，所以虽然99.9%的工作都完成了，但是有一个操作总是会抛出ORA错误，就因为这一点，全套的核心系统差点都回退，那个时候我真是心急如焚，打电话找行业的朋友来看，最后把电话打到了以色列总部，那头的首席专家给的几个解决方案都不奏效，时间一点一点过去，我们离回退的时间越来越近，记得那一次处理问题的时候，身后围了至少十多个人，还是客户的高级领导。经过一番努力，问题总算解决了，而解决方案可能就是一个SQL语句，一条命令，无论如何算是化险为夷。
要说让我最无奈的一次数据回退，那是一次数据迁移的项目，DB层面所有的准备都到位了，但是迁移的时候IO使用率上不去，CPU使用率上不去，结果最后迁移的时候时间点超出了预期的时间范围，无奈直接做了回退，多少年来第一次迁移项目做回退，对我们产生的影响是很深远的，而且问题的矛头指向了数据库层面，经过定位最后是存储的原因导致，但是我的技术方案也收到了Oracle原厂的挑战，因为还没有这一类相似的技术方案，所以在某种程度上而言，我和我的团队都有很大的心理压力，在后期我们一次一次的调试，拍错，总算找到了瓶颈所在，排除了存储和系统层面的问题，迁移工作就很顺利了，这样一次两次，三次，迁移都很顺利，而这个过程中的收获我觉得是最大的。记得当时我和团队做迁移的性能测试，大晚上3点多到了酒店，一个朋友到泰国来玩，看着我还在琢磨如何优化，他无意中说了一句，这么做，应该没有做不成的事情。这句无心的话成了支持我继续努力下去的动力。
技术方案之外，其实我们感觉自己能够做得事情很少，感觉所有的事情都准备好了，就差那临门一脚，如果达到了这样的状态，不妨换点角度来，我觉得一个就是信念了，我有一个不成文没有任何依据的做法，那就是大型迁移项目前都会去超市买瓶饮料，喝不喝是一回事，但是买了之后心里会踏实些。记得有一次我睡得晚了些没有买，结果那次的迁移就非常艰难，就是数据回退的那一次，虽然从科学的角度来说两者没有关联，但是从心理上我觉得是对自己的一点安慰吧。
我入行不久的时候，记得有一次我们的总监说道，他们在打标一个项目，感觉所有能做的事情都做了，实在没有其他可做的了，最后还能做什么呢，他就去庙里默默上了一炷香，许了个愿。
这里我不是在宣扬一些不合适和迷信的想法，我只是想告诉大家，技术方案之外，我们还能做些什么，其实就是最大程度上给自己的一个安慰。
今天又是一个不眠之夜，数据迁移的任务很有挑战，相信今晚的升级会一如既往的顺利，成功。
