高铁事故对IT系统建设的一些启示 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

IT系统作为业务功能的实现最终表现和运营操作的对象，本身的稳定性、安全性也非常重要，但是这恐怕是比较容易忽略的地方。
从业务到技术都更专注于功能的实现，而忽略性能需求或者安全性放慢的考虑，性能或可以从压力测试、性能测试等方法进行测试，得出相对量化和客观的指标。
但是对于安全性，却很难有办法穷举或者识别，恰巧老胡最近也在做一个全行的应用系统的项目，功能实现都没有问题，但是在复杂的系统集成情况下（周边系统，在包括核心系统在内，有10多个外围相关系统），耦合程度很深，在这种情况下，在试点阶段，分行反映情况良好，但是在推广阶段，忽然发生了热备过热，电力系统无法支撑，发生跳闸，最终造成了全行的影响，确实是防不胜防的。 作为个案，更多的时候我们考虑软件系统和硬件系统本身的因素，而忽略外围系统的和关键支撑系统的因素，虽然存在困难，但是最终表现，你不得不承认，发生在了你所负责的系统功能上。
既然问题无法穷举，风险无法全部识别，安全却需要保证，解决两难之间的一个平衡，老胡认为，关键还在于设计与规划，这点系统在功能和性能上必须余量和弹性，否则就如高铁一样，直接崩掉，其次又在于测试，特别是对于临界和边界情况的测试，复杂耦合下的场景设计与验证，必要的时候要搞PAT，生产数据下的变形数据导入测试，生产和测试终究是存在不同的。
[ 本帖最后由 家住海淀 于 2011-7-28 14:46 编辑 ]
多说一句的是，项目管理和项目组织架构非常重要，多重表象和数字，而不进行深入，这类重点的平台性的，集中性的平台类项目，必须要做最大的投入，质量管理从头开始做，而不是补课，否则代价不说了，问题是很多东西不可挽回和逆转的。风险太大了
项目经理和规划团队，BA，主要技术方案必须要慎之又慎，之前那些累积性（如内存泄露等）、功能缺失性、临界测试、设计错误、安全余量、灾备与容量、人性化设计与规范性检查与处理，系统性的工程，必须在各个层面，各个维度进行整合
高铁事故，最值得我们反思的是项目建设过程中，一味求快，搞面子工程，献礼工程，忽视质量，忽视软件开发的客观规律。
在这么多项目中，遇到的都是先定好上线期限，然后倒推项目计划。然后是根据这个不合理的工期要求，计算出来的项目报价，因此只能找些无证程序员来做开发，质量不比现在的桥啊楼的好到哪里去。
原帖由 家住海淀 于 2011-7-28 15:43 发表

你还真信什么无证程序员呀
幸亏这里的活儿不是临时工和精神病干的
不管你信不信，我反正信了，