电信级IT系统技术要求内容.docx
- 文档编号:25476734
- 上传时间:2023-06-09
- 格式:DOCX
- 页数:32
- 大小:223.81KB
电信级IT系统技术要求内容.docx
《电信级IT系统技术要求内容.docx》由会员分享,可在线阅读,更多相关《电信级IT系统技术要求内容.docx(32页珍藏版)》请在冰豆网上搜索。
电信级IT系统技术要求内容
电信级IT系统技术要求
-----------------------作者:
-----------------------日期:
1数据一致性要求
CRM和BOSS解耦后,业务运营支撑系统与业务平台间交互更加复杂,数据跨系统分布情况凸显,大量关键数据分别存储在两个或多个系统中,数据入口和出口不一致,多系统同时对数据进行操作,增加数据不一致风险。
为此,数据一致性管理提出了如下建设目标:
1、确保跨系统分布的数据在CRM、BOSS及相关网元间的一致性。
2、确保跨系统业务流程在CRM、BOSS及相关网元间的业务一致性。
3、根据数据的业务特性,采用适当手段,提升数据同步的实时性。
本规范通过对CRM、BOSS及相关网元间的数据分布和数据交互关系的分析,对不同情况产生的数据差异问题,采用不同的数据一致性保障手段,对数据一致性保障手段定义、适用范围等进行阐述,并对实现原则等提出明确技术要求。
1.1数据一致性原则
数据一致性管理是针对CRM、BOSS系统及相关网元间存在的数据差异问题采取的技术和管理手段。
CRM、BOSS及相关网元间的数据一致性通过业务完整性和数据稽核与同步等手段保证。
不同阶段产生的数据一致性问题,应采用不同保障手段,从事前、事中、事后三方面考虑。
事前数据一致性主要通过优化设计的手段保证,并遵循如下保障原则:
1、合理的数据分布设计,是指在实施CRM和BOSS的过程中,充分考虑到跨系统流程和跨系统数据分布对系统造成的影响,合理分布数据,尽量避免不必要的数据复制和同步,避免冗余数据,尽量在一个平台存储和管理数据。
2、合理的跨系统流程设计,是指在满足业务需求的基础上,尽量避免采用同步的通讯机制和不可靠的传输机制。
3、合理的应用分布,是指充分考虑冗余、复用机制,合理采用多进程、多线程,提高数据处理的实时性。
4、合理的同步策略,对于在多个平台存储同一数据的情况,应尽量考虑以其中的一个平台作为标准进行同步。
事中数据一致性主要通过业务完整性相关手段进行保障;事后数据一致性通过订单数据稽核、数据稽核与同步等方式实施保证。
下面章节将对事中、事后一致性保障手段做详细介绍。
1.2业务完整性要求
业务完整性是保障业务正常流转的一种手段。
由于存在跨系统的业务流程,任何一个环节的错误都可能导致业务办理的失败,导致用户的满意度下降。
因此,必然要有一定的手段和流程设计来保证业务完整性。
业务完整性通过全局事务控制、回退机制和重发机制三种技术手段实现。
1、全局事务控制
全局事务是指分布式事务处理环境中,多个数据库可能需要共同完成一个工作,这个工作即是一个全局事务。
例如,一个客户开户的事务中可能更新CRM、BOSS等几个不同的数据库,对这些数据库的操作发生在系统的各处,但必须全部被提交或回滚。
此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功,还要依赖与全局事务相关的其它数据库的操作是否成功,如果任一数据库的任一操作失败,则参与此事务的所有数据库所做的所有操作都必须回滚。
在一分布事务环境中,全局事务交易由中间件通知和协调相关数据库的提交或回滚。
而一个数据库只将其自己所做的操作(可恢复)影射到全局事务中。
为保证全局事务的完整性,由交易中间件控制数据库做两阶段提交。
全局事务控制由数据库和中间件配合保证事务的一致性,应用程序的逻辑相对简单。
但是对数据库来说事务从开始到结束(提交或回滚)时间相对较长,在事务处理期间数据库使用的资源(如逻辑日志、各种锁),直到事务结束时才会释放。
2、回退机制
回退机制提供CRM、BOSS未完成事务的撤销操作,是对事务完整性的一个补充手段,保证了系统间交易结果的一致性,是保障异步传输机制的重要手段。
用于通知接收方先前交易未按预定流程完成,应取消处理结果。
回退机制解决了多个节点之间交易的一致性问题,可分为自动回退和手动回退。
在回退机制中应能满足如下要求:
(1)提供单笔或批量回退操作。
(2)保证回退数据的正确性。
(3)回退逻辑应避免隔单处理。
3、重发机制
重发机制是一种前向纠错的手段,用于保证业务处理流程完整性。
一般会采取自动请求的方式。
重发机制是和回退机制完全相反的操作,保证后端流程的正常进行。
例如:
发起方提交工单失败后,能将失败工单存储起来,在一定时间内自动将工单再次提交,也要支持人工处理,用于保证业务处理流程完整性。
重发机制多用在异步处理方式,支持重发次数、重发间隔时间的可配置,如服务开通工单重处理。
2备份性能指标
数据备份是指用特殊的备份软件,能够在不影响正常业务运营的前提下将BOSS系统涉及的各种数据(包括数据库和文件系统中的数据)备份到备份设备上的过程。
数据备份须符合不能影响正常业务运营的原则。
数据备份包括全量备份和增量备份。
2.1全量备份性能指标
指标项
要求
数据(不含服务使用记录和详单)备份周期
<=7天
服务使用记录和详单数据备份周期
<=1个月
备份完成时间
<=24小时
备份数据保存周期
>=12个月
原始服务使用记录要求在线保存时间
>=3个月
原始服务使用记录要求离线保存时间
>=6个月
详单记录要求在线保存时间
>=6个月
详单记录要求离线保存时间
>=36个月
异常服务使用记录要求在线保存时间
>=3个月
异常服务使用记录要求离线保存时间
>=12个月
结算数据(包括漫游结算和网间结算)要求在线保存时间
>=4个月
结算数据(包括漫游结算和网间结算)要求离线保存时间
>=12个月
全量备份性能指标表
指标项说明:
(1)数据(不含服务使用记录和详单)备份周期:
这里的数据是指不包括原始话单和详单的各种BOSS系统数据,包括但不局限于用户信息、订购信息、各种局数据信息、用户帐单信息和累积量信息等。
备份周期是指相邻两次备份操作启动时间的间隔。
(2)服务使用记录和详单数据备份周期:
服务使用记录是指数据库详单和原始话单文件记录。
备份周期是指相邻两次备份操作启动时间的间隔。
(3)备份完成时间:
是指从备份启动到备份完成所需要的时间。
(4)备份数据保持周期:
是指备份生成的数据从生成到删除的时间间隔。
(5)原始服务使用记录要求在线保存时间:
原始服务使用记录是指采集到的原始话单;在线保存是指在BOSS主机文件系统上进行保存。
(6)原始服务使用记录要求离线保存时间:
原始服务使用记录是指采集到的原始话单;离线保存是指在磁带等外部存储上进行保存。
(7)详单记录要求在线保存时间:
详单记录是指经过BOSS系统处理在数据库中进行保存的清单记录;在线保存是指在BOSS主机文件系统上进行保存。
(8)详单记录要求离线保存时间:
详单记录是指经过BOSS系统处理在数据库中进行保存的清单记录;离线保存是指在磁带等外部存储上进行保存。
(9)异常服务使用记录要求在线保存时间:
异常服务使用记录是指BOSS系统无法正常处理的话单记录;在线保存是指在BOSS主机文件系统上进行保存。
(10)异常服务使用记录要求离线保存时间:
异常服务使用记录是指BOSS系统无法正常处理的话单记录;离线保存是指在磁带等外部存储上进行保存。
(11)结算数据(包括漫游结算和网间结算)要求在线保存时间:
结算数据是指BOSS处理的用于网间和漫游结算的详单记录;在线保存是指在BOSS主机文件系统上进行保存。
(12)结算数据(包括漫游结算和网间结算)要求离线保存时间:
结算数据是指BOSS处理的用于网间和漫游结算的详单记录;离线保存是指在磁带等外部存储上进行保存。
2.2增量备份性能指标
指标项
要求
数据(含服务使用记录)备份周期
<=1天
备份完成时间
<=3小时
备份数据保存周期
>=1个月
增量备份性能指标表
指标项说明:
(1)数据(含服务使用记录)备份周期:
是指BOSS系统数据库和文件系统中涉及的全部数据。
备份周期是指相邻两次备份操作启动时间的间隔。
(2)备份完成时间:
是指从备份启动到备份完成所需要的时间。
(3)备份数据保持周期:
是指备份生成的数据从生成到删除的时间间隔。
3业务连续性要求
业务连续性是指业务运营支撑系统应对风险具有自动调整和快速反应的能力,以保证业务的连续运转。
现有BOSS通过容灾系统的建设,提高了业务连续性的能力,但在CRM系统和BOSS解耦后出现了以下新问题,对业务连续性提出了新的挑战:
1、新增大量跨系统流程及长流程,系统间依赖关系增大,导致系统稳定性下降。
2、数据的跨系统分布,增加数据不一致的风险,导致业务失败。
3、CRM系统与BOSS的处理性能不匹配,造成系统瓶颈,导致系统性能下降甚至业务中断等。
4、为此,必须对CRM系统和BOSS的业务连续性提出更高的要求,为系统持续可靠运行提供保障。
本章节通过对业务连续性的风险分析和业务影响分析,明确相关业务的RTO和RPO指标要求;从满足业务连续性要求出发,明确应用设计、IT基础设施规划、日常保障、快速备份恢复、故障恢复、组织保障等方面的相关要求。
3.1业务连续性分析
业务连续性分析从风险分析、业务影响分析两个方面对影响业务连续运转的因素进行分析,提出相关业务的RTO和RPO指标要求。
3.1.1风险分析
风险是指可能导致系统中止运行、业务中断,并给企业和客户造成重大影响的潜在事件或事故。
风险分析的对象通常为“基础设施与技术”、“人为因素”和“不可抗力”三个层面。
同时,依据风险的来源又分为内部原因和外部原因,具体如下表所示。
基础设施和技术
人为因素
不可抗力
内部员工
外部人员
气候
自然灾害
硬件故障
技术缺陷
电源故障
空调损坏
消防设施毁坏
通讯线路中断
跨系统长流程问题
系统间处理能力匹配问题
数据不一致风险
病毒
误操作
盗窃
蓄意破坏
粗心或无知
辞职
情绪波动
…
病毒
黑客攻击
误操作
入室行窃
蓄意破坏
间谍活动
示威活动
消防灌水
…
严寒
冰雪
恶劣气候
崩塌
雷击
龙卷风
海啸
交通堵塞中断
…
水位过高
地震
火灾
塌方
飞行器撞击
爆炸
火山爆发
…
内部原因
外部原因
风险类型分类描述表
本次规范的关注重点是针对CRM与BOSS解耦在基础设施与技术方面对业务连续性的影响,特别是跨系统长流程问题、系统间处理能力匹配问题、数据不一致风险问题等三个方面,确定业务连续性相关的应用设计,IT基础设施规划,日常保障等要求。
3.1.2业务影响分析
本节根据业务中断对客户或企业的影响程度,对CRM系统和BOSS的业务级别进行分类,并提出相应的业务连续性指标要求。
1、业务级别分类
按照业务中断对客户和企业造成的负面影响程度,将业务分类为三个级别:
最关键业务、关键业务和非关键业务。
(1)最关键业务是指客户最敏感的业务,此类业务的中断,将会极大降低客户的满意度,对企业形象造成重大负面影响,如缴费,停开机等。
在特殊情况下,如发生地震,雪灾等自然灾害时,应考虑根据客户服务的实际情况对最关键业务的范围进行调整。
(2)关键业务是指业务中断将会对客户感知造成较严重影响的业务,及其所依赖的业务,如开户等。
(3)非关键业务是指由于该业务中断,将会对企业运营和客户感知产生一般或较小影响或基本没有影响的业务。
如综合结算、合作伙伴管理等业务。
根据以上的业务级别分类标准,CRM系统和BOSS业务级别分类如下:
系统
一级功能
二级功能
三级功能
四级功能
业务级别
BOSS
产品管理
产品目录管理
非关键
产品创建
关键
产品变更
关键
产品退出
关键
配置管理
关键
发布管理
关键
版本管理
关键
BOSS
服务开通
服务开通定单管理
关键
工单管理
关键
开通与激活
关键
BOSS
采集预处理
关键
BOSS
融合计费
关键
BOSS
综合帐务
帐务管理
缴费管理
最关键
销帐管理
关键
帐户资金管理
关键
帐单管理
关键
欠费管理
关键
帐务核算
关键
发票管理
关键
帐务处理
关键
信用管理
关键
积分管理
关键
BOSS
综合结算
非关键
BOSS
合作伙伴管理
非关键
BOSS
基础管理
系统管理
操作权限管理
关键
安全管理
非关键
操作日志管理
非关键
系统备份与清理
非关键
应用运维工具
非关键
软件版本控制管理
非关键
系统监控
非关键
业务局数据管理
关键
数据一致性管理
非关键
计费帐务稽核
非关键
统计报表
非关键
业务级别分类表
2、业务连续性的指标要求
业务连续性的指标有两个,即恢复时间目标(RTO)和恢复点目标(RPO)。
恢复时间目标(RecoveryTimeObjective,以下简称RTO):
表示了从灾难发生直到业务流程再次运行(即被恢复)的时间。
RTO从低到高分为5个级别,其中1级为最高级别:
级别
恢复时间要求
(1级)
2小时内恢复
(2级)
4小时内恢复
(3级)
8小时内恢复
(4级)
1天恢复
(5级)
可恢复,但无时间要求
恢复点目标(RecoveryPointObjective,以下简称RPO):
是灾难发生后业务能够容忍的数据丢失量,或者说灾难发生造成的数据丢失量。
RPO从低到高分为5个级别,其中1级为最高级别:
级别
可容忍丢失的数据
(1级)
无数据损失
(2级)
30分钟内的数据损失
(3级)
4小时内的数据损失
(4级)
8小时内的数据损失
(5级)
一天之内的数据损失
在CRM系统和BOSS中,各业务功能与业务连续性指标的对应关系如表所示。
系统
一级功能
二级功能
三级功能
四级功能
RPO级别
RTO级别
BOSS
产品管理
产品目录管理
4
4
产品创建
2
1
产品变更
2
1
产品退出
2
1
配置管理
2
1
发布管理
2
1
版本管理
2
1
BOSS
服务开通
服务开通类定单管理
1
1
工单管理
1
1
开通与激活
1
1
BOSS
采集预处理
2
2
BOSS
融合计费
2
2
BOSS
综合帐务
帐务管理
缴费管理
1
1
销帐管理
1
1
帐户资金管理
1
1
帐单管理
3
3
欠费管理
1
1
帐务核算
2
2
发票管理
3
3
帐务处理
2
2
信用管理
1
1
积分管理
2
2
BOSS
综合结算
4
4
BOSS
合作伙伴管理
4
4
BOSS
基础管理
系统管理
操作权限管理
1
1
安全管理
3
3
操作日志管理
3
3
系统备份与清理
4
4
应用运维管理
4
3
软件版本控制管理
3
3
系统监控
4
4
业务局数据管理
2
2
数据一致性管理
4
4
计费帐务稽核
4
4
统计报表
4
4
业务功能与业务连续性指标对应关系表
在CRM系统和NG1-BOSS系统实现时,根据此表确定业务连续性保障方式。
3.2业务连续性保障
业务连续性保障是指确保业务连续的机制,包括:
系统高可用性的规划和设计、、运维保障、故障恢复、容灾系统建设、组织保障等方面。
3.2.1高可用性
业务应用的高可用性和IT基础设施的高可靠性是实现业务连续性的基础,因此对业务应用的设计和IT基础设施的规划提出如下要求:
1、应用设计原则
(1)保证数据的合理分布,数据的一致性以及数据操作事务的完整性。
(2)合理规划和设计跨系统流程,保证流程执行的畅通和完整性。
(3)具备良好的可伸缩性,通过合理配置资源,消除性能不匹配所导致的系统瓶颈。
(4)应用系统接口应具备高可靠性。
2、IT基础设施规划原则
(1)网络应规划足够的网络带宽,保证接入设备与链路的冗余备份,以及接口的稳定性。
(2)服务器应保证容错机制、高可用性,支持负载均衡,并预留一定的处理扩展能力。
(3)存储设备应具备内部容错机制和数据保护机制。
3.2.2运维保障
在CRM系统的日常运行维护过程中,应采用各种流程、技术手段加大对系统异常的监控和处理,预防系统异常对业务连续性的影响。
1、日常保障手段
(1)通过日常系统监控和系统维护,提高系统运行稳定性。
(2)通过数据稽核,实现数据一致性和完整性,保证业务可靠性。
(3)通过软件版本管理等手段,确保应用系统的可靠性。
2、通过备份与恢复手段,保证应用和数据的可恢复性。
3.2.3故障恢复
系统出现故障导致业务中断后,应通过容灾提供业务恢复,容灾恢复有三个等级,即业务级容灾、应用级容灾和数据级容灾,其关系如图所示。
1、数据级容灾仅能保证数据的完整性,业务恢复时间很长(一般在3天以上)。
2、应用级容灾包含数据级容灾,灾难发生后业务能够比较快速地恢复(一般在一天之内)。
3、业务级容灾包含应用级容灾,是最高层次的容灾,灾难发生后业务几乎不受影响(一般小于30分钟);由于业务级容灾投资较高,本次规范中的业务级容灾只涵盖最关键业务。
容灾层次关系图
故障恢复方式包括本地应急接管,异地容灾接管,本地备份恢复。
本地应急接管是指通过启用本地应急系统,部分接管生产系统,保证关键业务连续性的方式,适用于业务级容灾。
异地容灾接管是指通过启用容灾系统,全面接管生产系统,保证整体业务连续性的方式,适用于应用级容灾。
本地备份恢复是指使用本地备份数据恢复生产系统,保证整体业务连续性的方式,适用于数据级容灾。
3.2.4业务连续性保障体系架构
1、系统定位
业务连续性保障体系由本地应急系统和容灾系统组成,本地应急系统、容灾系统与生产系统相互配合共同保证整体业务连续性。
本地应急系统是本地关键业务快速恢复的手段,通过启动本地应急系统可保证关键业务的连续性。
容灾系统是建立在异地容灾中心的一套整体生产系统恢复体系,通过启动容灾系统可以全面接管生产系统,实现业务系统连续性。
生产系统、本地应急系统和容灾系统三者之间关系如图所示。
容灾系统关系图
2、系统拓扑结构
根据生产系统、本地应急系统和容灾系统三者的定位和关系,落实到容灾系统的实现,网络拓扑示意图如图所示。
容灾系统网络拓扑图
本地应急系统与生产系统共同布署在生产中心,其处理能力应根据业务需求决定。
本地应急系统要求配备独立的服务器、数据库和存储设备等,并与生产系统的服务器、数据库和存储设备等相对隔离。
容灾系统布署在远程容灾中心,其与生产系统的结构和部署一致。
为了提高设备的利用率和节省投资,在满足业务需求的前提下,容灾系统的性能不作过高要求。
在生产中心与容灾中心之间,应具备足够的带宽,以及链路的高可用性和高可靠性,以满足数据同步的要求。
容灾系统应具有路由控制和负载均衡功能,以保证系统切换后,外部系统的正常接入访问。
3、切换原则
当CRM生产系统或NG1-BOSS生产系统发生故障需要切换时,生产系统、本地应急系统、容灾系统三者之间的切换原则如下:
(1)生产系统的最关键业务发生故障而且故障修复时间小于最高级别RTO恢复时间要求的情况下,生产系统应切换到本地应急系统。
(2)生产系统发生故障的其它情况,通过决策、审批后可切换到容灾系统。
(3)生产系统修复后,应从本地应急系统/容灾系统回切回生产系统。
(4)当本地应急系统的持续工作时间大于最高级别RTO恢复时间要求但生产系统故障仍未修复时,应通过决策、审批后从本地应急系统切换到容灾系统。
数据的一致性是保证业务连续性和完整性的基础,为了确保正常切换和业务顺利运转,容灾系统数据流向及处理原则如图所示。
容灾系统数据流向
其中:
(1)在生产系统运行期间,生产系统应同步最关键业务数据到本地应急系统,以保证本地应急系统的数据有效性。
(2)在本地应急系统回切到生产系统时,为保证恢复后的生产系统顺利运转,必须按照本地应急系统上的操作日志,在生产系统上批量地重做业务。
(3)在本地应急系统切换到容灾系统时,也必须按照本地应急系统上的操作日志,在容灾系统上批量地重做业务。
(4)在生产系统运行期间,容灾系统的数据必须同生产系统保持一致,可采用定点复制、连续复制的方式,从生产系统向容灾系统同步数据。
(5)容灾系统回切到生产系统时,必须将容灾系统的数据状态同步到生产系统。
3.2.5组织保障
1、人员编制
容灾中心与生产中心处于不同局址,包括完整的机房环境、配套设备、系统设备、应用软件等,因此要求人员必须冗余。
省公司应配备专职的维护和管理人员,以备发生灾难和重大故障的时候,确保容灾中心系统的可用性并能按照灾难恢复要求的时间完成系统切换。
省公司应根据容灾系统的功能和建设的模型,全面衡量容灾中心的工作量,确定容灾中心的人员编制。
在进行该组织结构制定时,应根据省公司的具体人事编制来补充扩编。
2、组织结构
容灾系统的管理组织结构,按照其功能以及灾难恢复和日常管理的流程需求划分,应分别建立省公司领导组、省公司执行组、分公司领导组等,如图所示:
容灾系统管理人员组织架构
其中:
(1)省公司领导组下设省公司执行组和分公司领导组。
(2)省公司执行组下设系统组、业务组、行政管理组。
(3)系统组和业务组下面设生产中心组和容灾中心组。
(4)分公司领导组下设分公司执行组。
每个组都应该指定相关的人员负责。
(5)组长应指定一名组员担任副组长,在组长不能履行其职
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 电信 IT 系统 技术 要求 内容