面对巨灾，我们需要什么样的软件？

5 月 12 日的地震给很多同胞带来了彻骨之痛、更凝聚起整个中华民族共同抵御灾难的力量。软件作为一个服务性的产业，面对巨灾我们需要应用什么样的软件和互联网产品呢？根据来自汶川、绵阳、首都机场、天津塘沽以及所有网络用户在使用的各种应用，我们不难发现灾难管理软件确实有很多特点。

地震之后，大家的关注点主要集中前一阶段的搜救和近期的防疫，但在很多新闻、现场亲历者、志愿者、指挥人员的工作中我们还是可以看到四类软件的身影：

1. 在抗灾一线网络、通信条件有限的环境下，基于 Microsoft Office 和宏完成的现场桌面应用。虽然从技术上看这些软件含量不高，但在涉及到各方人员、各种物资尤其是直接关系的生活必需品物资的发放和造册过程中，这种桌面软件的作用不容小觑。即便很多时候我门似乎已经进入“随时信息获取”的时代，但这次灾难还有之前的海啸、飓风等灾难一次次告诫我们，面对灾难设计软件，尤其是这种直接用于一线的软件，要回归到“随时随地信息积累”+“有限连通”的思路。
2. 在宏观层面，由于要协调物流、人力、生产、营地、地理态势等多种救灾要素，并且要对相关要素的情况进行实时跟踪，所以 ** IBM 的 Sahana 出现在很多灾难指挥调度部门的工作中 **。
3. 主要的搜索引擎，例如：Baidu、Google（发布寻亲 / 报平安信息）都在地震发生几天后推出了寻亲服务，对于帮助那些至今无法联系到亲人、朋友的网络用户而言，起到了非常积极的作用。不过这类软件也同时暴露出一个问题，就是信息可信度问题，对于一般的搜索，我们可能会获得大量的搜索结果，但涉及到灾害中亲人搜索的时候，即便搜索引擎提供了“失踪”、“确认死亡”等信息，其可信度也要大打折扣，最终还是要通过民政、公安等部门的官方信息做确认。如何协调“找到”和“公信”以及搜索厂商市场利益的关系，是此类互联网产品需要着力关注的。
4. 基于卫星信道的无线应用在最黄金救灾时间——“救人命”的阶段发挥了重要作用，虽然在北京、上海等大中城市无线网络应用已经有很多热点，但设计上他们更多基于“短途”的有限范围，一旦电信等基础设施被损坏后，就成了“聋子”和“哑巴”。所以，在灾难软件中，如果目标应用环境是条件恶劣的一线作业，在连通性方面就必须预留足够的可选项，甚至可以考虑将发报等方式融入设计中。但为了达到这些目的，不仅仅是简单的信道问题，还需要应用栈提供必要的支持，要能够把最关键的信息优先发出去，比如：即便有了流媒体压缩，也很难想象用电报方式发送一段 2 分钟的视频，不如一句“已至望接洽”直接（采用电报的写法，省去了标点）。