4.4 核心处理能力要求

4.4.1 总体概述

如图4-23所示为大数据核心处理能力系统的总体架构。需要注意的是，实时处理的数据分层模型可依据实际情况而有所不同。

1．接口层

（1）概况

接口层面向外围数据源，负责进行数据统一采集工作，管理外部数据的来源、数据结构、接口方式、格式要求、质量要求等信息。数据模型与源系统基本保持一致。接口层数据按实时或准实时、按天、按月更新。

（2）设计目标

接口层设计目标如下。

① 完整性：保证源系统输入模型的完整性、数据字典清晰明确。

② 及时性：数据更新的频度与源系统接口数据更新频度基本一致，保证输入信息的及时性。

③ 一致性：接口数据一般不做清洗和转换，以保证和源系统信息的一致性，做到信息可追溯、过程可查。

（3）设计要点

接口层设计要点如下。

① 接口同步协议的约定：接口采集时间、频度、访问方式、抽取方式、触发条件、验证方法、重处理机制。

② 接口数据字典的约定：明确接口数据内容，包括数据结构、数据存储方式、编码解释等。

③ 数据模型结构和源系统的模型结构基本保持一致；数据不做清洗、转换；可以增加辅助信息，例如区分数据域、主题、地域、账期、频度等。

④ 统一命名规范。

2．整合层

（1）概况

整合层在接口层的基础上，整合各孤立的业务数据模型，建立一套面向主题的企业级数据模型。整合层中的数据原则上是统一编码格式数据，可作为企业数据标准指导外围系统逐步统一数据格式。整合层的数据包含与接口层同步的最新数据，以及按天或月等与业务需求相关的拍照数据。

（2）设计目标

整合层面向主题，按照企业数据模型统一定义。整合层设计目标如下。

① 一致性：整合层模型对多个数据源进行统一清洗、编码转换，保障数据的可用性。

② 及时性：数据更新的频度与源系统接口模型的数据更新频度基本一致，保证输入信息的及时性。

③ 完整性：整合层数据是企业数据存储的核心，应确保数据的厚度和广度。

（3）设计要点

整合层设计要点如下。

① 数据清洗：识别和清洗无效、无用、异常信息，确保数据的规范和有效。

② 数据转换：统一主数据编码，将相同含义不同编码的信息进行统一，根据设定的转换规则将源系统数据转换为统一的数据格式。

③ 数据格式规范：根据数据特点和应用要求，建立统一的数据格式。

④ 数据存储：遵照企业的需求进行分类组织。

3．中间层

（1）概况

中间层位于整合层和汇总层之间，形成以业务实体核心、基础属性、扩展属性为主体信息的数据模型，它以应用为目的提炼整合层信息，采用碎片化方式处理和存储，支持快速敏捷的数据处理、支持应用数据的快捷组装，满足应用需求多样化、及时性的要求，最大程度降低模型间耦合度。

● 中间层主要由三类表构成，基础宽表、属性表和维表。

● 基础宽表：根据应用主题将稳定的、事实的、共性的业务实体属性进行整合或轻粒度汇总，完成简单维度转换，保留原始编码，保留复杂业务口径的最细计算因子，不含业务口径的标签及维度。

● 属性表：因业务的不确定性，为确保基础宽表的稳定性，和应用模型的快速扩展性，将部分业务规则不稳定、易变化的属性信息整合形成属性表。

● 维表：维表是对模型属性、维度的描述性信息集合，可具备多层、树状等结构形式。维表信息模式属于快照类、静态信息。不含标签类信息。

（2）设计目标

中间层设计目标如下。

① 低耦合：合理定义基础属性、扩展属性，避免属性定义重复、冗余出现；

② 稳定性：保持基础宽表模型的稳定性，通过属性表解决扩展属性变化频繁的问题；③ 高效性：模型解耦设计兼顾应用灵活组装和高效数据更新。

（3）设计要点

中间层设计要点如下。

① 采用星形建模，形成业务主体+基础属性或扩展属性基本结构。

② 模型的基础处理功能设计如下。

● 数据整合：明确业务主体，整合相关基础属性形成复杂业务维度及标签需要的基础因子。

● 数据映射：根据应用共性要求形成不同层次、不同角度的基础维度信息，并建立源编码和维度值一对一或者多对一的映射关系。

