一点对铁路售票系统改进的设想

12306，相信大部分程序员都曾用过，大家也都见证了这个网站从当年卡的要死到现在的加载如飞。

很明显可以看得出该网站开发团队对整体架构进行了疯狂地优化，从以前半夜12点到凌晨7点，到现在的晚上七点到凌晨七点，维护时间越来越久，同时这也恰恰说明了一个问题，那就是J2EE网站做这种大型应用的维护性能。我的原则是不涉及任何语言纷争，牛人太多，浑人也多，所以做大型应用服务平台还是应该事先定好易维护的平台。

为什么现在是晚上七点到早晨七点了呢？这里可以看出这个网站背后应该有一大票维护人员，而铁道部对这些维护人员的投入应该不足以支付其付出，或者是这块费用该公司领导觉得浪费，所以他们就变成了现在每天早七点上班，晚七点下班。在这里问题又出现了，那就是为什么不可以让该系统放心运行呢？是其中有什么猫腻吗？

所以就有了本文的主题，一点对铁路售票系统改进的设想----无人值守自动维护。

个人看来，这种系统的关键之处在于其随时都有收退费业务，其实还有更为引起领导重视的，那就肯定是投诉和建议这类了。除此之外，值得投入全天候人力去运维的，还能有什么呢？所以完全可以针对这么几个点来各个击破，逐个实现无人值守自动维护。

针对收退费，没有考虑过主营业务的自维护，一是因为对其具体业务不熟，只做用户不做开发；二是因为并不提倡业务系统无人值守，个人看来对业务系统的无人值守，大都是概念和噱头。对于投诉和建议这类则可以考虑无人值守，个人见识有限，只想如果能够增加投诉相似度对比功能，类似于论文查重，这样一来就可以实现无人值守第一步了。

原理：

1、收集投诉、建议

2、对收集到的信息进行对比，找出相似度80%以上的回复

3、对成为进行定位，这里需要一定的算法，就是检索出人名来，或者是规定回复中不允许带有人名，超过80%的情况，一般文本可以直接作为回复使用。

这样一来，无人值守的第一步应该可以开展了，然后就是进行精准定位和人工辅助回答的范畴，虽然无人值守的初步想法较为简陋，但应该可以减少一部分人力。

那么对其进一步的设想就是还是通过对比度分析算法，读相似问题进行分类，提高相似度对比算法的命中率，把80%进一步提高到90%、95%或者更高，这样就形成了一个良性循环，从而让无人值守越来越智能化，但这里还存在着一个缺陷，那就是知识语言的更新速度，这种情况还是需要一定人力去干预的。