有任何问题欢迎微信联系我沟通交流，个人微信号“Sammy-Mosch”
本公众号文章未经授权不欢迎任何形式的商业使用！
XRELIABILITY业务范围
软件可靠性的关注度一直以来都不高，但是对于大型复杂系统是不可轻视，否则就给你好看。香港地铁的信号系统故障部分是由软件可靠性导致，直接导致东铁线运营中断122分钟。
如果大家希望和同行进行可靠性技术的交流讨论，欢迎加入QQ群：
QQ群名称：Reliability Technology - MOSCH
QQ群号码：342531964
港铁公司就2018年1月11日早上发生的东铁线列车服务事故，于3月12日向政府提交调查结果。
港铁联同信号系统供应商的专家就1月11日的列车服务事故进行了详细调查，以查找事故原因。调查确认事件起因是由于列车控制系统内一个负责执行列车调动特定指令的软件程序，存在一个隐藏的编码误差。由于过去数年，车务调动及班次持续增长，致使该隐藏的编码误差发生作用，进而影响列车服务。事发当天，列车控制系统在执行该特定指令和TCS-A软件内容管理问题而导致OCC所有服务器死机。
首先不同忽视的是软件代码的问题，导致发送出“invalid message”的发出，这只能够说软件代码审查的缺陷。其实更大的问题是软件可靠性的问题，在改善措施中并没有得到彻底解决，只是增加了24小时的监测以及在非运营时间增加系统重起的次数了事。
港铁和供应商以及信号方面的专家给出的改善措施如上，我只能够说港铁作为地铁运营的标杆，在可靠性方面确实比较弱，或者从这件事情上表现出的水平比较业余。
我来说说具体应该如何解决。首先软件的内存管理机制的代码必须进行深入审查来找出内存管理缺陷的问题，其实就是必须要开展长时间的仿真环境的软件可靠性试验，并且在一定运行里程数内监控内存的使用情况，从而彻底解决问题，而不是被动做一些无用功。
所有的软件在运行时都需要占用内存，通常情况下内存管理做的不好的就会出现软件的内存占用量随着使用时间的增加而持续增加，当达到临界情况是就会出现系统死机或者奔溃，也就是港铁这样的故障。
我之前曾经做过一个项目，软件规模很大，服务器的内容是16G，但是软件构架存在缺陷，导致16G的内存最终都不够用，于是长时间使用后就会出现蓝屏，由于软件开发工作很多已经完成，这时候再改软件构架损失太大，于是出了个馊主意，内存从16G增加到32G，这样蓝屏的时间就会被推迟，从而降低风险，但是问题并没有解决，这一的产品始终是存在风险的。
一旦这样的风险在大众运输或者对于安全性要求极高的产品上使用，那么就会带来重大的社会影响。
设计上首先要保证，其次就是在软件可靠性的验证上花功夫，复杂系统基本不太可能有很多样品，甚至像地铁这类根本就没有样机来做可靠性试验，这就要求我们在仿真环境下开展软件可靠性试验，例如用服务器来模拟实际地铁运营的软件环境，从而确保所交付软件产品的可靠性水平。在试验过程中必须监控内存占用情况，从而保证软件长时间使用的可靠性。
当然了，对于复杂系统，软件规模也就非常庞大，这时候就会设计到软件的日志设计和日志文件的分析了，这个工作也非常有挑战，等以后有机会再聊。
可靠性无处不在，如果我们可以一眼从公开信息中发现其背后的可靠性问题所在，这样的感觉会妙不可言。
如果港铁需要可靠性顾问服务业欢迎找我洽谈合作哦！
欢迎大家访问 www.xreliability.com 网站了解我们的业务，同时也欢迎大家对我们的网站提出宝贵意见。
公司专注可靠性技术，提供咨询、培训、检测、设备和软件等平台可靠性解决方案服务。
欢迎扫描二维码关注摩西的可靠不可靠微信号：