● 数据属性标识：根据业务主体的规则完成属性标识计算，以及提供复杂口径的计算因子，如战略分群、上网偏好特征等。

● 数据汇总：按照一定的口径规则汇总业务实体的基础特征数据。

③ 模型的内容设计，通常按照加工方式和数据特点将属性信息分为四大类：实例对象信息、基础属性维度、统计维度信息、统计指标信息。

● 实例对象信息：以源数据为主，不做任何加工处理的实例化信息，如产品实例ID、用户装机时间等。

● 基础属性维度：以源数据为主，不做任何加工处理的属性类信息，如CRM产品规格、CRM销售品规格、终端类型等。保留源系统编码是非常有必要的，此类数据可以没有对应的维表，但必须有对应的编码解释。

● 统计维度信息：是通过将基础属性进行转换或归集得到的、有标准编码规范的、有层次的维度信息。

● 统计指标信息：是体现业务主体某种业务特征规模的统计值，通过一定规则汇总形成，单位上保留原始单位，只做单位统一、不做单位转换，以免降低指标精度，如流量、邮箱登录次数、投诉次数等。

4．汇总层

（1）概况

汇总层面向应用，是为支撑跨域企业级的数据分析、数据挖掘、即席查询等而形成的多级汇总数据层。包括以用户、客户等实例为粒度的应用宽表，以指标为粒度的指标集市，以应用标签为粒度的标签集市。其中，应用宽表与基础宽表的区别在于，应用宽表完成跨域数据整合，可来源于基础宽表、属性表、指标、标签信息。基础宽表完成业务主体相关的稳定的、事实的、共性的信息整合。汇总层包括：

● 指标集，根据指标业务规则定义生成的指标实例数据。

● 标签集，根据业务规则定义生成的标签实例数据。

● 应用宽表，从客户和管理的角度构建应用宽表，如宽带产品宽表，包含宽带产品基础信息、属性信息、标签信息、资源信息、成本信息等。

（2）设计目标

汇总层设计目标如下。

① 指标集

● 提供以指标分析为主的数据应用支撑，防止因业务理解差异造成的数据质量问题。

● 提高指标复用度，达到一点修改多点变化的目的。

● 建立完整的企业级指标仓库，满足共性需求。

● 配合指标维度提升支撑灵活性。

② 标签集

用最简单的数据表现形式体现客户的基础特征、业务特征，提升使用的灵活度；原则上标签通过“是否”的方式进行实现。

③ 应用宽表

● 继承性原则：模型中，对于EDA的核心实体和相关概念，在不影响理解的前提下，尽量不提出新的概念。

● 稳定性原则：为保证模型的稳定性，实体与规则分离，突出核心实体的描述，提出规则点，对规则本身不做详尽描述。

● 前瞻性原则：为保证模型的前瞻性，模型适当超前，能够适应业务的发展变化。

（3）设计要点

汇总层设计要点如下。

① 指标集

● 数据和元数据分离，数据模型中只存在指标编码和指标值，通过指标库获取指标元数据。

● 维度信息一般采用层次结构中最细层次的维度值，避免相同维度不同层级不同字段的设计。

● 指标字段单位保留原始单位，只做单位统一、不做单位转换，以免降低指标精度。

● 模型基本结构保持统一，由指标编码、基础维度（如账期和地域）、支持的业务维度、指标值四类信息构成，针对不同指标，除支持维度数量不同外，其他字段信息没有差别。

② 标签集

● 采用数据和元数据分离的设计思路，数据模型中只保留业务实体实例编码、标签编码和标签值；通过标签库获取标签规则。

● 模型基本结构保持统一，由业务实体实例编码、基础维度、标签编码和标签值构成。

● 针对复杂的标签，保留生成过程中引用的基础标签信息。

③ 应用宽表

● 为保障模型稳定性、完整性和前瞻性的目标，以客户和管理两种视角整合相关信息，以应用主题为主键，聚合企业级数据基础信息、属性信息、标签信息、指标信息，形成主题宽表，允许信息冗余。

● 采用自顶向下的建模方法。模型内分级设计。

● 宽表信息唯一来源于中间层和标签集、指标集，不允许宽表相互间存在血缘关系。

