日本福岛核电站事故分析报告
论软件工程管理常见问题
事件回顾:
当地时间3月11日14时46分,日本发生里氏9级地震,震中位于宫城县以东的太平洋海域,震源深度20公里.地震引发的10米浪高大海啸随后横扫沿海地区.地震发生后,宫城县、福岛县的数所核电站自动关闭。虽然核裂变被终止，但核反应堆还需要数天的冷却才可以完全关闭。而随后而来的海啸损坏了福岛核电站冷却系统的紧急供电系统，导致反应堆冷却系统失效。当地时间3月12日下午15时36分左右，福岛第一核电站1号机组发生爆炸，4人受伤，反应堆燃料可能发生熔化，官方要求方圆10公里范围内的居民紧急疏散，晚些时候将范围扩大到20公里。当地时间3月14日上午11时左右3号机组发生爆炸。当地时间3月15日晨6时10分左右，2号机组发生爆炸。当地时间3月15日11时左右3号机组再次发生爆炸，4号机组起火，造成大量辐射物泄露。到目前为止，日本还在积极处理此次核事故。
看到这些，我们可以说这是一次天灾。但我更觉得这个是一次“人祸”，中间有许多设计和实施上的缺陷，导致此次事故的扩大。由此我想到我们在实施一个大型软件项目的时候，我们也会经常遇到的一些问题，我把它罗列出来，一一加以说明。
1、架构选型
发生事故的福岛核电站是当今世界上最大的核电站，位于日本福岛工业区，由福岛一站、福岛二站组成，共有10台机组，一站6台，二站4台，均为沸水堆，总输出功率为9096兆瓦。福岛一站1号机组于1967年9月动工，1970年11月并网，福岛二站4号机组于1987年投入运行。
简单介绍下核电的知识，核电的核心核反应堆目前主要有压水堆和沸水堆两种。压水堆有两个回路，一回路里的水被核燃料直接加热，然后流到热交换器里，冷却后再流回到反应堆来冷却核燃料，如此循环，不断带走核燃料产生的热。通过热交换器一回路里的高温去加热二回路里的水，使其产生蒸汽来驱动涡轮发电机来发电。一回路里是有辐射性的，而二回路里是没有辐射性的。而沸水堆只有一个回路，核燃料加热的水直接产生蒸汽，直接去驱动涡轮发电机来发电。相比压水堆比沸水堆更安全。
据报道，福岛核电站使用的就是老式的只有一个回路的沸水堆，冷却水直接引入海水。由于只有一个冷却回路，沸水产生的蒸汽用来直接驱动涡轮，一旦发生事故导致回路泄露，蒸汽里就带有放射性物质，而且整个涡轮机也直接与辐射性蒸汽接触，涡轮机结构复杂，环路多，要做到绝对不泄露比较困难，因此泄露事故隐患比较多。
由此可见，由于福岛核电站建设比较早，且选择了相对安全性比较低的沸水堆，为今天的事故发生埋下了隐患。
福岛核电站，可比成一个大型的门户网站，每天要提供数亿pv的访问量，为了能实现7天24小时不间断的运行，需要有一个结构良好，可伸缩的，而且是安全可靠的整体架构。因此在整体选型的时候，要选择安全性高的，可靠的且可伸缩的框架。错误的选择将会给以后的运行埋下隐患。
2、基础建设
世界上有三大地震带：环太平洋地震带，欧亚地震带，海岭地震带。而日本就处在环太平洋地震带上，属于地震高发地区。福岛核电站直接建在靠太平洋的海岸上，外围没有大陆和岛屿的阻挡，太平洋上的台风和海啸直接对其有威胁。从安全性考虑，在福岛建设核电站并不适宜。
对于建设一个大型网站，需要合理考虑机房的位置，比如需要考虑南北互通问题，国际线路访问慢等问题。在建设初级就要充分考虑到不利因素，然后逐一做出合理的对应方案，在建设的时候充分考虑进去，避免日后的应对危机。
3、异常处理
当地震发生后，福岛核电站就主动关闭了核反应堆，终止了链式反应，避免了直接的核反应堆爆炸发生。核电站在建设之初，对于导致核反应堆异常的情况，也增加了紧急停机的处理。
对于一个大型网站，结构复杂，有大量的服务器参于运行，硬件发生故障已经是一个日常要处理的问题。整个系统中有大量由不同层次的人员开发的软件运行其中，编写错误和运行异常在所难免。如果不考虑这些问题，那么系统将在不停的维护中痛苦不堪。
根据28理论，我们所开发的满足业务功能的代码，可能只占我们所有代码的20%，而为了让我们的业务功能能正常运行，去检测和处理异常的代码，可能占80%。如果比作海面上的冰山的话，业务代码就是露出海平面的冰山，而故障检测和处理代码就是海平面以下的庞大身躯。
为了能减少系统故障，提高整体可用性，我们需要一个假设：就是异常状态是一种常态，而非异常状态是一种非常态。开发人员在编写代码的时候，对于任何硬件，资源，甚至是任何一个变量，都要先假设它出现异常时该怎么处理，然后才是正常处理的业务逻辑。
在c/c++语言里的指针为空被调用的情况，是导致宕机的主要原因之一，但可以用一个简单的if语句，就可以检测出空指针，避免系统崩溃，用这个简单方法，使代码的安全性一下提高不少。在java中对象为null而被使用的现象，也是代码崩溃的主要原因，在使用前用if语句检测下，也是可以彻底杜绝此类问题发生的简单办法。
4、地震
导致此次日本福岛核电站事故的直接原因是发生在太平洋海底的地震。
对于一个大型网站，由于规模庞大，可能分布在全国的多个地方，甚至是全球的多个地方，对于每个机房的环境都不一样，即使再好的考虑，也有可能发生比如机房整体故障，洲际通讯电缆断裂这样的严重事故。因此我们需要在建设中考虑这样情况的应对办法。比如可以使用备份站点，动态dns故障切换等来处理。这类处理主要成本比较高，处理的时间比较长，反应比较慢。
5、海啸
在发生地震后，由地震引发的海啸直接冲击了福岛核电站，直接冲毁了核电站的应急发电系统，导致无法给冷却循环系统提供动力，使核反应堆产生的热量不能得到及时的疏散，最终导致反应堆温度升高，压力容器内压力升高，同时产生锆水反应，产生大量氢气，从泄压阀泄露出来导致爆炸，而部分核燃料也被高温熔化。
这次福岛核电站事故最主要的原因是海啸。福岛核电站虽然建设有防7米高海浪的防波堤，但是此次的海啸高达10米，远远高于防波堤的设计高度。事实上此次海啸的海浪还不是最高的，在一百多年前的1896年发生的明治三路地震后的海啸比这次还要高，比如岩手县绫里就有38.2米，吉浜有24.4米，田老有14.6米高的海啸记录，而这些地方离福岛也只有一百多公里。
由此可见，在建设当初，由于种种原因，在防御海啸的能力上考虑不足，导致此次事故在发生后没有及时处理，致使事故不断扩大。
对于我们建设大型网站，能承受的最大访问压力，是我们第一关心的因素。比如突发事件引起的访问流量异常增加，或者由于黑客引发的ddos攻击，都可能引起如海啸般的超大访问压力，可能在短时间内就将网站压垮而瘫痪掉。对于预防此类事件的发生，简单的方法是限制每个用户的刷新间隔，对于明显异常的ip在路由器或防火墙上来阻隔。但最根本的解决是让系统具备动态适应负载大小的能力，也就是具备实时的可伸缩性。
6、核辐射
核电站最核心的是核反应堆，使用核燃料来产生强大的动力，来推动涡轮发电机发电，虽然核燃料威力强大，但是一旦泄露出来，会造成数万平方公里的核污染，对周边环境造成巨大危害，如果不能得到及时的处理，将导致直接反应堆报废。
对于我们大型网站的核心来说，那就是存储数据的数据库了。数据库的可用性，数据逻辑的正确性，是决定网站可用性的最大问题，如果数据库在外在因素的影响下，导致无法使用，或是数据错乱，那么网站失去用户的信任。数据库不可用是比较容易发现，可以通过设置双机热备的方式来预防。但是对于数据的错乱，往往不容易发现，只有当用户有发觉的时候，才可能联系客服处理，由于可能丢失操作日志，因此数据的准确性很难保证，带来的就是业务上的直接损失。
7、监控系统，自动化控制
对于一个正常运行的核电站，在各处都安转有温度监测，压力监测，辐射剂量检测等监控系统，这个是保证核电站稳定安全运行的必备条件。一旦监测系统发现异常，就可以在第一时间自动做出反应，比如自动关闭核反应堆，自动启动备份系统等。
一个大型网站，服务器可能就有成千上万台，光靠人去每天一一检测是否正常，一个是工作量大，成本高，二是人难免有疏忽遗漏，而且反应比较慢。因此必须配备自动化的监控系统，对所有服务器的工作状况进行监控，及时反馈给管理人员，更重要的是，配合自动故障转移系统，及时在发生故障的情况下，切换系统，保证系统业务能正常运行，不受影响。
监控系统的开发已经成为大型系统的核心工作，他是网站架构是否稳定可靠的核心，目前除了几个国内一线的互联网企业有比较完善的监控系统外，一般中小企业都不具备这个条件。监控系统开发成本甚至可能超过业务系统的开发成本。
8、集成测试不足
虽然福岛核电站在备用发电机组被海啸损害之后，紧急启动了应急电池来供电，但电池只能维持8个小时的时间，在8个小时之后，备用发电机组并没有恢复，在这种状况下，并没有及时找到一种有效的冷却核反应堆堆芯温度的方法，导致堆芯温度上升，发生氢气爆炸，并导致核燃料发生熔化，出现核辐射物泄露。
虽然核电站的日常维护中考虑了一些异常发生时候的应急处理，但是对于此次地震，海啸冲毁发电机组的情况，是没有任何准备的。
由此可见，我们在建设一个大型网站的时候，应该充分考虑最严重事态的发生，在开发中应该做合理的测试，在上线之前，应该对一些事件做真实的演练测试，也许每个部件在开发的时候都是完美的，但是到系统运行的时候，互相的配合可能会出现问题，这些小问题，单个测试很难暴露，但一旦运行可能直接影响你的系统的稳定性。因此必须给与整个系统合理的在线整体联调的时间，充分发现问题，及时做出合理的处置方案。而不能因为赶工期而忽略了这方面的测试。
9、定期演练，应对不足
从上边的情况，也可以看出一个问题，在1号机组发生爆炸后，3号，2号，4号都先后发生了爆炸。为什么同一个问题发生后，其他的机组没能阻止住，而是同样发生？因为地震海啸的影响，使得处理变得困难是一方面的原因，另一方面是事故处理人员操作不熟练，不熟悉应对流程导致的。
一个好的公司，需要训练有素的员工。而目前国内的情况是it行业的人员流动频繁，而公司为了出于省钱的考虑，比较多的招收大学生，
很多公司有学校的氛围就可以感受到。新人的加入，也意味着工作没有经验，对工作的细节，流程不了解，虽然可以通过时间的推移，可以不断积累经验，但是这个一要时间，不是一上来就能熟练，而是有些情况是百年不遇，因此你就不可能有经验，当真遇到了，你就只有惊慌失措的份。因此为了应对这样的局面，需要对每个it岗位建立岗位说明，描述清楚各个岗位的工作职能，以及对遇到事情的处置流程，并定期对员工进行考核和处理演练，加强工作能力，减少工作不熟悉，流程不熟悉带来的效率低下。及时淘汰不适合的人员，打造一个高素质的工作团队。
10、系统重构
福岛核电站始建于上世纪60年代，至今已经运行近40年，已经远超过30年的设计使用寿命。由于日本国内电力供应紧张，在国际原子能机构的核准下，东京电力公司最终制定了长期保守运行方案，将福岛核电站的使用寿命又延长了20年。超期服役，年久失修，也是核电站发生核事故没能及时处理的原因之一。
对于一个大型网站，随着时间的推移，用户量随时间不断增长，系统的承载压力也不断提高，会最终超过系统原设计的承载能力，因此在运行一定的时间后，需要对整个系统进行升级，最彻底的方法就是重构。一般一个系统在运行5年之后，就需要考虑重构。进行重构是一件成本巨大的工作，而且耗时比较长，像taobao这样的网站，可能需要一年以上的开发时间，因此重构工作应该在系统压力达到饱和前一年就要开始。这对公司管理层的高瞻远瞩，远期规划能力是个挑战。同时虽然重构可以解决系统原有的一些问题，但不好的重构，也可能引入原系统所没有的新问题，有时会导致重构的彻底失败。因此良好的品质管理，采用原型开发模式，逐步细化设计，实现系统，并不断反馈修正设计方案，既要均衡技术的利弊，又要追求整体的完美。这个不是一个工作，而是一门运筹帷幄的艺术。