变革运维 运营商网络运维转型进行时(1)

流量经营时代,建立以用户感知为中心的网络运维体系已经成为全球运营商的诉求。

图片 1

“中国联通正在推动从以网络为中心到以业务质量和用户感知为中心的转型。”中国联通网络分公司运行维护部副总经理崔荣春在公开演讲中表示。

无独有偶。据记者了解,中国电信和中国移动都将建立用户感知为中心的运维体系作为2014年的一项重点工作,有序展开。反观国外,沃达丰、德国电信等知名运营商早在前两年就开始注重提升用户感知,进入流量经营时代。

在运维体系的变革中,加快形成集中化网络维护管理和属地化维护支撑相结合的运维模式,实现集中监控成为运营商的另外一个主要目标。

在这两个目标的牵引下,运营商网络运维转型的大幕已经拉开。

运维体系亟待转型

过去10年,电信业成本下降主要依赖设备的成本降低,而随着摩尔定律的逐渐失效,近几年网络设备中与摩尔定律相关的部分已经低于30%,依赖设备成本下降已经不可持续。与此同时,运营商的OPEX比重越来越大。

“这种背景下,电信业传统的网络运维模式已经无法适应技术发展潮流。”中国联通研究院王光全向记者表示:“因此,运营商的运维体系亟待转型。”

事实上,运营商面临的挑战不仅这些。

LTE时代,为了提供更高的带宽,单个基站的覆盖越小。为了满足用户的覆盖需求,运营商部署的基站越来越多,越来越密集。网元数量几倍乃至几十倍的增量为运营商的运维工作带来了巨大的挑战。

LTE时代带来的不仅仅是网络架构的变化,更是业务形态的变化。2G/3G时代,运营商提供的业务以语音、短信和低带宽数据业务为主,到了4G时代,业务更等同于互联网业务。互联网业务复杂多样化,而且更新速度非常快。

“4G业务的互联网化特征对传统的维护方式提出的第一个挑战就是故障定位困难。”贵州移动网络部工程师、网络运行分析专家刚周伟在接受《通信产业报》(网)采访时表示,传统电信业务运营商全程管控,业务故障点定位简单,但互联网业务由于运营商无法全程管控,业务质量难以保证。同时互联网网络庞大而复杂,导致影响业务和感知的故障点增多,难以迅速响应和处理。

除此之外,维护标准无法统一和维护制度更新较慢都将成为运营商开展4G业务维护的挑战。

崔荣春表示,面对网络及业务、内部和外部对运维工作带来的新挑战,全球主流运营商都在探索集中化维护和贴近用户感知的运维转型。

例如,德国运营商T-Mobile借助终端侧CEM工具,进行用户感知侦测和反馈:一是,通过网络状况测试,了解网络的时延、速率等情况;二是,开展业务与服务感知反馈评价,使得用户可以主动对业务和服务类体验进行评价;三是,对用户感知和满意度进行问卷调查。

与此同时,国内运营商运维转型的步伐也在加快。

面对LTE时代的挑战,四川联通2013年提出“大运维”战略,构建集中化的大运维系统,降低运维成本并提升用户感知。“四川联通的大运维平台化战略,以实现‘降低运维成本、以用户感知与用户需要为使命’为目标,为用户提供更优质的服务。”四川联通副总经理廖建文在接受《通信产业报》(网)采访时表示。

而石家庄联通运行维护部以“夯实基础管理”为目标,重点聚焦网络质量提升、客户感知提升和基层管理提升三个领域,实现运维管理转型。来自石家庄联通的运维人员向记者表示,运行维护部一方面完善综合网管功能,实现统一故障集中管控;另一方面强化网络数据分析和移动网基础数据的稽查和评估。

网络KPI落伍了

运营商传统的运维体系以网络为中心而建立,讲究各种网络KPI参数。

以中国移动2013年网络KPI指标构成举例说明。网络运行质量10分,包含GSM网络语音4分、TD网络覆盖率3分和TD手机用户下载速率3分;客户满意度25分,包含整体客户满意度8分、重点客户群体满意度和客户感知要素满意度12分和端到端网络质量客户满意度5分;手机流量分流比例4分,扣减分则不超过10分。

为了交出一份漂亮的网络KPI答卷,运维人员唯KPI至上,针对网络不停地进行调整、优化和改良,一些地市的KPI可能达到6个9乃至7个9。一旦达不到达不到这个级别,排名非常靠后。例如一个地市运营商的语音质量97.59%,对比全国排名仅仅位列第27名。

而有趣的现象是,在6个9的KPI分值看似繁华的背后是用户的频繁投诉,数据网络的卡顿或者连接不上。如此一来,用户体验的日益下降,而运营商收到的投诉电话也日益增多。

为什么会出现这种现象呢?中兴通讯服务业务部副总经理周勇向记者进行了阐释:随着数据业务的爆发性增长,网络的KPI度量已经无法真正反映出用户使用网络的体验。其实运营商也非常困惑,如何得到用户体验的真实数据。这就要求运营商重新审视用户体验,其由什么要素构成,围绕这些要素重新搭建一个以用户感知为中心的运维评价体系。

目前,北京电信已经改变了传统的网络KPI模式。从用户的角度出发,从单纯优化网络KPI指标向优化网络速率和时延转变,从而更贴近用户的实际体验。

不过需要清醒的认识到,从以网络为中心向以业务质量和用户感知为中心转变,不可能一蹴而就。