● 维度信息一般采用最细层次的维度值，避免相同维度不同层级不同字段的设计。

5．应用层

（1）概况

应用层是提供给应用功能、外系统直接访问的数据层。因报表效率高、个性化的展现方式和数据提供方式的不同，要求单独建立数据层为各类应用提供数据支撑，方式可以通过表、视图、文件、消息等。

（2）设计目标

应用层整体设计目标为：提高访问效率、提升访问安全、减少应用过程对基础资源的影响、满足个性化访问要求。数据可来源于从整合层到汇总层的所有数据模型。

① 报表应用：支撑多维的报表访问格式、支撑横纵表头访问；数据和元数据分开访问，即数据的描述信息单独提供；支撑跨时段数据提取。

② 查询应用：支持关键字快速检索；查询属性灵活扩展。

③ 挖掘应用：独立建模，以前瞻性为主要原则，模型适当超前，聚合业务主体相关属性、适应业务的发展变化。

④ 多维自助应用：支撑多维数据快速检索、快速汇聚，提供多层级粒度的汇总数据。

（3）设计要点

应用层设计要点如下。

① 采用维度建模方式，形成多维数据模型。

② 多层级维度，一般要求在应用层形成多层级粒度的汇总数据。

③ 按照应用要求设计字段格式、转换数据单位。

④ 数据来源于接口层、整合层、中间层和汇总层，不同应用可以共用应用层数据。

6．数据存储周期策略

数据存储周期根据数据类型、存储内容、数据粒度等几个纬度进行区分，再根据接口层、整合层、中间层、汇总层及应用层分别采取不同的存储时间，如表4-6所示。

接口层数据滚动存储，整合层和接口层数据采取离线方式存储至5年。冷数据备份方式建议采用基于光盘技术的冷数据备份方式。

7．命名规范

如表4-7、表4-8和表4-9所示为大数据核心处理能力系统中各个部分的命名规范表。

4.4.2 数据模型

1．总体建模原则

如图4-24所示为数据模型总体建模原则。数据模型的整体设计思路为横向分层、纵向分域、域内分表、横纵结合。按数据处理流程，横向将数据分为整合层、中间层、汇总层。按数据来源与数据类型将整合层数据模型分为参与人、产品、账务、营销、事件、地域、财务、资源。建模时应贯彻如下理念。

① 前瞻性理念（Prospective）：模型要满足当前功能需求，同时不拘泥于需求，要依据企业数据流图，做全面分析；设计要全面，落地可分阶段。

② 扩展性理念（Extendibility）：数据模型设计环节要考虑扩展性，维表预留是大数据模型扩展性常用策略。

③ 可维护性理念（Maintainability）：将共性的、可复用的标签、指标，甚至子报表元素加工逻辑剥离出来，提高部分加工逻辑的复用性。解耦可复用逻辑，可以屏蔽底层模型变化对应用层的影响。

④ 健壮性理念（Robust）：新需求、新应用不断对数据模型提出挑战，健壮性是模型维护阶段，不断积累，不断追求的目标。

2．数据建模过程

整个数据建模的过程包括业务建模、概念建模、逻辑建模、物理建模。

① 业务建模：生成业务模型，主要解决业务层面的分解和程序化。

● 划分整个单位的业务，一般按照业务部门的划分，进行各个部门之间业务工作的界定，理清各业务部门之间的关系。

● 深入了解各个业务部门内的具体业务流程并将其程序化。

● 提出修改和改进业务部门工作流程的方法并程序化。

● 数据建模的范围界定，整个大数据核心处理能力系统项目的目标和阶段划分。

② 概念建模：主要是对业务模型进行抽象处理，生成领域概念模型。

● 抽取关键业务概念，并将之抽象化。

● 将业务概念分组，按照业务主线聚合类似的分组概念。

● 细化分组概念，理清分组概念内的业务流程并抽象化。

● 理清分组概念之间的关联，形成完整的领域概念模型。

③ 逻辑建模：生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。

● 业务概念实体化，并考虑其具体的属性。

● 事件实体化，并考虑其属性内容。

● 说明实体化，并考虑其属性内容。

④ 物理建模：生成物理模型，主要解决逻辑模型针对不同关系数据库的物理化以及性能等一些具体的技术问题。

