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

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

设备上学习IT行业做法，新网络推行SDN、NFV技术，能力开放，技术开放，打破厂商盒子垄断。从底层管理对象上实现软硬件分离、转发控制分离、可编程。使业务敏捷具备基本条件。然后上层的软件以控制器和改良网管配合。比如：AT&T尝试通过ECOMP来构筑网络编排能力和基于策略的自动化闭环能力，实现业务敏捷和运维自动化。这是对于新网络的办法，用全新的网络和全新的网管来解决未来网络能力演进。
还有一种做法如图：

文章图片
New OSS思路图思路是不区分新网络还是传统网络，在网管层之上再构筑一层使能层，通过这一层新系统提供运维转型的各种能力：

API开放能力。通过预集成，提供下层网管的API对接、注册和开放，为上层应用提供可编排组件。同时系统还提供快速集成能力，可根据需求低成本集成下层网管或者设备的北向或者命令行，持续提供API组件；
自动化场景API编排能力。通过可视化手段，将API目录里的原子API通过逻辑规则编排成自动化操作流，应用于配置变更、故障恢复、伸缩容、巡检等场景；
告警、性能、日志、资源存量等运维数据的采集和分析能力，通常基于ECA模型，作为各种自动化活动的触发事件，同时，也做为运维日常监控的中心；
图形化APP开发能力。电信运营商的运维人员虽然在转型过程中，可以通过招聘引入有软件开发能力的员工来提升开发能力，但是大多数的有经验的绩效良好的员工并不具备开发能力。要让他们转型DevOps，必须为他们提供能力支撑。这里就需要提供界面、API、规则、模型等辅助开发工具，让不具备编码能力的业务运维人员，能通过简单的一两周培训和图形化为主的开发IDE，掌握APP的开发能力。可以自己去根据工作需要，开发称手的运维工具。同时，在新的OSS平台上，提供APP自运维能力，开发者不用关心APP的资源分配和日常运维。这样就可以在一定程度上解决运维人员转型的困难，让业务敏捷起来。
这样的新OSS构建思路在传统IT行业是有成功经验的，现在引入电信行业正逢其时，有些厂商正在尝试中，还很年轻，希望能成为未来的运营商数字化转型的必备工具。后续有机会我们再继续详细说说。