1.3 电信业务支撑困境

随着技术的发展和业务的增长，电信业务支撑系统的架构和软件开发模式渐渐落后。由于缺乏有效的手段进行服务管理，在系统开发和运维过程中产生了大量冗余、耦合的代码。服务接口重复开发，服务关系错综复杂，业务边界交叉重叠，这给开发和运维带来极大的挑战。需求支撑响应越来越慢，上线故障越来越多，上线时间越来越长，失败次数越来越多，对创新业务的支撑越来越难。系统运维难以为继，运维人员苦不堪言，我们作为其中的一员深有体会。

下面，我们以某省运营商为例，总结了其业务支撑系统存在的问题以及产生问题的原因。

1.重复建设维护成本高

重复建设分两个层面，一是系统层面重复建设，这是由于系统没有统一规划，而系统建设多是由各职能部门和渠道独立建设，业务功能有较多类似或相同，本书在此不做过多的论述。二是服务层面重复开发，这主要与系统架构、软件开发模式有关，造成重复造轮子的严重现象。

由于系统架构缺少有效的代码开发质量管控手段，软件开发还是采用面向过程的开发模式（Server、DAO的开发模式），造成Server成为各种服务的容器。再加上合作伙伴的开发人员流动性大，开发任务重，开发人员为了尽快完成任务，规避风险，往往知道有相同的服务或相似的服务也不敢用，都是先复制，再修改，先保证自己的需求上线再说。久而久之，服务重复越来越严重，业务边界越来越模糊，服务关系越来越复杂。举个例子，在系统中仅客户资料查询就存在180个类似的服务，而一个“Server容器”就有几万行代码，上百种方法，这样的系统很难维护。

2.支撑响应速度慢

支撑响应速度慢除了管理流程方面的原因外，主要还有系统架构的制约。由于系统采用的是单体架构，后台对业务没有进行解耦，所以整个后台服务耦合在一起，每次上线发布都要进行代码的全量编译（一个JAR包），效率低。其次，前后台服务调用采用的是简单的负载转发，没有实现服务的注册、发现，做不到系统的全天候发布，系统升级或新业务上线往往只能在晚上空闲的时间进行。最后，代码管控力度不足，系统可维护性越来越差，开发难度上升，测试耗时增加，再加上厂家人员流动性大，这些都严重影响了业务的支撑响应速度。

3.运维风险不可控

服务运行中出现问题，缺乏有效的管控手段。一个服务出现问题，影响多个业务和渠道，无法预知。如某个业务变更影响了互斥规则校验服务，可能会导致开户、产品变更等大批业务不可用；服务的质量无法保障，如电子渠道进行抢购、秒杀等营销活动时，短时间内产生海量（瞬时并发约20000用户）的互联网订单，造成订单管理系统运行缓慢，营业前台受理受阻，业务无法开展，严重影响客户体验；监控手段缺失，缺少对服务调用，服务质量的监控，无法进行调用链分析和故障传导分析，无法快速、准确地定位问题。

4.创新业务难支撑

近些年随着移动互联网的兴起，“互联网+、大众创业、万众创新”的国家战略实施，彻底激发了人们的想象力，各种创新应用、商业模式层出不穷。面对如潮的创新应用，业务支撑系统明显感到力不从心，无法跟上业务发展的步伐。如某手机电子商城，为了提升客户体验，提升竞争力，想在卖手机的同时能够办理套餐，这样的需求目前就很难满足。还有，对于互联网公司经常使用“秒杀、抢购”等营销活动，业务支撑系统也很难满足。面对市场前景无限的手机类支付创新应用，系统也难有所作为。

事物都是发展变化的，没有什么是一成不变的，IT系统更是如此。系统在建成初期，功能丰富且创新前瞻，很好地满足了当时业务的发展。但是，IT是有时效性的，随着时间增长和业务的变化，IT系统也会出现不适。IT系统发展的历史就是一部业务与技术博弈的发展史，两者呈螺旋上升趋势。业务在很长时间内占据了主导地位，俗称业务定义IT。近些年，技术发展迅猛，正在改变着这个世界，带我们进入了IT定义一切的时代。