在崔荣春看来,以业务质量和用户感知为中心的运维体系建立是一个系统工程。需要在组织与流程优化、评估体系优化、支撑系统完善、人员结构优化等方面协同推进才能真正落地,并以此推动集约化维护体系和端到端服务体系的建立。

运营商网络运维转型进行时(1)
流量经营时代,建立以用户感知为中心的网络运维体系已经成为全球运营商的诉求。
中国联通正在…

作者介绍:宋磊毕业于武汉大学,09年加入百度,现任百度网络与服务器运维团队技术经理。

精彩看点

  1. 网络工程师在业务需求不断变化和网络规模急剧增长下都会遇到哪些挑战?技能短板、各方的认可度、成就感和成长空间,这些是否能与你产生共鸣。
  2. 百度网络运维这些年的变革和方法论转换,从应急抢险、到局部优化,数据测量,再到能力建设,你的网络目前处于哪个阶段?能否从这里得到一些经验和帮助
  3. NetDevOps是网络工程师职业发展的新方向,企业内部如何培养网工DevOps的能力,除了技能学习,还应该有管理方法和团队协作模式的变化。

网络工程师的价值

图片 2

伴随近些年互联网的蓬勃发展,百度的产品线日益丰富。业务上从搜索变现一枝独秀到现在
O2O、互联网金融、公有云服务崛起。但是所有业务对基础设施的稳定运行、随需而变的要求没有变化。这也是网络运维团队工作的核心目标,提供稳定优质的网络基础设施,同时高效的满足业务需求,保持业务的正常运行。

图片 3

任何一个团队的成长都是从平凡一步步鲜血淋漓的走向卓越,百度网络运维团队也不例外。在追求稳定和高效的过程中不断遇到挑战。技术方面的挑战主要来自于业务需求的不断变化和规模的增长:

业务需求的不断变化推动技术发展和规模发展,百度的业务形态很长时间以来都是类似搜索、贴吧等页面展现类服务。随着百度云、百度钱包这些新形态服务的发展,连带推动了一大波网络技术的迭代,这是一个各种技术不断出现又消失,逐渐趋于稳定的收敛过程,在这个过程里工程师需要投入大量精力去了解新技术并进一步判断技术的发展方向。

随着网络规模不断增长,变更和监控也变得更加困难。特别是架构和策略复杂的情况下,人工决策风险难以控制,考虑不周的变更会对整个网络造成影响。规模增长的同时,网络监控也在逐步失效。传统基于SNMP、SYSLOG的监控可以测量到一部分网络特征比如流量和协议状态,但是对于全网时延、丢包这些重要的网络特征无法监控,从而忽略了这些业务有感问题的监控。

澳门新葡8455最新网站 ,与此同时,网络工程师的个人发展也遇到了的挑战:

  1. 技能存在短板,好想法落地困难。经常能遇到网络工程师有好想法,但是在项目落地的过程中只能依赖外部开发团队,排期和项目完成度较难控制,甚至因自己不具备
    coding
    能力,在前期的数据分析阶段项目就夭折。网络工程师coding能力的不足成了项目落地中的一个困难。
  2. 认可与理解,每天报警不断,家人不满意。故障处理速度慢,业务不满意。网络故障业务先感知,自己不满意。必须跳出救火式运维的套路,提高网络运维的能力和效率,让大家都满意,从而得到更多的认可和理解。
  3. 成就感和成长空间,项目无法快速落地,工作成绩不被认可,每天疲于奔命没有成就感,成长空间有限。如何突破个人的瓶颈?

改变的最重要一步是根据实际情况建立合适的方法论,调整工作重心。下面给大家介绍百度网络运维这些年的变革和方法论转换。

应急抢险

图片 4

和绝大部分公司一样,百度网络运维团队早期最主要的工作是应急抢险。当年的网络是一个用商用设备组成的STP+VLAN大二层,除了有一些商用负载均衡设备外,同时还有一些服务器直接接入到公网。

大二层带来的最明显的问题是广播风暴,08年某数据中心有4000多台服务器,在这个网络里面常态有1Gbps的单播泛洪流量,时不时还会有广播风暴。网络监控用MRTG做流量图、用正则表达式匹配SYSLOG做告警,工程师则拿着手机随时等着收报警短信。

局部优化

图片 5

第二个阶段开始做一些局部优化。此时网络架构由大二层改为三层,网关终结在TOR上,网络设备仍然是商用黑盒设备,开始自研负载均衡器等网络组件。网络运维团队在这个阶段的主要工作是联合开发团队做监控和自动化定制,同时在网络架构上做一些深度优化。

告警根因定位系统是当时的标志性项目。百度线上每天有几百万条原始日志告警,通过决策树推理聚合同一事件的日志,可以将告警收敛到几百个事件,今年的目标是告警量控制在每天100条以内。

另外一个例子是做OSPF路由优化。当时全网运行OSPF,在优化之前核心交换机上维护了6万条LSA,路由震荡频发,一次收敛需要1到2分钟。当时做了大量分析,花了几个月时间对全网OSPF整体进行了优化,包括协议定时器的调整、各种路由汇总等,做完之后核心交换机LSA减少80%以上,接入层交换机路由条目减少90%,路由收敛时间降低一半且故障不再频发。这里可以跟大家分享一下我们的经验,如果用OSPF来做组网,服务器规模没超过15万台前可以通过各种优化手段维持网络稳定运行。超过15万台后就需要从架构和路由上进一步优化了。

数据测量

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章