● 针对特定物理化平台，做出相应的技术调整。

● 针对模型的性能考虑，对特定平台做出相应的调整。

● 针对管理的需要，结合特定的平台，做出相应的调整。

● 生成最后的执行脚本，并完善之。

3．数据建模体系架构

借鉴SOA与DOA设计方法及考虑应用与数据变化趋势，构建以数据为引擎、管理为手段、服务为载体的生态化的数据模型体系。

（1）面向服务的体系架构

面向服务的体系架构SOA是一类分布式系统的体系结构，其将异构平台上应用程序的不同功能部件（称为服务）通过这些服务之间定义良好的接口和规范按松耦合方式整合在一起，即将多个现有的应用软件通过网络将其整合成一个新系统。如图4-25所示为SOA体系结构图。

（2）面向数据的体系架构

面向数据的三层体系架构DOA是采用“面向数据和以数据为核心”的思想，通过数据注册中心（DRC）、数据权限中心（DAC）和数据异常中心（DEC）统一定义数据、管理数据和提供数据服务。通过数据应用单元（DAUs）对各种应用进行管理和服务，建立一种数据大平台与碎片化应用的数据生态系统。它是为构建大数据时代从数据保护到授权应用整套机制的软件体系结构进行的有益探索。如图4-26所示为DOA体系结构图。

4．数据建模方法

（1）范式建模法

范式建模法主要是为解决关系数据库的数据存储而用到的一种技术层面上的方法，适用于逻辑建模阶段。如图4-27所示。

（2）维度建模法

维度建模法是按照事实表、维表来构建数据模型、数据集市。这种方法的最被人广泛知晓的名字就是星形模式（Star-schema），该建模方法适用逻辑建模阶段。如图4-28所示。

（3）实体建模法

实体建模方法是将任务业务分成实体、事件、说明三个部分，如图4-29所示。

① 实体：主要指领域模型中特定的概念主体，指发生业务关系的对象。

② 事件：主要指概念主体之间完成一次业务流程的过程。

③ 说明：主要是针对实体和事件的特殊说明。

4.4.3 数据处理

1．ETL过程

ETL过程，是数据处理最重要的步骤之一。ETL规则设计和实施工作量巨大，是构建大数据核心处理能力系统成败的关键。对于核心处理能力系统来说，ETL的主要工作是集成、转换、汇总等，最后将处理完的数据加载到相关存储设备中。

2．ETL调度管理及策略

ETL流程管理调度是ETL过程中的统一调度者和指挥者，它把复杂的数据处理过程中的各个步骤整合成一个整体。管理调度程序的主要功能包括ETL的调度和ETL的监控。

ETL工具具备统一调度、统一监控和统一管理的功能。在统一调度方面，通过界面进行配置后，能够统一进行调度程序的启动和停止。可以在不同阶段调用相应的资源进行处理，支撑ETL的整个过程。

建立可统一调度的ETL处理过程，可以对各类数据进行整合并保障数据质量。提供图形化工作界面，可以快速简单地定时调度，同时可以监控运行任务的运行日志。ETL调度策略包括以下几点。

● ETL作业流程管理应提供复杂的ETL处理能力，包括但不限于作业依赖、作业触发、定时触发、作业优先级配置、最大执行作业数控制、生效/失效程序调节、异常报警等功能。

● 并行机制：对于某一流程来说，其不同周期的数据运行没有相应的依赖关系，建议采用并行调度机制，实现多个时间周期的同一流程并行调度。

● 串行机制：对于某一流程来说，其不同周期的数据运行存在强烈的依赖关系，建议采用串行调度机制，实现同一流程按照时间周期有序调度。

● 依赖等待机制：对于某一流程来说，不同周期的数据运行在后续某一阶段存在一定依赖关系，建议采用依赖等待调度机制，首先实现按照无依赖关系的分支流程并行调度，当流程运行至需要依赖的前一节点实现相互等待，然后实现统一调度环节。

● 紧急干涉机制：对于某个流程来说，其不同周期的数据没有什么依赖关系，但因为数据的重要程度和紧迫性要求，建议进行流程的人为重置和调度，以满足数据的加工要求。

3．ETL异常处理机制

