【IT168 资讯】在今天我们谈到应急指挥IT系统的时候，最终极的一个困惑就是描述不清楚它的边界。“应急指挥”的外延可以非常宽广，深入社会的各个维度，所以曾经有人说：应急指挥IT系统是有史以来最复杂的IT系统。从技术实现的角度看这个结论，这无疑是一个灾难，因为这意味着这个史上最复杂的IT系统几乎是不可实现的，至少是成本的黑洞。而但凡是应急系统，都具有养兵千日、用兵一时的特点，连长城都不例外，所以不能堆砌过于高昂的成本而“无急”时无用。因此，应急指挥IT系统究竟要建成什么样子，核心正如标题，简单or不简单，是道难以回答的选择题。

简单or不简单，代表了当今对应急指挥的两种典型建设思路。一种是往低了看，往简单了建。在极简的情况下，应急指挥IT系统可以剥皮去肉、只剩骨架，简化为一套视频会议加上一个应急指挥办公场所的显示大屏装修，这种冠以“应急指挥”名头的建设，在真正的应急事件到来的时候，是起不到太大的作用的；另外一种极端是往高了看，往复杂了建。智能分析、智能联动、模糊决策，各种软硬件有条件的都装上，没条件的创造条件也要装上。这种方式的弊端一目了然，一是技术条件未必具备，二是成本高昂。面对这样一个课题，极度简单和极度复杂都不是可取之道，我们必须回归到问题的本质，即

（1）“应急指挥IT系统”和“应急指挥”二者的关系是怎样构成的

（2）“应急指挥IT系统”最核心要解决的问题是什么

“应急指挥”和“应急指挥IT系统”正如抵御外敌和万里长城的关系一样，前者是目标，而后者是手段。手段服从且同步于目标。“应急指挥”不是一个技术的概念，而更接近一个管理的概念。若以效果来反朔，则有效的应急指挥应该至少具备这样的特征：信息掌握足够准确、反应足够迅速、应对措施足够全面得力。如果以管理的三段论来划分，则应急事件发生时包含信息汇集、决策生成和指挥执行三个关键阶段。再放大一点看，一个完整的应急指挥大周期不应局限在应急事件爆发后的一段时间内，而是由应急前的信息汇集分析阶段、应急事件发生时的应急指挥阶段、应急指挥实施完成后的信息积累和分析阶段构成一个完整的循环，每一次应急事件的发生和处置不仅针对当次的环节，更应自动成为下一次类似事件的经验值和素材库。比如03年发生的SARS疫情对于今年的H1N1疫情来讲，就构成了信息和预案的先导输入。从手段和目标的关系来论，“应急指挥IT系统”狭义的看应该是支撑应急事件发生的三大阶段，而广义的看应该是支撑应急全流程的三大阶段。就前者而言，映射到技术实现上，重心在于与应急相关的信息获取、通讯、通讯支撑，而对广义而言，则有更多的资源和力量应该放在非应急事件爆发状态下的信息获取、信息分析等相关方面。必须看到的一点是，应急指挥不是一个一次性的系统，从狭义逐渐演进到广义，避免好高骛远不可实现，也避免鼠目寸光短视近视，是很多时候，能够把应急指挥真正落到实地的关键。从另一个角度，“应急指挥”和“应急指挥IT系统”一个是形而上的，一个是形而下的。形而下的东西往往受限于现实的技术条件，在一定时间内，必须划定一定的实现边界，否则是不可操作的。IT系统领先、管理措施没有跟上，IT系统就会形同虚置；IT系统过于低下，管理措施无法获得足够的技术支撑，就会导致动作变形、结果滑坡。此外，IT系统从规划到建设到运行，需要较长的时间周期，如果以规划作为时间点基准，则还必须考虑到“应急指挥IT系统”相对于应急指挥管理操作制度应具有一定的提前性，否则在上线运行的时候就会反过来成为管理操作的桎梏。

