电信运维转型真能学Google吗()

电信运维为什么要转型 近几年电信行业营收情况让人担忧。一方面运营商花了大笔钱建了3G、4G网络,但是基于老的商业模式,增量不增收。另一方面互联网OTT新秀们不断大举蚕食电信业务,时时刻刻想让电信沦为管道,如:微信、Whatsapp直接弄残短信业务,诸如此类不胜枚举。这种前有天堑后有追兵的日子过了几个年头,近期似乎并没有好转的迹象。去年跟同事扯淡,运营商未来5到10年可能会死一半,如今看来貌似越来越靠谱。
运营商着急呀,想想老的管道模式不行了,咱们师夷长技以制夷吧。好,跟腾讯交流新通讯、向阿里学习电商、走访Facebook社交、看看Google B4、上云、IT化、SDN、NFV,一通学。可到现在我们看到的还是手机上网、家庭宽带、企业专线这些老菜谱,其它的创新好像没激起什么多大水花。不行,光学业务形态型似而神不似,达不到效果。要从根本的核心运营理念和组织形式上改革,市场要用互联网思维武装,组织运作要用DevOps变革。总体来说就是要用数字化、自动化、智能化技术使能业务转型,真正跟上互联网时代的脚步。
背景扯得有点大,力有不逮,还是得回到运维上来。运营商新业务增收还未成功前,首当其冲的就是内部节支。运维部门做为成本中心,在转型战略中,压力很大。于是想了各种办法,我们有空再一个个看,今天还是说标题里提,学Google。
为什么要学Google Google在行业上一直是极客领袖形象,高技术、高利润、高瞻远瞩,是人类未来的技术储备,但这些都跟运营商学Google运维没直接关系。跟运营商运维有关系有借鉴的,是Google全球数百万主机、数百数据中心,通过SRE在DevOps模式下,实现业务高可靠、快速上线、人均维护万台的实践经验。这种经验有可能帮助运营商实现运维成本大幅下降,业务TTM大幅缩短。
能学Google吗 首先看看Google SRE运维对象和工具,如下图:

电信运维转型真能学Google吗()
文章图片
Google SRE的运维对象和工具
【电信运维转型真能学Google吗()】可以看出Google的维护对象可以类比云架构分层,包括硬件、基本服务,以及应用程序。最外层是硬件设施,接近于云架构中的IaaS层,主要是自研的服务器、交换机、裸存储、文件系统、网络等。由于基本上全是自研的硬件设备,所以设备型号、技术较为统一。中间一层为基础服务层,主要是数据库、管理软件、负载均衡、应用服务器等。基本上也是自研软件、可控性强,都是天生的分布式架构。最里层是SRE以及Google程序员们的主流开发语言,既是应用程序的主体,也是维护工具的主体。SRE是能力相当于80%-99%个软件工程师的技术人员,在这样的三层环境里,几乎就是如鱼得水。也正因为这种相对单纯的技术栈及物理设备,让SRE每天只从事以50%为上限的传统工作成为可能。
我们再看看电信运维对象和工具,如下图:

电信运维转型真能学Google吗()
文章图片
电信运维的对象和工具
上图可以明显地看出电信运维对象与Google截然不同的地方。电信运维基本上可分为两层,网元层和网管层。网元层主要包括无线、传输、核心网、增值系统等各类网元设备。图中只列举出了各技术域的大类网元,细分下去,往往一个运营商不同厂商的设备可以达数千种。不同的设备不同的管理方法,技术、架构、特性也是各不相同。第二层为网管层,运维人员直接通过这些网管软件来管理网络。有10年以上历史的运营商通常能有上百种或者几百种网管工具,可以想像电信运营商的运维人员有多苦逼(IT运维的同学们可以站起来给他们些鼓励)。如今运营商想做运维转型,学习Google后,觉得如果我们的运维人员也能像Google的SRE一样,手握键盘,心怀远方,每天花50%的时间来写工具,然后大部分传统工作都通过运维工具来自动化、智能化。然后运维人员减半、效率倍增不是梦,这多美啊。看到这里,运营商的运维同学们现场一个都瞧不见了,估计都排着队哭晕在厕所里。想想,这么多系统,不同的技术、不同的协议、不同的接口,别说开发程序,光手册都够看到退休。传统模式下专业的第三方ISV(集成服务提供商)每年光给我们做几个功能,拉通几个场景都不知道要收我们多少钱,工期还一拖再拖。现在让我们这些被图形化网管惯坏了,连命令行都用不利索了的老网工来开发应用,是消遣我们吧~
现在,我们应该觉得电信运营商运维不管是人员能力模型还是管理对象,都与Google差异太大,应该是学不了Google SRE了~~
但人生在世总要想些办法来冲一冲没有走过的路,运营商也在想办法。
就要学Google 运营商在想办法:

  • 设备上学习IT行业做法,新网络推行SDN、NFV技术,能力开放,技术开放,打破厂商盒子垄断。从底层管理对象上实现软硬件分离、转发控制分离、可编程。使业务敏捷具备基本条件。然后上层的软件以控制器和改良网管配合。比如:AT&T尝试通过ECOMP来构筑网络编排能力和基于策略的自动化闭环能力,实现业务敏捷和运维自动化。这是对于新网络的办法,用全新的网络和全新的网管来解决未来网络能力演进。
  • 还有一种做法如图:
电信运维转型真能学Google吗()
文章图片
New OSS思路图 思路是不区分新网络还是传统网络,在网管层之上再构筑一层使能层,通过这一层新系统提供运维转型的各种能力:
  1. API开放能力。通过预集成,提供下层网管的API对接、注册和开放,为上层应用提供可编排组件。同时系统还提供快速集成能力,可根据需求低成本集成下层网管或者设备的北向或者命令行,持续提供API组件;
  2. 自动化场景API编排能力。通过可视化手段,将API目录里的原子API通过逻辑规则编排成自动化操作流,应用于配置变更、故障恢复、伸缩容、巡检等场景;
  3. 告警、性能、日志、资源存量等运维数据的采集和分析能力,通常基于ECA模型,作为各种自动化活动的触发事件,同时,也做为运维日常监控的中心;
  4. 图形化APP开发能力。电信运营商的运维人员虽然在转型过程中,可以通过招聘引入有软件开发能力的员工来提升开发能力,但是大多数的有经验的绩效良好的员工并不具备开发能力。要让他们转型DevOps,必须为他们提供能力支撑。这里就需要提供界面、API、规则、模型等辅助开发工具,让不具备编码能力的业务运维人员,能通过简单的一两周培训和图形化为主的开发IDE,掌握APP的开发能力。可以自己去根据工作需要,开发称手的运维工具。同时,在新的OSS平台上,提供APP自运维能力,开发者不用关心APP的资源分配和日常运维。这样就可以在一定程度上解决运维人员转型的困难,让业务敏捷起来。
    这样的新OSS构建思路在传统IT行业是有成功经验的,现在引入电信行业正逢其时,有些厂商正在尝试中,还很年轻,希望能成为未来的运营商数字化转型的必备工具。后续有机会我们再继续详细说说。

    推荐阅读