ETL作业过程会发生各种异常，需要在设计时考虑各种异常监控及处理机制。

4．ETL作业流程监控

ETL作业流程监控主要涉及ETL的监控范围、监控点、监控内容、异常级别以及异常通知机制。

① 异常监控范围：以各时间段内需要执行或者执行完成的ETL作业作为监控对象，主要涉及ETL作业的计划开始时间、计划完成时间、执行时长范围、质量监控点、任务级别、责任人、应急预案等。

② 监控点：ETL作业的异常监控点，主要是执行时间要求、数据质量情况等。

③ 监控内容：作业是否在正常时间开始执行，作业执行时长是否超时，作业是否发生错误，作业处理数据结果是否满足质量要求。

④ 异常级别：指ETL作业异常的影响严重程度，相同监控点会有不同的严重程度，比如根据作业超时长短逐步升级。异常级别通常分为警告、报警、错误、严重错误等。

⑤ 通知机制：指ETL作业执行异常时的报警通知机制及方法，一般需实时通知。通知方式包括短信通知、邮件通知以及通过系统界面信息提示等。

5．ETL作业异常处理

ETL作业异常处理大致可分为人工处理和系统自动处理。对于可修复情况由ETL自动处理，比如网络连接错误，系统设置重新执行次数及间隔，在预警的同时尝试重新处理。否则采取人工处理方式。异常处理可分为以下几种。

① 警告（Warning）

ETL处理结果存在稽核差异，但尚在经验范围之内，不影响数据质量和流程处理的信息。

处理方式：后台记录该信息，所在的ETL流程继续执行。

② 报警（Alert）

ETL处理结果与期望结果差异较大，超出了经验波动范围，可能存在数据质量和流程处理的问题，需要进行跟踪复查。

处理方式：所在的ETL流程继续执行，但是将报警错误发送给维护人员。

③ 错误（Error）

ETL流程无法正常执行，影响后续流程的正确性；或者ETL处理结果存在重大错误。

处理方式：ETL流程暂停执行，以短信的形式将错误信息发送给维护人员。

④ 严重错误（Fatalerror）

错误后果影响重大，总部的数据应用无法正常提供统计分析功能。

处理方式：ETL流程立即中止，以短信的形式将错误信息发送给维护人员和监控人员，需要人为对出现的错误进行修正和流程重置。

6．ETL监控

（1）监控对象

ETL监控支持对整个ETL过程的调度、执行及异常情况进行查询，查询对象包括：

● ETL执行过程；

● ETL调度计划和任务；

● ETL执行状态信息；

● ETL节点处理日志信息；

● ETL结果统计信息；

● ETL异常信息及跟踪。

（2）监控角色

ETL监控支持按角色分别查看不同服务内容，服务角色包括：

● 局方信息化人员；

● 局方实施和维护人员；

● 建设厂商管控人员；

● 建设厂商运维人员；

● 相关环节交互人员。

（3）监控功能

通过统一界面对ETL流程进行监控，监控的内容包括以下两点。

① 整体情况监控：监控流程处理的整体进度情况，包括某个时间段内各类流程成功执行、正在执行、失败的流程数等。

② 外部接口监控：监控外部接口的到达、传输情况，统计接口到达的及时性、合法性、文件个数，以及MD5校验、解压缩、合并等操作的处理情况。

（4）入库情况监控

对外部数据的入库情况进行监控，包括入库起始时间、结束时间、入库执行情况、入库记录数、入库次数、入库异常情况等信息。

（5）处理流程监控

监控各层处理节点的执行情况，包括处理时间、调用参数情况、处理执行情况、异常反馈信息等。

4.4.4 数据质量

在数据处理平台系统中，所依赖的各类源数据是非常复杂和广泛的，这些源数据存储在不同的业务系统和网络平台上，数据处理系统需要做的是将这些源数据系统的数据信息合并到统一的系统中。

数据质量对于数据平台而言是至关重要的，在不一致、不准确的数据基础上所做的分析和挖掘工作同样也是不准确的。低质量的数据会直接影响数据应用和数据分析的及时性和准确性，而产生的分析结果（输出数据）在与源数据系统的互动中又进一步影响到公司经营活动的各个方面。因此，如何保证输入输出数据的数据质量就成为数据处理平台与源数据系统之间互动应用成败的关键。

