智慧城市应急指挥中心值班指挥调度系统建设方案

新区应急指挥中心值班指挥调度系统技术方案 -表81：预案系统功能清单：表STYLEREF1\s8SEQ表\*ARABIC\s11：预案系统功能清单功能名称简要描述文本预案使用使用文本预案法律法规使用提供法律法规库的查阅其他各警种文本预案使用在处警时，根据案情类型进行文本预案提示资源预案使用根据事件的类型，在处警时可以自动弹出提示图形预案使用根据事件的类型、信息，调用地图、重点单位预案临时预案通过临时地图的编辑，输出临时预案运行预案维护对预案系统进行维护、修改。进行权限控制

系统接口设计基于XML信息交换标准 接口概述为了能够在异构平台、在不同的应用系统中实现数据交换和业务自动处理，必然涉及到数据和文档格式的标准化、统一化，需要建立一个能够描述不同系统之间的数据交换和业务处理流程的规范标准，以解决数据在处理过程中因标准不统一而引起的诸多问题。可扩展标记语言XML，是当前信息技术领域最重要、最活跃的发展之一，已经逐渐成为WEB领域的通用语言，也是进行企业应用集成的最佳语言规范。目前，在国家相关部门确定的电子商务和电子政务发展的总体标准中，也已经确定把XML作为数据交换的标记语言。作一个形象的比喻，XML就好像是不同应用系统中的普通话，通过它使纷繁复杂的不同应用系统不再讲各自的“方言”，而是通过XML这个普通话进行交流，这样大家都能以最简便的方式明白各自要表达的含义，实现彼此的沟通。XML信息交换系统的建设目的，就是通过XML这一种“普通话”，实现不同业务数据，不同信息之间顺畅的完成信息交换，是整个信息交换系统的基石。XML是一种具有数据描述功能、高度结构性及可验证性的置标语言。XML允许用户自行定义标记和属性，并可以依照所定义的标记与属性的语法来开发应用程序。XML可以通过标记来描述数据，或配合属性来辅助描述数据；并且可以借助验证规则来规范一个XML文件的内容和结构。XML文档是由XML元素、XML属性、XML实体组成的。这些元素、属性和实体描述了文本内容是如何组成的。元素是XML文档中最主要的组成部分，用于创建单独的数据块，实体描述XML中的存储单元。总的来说，XML语言主要特点有：XML数据交互的透明性、易读性与IPv4等底层通讯、数据交互协议不同，XML具备很强的透明性，它不但适合于”机读”，更适合于”人读”，XML的透明性使得人们可以更多地去关注交互的数据内容本身，而不用过多地去关心底层细节；XML的安全性与其他的数据交互方式不同，XML中不仅包含了交互数据的内容本身，而且还可以包含应用系统的安全属性信息，不符合安全设置的请求将被拒之门外，这提高了应用安全性、使得不同的角色具备不同的功能访问权限；XML的可靠性众所周知，IPv4具有无序不可控性、服务质量不可保障性和不可管理性等弱点，采用XML结合中间件IBMWebsphere等，可以确保数据交互的可靠性；XML的灵活性和可扩展性作为对SGML语言标准的一种改良，XML具备灵活性和可扩展性，同时，它又没有SGML规范那么复杂以致难于实施。作为一种标记语言，XML允许你任意定义标记以及多层次嵌套。正是由于XML的专业性和可扩展性，许多行业纷纷采用XML来制订行业的数据交互标准；XML的平台无关性、开发语言无关性XML与操作系统平台无关、与应用系统所采用的具体开发语言无关，正是这一点使之成为异构系统之间互联互通的国标通行标准，也成为第二代Internet互联网技术的技术基础。基于XML信息交换标准可分为两部分：信封格式规范和业务数据表示规范。其中信封格式规范主要用来描述信息从哪里来到哪里去、业务类别、事务编号等等；业务数据表示规范则描述的是具体业务数据内容定义。见下图：图表STYLEREF1\s9SEQ图表\*ARABIC\s11接口XML格式规范总体结构如图中所示，i-Switch为XML信息包的根节点，Envelope为XML数据包的信封部分，其中包括该数据相关的各种属性信息；BizMessage为业务大类名称，在具体应用时将会被“信用分类查询”、“信息发布”或“数据共享”等字符串所代替，BizMessage包含四个节点，标明访问者编号（SPID）、签名信息、加密信息及具体业务操作及内容（如Comand1、Comand2等）。接口信封格式规范如前说述，信封主要是数据包的一些有关属性信息，并不包含具体业务的内容，其主要信息包括：图表STYLEREF1\s9SEQ图表\*ARABIC\s12接口信封格式规范具体描述如下：版本号（Version）—表示当前所使用的数据类型定义（DTD）文件的版本；信息类型（ActivityType）——信息类型分为三类：管理类（Administration）、查询类(Inquery)、业务处理类(Transaction)信息。信息交换系统在对信息处理的时候，根据不同的信息的类型进行处理，并可根据需要添加类别；源服务ID（SourceID）——SourceID是请求信息发送方的信息交换系统统一分配的ID号；宿服务ID（DestinationID）——DestinationID是请求信息的最终接受方的信息交换系统统一分配的ID号；接入和服务代理ID（UserProxy）——UserProxy是服务代理商和接入代理商的服务ID号；终端类型代码（UserAgent）——UserAgent代表用户终端的类别，为了与HTTP协议中的终端类型代码的名称一致，故采用UserAgent来进行表示，这个信息在统一消息系统中可能会用到；服务流水号（TransmissionID）——服务流水号用于标识一个服务的请求和应答。在一对服务请求和应答中，服务流水号应该是相同的。也就是说，服务端在应答服务请求时，应该按照请求方的服务流水号来进行应答。会话号（SessionID）——表示在面向会话的服务处理中的会话标识；服务发起日期（DateOfService）——表示服务产生的日期；服务发起时间（TimeOfService）——表示服务产生的时间；服务类别（ServiceType）——表示服务的类型，包括信用分类查询、信息发布、数据共享、管理、系统信息等，可以根据实际业务的分类需要添加和修改；功能类别（CommandType）——表示某类服务中的不同的业务功能，例如数据共享中的企业登记信息共享等同一个业务类别下的不同功能。Envelope在整个信息交换系统的信息交换中起到关键性的作用。对于每个数据单元的具体含义如下：Version：表示信息交换系统中所用到的XML规范的版本号，如1.0等。SourceID：SourceID表示请求发送方的应用ID号，16个可见字节组成的字符串，其中前8个字节为连接的信息交换系统的编号，后8个字节表示应用系统。在整个请求的传输过程中，SourceID是不变的。DestinationID：DestinationID表示数据包目的方的应用ID号，16个可见字节组成的字符串，编码方式与SourceID相同。UserProxy：UserProxy是第三方接入代理和第三方服务代理的服务ID号。在第三方接入代理和第三方服务代理连接到平台时，采用UserProxy和对应的密码来进行接入验证。UserAgent：UserAgent代表不同的用户终端类别，可能的取值包括WEB、PDA、SMS等。UserAgent有一个可选属性ID，表示终端ID。比如PDA的编号等。TransmissionID：TransmissionID表示同一个业务的请求与响应消息包之间的匹配序号，是长度小于40个字节的可见字符串。TransmissionID可以通过信息交换系统提供的API接口获得。SessionID：SessionID表示通信双方的一次会话，采用64个字节长的可见字符串，可以通过信息交换系统的API接口获得。TimeOfService和DateOfServiceTimeOfService和DateOfService表示服务请求产生时的日期和时间。TimeOfService的格式为HHMMSS，采用24小时制。如，120314表示12时3分14秒。DateOfService的格式为YYYYMMDD。如，20000620表示2000年6月20日。ActivityType、ServiceType和CommandType：ActivityType、ServiceType和CommandType表示信息包的数据类别。ActivityType：表示整个信息包的大的类别。目前可选项为Administration、Inquery和Transaction。其中，Administration表示信息包为管理类的信息包，包括信息交换系统的管理子系统的信息包、系统控制信息包等；Inquery表示信息查询类包，比如信用分类查询等；Transaction表示业务处理类包，比如信用分类数据更新等。ServiceType：表示本信息包所承载的业务的类型。它的内容为业务数据的标识名，可由用户根据业务的需要任意定义和添加。CommandType：为某类服务中的不同服务功能。CommandType的值为服务功能的数据单元的Tag名。CommandType由一个属性Status，取值及含义如下：值 含义“0” Request“1” Broadcast“2” ReplyOK“3” ReplyFail“4” 单向通信，如主动通知其中“0”表示该数据包为一个请求数据包，“1”表示为广播数据包，“2”表示为一个成功应答数据包，“3”表示为错误应答数据包，“4”表示为单向通信数据包，如主动通知方式通信。 接口业务数据规范信封格式规范定义了业务相关的属性信息，保证信息能够正确的传输和解析，并不包含真正的业务数据。业务数据格式标准则由业务数据规范来定义。本节主要讲述业务数据定义方法及准则，具体业务数据规范参考“业务数据标准”节。业务数据规范包括数据定义和安全定义。数据定义XML是一种结构化标识语言，结构化描述对于复杂数据类型的可读性来说非常重要，XML的结构化带来的两个主要特点是：1）每个数据都有自己的名字和属性；2）每个数据项可以有子数据项。因此，在用XML对业务数据进行定义时，一定要按照这种结构化特点进行分析和构造。另外，如前面所述，信封中ServiceType和CommandType定义数据的业务分类和功能分类，提供了两级分类方法，ServiceType为父类，而CommandType隶属于ServiceType，为子类。在进行数据定义时，尽量根据业务数据的性质进行分类，也是为了方便管理和理解。安全定义在某些环境下，要求对传输的业务数据进行加密和签名。参见“XML格式规范总体结构”，BizMessage（业务类名）有两个特殊节点：Signature和Encrypt，Signature为数据包的签名信息，Encrypt为数据包的加密方法。具体见下图：图表STYLEREF1\s9SEQ图表\*ARABIC\s13接口数据包加密XML格式数据包加密方法定义包括两个部分：①加密字段是否加密标识，在所需要加密的字段中增加属性EncryptMethod来标识；②加密方法和参数描述，EncryptMethod为0表示不加密，1,2,3为不同EncryptedInfo中所描述的加密方法（加密方法和参数在加密方法描述中定义）。数据签名XML格式见下图：图表STYLEREF1\s9SEQ图表\*ARABIC\s14接口数据包签名XML格式如图中所示，Signature包含SignedInfo、SignatureValue以及KeyInfo三个节点，其中KeyInfo可选。SignedInfo描述签名的信息，包括签名方法、对象引用等，这里主要用到的子节点是SignatureMethod，即签名方法；SignatureValue为具体的签名内容，用Base64编码；KeyInfo中包含密钥的信息，包括具体签名方式的名称，签名私钥对应的证书等，这里主要用到KeyName和KeyValue两个子节点：其中KeyName为具体签名方式的名称，KeyValue为签名私钥对应的证书。业务访问标准业务访问标准是在XML信息交换的标准上，对指挥中心各个业务系统之间相互调用时的消息进行约定。在市局府指挥中心，业务访问接口基于Webservice来进行。业务接口的XML描述采用WSDL，业务协作流程的定义采用BPEL4WS来定义。其他标准参照WebServices的相关标准进行定义。业务数据标准业务数据标准是定义具体业务数据的数据元、数据结构等。一般包括数据元标准和业务数据结构标准。数据元标准数据元标准规定在指挥系统中涉及到的所有的数据字段标准。数据字段标准包括数据名称、数据标示、数据来源、数据所遵从的标准、数据的更新周期等。业务数据结构标准业务数据结构是由数据元按照不同的方式组合而成的。按照业务分类可以大致划分为：个人信息标准、权限信息标准、CTI数据标准、GPS数据标准、GIS数据标准、SMS数据标准、IVR数据标准、决策信息标准等。这些标准需要根据系统的实际情况来进行设计和约定。业务集成应用接口标准综合信息查询数据访问接口接口说明：系统通过接口实现相关业务数据信息的综合查询；接口形式：数据库中间件和WebService；接口主要功能：提供接处警、公安相关业务、人口、车辆等接处警业务相关信息的综合查询。CTI系统接口接口说明：系统通过接口实现有无线的通信基础集成，实现对话机/无线设备的状态监控，对有线/无线交换机的控制，并实现软电话的功能；接口形式：系统通过厂商提供的API接口进行交互，以实现各种交换机提供的功能；接口主要功能：签入、签出、座席状态设置、查询话机状态信息、外拨、挂机、电话会议、电话转移、会议拆除、电话保持等。 GPS系统接口接口说明：为系统提供GPS功能，包括下达命令、收发信息、轨迹回放、实时跟踪、查询车辆状态；接口形式：将座席的各种GPS操作请求转化成指令数据包，发送的GPS服务器，并将回应结果传送到请求的座席。接口主要功能：发送命令、发送/接收文本短消息、发送/接收图形消息、车辆状态查询、实时跟踪、车辆轨迹回放等。 录音系统接口接口说明：系统通过调用该接口取得相关话务的录音信息；接口形式：系统通过录音系统提供的API接口与录音系统进行交互；接口主要功能：监控录音通道、查询当前通话录音信息、录音文件生成、查询历史话务录音文件等。 视频系统接口接口说明：系统通过该接口使用相关视频播放和摄像头操作功能，使视频可以在CAD或GIS中实时显示；接口形式：系统通过视频设备提供的API接口或程序进行交互；接口主要功能：视频点的查询、历史视频播放、即时视频播放、云台操作等。 有/无线综合调度子系统接口接口说明：系统通过该接口使用有/无线调度平台，可以无缝集成有线、无线调度；接口形式：系统通过厂商提供的API函数无缝集成；接口主要功能：有线电话通信调度、无线电话通信调度、多方会议功能等。 短信网关接口接口说明：系统通过该接口使用已有的移动通信无线网关，可以充分利用覆盖广泛的移动通信网络，利用短消信机制进行命令、信息传达；接口形式：系统通过厂商提供的API函数无缝集成；接口主要功能：有线电话通信调度、无线电话通信调度、多方会议功能等。 非语音自动报警系统接口接口说明：系统通过该接口接收技防设备、民用GPS设备以及其他连接到自动报警服务器设备的报警信息；接口形式：系统通过相关设备厂商提供的API接口或定义的详细数据协议进行交互；接口主要功能：接收报警、判断报警性质、传递报警信息等。UTIR系统接口接口说明：当公网（PSTN）电话或短信网关打入系统后，系统通过此接口可以得到打入电话的四字段信息。四字段信息包括：机主姓名、装机地址、主叫号码、交线箱编号。接到四字段信息后，根据数据库中是否存在该记录及该记录是否是最新数据，系统自动在数据库中更新或添加数据；接口形式：系统物理上通过外置调制解调器建立与电信局的连接，当系统有呼叫到达时，电信局（中国电信、中国网通、中国移动和中国联通等）主动向此连接发送打进系统的报警电话的四字段信息；接口主要功能：四字段接收、四字段发送、测试包发送/接收、短信来电四字段查询等。IVR系统接口接口说明：系统通过该接口操作IVR设备；接口形式：系统通过IVR设备提供的API接口进行交互；接口主要功能：VIP电话识别、黑名单电话识别、自助语音咨询、指定咨询转接等。其它信息系统接口接口说明：系统根据用户的需求，通过该接口与原有的公安综合系统接口，并进行访问获取必要的信息，实现数据互访；接口形式：系统根据不同信息系统给出的协议，进行API开发实现；接口主要功能：原有信息系统数据查询、指挥调度系统信息输出、数据加密功能等。

