G2Rail拥有庞大的交通数据，比如铁路公司班次、车型、舱位、票价折扣。如果再加一个时间维度，不同的铁路公司会不断引入新车型、推出新的票种、新的路线。如何维护大数据的实时性、完整性、正确性是一个巨大的挑战。过去一年多花了很多精力去设计、建构、迭代G2Rail的数据运维系统

作用

建构数据运维系统给我们带来的好处远远超出我们最初的想象：

• 最直接的作用是监控系统的健康运行。比如：及时发现网络问题、证书问题、与铁路公司和对接下游客户链接问题等
• 发现数据异常或者错误。比如：车站编码错误、铁路公司的新折扣、主要路线没有返回车次结果
• 优先级。通过数据监控，可以获得第一手材料，比如客人经常搜索的时间段、经常搜索的国家、路线、在某些页面客人经常关心的问题。
• 数据完整性探查、维护。
• 地面交通大数据知识系统的知识构建。
• 监控下游合作伙伴的活动、绩效以及计费统计。
• 关键字挖掘。
• AHA的点子。现在这些点子已经用于丰富客服系统、搜索引擎优化、产品组合等等

源自于技术

最初的想法很简单，从技术人员角度去监控与上游各个铁路公司的链路。做法其实就是定期去搜索某条固定的线路。直到有一次遇到服务器宕机事故，究查原因来自于某家海外对接合作伙伴，通过各种爬虫手段来盗取G2Rail的路线、价格等数据。这让我们意识到监控系统等重要性，我们有必要记录从每个合作伙伴、每个渠道的搜索、订单数目，从而及时发现同类问题，采取针对行动。

业务故障监控

从技术监控到业务监控到转换，来自于一个不经意的AHA：

只需要监控各个渠道搜索返回的结果数目，其实就可以解决最初铁路公司链路健康检查的目的，而且通过返回结果数目的异常，可以发现更多隐含问题。

举一个例子：慕尼黑到法兰克福一天会有二十几个班次，如果返回结果为0，这意味着某个节点出了问题。需要针对性的排查问题，可能是网络问题，可能是数据问题，可能是服务器问题。

建好结果统计监控之后，开始每天时不时会去监控一下搜索结果数目，我突然意识到，如果记录下来的不光是搜索结果数目，而是整个搜索结果、订单流水，就可能发现更多的问题。

接下来进一步扩充为记录整个搜索结果、订单整个生命周期。有了整个日志记录后，开始添加对日志的各种数据、完整性分析。这其实不光是技术知识，还需要很多地理、交通、车型、舱位等等很多的各种知识。

举个例子：有个客人今天凌晨用俄罗斯语，搜索从Cologne(it)到阿姆斯特丹中央火车站到列车后系统报错（最近很多有很多乌克兰人下载Xmove，并向我们求助，指点路线、帮忙查票，转车站台指引等等）。

欧洲其实有两个英文为Cologne的城市，一个是德国著名的城市-科隆(德语是Köln，英文是Cologne)，而另一个科隆(Cologne)位于意大利。而德国科隆离阿姆斯特丹不远，每天都会有很多车次。从意大利到荷兰阿姆斯特丹需要穿过意大利、瑞士、法国、荷兰，基本不会有正常人坐火车。所以可能的原因是客人想选择德国科隆，但是选择了意大利到科隆，因此可以推断出是意大利科隆的俄罗斯语翻译出了问题。

业务监控也可以根据业务不同而演化出多种不同的业务监控，比如车站编码、发现新款列车、发现新车型、发现新舱位、数据映射错误、搜索分发错误。。。

从监控到数据挖掘、系统自学习

搜索结果、订单结果记录的另一个好处是让G2Rail/Xmove变得更加智能。

很直接的就是搜索的次数、订单数会影响到路线选择推荐的权重。当然根据搜索结果日志还可以分析出每天列车趟数、每天的车型、每种车型的舱位设置、不同车型的价格体系、价格变化等等。

业务优先级

业务监控的另一个好处是对于业务优先级有了明确的、具体的客观指标。

模块

随着数据运营的需求不断演进，也需要引入多种工具，当然更重要的是开发一些自有系统和系统功能来完成整个数据运维的要求。而从实现角度，整个数据运维系统帮我们实现了下面的功能。

• 采集、分析
• 整合、清洗、提炼
• 探查、捕获
• 挖掘、学习
• 监控、报告

反思

反思一年多集中运营、迭代、完善大数据运维体验，其实更重要的是关注以下几点：

业务角度

脱离技术，从业务角度，对于业务全流程记录、分析、监控才给数据运维带来了活力，体现了价值。运维目标也需要以业务导向，比如：增加搜索成功率，降低搜索结果重复度和噪音，增加成单率等等。而基于业务积累出来的数据运维体系就变成了业务壁垒的一部分。

关注小数据

尽管G2Rail/Xmove有很大的数据，但是我们的习惯却是关注小数据。对于每一条搜索、每一个订单的分析给我们带来更多的AHA。因此我自己每天的工作总是从分析前几个小时的小数据开始的。每天早晨的运维数据分析总会给我带来新的AHA。