对于第二个问题，则必须要讨论清楚应急指挥要解决的核心问题是什么，IT系统要解决的问题一定是业务目标要解决的问题的技术映射。前文提到，应急事件一般都具有突发性强、发生速度快、涉及范围广的特点。随着现代信息技术的发展，对于“不可预知”这样的一个特征，则可以通过系统的前后期工作，最大程度的加以削弱。比如秦始皇时候游牧民族来袭是很难预知的，而在今天，天上有卫星、地上有雷达，类似的行动就可预知了。但是即便如此，道高一尺、魔高一丈，新类型的事件层出不穷、新的技术手段也会反向构成新的威胁，大规模军队集结可预知了，自杀式炸弹袭击就很难预知，F15可以提前发现，F22就发现不了。因此应急指挥要解决的核心问题还是集中在事件爆发后最短的时间内做出正确而全面的反应。 正确而全面的应急指挥实际上包含决策和指挥两个关键动作，这两个动作是串联的。一定是先有决策后有指挥。汶川地震后，温总理赶赴现场指挥救灾，亦是先汇集各级决策者、专家针对现场情况进行论证分析做出决策，然后再指挥各部门、部队行动。在此，面对突发性强、发生速度快、涉及范围广的应急事件，最大的挑战就是“最短的时间”和“正确而全面”两个要求要同时满足。对应到IT系统，则反映在贯穿整个应急指挥过程中的信息的特点，既要在搜集、反应、分析各环节足够快，也要具备非常宽的覆盖度，二者缺一不可。现代应急事件的发生所带来的往往是连锁反应，参与应急处置的系统和部门也空前的多，比如H1N1的防控，涉及到政府、卫生、铁路、航空、公安……，没有广度覆盖，决策就不可能全面而正确，没有快速反应能力，就会耽误宝贵的时间、酿成严重后果。另外，由于应急所面对的往往是很恶劣的状况（例如汶川地震导致几乎所有地面通讯设施的损毁，影响通讯），所以应急IT系统本身的可靠性设计和冗余考虑也是正常运作的保障。以此总结，应急指挥IT系统面对的最核心问题可以抽象为：

（1） 快速——信息汇集要快、决策过程要快、指挥通讯要快

（2） 全面——所有在应急处置过程中可能需要的信息都要有采集手段和联接方式

（3） 可靠——信息系统要可靠、信息传送路径要可靠

信息是IT系统的灵魂，也是连接业务目标和技术手段的纽带。从应急指挥的业务特征出发，对应到对系统中信息的要求，就可以明确应急IT系统到底重点是做什么。

在快速、全面、可靠三个要求中，全面是最难解决的。由于应急指挥涉及到社会的几乎所有方面，那么从全面的角度考虑，必须具备将这些社会各个系统的IT信息全面接入的能力。这些信息大体上可以分为两类，一类是以各个部门业务系统内的数据库数据为主的结构化数据，一类是以图像、视频以及一些特殊的类似地震、气象的专业图片为主的非结构化数据。由于若干年来绝大多数部门的IT系统建设都只考虑自身的内部业务需求，较少考虑不同部门之间横向的信息共享和获取，因此当前真实的状况是耸立着一个又一个的信息孤岛、彼此制式标准不同，横向的数据整合很难进行。但是对于应急指挥IT系统的建设而言，这是一个必须要解决的问题，是一切的核心，否则任何决策和指挥都无从谈起。对于结构化数据，目前应急IT系统解决这个问题的方法有以下几种：

（1） 从各个下级系统抽调人力、配置终端集中到应急指挥大厅，事件发生时采用远程登录的方式来实时获取信息。也就是信息不集中人集中。这种方式的弊端显而易见，一是不足以覆盖足够广的面，二是远程登录系统在可靠性方面很难保障，三是对于未来多系统横向数据分析提供辅助智能决策的软件无法从数据层支持。这种方法是无法满足应急系统真正的业务需求的。