1．数据质量稽核要求

在大数据平台核心处理系统中，数据在不断地进行分层汇总，来自一个数据接口数据可能被多个数据集市使用，底层的数据问题很容易被放大，这称为“误差放大效应”。由于大数据平台中的数据存在这种层次间放大的特点，数据稽核必须重视最初的数据处理环节，从数据接口开始就必须进行认真核查，并且在整个系统运营过程中，数据稽核必须在每个环节完成之后都要进行，以避免数据错误被不断扩大。数据稽核的目的是保证数据在处理过程的各个环节中正确、完整。

稽核点选取原则是依据各数据层特性及数据质量，检查五个共性：及时性、完整性、一致性、准确性、逻辑性。

① 及时性：指数据刷新、修改和提取等操作的及时性和快速性，要按规定时限要求完成，如各级数据提供责任部门必须按经营数据管理时限要求完成工作。

② 完整性：从数据定义、数据录入、规则约束三方面保障数据的完整。如实体不缺失、属性不缺失、记录不缺失、字段值不缺失、主键不缺失。

③ 一致性：同一信息主体在不同的数据集中的信息属性应相同，如各级报表统计口径一致，使得出现差异的原因可解释，可追溯。

④ 准确性：包含了真实性和准确性，真实性是数据符合事实、标准或真实情况，没有误差或偏差；准确性是数据值与设定为准确的值之间的一致程度，或与可接受程度之间的差异。如某指标的准确程度。

⑤ 逻辑性：各项数据之间符合业务逻辑关系，如在业务口径一致的基础上，报表的各项数据之间符合相应的逻辑关系，尤其表现在数据之间。

2．稽核点类型及要点

技术稽核：需按照接口方式来定义，如文件方式、DBLINK、数据库Log方式等，主要包括文件规范性稽核，文件数稽核，记录数总量稽核，记录数分量稽核，检查分类型的记录数是否符合校对文件的描述。

业务稽核：指对客户数、发展量等进行业务指标阀值校验、业务指标总量稽核、业务指标分量稽核等。

3．整合层稽核

整合层是对接口层进行数据转换、清洗、整合加工的过程，重点关注数据处理过程本身的操作正确性和完整性，根据数据处理的不同环节和实际的业务要求设立不同的稽核点，从技术和业务两个层面对数据进行验证。

如图4-30所示，数据稽核方法主要有总量稽核法、分量稽核法、指标稽核法。

① 总量稽核法：对数据从接口层到整合层环节的数据总量进行稽核验证，确保数据的完整性，主要指标包括数据总记录数、总费用金额等。

② 分量稽核法：在接口层到整合层数据总量验证正确的前提下，需要对数据分布的情况进行稽核验证，在这个过程中，需要对每个维度的有效性进行验证，比如主数据编码是否合法，还需要对多个维度的组合分布的稽核指标进行验证，比如验证组合维度的总计、最大、最小、均值等度量指标，确保数据分布的正确性。主要指标包括：客户总数、账户总数、产品总数、总收入等。

4．中间层稽核

中间层稽核应同样采用整合层稽核方法，同时也需要增加一些汇总方式的稽核，包括以下几点。

① 业务逻辑性稽核：业务逻辑性稽核应进行多维度稽核，如客户群稽核、地域稽核、量收稽核等。具备对常规影响因素的组合分析，如周期性影响因素、节假日影响因素、业务变更影响因素、市场竞争影响因素、配置规则调整因素等。

② 一致性稽核：保证各整合层分类汇总值在中间层一致，如整合层的总通话时长和中间层是否一致以及不同中间层的相同指标是否一致。

③ 及时性稽核：保证中间层数据在约定时间点前完备稽核。

5．汇总层稽核

汇总层稽核可以从经验值、逻辑阀值、常规影响因素等方面对数据进行稽核。

① 业务逻辑性稽核

● 经验值稽核：日、周、月、年等维度的环比、同比，周均值对比的波动百分率稽核方法等周期性稽核。

● 逻辑阀值稽核：确保数据汇总结果之间的逻辑、平衡，同时保证汇总层数据按业务要求能及时展示。

② 常规影响因素稽核

方法同中间层稽核方法。

