《[精选]电信级IT系统技术要求》由会员分享，可在线阅读，更多相关《[精选]电信级IT系统技术要求（19页珍藏版）》请在金锄头文库上搜索。
1、1 数据一致性要求CRM和BOSS解耦后，业务运营支撑系统与业务平台间交互更加复杂，数据跨系统分布情况凸显，大量关键数据分别存储在两个或多个系统中，数据入口和出口不一致，多系统同时对数据进行操作，增加数据不一致风险。为此，数据一致性管理提出了如下建设目标：1、 确保跨系统分布的数据在CRM、BOSS及相关网元间的一致性。2、 确保跨系统业务流程在CRM、BOSS及相关网元间的业务一致性。3、 根据数据的业务特性，采用适当手段，提升数据同步的实时性。本规范通过对CRM、BOSS及相关网元间的数据分布和数据交互关系的分析，对不同情况产生的数据差异问题，采用不同的数据一致性保障手段，对数据一致性保障
2、手段定义、适用范围等进行阐述，并对实现原则等提出明确技术要求。1.1 数据一致性原则数据一致性管理是针对CRM、BOSS系统及相关网元间存在的数据差异问题采取的技术和管理手段。CRM、BOSS及相关网元间的数据一致性通过业务完整性和数据稽核与同步等手段保证。不同阶段产生的数据一致性问题，应采用不同保障手段，从事前、事中、事后三方面考虑。事前数据一致性主要通过优化设计的手段保证，并遵循如下保障原则：1、 合理的数据分布设计，是指在实施CRM和BOSS的过程中，充分考虑到跨系统流程和跨系统数据分布对系统造成的影响，合理分布数据，尽量避免不必要的数据复制和同步，避免冗余数据，尽量在一个平台存储和管理
3、数据。2、 合理的跨系统流程设计，是指在满足业务需求的基础上，尽量避免采用同步的通讯机制和不可靠的传输机制。3、 合理的应用分布，是指充分考虑冗余、复用机制，合理采用多进程、多线程，提高数据处理的实时性。4、 合理的同步策略，对于在多个平台存储同一数据的情况，应尽量考虑以其中的一个平台作为标准进行同步。事中数据一致性主要通过业务完整性相关手段进行保障；事后数据一致性通过订单数据 稽核、数据稽核与同步等方式实施保证。下面章节将对事中、事后一致性保障手段做详细介绍。1.2 业务完整性要求业务完整性是保障业务正常流转的一种手段。由于存在跨系统的业务流程，任何一个环节的错误都可能导致业务办理的失败，导
4、致用户的满意度下降。因此，必然要有一定的手段和流程设计来保证业务完整性。业务完整性通过全局事务控制、回退机制和重发机制三种技术手段实现。1、全局事务控制全局事务是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务。例如，一个客户开户的事务中可能更新CRM、BOSS等几个不同的数据库，对这些数据库的操作发生在系统的各处，但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。在一分布事务环境中，全局事务
5、交易由中间件通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。为保证全局事务的完整性，由交易中间件控制数据库做两阶段提交。全局事务控制由数据库和中间件配合保证事务的一致性，应用程序的逻辑相对简单。但是对数据库来说事务从开始到结束（提交或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁），直到事务结束时才会释放。2、回退机制回退机制提供CRM、BOSS未完成事务的撤销操作，是对事务完整性的一个补充手段，保证了系统间交易结果的一致性，是保障异步传输机制的重要手段。用于通知接收方先前交易未按预定流程完成，应取消处理结果。回退机制解决了
6、多个节点之间交易的一致性问题，可分为自动回退和手动回退。在回退机制中应能满足如下要求：(1) 提供单笔或批量回退操作。(2) 保证回退数据的正确性。(3) 回退逻辑应避免隔单处理。 3、重发机制重发机制是一种前向纠错的手段，用于保证业务处理流程完整性。一般会采取自动请求的方式。重发机制是和回退机制完全相反的操作，保证后端流程的正常进行。例如：发起方提交工单失败后，能将失败工单存储起来，在一定时间内自动将工单再次提交，也要支持人工处理，用于保证业务处理流程完整性。重发机制多用在异步处理方式，支持重发次数、重发间隔时间的可配置，如服务开通工单重处理。2 备份性能指标数据备份是指用特殊的备份软件，能
7、够在不影响正常业务运营的前提下将BOSS系统涉及的各种数据（包括数据库和文件系统中的数据）备份到备份设备上的过程。数据备份须符合不能影响正常业务运营的原则。数据备份包括全量备份和增量备份。2.1 全量备份性能指标指标项要求数据（不含服务使用记录和详单）备份周期= 7天服务使用记录和详单数据备份周期= 1个月备份完成时间= 12个月原始服务使用记录要求在线保存时间= 3个月原始服务使用记录要求离线保存时间= 6个月详单记录要求在线保存时间= 6个月详单记录要求离线保存时间= 36个月异常服务使用记录要求在线保存时间= 3个月异常服务使用记录要求离线保存时间= 12个月结算数据（包括漫游结算和网间
8、结算）要求在线保存时间= 4个月结算数据（包括漫游结算和网间结算）要求离线保存时间= 12个月全量备份性能指标表指标项说明：(1) 数据（不含服务使用记录和详单）备份周期：这里的数据是指不包括原始话单和详单的各种BOSS系统数据，包括但不局限于用户信息、订购信息、各种局数据信息、用户帐单信息和累积量信息等。备份周期是指相邻两次备份操作启动时间的间隔。(2) 服务使用记录和详单数据备份周期：服务使用记录是指数据库详单和原始话单文件记录。备份周期是指相邻两次备份操作启动时间的间隔。(3) 备份完成时间：是指从备份启动到备份完成所需要的时间。(4) 备份数据保持周期：是指备份生成的数据从生成到删除的
9、时间间隔。(5) 原始服务使用记录要求在线保存时间：原始服务使用记录是指采集到的原始话单；在线保存是指在BOSS主机文件系统上进行保存。(6) 原始服务使用记录要求离线保存时间：原始服务使用记录是指采集到的原始话单；离线保存是指在磁带等外部存储上进行保存。(7) 详单记录要求在线保存时间：详单记录是指经过BOSS系统处理在数据库中进行保存的清单记录；在线保存是指在BOSS主机文件系统上进行保存。(8) 详单记录要求离线保存时间：详单记录是指经过BOSS系统处理在数据库中进行保存的清单记录；离线保存是指在磁带等外部存储上进行保存。(9) 异常服务使用记录要求在线保存时间：异常服务使用记录是指BO
10、SS系统无法正常处理的话单记录；在线保存是指在BOSS主机文件系统上进行保存。(10) 异常服务使用记录要求离线保存时间：异常服务使用记录是指BOSS系统无法正常处理的话单记录；离线保存是指在磁带等外部存储上进行保存。(11) 结算数据（包括漫游结算和网间结算）要求在线保存时间：结算数据是指BOSS处理的用于网间和漫游结算的详单记录；在线保存是指在BOSS主机文件系统上进行保存。(12) 结算数据（包括漫游结算和网间结算）要求离线保存时间：结算数据是指BOSS处理的用于网间和漫游结算的详单记录；离线保存是指在磁带等外部存储上进行保存。2.2 增量备份性能指标指标项要求数据（含服务使用记录）备份
11、周期= 1天 备份完成时间= 1个月增量备份性能指标表指标项说明：(1) 数据（含服务使用记录）备份周期：是指BOSS系统数据库和文件系统中涉及的全部数据。备份周期是指相邻两次备份操作启动时间的间隔。(2) 备份完成时间：是指从备份启动到备份完成所需要的时间。(3) 备份数据保持周期：是指备份生成的数据从生成到删除的时间间隔。3 业务连续性要求业务连续性是指业务运营支撑系统应对风险具有自动调整和快速反应的能力，以保证业务的连续运转。现有BOSS通过容灾系统的建设，提高了业务连续性的能力，但在CRM系统和BOSS解耦后出现了以下新问题，对业务连续性提出了新的挑战：1、 新增大量跨系统流程及长流程
12、，系统间依赖关系增大，导致系统稳定性下降。2、 数据的跨系统分布，增加数据不一致的风险，导致业务失败。3、 CRM系统与BOSS的处理性能不匹配，造成系统瓶颈，导致系统性能下降甚至业务中断等。4、 为此，必须对CRM系统和BOSS的业务连续性提出更高的要求，为系统持续可靠运行提供保障。本章节通过对业务连续性的风险分析和业务影响分析，明确相关业务的RTO和RPO指标要求；从满足业务连续性要求出发，明确应用设计、IT基础设施规划、日常保障、快速备份恢复、故障恢复、组织保障等方面的相关要求。3.1 业务连续性分析业务连续性分析从风险分析、业务影响分析两个方面对影响业务连续运转的因素进行分析，提出相关
13、业务的RTO和RPO指标要求。3.1.1 风险分析风险是指可能导致系统中止运行、业务中断，并给企业和客户造成重大影响的潜在事件或事故。风险分析的对象通常为“基础设施与技术”、“人为因素”和“不可抗力”三个层面。同时，依据风险的来源又分为内部原因和外部原因，具体如下表所示。基础设施和技术人为因素不可抗力内部员工外部人员气候自然灾害硬件故障技术缺陷电源故障空调损坏消防设施毁坏通讯线路中断跨系统长流程问题系统间处理能力匹配问题数据不一致风险病毒误操作盗窃蓄意破坏粗心或无知辞职情绪波动病毒黑客攻击误操作入室行窃蓄意破坏间谍活动示威活动消防灌水严寒冰雪恶劣气候崩塌雷击龙卷风海啸交通堵塞中断水位过高地震火
14、灾塌方飞行器撞击爆炸火山爆发内部原因外部原因风险类型分类描述表本次规范的关注重点是针对CRM与BOSS解耦在基础设施与技术方面对业务连续性的影响，特别是跨系统长流程问题、系统间处理能力匹配问题、数据不一致风险问题等三个方面，确定业务连续性相关的应用设计，IT基础设施规划，日常保障等要求。3.1.2 业务影响分析本节根据业务中断对客户或企业的影响程度，对CRM系统和BOSS的业务级别进行分类，并提出相应的业务连续性指标要求。1、业务级别分类按照业务中断对客户和企业造成的负面影响程度，将业务分类为三个级别：最关键业务、关键业务和非关键业务。(1) 最关键业务是指客户最敏感的业务，此类业务的中断，将
15、会极大降低客户的满意度，对企业形象造成重大负面影响，如缴费，停开机等。在特殊情况下，如发生地震，雪灾等自然灾害时，应考虑根据客户服务的实际情况对最关键业务的范围进行调整。(2) 关键业务是指业务中断将会对客户感知造成较严重影响的业务，及其所依赖的业务，如开户等。(3) 非关键业务是指由于该业务中断，将会对企业运营和客户感知产生一般或较小影响或基本没有影响的业务。如综合结算、合作伙伴管理等业务。根据以上的业务级别分类标准，CRM系统和BOSS业务级别分类如下：系统一级功能二级功能三级功能四级功能业务级别BOSS产品管理产品目录管理非关键产品创建关键产品变更关键产品退出关键配置管理关键发布管理关键版本管理关键BO