（2） 利用数据库中间件，从不同的业务系统中抽取所需的数据，汇总到应急指挥中心进行应用。这种方式原理很清晰，但是复杂度太高。由于数据库中间件和数据库、操作系统强关联，因此对于各种各样的异构系统，也必须用异构的二次开发去加以解决。这种方式的工作量和成本随着覆盖广度的增加会呈指数上升。

（3） 共享存储容灾的方式。即将各业务系统以数据容灾的方式在应急指挥中心做统一的关键数据储存。这种方法可以较好的解决异构性问题、方案成熟，对未来业务支撑度高，数据安全性好。需要解决的是管理体制配套的问题。

（4） 将结构化数据非结构化，采用高清视频编码器将远端的显示信号同步传送到应急指挥中心进行显示。这种方式布署简单、快速，投入小。不获取数据，但通过远程呈现同步远端的系统桌面。

从长远看，第三种方式必将成为根本上解决问题的一种数据共享手段。而在当前，通过第四种手段进行阶段性的布署，可以作为过渡方案。

对于非结构化数据，现在通行的方案是通过数字编码器将远端的模拟或数字图像传送过来，根据应急决策的要求进行集中的显示。实际上，应急指挥的需求不断深入，从另一个角度也会极大的促进整个社会监控和视频资源的联网化、标准化进程，最终形成一个全联网、全互通的非结构化资源体系。

而可靠的要求，反映在应急IT系统中，主要包含有两个方面：一是应急IT系统自身的安全可靠性设计，另外一个更重要的就是通讯链路的可靠冗余设计。由于极端应急事件的破坏往往很大，正常通讯链路的中断是必须要作为设计基准预估的。因此一方面不依赖于传送条件和气象条件的卫星通讯作为应急IT系统必备的备份链路是必备的选择，另一方面基于无线WLAN或集群的现场快速布署启用的前端通讯系统也是尤为重要。在汶川地震救灾中，在绝大多数通讯手段损毁的情况下，这两种手段起到了很大的作用。更重要的是，对于有线无线、多种连接手段的融合管理能力、切换控制能力在应急IT系统的链路支撑中是非常重要的。在极端紧急的状态下，基于应急预案，在广域链路全部不可用，实时数据获取能力瘫痪的情况下，则应急指挥中心至少应具备一个数据中心的功能，基于历史数据和通讯来应对问题、进行决策，然后基于卫星通讯等较难被损毁的通讯能力进行指挥处置。前文提到应该加强各系统在非应急状态的数据向应急中心的灾备，正是出于这种考虑，完全依靠数据实时获取的应急指挥中心在极端恶劣情况下是不可用的。

对于快速的要求，反映到IT系统上，其实就是尽量加强系统的智能性，增加计算机的处理比重、减少人的处理比重。这其中有两个努力方向：一是对于系统的快速响应能力的建设，比如数据分析辅助决策、与显示相关的各种快速功能建设、实时数据调取能力的加强等。另外一个方向是加强非应急状态的准备以尽可能缩短应急处置时间。非应急状态下主要包括数据的储备、整理和分析报告，以及针对各种可能情况的应急预案的设立和触发机制的建立、配套的演练等。后者对于加快应急响应速度是更为根本的，事件发生后反应再快，决策者再高效，如果每一个细节事项都要逐一落实安排的话，效率还是很低的。加强应急指挥IT系统的建设，其实还是为了改变现在处置应急事件的模式——就是“一把手工程”，非得一把手到了现场指挥，各部门才能动起来、协调起来。真正的应急指挥，最核心的决策者应该位于应急指挥中心或者移动应急指挥中心，即各类数据和结论汇集的地方，才能最高效的决策；真正的应急指挥，应该80%的处置都是触发式的而不是指令式的，即出现某种情况，相关部门人员根据事先设定好的预案和演练立即反应，而不是等待领导指示要求。设想地震发生的时间只有几秒，在应急指挥系统覆盖下的学校，一方面应该立刻有相关的建筑、交通、卫生资源等相关数据汇集到应急指挥中心进行处置决策，另外最关键的，是要在第一时间由老师一声令下，学生立刻全钻到课桌下面。成熟的应急指挥快速响应，预案解决80%的问题，应急决策和指挥只解决另外20%不能解决的问题，这是发展的方向。

