这两天NHS内部有些变动，被迫追着他们的时间表改程序，有点小忙。闲散久了，突然加速忙起来多少有点不适应，胡乱感慨一下，也从一个侧面证明一下国外的月亮一点都不比国内的圆，天下有人的地方就有腐败。
事情的大概是这样的：
NHS本来是用的tracing系统是NSTS（NHS Strategic Tracing Service），因为一些冠冕堂皇的原因，该系统在出色运转了N年以后就要被一个新的系统DBS（Demographic Batch Service）所取代，交接截止日期是本月底。所谓的tracing简言之就是我们提交患者的不完整信息，经过他们数据库匹配后返还给我们完整信息的过程。DBS据说是NHS投资数M英镑搭建的新一代平台，相交其前辈NSTS有7大好处8大有点9点进步10点超越
糟糕的现状是这样的：
1） 用NSTS trace一批数据，大约1-4小时之后就能收到反馈结果；DBS系统只能在每天凌晨处理前日的请求，理由是白天高峰期处理会降低 online tracing （相当于一个网站提供的手工检索平台）的速度，影响更多人工作。NSTS 也提供同样的服务，从来没有过这种问题。
2）NSTS时代做tracing没有数量限制，DBS每天只能处理1.1M个病人的检索，这个阈值后，未处理的记录就只能再等24小时之后继续排队。
3）NSTS系统的精确度比DBS高，最近两周我们统计的结果大约是1到3个百分点的样子。
4）DBS系统有时候会有很多奇怪的错误，比如文件发送过程中连接丢失导致的文件迷失在异空间啊（队列中排在后面的文件一并蒸发），半夜他们的tracing系统启动之后突然间莫名其妙当机啊（期间所有被trace的记录返回time out错误）等等等等。而且所有这些错误统统没有任何通知或者报告，他们甚至连个system/error log都没有，所有这些只能等第二天没有收到反馈后才能知晓。
5）当出现上述任何问题，需要重新发送文件retrace的时候，如果仅仅是把原来的文件resend一次，会在第二天早上收到邮件通知（终于见到email notification了），说系统记录显示该文件曾经被trace过，请不要藐视我们系统的智商。（我们估计他们是记录了文件的digest hash，因为具体数据是显然不能改的，所以只能改文件头的meta data，比如batch id，这样做的结果是收到反馈后还要再一次手动给改回来。赶上那天是几十个文件被通讯握手时的故障阻塞掉，第二天第三天光该文件头就得一个小时）
6）NSTS的help desk接电话的是programmer，DBS的是BT（British Telecom）的Customer Service。（DBS是BT建的）跟他们讲技术故障，完全是对牛弹琴，我觉得跟个老外讲中文都没这么费劲。
7）DBS的tracing程序客户端是用JAVA写的，但是引用了两个DLL动态连接库，所以只能在windows平台运行。开发这个程序的估计是英国的90后，明显脑残。
悲惨的结局是这样的：
两个平台的交接截至日期是9月30日（下周三），如果在此之前不把所有问题解决，我们的工作效率会被拖累降低7%～19%（老板估计的，不知道她怎么算出来的=_=##），所以国庆之前我注定要继续忙碌下去。我今天一天忙下来最大的感受就是：DBS就是英国的驴霸！
