灾难环境下的Mobile应用构建及部署

写下这个题目绝对不是为了哗众取宠。看题目大家都会知道这篇文章的源头在哪里，的确地震之后，我一直有一种无力感。IT系统无法快速切换到灾难状态，于是，很多的信息管理又再次回到笔和纸的时代。但是，信息管理系统在灾难中其实更为重要，比如救灾物资的跟踪、发放，遇难人员身份确认和统计，GPS导航等等。尤其是我们的Mobile移动终端设备，其实能够发挥比平时更大的作用。

在这篇文章中，我试图思考一个问题：如何让我们的IT系统在灾难面前更加有效的运行起来？至今我没找到答案，不过，我希望能够让大家重视灾难环境下的IT信息管理。

灾难后还剩下什么？

逃出生天的人们往往会下意识地检查一下肢体是否还完整，同样，一个灾难过后的IT系统，我们也要首先知道，哪些部分可用，哪些部分不可用。首先是不可用的：

1， 电源：

前24小时将完全依赖电池或后备电源供电，24小时后可能会间断性电源或发电机供电；

2， 信息网络：

灾难核心区，有线网络将无法使用，边缘地区的网络将在24小时后恢复；依赖移动电信网络的无线网络将遭到毁灭性打击；

3， 计算机设备：

因为无法移动，所以在灾难过程中计算机设备会遭到摧毁，而之后的电源、网络等问题会造成信息孤岛。

可用部分：

1， 便携设备：

不依赖AC电源供电的PDA等设备更容易适应灾难后的环境，但要考虑电源问题。

PDA能做什么？

在便携设备中，PDA是最能适应灾难环境的电子产品，只要有相应的软件配置，就可以快速切换到灾难救援之中。工业标准的PDA（或EDA）本身就可以工作在野外环境中，对于灾难环境来说，硬件本身不是问题。PDA设备能够提供的功能：

1， 信息管理平台

可以完成灾难环境下的信息管理，如灾民统计、遇难人员统计、物资统计、物资发放明细记录；

2， GPS导航平台

外接GPS设备后，可以用于指示救援人员位置、记录被困人员位置、获取地理信息等；

3， 信息交换平台

配合RFID，作为信息交换平台，如交换救灾物资的信息，记录和快速浏览伤员情况等；

4， 图像采集平台

采集视频、音频和图片信息，如遇难者身份确认等；

5， 信息查询平台

用于查询遇难者信息、寻亲、救灾物资信息、灾情通报等。

PDA的限制和应对之道

尽管PDA是最适合救灾的信息设备，不过PDA也有其局限性，接下来，我们试图来想办法解决：

1， 电源

灾区不会有电，所以

1）我们必须配备大功率的电池，并且配备手机电源伴侣，能够让PDA、GPS等电子设备坚持72小时以上。

2）并且配备各种充电设备，增强电子设备的可用时间，考虑太阳能、汽车电源、发电机等备用充电方式。

2， 网络

已有数据网络，比如有线网络、GPRS、CDMA等肯定会被摧毁。

1） 我们可以搭建依赖卫星地面站的无线网络，卫星地面站可以完成与外界通讯，而无线网络可以完成某个覆盖范围内电子设备的信息交换。

2） 更为残酷的现实是，很多电子设备必须通过点对点通讯来完成数据交换。

3， 数据库

因为网络的关系，外界的中心数据库是无法访问的。

1） 使用PDA本身自带的移动数据库存储信息；

2） 使用RFID等标签设备存储信息，如病人的医疗信息等；

3） 在有机会的情况下，PDA通过网络和中心数据库进行信息交互，比如PDA设备被带出灾区时。

4， 外设

必须能够连接的设备如下：

1） GPS：

地理信息的获取对于救援工作的作用毋庸置疑，我们还需要能够标记等待救援人员的方位等信息；

2） 蓝牙、红外：

在外部网络不通的情况下，作为短距离通讯手段，即可以连接外设，又可以作为PDA之间的通讯手段；

3） RFID：

作为身份识别的重要载体，能够读取和写入信息，随伤员或救灾物品一起部署；

4） 摄像头：

作为统计灾情、遇难者身份确认的手段，我们可以通过摄像头、数码相机等留存证据，待灾后辨认；或者上传灾区信息，用于救灾决策。

移动救灾系统的功能

将来开发这套系统的程序员肯定会很郁闷，谁都希望自己的软件能够被使用，但是用这套软件的时候，就意味着灾难的来临。我们无法预测灾难，不过只要能在灾后起到作用，也就足够了。先来试想一下救灾系统应该包括的功能：

