昨天令人难忘，不是因为加班到10点（好几个月没有这么晚走了），也不是回家晚上十一点半才吃饭（当时其实不是很饿，或者饿过劲了），而是在自认做了很多准备工作之后，还是遇到好几件意外，尽管最终算是成功上线，还是感觉很有挫折。第二天早上还要来解决一下，头一天遗留的问题。下面把自己的感受总结一下。
第一条教训就是没有完全按照金字塔原理，排列出所有的步骤，于是造成遗漏。因为是财务模块、直播优化，而财务模块又有好几个部分，包括前端的三个模块、后台、财务，这些模块部署在不同的机器上，有好几出数据库的修改，上线以后还需要操作已有数据，生成新数据后，再导入老数据。这些工作比较琐碎，很容易遗漏，没有完全采用金字塔原理，导致了部分遗漏。
第二条教训就是假定已完成的工作肯定成功，尤其是别人开发的模块。在上线过程遇到两次这样的情况，一次是财务模块的软件包错误的连接了测试环境的数据库，另一次是在倒数据生成新数据的过程中遇到的错误，测试环境成功不代表生产环境真实执行十一定会成功。由于这个教训，自己和团队的人都饿了肚子。
第三条教训是关于跨团队合作，尤其是合作团队本身还有其他任务的时候。这样的项目开发很容易拖延。如果事先计划不具体、关键点同步没有跟上、后期不能跟进同步，任务拖延必不可免。这一条以后要十分小心，在计划任务的时候，一定要考虑这些因素，做好充分的缓冲准备。免的像这次这么狼狈。
第四条已经遇到不止一次的情况，当一个模块一开始问题很多，吸引很多的关注，于是大家的注意力都在这个模块上，这时很容易其他部分的测试与检验。等到真实的生产环境，被忽视的部分模块，很容易爆出严重的问题。上次发生的客户录制失败的情况让我记忆犹新。这次又发生了。就是注意力都在财务模块，结果一同上线的直播优化部分，缺乏必要的测试，导致发生问题。这个问题的解决方法也是要依靠金字塔原理，列举所有模块，避免遗漏，完成所有模块相应的测试、检验。
这两天看完了《基地》这一部小说，内容主要是银河帝国的科学家们带着编辑《银河大百科全书》的“任务”来到银河最边缘星球，开始谢顿的保留文明火种计划。这一部最要讲述基地的形成以及最开始两百年左右时间发生的故事。其实故事是按时间顺序，讲述了最开始五十年、八十年、一百五十年，几个关键的谢顿时刻（谢顿危机）发生的故事。这里的谢顿时刻是指，基地遇到内忧外患的危机，以往的做法无法解决危机，于是基地的人们必须作出改变，采取更理性、合理的做法解决危机，只有一条正确的道路。如果走上这条路，危机可以得到解决，同时基地的整体实力、规模都会上一个台阶。我感觉这种谢顿时刻很有现实意义。大到国家，小到个人也会不断遇到“谢顿时刻”，如果你足够理性、不因循守旧、大胆改变，往往可以找到一条道路，让自己获得提升、同时解决眼前的危机。然后，生活回到平静，直到遇到下一次谢顿时刻。人生就是在这样的循环发展、突破中前进。