③ 技术稽核

● 一致性稽核：保证中间层分类汇总值在汇总层一致。

● 及时性稽核：检查数据的更新时间。

● 完整性稽核：保证各类指定汇总数据按约定展示项目完整展示。

4.4.5 系统性能

① 开放性

开放性与标准化是系统赖以生存发展的基础，系统建设必须基于业界开放式标准，以保证系统的生命力，保护投资，体现良好的扩展性和互操作能力。

② 健壮性

系统健壮性要求如下。

● 排除人为误操作因素，只考虑由应用系统自身原因导致的系统崩溃故障，则平均无故障时间应大于365天，平均修复时间应小于4小时。

● 核心处理能力系统必须支持连续7×24小时不间断地工作，应用软件中的任一构件在更新、加载时，在不更新与上下构件的接口的前提下，不影响业务运转和服务。

● 核心处理能力系统必须采用增量备份和全备份相结合的方式定期备份重要的系统数据。

● 核心处理能力系统必须支持负载均衡技术，支持应用分布式部署在多台服务器上，避免应用系统的单点故障。

● 核心处理能力系统应具有良好的并行处理机制，对存取冲突的竞争具有有效的仲裁和加锁机制，充分保证事务处理的完整性，并降低系统I/O开销，提高并发用户查询和存取的性能。

● 核心处理能力系统能够正确识别外围系统发的错误请求及重复请求，避免出现一些不可预测的结果。

③ 兼容性

支持IE6及以上版本、Chrome、Safari等浏览器，系统可在Linux等多个系统运行。

④ 可扩展性

系统设计应充分考虑扩展性。系统设备必须能充分估计未来的扩展情况，系统设计必须是模块化、可配置，能够适应一定时间内的业务变化，并保证系统在进行扩展时，不影响系统的正常运行。

⑤ 可维护性

系统可维护性要求如下。

● 系统在运行过程中所发生的任何错误都应该有明确的错误编号，并能在系统的相应维护手册中查到错误处理方法与步骤。

● 应用系统应该支持通过统一的图形界面，监控各应用构件的运行状态。

● 应用系统必须支持通过统一的图形界面，能够监控到应用系统所有的报警、异常信息。

● 应用系统应该采用构件化设计思想，系统框架与业务逻辑分离，要求具备开放的体系结构。

● 应用系统应该支持通过统一的图形界面能够访问到系统各构件的版本信息及相应功能说明。

● 应用系统必须支持各构件的单独升级，并应该尽可能实现在线升级功能。

⑥ 可测试性

系统可测试性要求如下。

● 随系统提交的技术文件必须明确说明所实现的可度量的功能和性能指标。

● 应有固定的测试工程师进行专门的测试工作，每次新功能测试完成后，应提供详细的测试文档，包括测试的用例、方法及其结果等。测试结果应符合实际，测试未通过的项目应及时反馈并进行修改。

⑦ 性能监控

系统性能监控要求如下。

● 关键数据的传输必须采用可靠的加密方式，保证关键数据的完整性与安全性。

● 核心处理能力系统应该充分利用防火墙、安全证书、SSL等数据加密技术保证系统与数据的安全。

● 核心处理能力系统必须支持对系统运行所需账号密码周期性更改的要求。

● 核心处理能力系统必须强制实现操作员口令安全规则，如限制口令长度、限定口令修改时间间隔等，保证其身份的合法性。

● 登录系统需要提供验证码或短信功能，用户密码限制至少8位，且为数字、字母组合，密码多次错误锁定，验证密码有效性，有效杜绝SQL注入等低级别黑客入侵途径。

● 核心处理能力系统必须支持操作失效时间的配置。如果操作员在所配置的时间内没有对界面进行任何操作则该应用自动退出。

● 核心处理能力系统必须提供完善的审计功能，对系统关键数据的每一次增加、修改和删除都能记录相应的修改时间、操作人。

● 核心处理能力系统的审计功能必须提供根据时段、操作员、关键数据类型等条件组合查询的审计记录。

● 核心处理能力系统的审计功能必须提供针对特定关键数据查询历史的审计记录。

● 核心处理能力系统用户账号管理、密码管理、数据访问权限和功能操作权限管理必须满足企业的IT管控要求。