系统安全及运行管理功能需求具有图形化用户界面的维护管理和告警模块。可以对主要模块进行配置管理。系统报警功能。当系统出现不正常情况时，需要提供报警功能。远程维护，同时后台详细记录维护情况。密码管理功能。日志管理功能。网络安全隔离设计鉴于应急指挥系统是一个设计到政治、经济领域至关重要的系统，在整个指挥中心的安全系统的考虑进行如下设计：利用物理隔离、逻辑隔离以及普通防火墙将整个网络划分为三大区域：与因特网采用防火墙隔离；第三方的业务系统（如短信中心、社会GPS中心、金融系统等）采用逻辑端设备隔离系统（符合公安部的端设备隔离规范）；所有涉密信息都通过物理隔离的方式对外交换。由于指挥决策子系统、远程接入子系统、综合信息子系统等都属于涉密子系统，所以，接处警系统、GPS/GIS系统、有线/无线调度系统与这些涉密系统的互通可采用短时间单项逻辑隔离或完全物理隔离的方式进行互通。在设备选择上进行可能采用国内完全自主知识产权的产品。安全策略安全策略是整个系统的安全基础，它是在充分分析用户需求，并对系统安全威胁、漏洞进行全面评估的基础上，所形成的一套基本框架和规则，通过确立诸如系统中什么可以被允许、什么不被允许等规则，从而在系统中形成一套原则、制度、方法和指导文档，用以规范工作人员、承建商、产品供应商、客户的详细责任和可接受的行为。业界专家建议，任何有关购买和使用安全产品或解决方案的决策，均应审慎地根据系统安全策略来作出。安全策略须反映出系统在信息系统和服务方面的安全需求，以及在保护系统关键信息资源时所需要采用的安全控制。安全管理策略安全管理是安全策略中非常重要的环节，也是容易出现漏洞的环节，在建立系统的过程中以及在项目完成后，都必须建立严格的管理规程，为了确保系统的安全，制定安全策略时需要重点考虑以下几个方面：建立安全管理小组，小组的成员要由熟悉CA系统操作的安全专家组成。安全管理小组负责安全措施的制定，并定期进行风险评估、安全审计。安全管理小组要定期对系统安全问题进行讨论，对于安全问题提供相应的解决方案。安全管理小组能够及时地对系统的安全问题做出响应，减少因处理不及时所造成的损失。任何部门出现问题之后，必须及时向安全小组报告。系统软件的更新和升级都必须要经过安全小组的测试和批准后才能进行。如果要在系统中安装软件，必须要经过安全小组的批准才能实施。数据安全策略系统中的数据来自很多方面，入侵者如果非法取得了系统的数据，就可能通过对其进行分析研究，而提高攻击成功的概率。因此对数据进行安全保护十分重要。在CA中心的数据中，就对系统安全性而言，最重要者莫过于CA私钥，因为如果CA的私钥失密后，所有由该CA所签发的证书都要作废，这样就会给系统带来严重的后果。对CA的私钥要采用多重保护方式，要分割私钥的操作、管理权限，以保证只有多数具有其管理权限的人员在场的情况下，才能对其进行操作。对用户数据（包括用户的证书以及用户的个人资料）的存取，要通过LDAP服务器进行限制。要根据相关的法律、用户的要求和CA中心的规定，确定限制措施，并将把用户的数据划分成不同的安全等级，利用LDAP服务器的安全机制对这些数据的存取权限进行限定，确保用户的私有信息不能被第三方非法获得。对系统中的关键数据，必须定期进行备份，所有的备份都必须存放在安全的地方，以便在发生意外时进行恢复。对于操作人员的操作进行键盘级记录，这些记录以加密的方式存放在硬盘上，同时也要定期备份。对这些数据，任何人不能进行修改，系统管理维护中心的审计人员只能阅读这些数据。通过CA中心签发的所有证书，必须进行存档保管，所有的证书只有在证书的有效期过后10年才能销毁。系统安全策略系统的安全策略要保证系统正常运行，防止其他因素造成对系统的破坏，从而给系统的安全带来影响；系统的安全还包括制定安全、严谨的证书操作规范（CPS），这是保证CA中心系统正常可靠运行的重要部分。CA要制定自己的CPS，并要在其运营过程中不断地完善，以保障系统的安全运行。在CA系统的服务器上，所有的软件都只能用于完成与CA系统有关的工作，不能用来做其他任何辅助性的工作。在系统的所有计算机上，要尽量避免安装其他的应用软件，特别是不要从Internet上下载任何应用软件，要防止计算机病毒的侵入。所有服务器的操作除了计算机系统本身要进行操作记录(操作日志)外，还要采用摄像等监控设备进行24小时监控。要控制对系统的访问，确保只有授权用户才能访问系统。在给各操作人员授予访问的权限的时候，要遵循“知所必须”的原则，只授予其所需安全权限的下限。所有服务器的操作人员要登录，都需要出示其数字证书。尽量要为每一个操作人员签发数字证书，用以授权他/她操作其职责范围之内的服务器；该数字证书要存放在IC卡上，只有使用这种数字证书才能进入系统。用户与核心业务系统的所有通讯要进行身份验证，以防止对系统的非授权访问，此外，两者之间的通信也要采取安全保护措施，防止第三方通过互联网窃取用户以及系统的信息，减少系统被攻击的机会。采用自动实时分析和监控软件，对系统的安全进行动态跟踪。这些软件可以是基于主机的，也可以是基于网络的。系统运行管理系统的安全问题不仅仅是技术上的问题，还包含管理上的因素，从某种意义上说，一旦确立系统的安全策略，并建立一定的安全技术体系，安全管理就成为保证系统安全的关键因素。安全管理是确保系统安全、稳定运行的极为重要的环节，安全技术必须与安全管理相结合才能发挥作用。安全管理包括人事安全管理、安全规章制度、安全组织机构、应急计划等，而人是其中的决定性因素。系统应该逐步建立一系列的安全管理制度，以用于规范整个系统的管理、操作人员的行为规范，这些规范包括：系统工作人员设置与职责、机房出入制度、系统日常操作、维护规范、安全扫描/监控工具使用规范、系统应急处理措施、安全审计制度等。安全操作操作安全规则将根据实际情况的不同，由系统的安全小组制定相应的规则，根据我们的经验，在操作规则方面应该包括以下内容：为每个操作人员签发一张数字证书，在数字证书的扩展域中，规定证书持有者的操作范围和操作权限，防止对系统的非授权操作。定期对操作人员进行技术培训，减少因操作人员的操作错误而造成的系统故障。对于软盘、光盘等设备的使用进行严格限制，未经安全管理人员的同意不得使用。严禁在运行CA系统的机器上执行无关工作，对于CA中心的证书签发服务器和RA的登记服务器，尤其要注意，以防对系统的安全造成威胁。证书的签发可以采用集中签发的操作方式，譬如，可以在每天的一个确定时间段里为审核合格的申请人签发证书；在不进行证书签发的时间里，服务器和CA私钥的存储设备要与网络系统断开连接，并且不得启动。安全审计首先系统应该对安全性事件进行记载，形成审计日志。安全性事件包括登录/退出系统、更换口令、更换密钥、签发证书等等。一般而言，操作系统、数据库管理系统、业务应用系统都具有审计功能，各自产生相应的审计日志。对这些不同层次的日志应该有统一的管理和规划，使其能够相互配合，避免漏审。其次，系统应该有专人负责分析审计日志，及时发现不安全线索，并采取措施，预防安全事故。系统容灾系统容灾的重要性应急联动系统建成后，将使一个城市应对紧急事件的能力大为提高，此时应急联动系统本身的安全性就显得非常重要。需要防止应急联动系统自身成为恐怖分子的袭击目标，不仅需要采取措施防范此类事件的发生，而且一旦发生了这样的事件，要有应对措施，能尽快恢复运作。应急联动系统建设时，应将容灾系统的建设列入考虑范围。造成应急联动与社会综合服务系统中断运行，除了恐怖袭击这样的人为灾难外，主要有自然灾难和慢性灾难两种形式。自然灾难包括：飓风、龙卷风、地震、洪水、火灾等。慢性灾难是指人们在平时可能意识不到的灾难，它潜伏在人们的日常工作过程中，是对IT架构及其相关组件操作、运行过程中积累下来的灾难，它包括计算机/网络犯罪、计算机病毒、掉电、网络/通信失败、硬件/软件错误和人为操作错误。备份在日常工作中，人为操作错误、系统软件或应用软件缺陷、硬件损毁、电脑病毒、黑客攻击、突然断电、意外宕机、自然灾害等诸多因素都有可能造成计算机中数据的丢失，给企业造成无法估量的损失。数据的丢失极有可能演变成一场灭顶之灾。因此，数据备份与恢复对企业来说显得格外重要。数据备份，是指为防止系统出现操作失误或系统故障导致数据丢失，而将全系统或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。传统的数据备份主要是采用数据内置或外置的磁带机进行冷备份。一般来说，各种操作系统所都附带了备份程序。但是随着数据的不断增加和系统要求的不断提高，附带的备份程序根本无法满足日益增长的需求。要想对数据进行可靠的备份，必须选择专门的备份软、硬件，并制定相应的备份及恢复方案。目前比较常见的备份方式有：定期磁带备份数据。远程磁带库、光盘库备份。即将数据传送到远程备份中心制作完整的备份磁带或光盘。远程关键数据＋磁带备份。采用磁带备份数据，生产机实时向备份机发送关键数据。远程数据库备份。就是在与主数据库所在生产机相分离的备份机上建立主数据库的一个拷贝。网络数据镜像。这种方式是对生产系统的数据库数据和所需跟踪的重要目标文件的更新进行监控与跟踪，并将更新日志实时通过网络传送到备份系统，备份系统则根据日志对磁盘进行更新。远程镜像磁盘。通过高速光纤通道线路和磁盘控制技术将镜像磁盘延伸到远离生产机的地方，镜像磁盘数据与主磁盘数据完全一致，更新方式为同步或异步。备份是数据高可用的最后一道防线，其目的是为了系统数据崩溃时能够快速的恢复数据。那么就必须保证备份数据和源数据的一致性和完整性，消除系统使用者的后顾之忧。其关键是在于保障系统的高可用性，即操作失误或系统故障发生后，能够保障系统的正常运行。如果没有了数据，一切的恢复都是不可能实现的，因此备份是一切灾难恢复的基石。从这个意义上说，任何灾难恢复系统实际上都是建立在备份基础上的。容灾但是光有备份是不够的，容灾必不可少。从广义上讲，任何提高系统可用性的努力，都可称之为容灾。但是现在人们谈及容灾往往只是针对慢性容灾而言。在系统设计中，企业一般会考虑做数据备份和采用主机集群的结构，因为它们能解决本地数据的安全性和可用性。这是针对慢性容灾的本地解决方案，如果当某台主机出现故障，不能正常工作时，其它的主机可以替代该主机，继续进行正常的工作。目前人们所注意到的容灾，大部分也都只是停留在本地容灾的层面上。对城市应急联动与社会综合服务系统来讲，光有本地容灾是远远不够的。其关键业务应用，必须要防范地震、恐怖分子破坏等灾难，应该采用异地容灾的保护措施。因此，一套完整的容灾方案应该包括本地容灾和异地容灾两套系统。另外，容灾系统必须要考虑到系统恢复的问题。采取系统定期检测与维护、双机热备、磁盘镜像或容错、备份磁带异地存放、关键部件冗余等这些灾难预防措施，一般能够进行数据备份，并且在系统发生故障后能够进行系统恢复。但是这种一般的措施只能处理计算机单点故障，对区域性、毁灭性灾难则束手无策，也不具备灾难恢复能力。因此，仅有这些措施还不够，其关键业务必须实施远程容灾保护。远程容灾系统具备应付各种灾难特别是区域性与毁灭性灾难的能力，具备较为完善的数据保护与灾难恢复功能，保证灾难降临时数据的完整性及业务的连续性，并在最短时间内恢复业务系统的正常运行，将损失降到最小。其系统一般由生产系统、可接替运行的后备系统、数据备份系统、备用通信线路等部分组成。在正常生产和数据备份状态下，生产系统向备份系统传送需备份的数据。灾难发生后，当系统处于灾难恢复状态时，备份系统将接替生产系统继续运行。容灾系统的核心技术是数据复制。复制，顾名思义就是将数据库中的数据拷贝到另外一个不同的物理点上。目前主要有同步数据复制和异步数据复制两种。同步数据复制，指通过将本地生产数据以完全同步的方式复制到异地，每一本地IO操作均需等待远程复制的完成方予以释放。异步数据复制则是指将本地生产数据以后台同步的方式复制到异地，每一本地IO操作均正常释放，无需等待远程复制的完成。数据复制对数据系统的一致性和可靠性以及系统的应变能力具有举足轻重的作用，它决定着容灾系统的可靠性和可用性。恢复演习无论怎样的容灾防案，其最终目的都是在于灾难发生后能够在可以接受的时间内快速恢复系统的正常运行。那么建立的系统在灾后能不能快速恢复呢？这就需要系统在正常运行时能够进行灾难恢复演习，只有这样才能保证容灾系统确实可行。第一要明确灾难恢复演习不能以停机为代价，更不能够演习之后系统无法正常运行。第二要明确问题。建立实际的灾难恢复计划是一个非常复杂的过程，一定要分析清楚：什么是最大的风险？系统对那些灾难最为敏感？系统停机时的影响是什么样子？同时要进人员分工，当发生灾难时，谁将负责数据恢复？谁负责监控设备？等等，这些都必须在演习中明确分工，并且按照计划执行。第三要定时不定时进行演习。仅仅制定出一个计划是不够的。不论计划多么严密，必须对其进行测试——不是一次，而是经常测试。容灾系统必须跟得上环境的变化。恢复演习也应如此。是否开展了新的业务？是否有新应用加入到了系统之中？系统恢复小组成员是否变化？这些都是在演习中应该考虑的重要因素。目录1 项目概述 51.1 建设背景 51.2 建设目标 52 系统设计特色 62.1 系统特色 62.2 技术特色 62.3 功能特色 73 系统总体设计 93.1 设计原则 93.2 需求分析 113.2.1 性能需求 113.2.2 基本数据库及查询功能 113.2.3 救助受理功能 123.2.4 系统管理功能 123.2.5 席位设置 133.2.6 控制台系统 133.2.7 交换机系统 133.2.8 VoIP性能与组网 143.2.9 业务功能需求 153.2.10 调度通信平台能指标 183.2.11 电话系统 193.2.12 录音和存储系统 193.3 方案思路 203.4 体系结构设计 203.4.1 系统拓扑结构 203.4.2 系统软件架构设计 213.4.3 系统子系统构成 224 有线通信调度平台子系统 234.1 技术特色 234.1.1 调度通信平台高可靠性 234.1.2 网络可靠性保证 244.1.3 容量拓展 254.2 系统设计概述 255 CTI中间件子系统 275.1 开发中间件平台 275.2 CTI应用