经常提到的还有应急通讯车的问题，其实应急通讯车可以看做是一个通过卫星链路和主应急中心相连接的分中心。其具备基本的应急指挥中心的能力，而更靠近现场，对于处置某些特定的事件非常有价值。配合通过无线布署的现场图像获取，则可以更为迅捷的由应急中心获得第一手的现场材料。这种应用，从本质上和阿波罗登月计划中月球车和地面NASA的指挥大厅的关系一样。

由此看见，应急指挥IT系统的建设，虽然在外在表现上似乎还是不同软硬件的排列组合，一样有服务器存储网络，一样有视频会议防火墙监控，但是它的核心实质又不仅仅是一个综合堆砌的系统。它最大的特点在于要解决上文提到的信息的全面、可靠和快速的问题，一切围绕着这三个要求而展开，一切也因这三个要求而不同。从逻辑上看，应急指挥IT系统不同于以往各个部门独立建设的IT系统，比如银行的系统、电力的系统、政府的14金工程等等，而是构建在这些系统之上的，横向需要渗透在所有系统的数据平面的、指挥触角需要延伸到所有系统的操作层面的上一级的新的IT系统。在物理实体上，可以看作是应急数据中心、应急指挥通讯系统和应急数据采集系统的有机合一。从这些结论再来审视应急指挥是应该简单还是不简单的课题，就会发现唯一正确的方法，就是从简入繁、由浅入深，循序渐进、逐步叠加。因此应急指挥的IT系统规划建设是一个特别需要进行三到五年长线规划的课题，并应非常注重在规划中的管理制度与技术手段的交织互动。架构决定价值，万丈高楼平地起，不管怎么建，从起点开始，就要牢牢的把握住数据信息的共享这一本质中的本质。应急IT，说到底追求的是在业务实现上，不同的数据的横向互通、不同的通讯手段的横向互通、不同的链路的冗余互通。只有高度互通的系统，才是快速响应的、高效的系统。应急指挥IT，绝不是一堆IT设备的物理堆砌，而一定是基于一个统一的硬件平台架构，通过分层和标准接口上下衔接，实现软件分步建设的业务目标。必然的结论是：越统一的底层平台，越有利于数据共享和业务分阶段建设；越标准的技术和管理架构，越有利于功能的发挥。无论哪行哪业，纵使所面对的应急业务种类大不相同，但以上两点应该是共通的准则。

万里长城作为标志性应急系统早已成为过去时了，现代人类社会所需要面对的应急事件复杂的多、也严重的多；现代人类社会所具备的技术手段也使得我们比之祖先能够做出更好的应急响应。社会应急被称为“亚战争”，可以预见的是，应急系统的建设和应用必将随着时间的推移不断在广度和深度上得以加强，应急IT系统也必将成为整合各类IT资源的最为重要的社会IT系统。我们时常从美国大片里面看到的紧张场景，随着应急IT系统的成熟，将成为我们生活中不可或缺的组成部分。有朝一日，当我们面对火灾、交通事故、地震、重大疫情的时候，整个社会由上到下，在应急IT系统的支撑下，井然有序的进行各种应对，这其中所体现的，不再是防御外敌这样的简单诉求，而是人类文明向高等级发展的重要标志。

因此，应急指挥，简单or不简单？恐怕我们得说，是一件非常不简单的事，但是如果我们把握住了信息特征这样一个本质，我们完全可以把它从简单做起。