1） 现场救援

现场信息记录、与生命检测仪等系统互联，获取生还者信息，统计遇难人数、身份，绘制现场简图；

2） 伤员救护

配合带RFID的手环，记录伤员身份信息、伤病情况、救治情况、后续治疗建议，待后送之后，医生可以根据信息进行快速诊断、救治。如果配合电子病历系统，可以快速将信息导入医院管理系统中，方便之后的治疗；

3） 地理信息

使用GPS及地图系统，为救援人员指示目前方位、目标方位等信息，还可以记录待救援人员的位置，方便指挥系统进行合理的人员分配；

4） 物资管理

进行物资管理及分发，从中心数据库中获取物资信息：如种类、数量、目的地、运输方式等；运送到救助点后，进行物资发放的同时，收集受救援者的信息。留待灾后进行统计时，防止物资发放过程中出现的问题；

5） 灾情报告

对于救灾决策而言，获取灾情信息的报告也至关重要。统计受灾人数、遇难者人数、房屋财产损失、检疫卫生信息等，获取视频、音频、图片资料，及时上报。

6） 遇难者身份确认

遇难者身份确认也是历次大灾难中的难点，获取遇难者信息，如图片、身份信息、DNA信息等，配合RFID或条形码标签，然后录入数据库中，进行伤亡人数统计、身份识别等工作。

7） 寻亲

登记遇难者、伤者与幸存者的身份信息、所处位置，为幸存者提供亲属、朋友的查询服务。

移动救灾系统的设计架构

Mobile系统为了应对Offline状态，已经有了离线访问、本地数据缓存等机制，来保证数据完整性，但是在灾难体系下，这种机制还要继续深化：

1） 无Server状态下的P2P信息传递

在无法访问Server的情况下，Mobile设备之间应该具备点对点信息交互的能力。当处于同一区域的两台设备相互发现后，应该按照一定的规则进行数据交换，当信息交换频率达到一定密度时，所有设备的信息应该都是最新的。

所以，在设计数据库时必须保证：1，使用GUID作为每条记录的唯一标记ID；2，使用时间戳来判断记录是否为新。

2） 与Server进行数据同步

在进行数据交互之后，Mobile设备的信息还是需要与Server进行交互的。途径有两种：1，当救援人员从灾区出来时，有无线或有线网络被发现时，系统会自动上传未上传信息（至少有些救援人员是穿梭于灾区与后方之间运送物资的，使用他们的设备作为信息载体，将信息进行及时后送是可行的）；2，架设临时的数据传输系统，比如卫星地面站，成本会比较高。

待解决的问题

我们无法预知下一次的灾难是什么样子的，所以救灾系统的最大敌人就是——时间。我们无法根据已知需求来针对下一次灾难来部署IT系统，只有在灾难发生后的几个小时迅速根据已知情况来进行部署工作，然后在随后的几天时间中逐步修改已有系统。如果某个功能需要两周时间来实现，对于灾难情况下的IT系统来说，是没有任何价值的。

所以我们尽可能做的是：

1， 依赖现有系统

比如Google和Live使用已有系统来搭建灾情信息系统，尽管实际作用有限，不过已经是可喜的第一步了。目前很多网站都提供二次定制的API，这将是我们可以利用的宝贵资源；

2， 组件化、模块化

预先开发救灾系统的某些模块，根据具体需求进行定制或分类部署；

3， 可定制性

根据现场需求定制某些模块中的特殊功能，比如增加新的数据信息分类等；

4， 可修改性

一旦发现现有救灾IT系统不符合实际要求，开发人员能够在很短时间内进行修改，将修改之后的软件进行再次发布。

也许这一切都是纸上谈兵，但是IT的意义就于让信息交换更加顺畅、有序，而在灾难的背景之下，信息的正常传递就显得尤为重要。

保证已有IT系统的正常运行，并将其快速转入灾难体系，参与到灾难救援过程中，其实是我们之前很少考虑的一个问题。有个很简单的例子，我们经常在做系统设计时，说到网络连接，随口就是GPRS/CDMA，可是在灾难背景下，这一切都不存在了。GPRS/CDMA不存在了，网络就不存在了吗？错，我们还有蓝牙。于是，我循着这个思路，写了上面的文字，期望对面对下一次灾难的救援有所帮助。尽管很不成熟，但我认为有实现的可能。

借用这次灾难中的一句名言作为结尾，期望灾区的人一切都好：

所谓奇迹——就是你修房子时能在十年前，想到十年后的事情。