2014年12月31日，人们还沉浸在辞旧迎新的气氛中，微信上还在互相发着红包，微博上突然出现了上海外滩踩踏事件的消息。这个事件突发而至，36人死亡、47人受伤的结果，让我们在2015年的第一天“新年快乐”这几个字说的有些有气无力，消减了许多喜庆气氛。
踩踏事件在我国已经发生过多次，上海发生过，北京也发生过，就在十年前，也是辞旧迎新的日子，北京密云也发生了踩踏事故，也是三十多条人命的代价！
踩踏事故不能列入天灾，在法律上可以找到责任人。我国《突发事件应对法》中明确规定，县级或者省级政府机关应该制定应急预案应对突发时间，并且应该对危险源进行调查、登记、监测，必要的时候进行预警，并采取临时措辞，直至启动临时预案。
虽然事故发生的原因仍然在调查之中，但是调查的重点我们不如预测一下，大概有这么几个：当地政府有没有制定应急预案，有没有根据应急预案采取相应的措施（很多情况下，应急预案只是供领导检查的摆设，却没有实际用途），包括有没有预警、有没有限制人流等等。
由此让我联想到，在我们的工作中，对于我们开发的一些重要应用系统，当偶遇突发事故，造成的损失虽远不及人命，但后果也常常很严重。如电商项目因订单量大而产生的订单积压，直接影响到订单的生产；再如用户在线进行支付时“邂逅”银行不支持（这种情况往往由于第三方支付公司临时中断了与银行的合作但未通知商户）而不得不中止交易。谁也保证不了开发的系统永远不出事故，谁也逃不出墨菲定律的“魔掌”，凡是可能出错的事有很大概率会出错。泰坦尼克号的悲剧我们都知道。这样一艘汇集当时顶尖技术号称永不沉没的巨轮，却在首次航行时撞上冰山而沉入大西洋。
据说在阿里，有时在晚上拔网线，以此检测系统容灾能力。针对我们开发的软件应用系统，我们也有责任制定突发事故的应急处理预案。首先要具备这个意识，然后要制定，制定好了要进行演练，旨在当突发事故真正发生时，能够立即启动应急处理预案，在最短的时间内通过大家的协作将损失降到最小。即所谓的派上用场行之有效。
我在jd时，研发部门为了保证研发质量，各开发项目组都制定了相应的突发事故的应急处理预案，我也参与其中，并负责收集整理各部门反馈的文档。虽然一再强调宣贯和演练，但各组的执行效果甚微。很佩服当时的OFC项目组，项目小组模拟组内的各个角色以及依赖的上下游系统的对接人，做了实地演练，取得了比较好的成效。
不可否认，中国政府形式主义盛行。转而一想，我们在日常工作中，是不是也在助推这种风气呢？ 莫把应急预案当摆设。