就是干!移动的运维实践之路

来源:企鹅电竞比赛    发布时间:2024-02-11 19:42:30 点击:1次

  中国移动通信集团浙江有限公司信息技术部副总经理,中国移动集团业务支撑高级技术专家。

  中国移动通信集团浙江有限公司信息技术部副总经理,中国移动集团业务支撑高级技术专家。

  作者是中国移动浙江公司信息技术部副总经理兼云计算中心主任,本文主要讲中国移动浙江公司云运维的一些实践。

  首先看一下,谈到运营商大家都会有这个感觉我们是一个电信化的企业,电信讲究的是标准、规范,在电信的 IT 时代中,我们曾经用过当时国内非常先进的技术,就是 IOE 。

  1998年我们就进入了惠普高端小型机,当时有个笑话,我们在引入惠普小机的时候工作进度比我们预想的工期慢很多,因为美国政府怀疑我们引用这些小机有军事方面的用途。

  后来我们到 2003 年组建了一个以 OCM 为核心的数据库团队,在 Oracle 运行方面在业界也是跑得比较领先的。

  自从 2011 年以来去 IOE 这块走得非常迅猛,包括这样的一个东西对我们运营商,对我们金融行业,都造成了非常大的影响。

  不管怎么说,这种灵活性、弹性、开放性永远是一个企业所追求的梦想,尽管我们的架构曾经非常的强大也非常的传统,但是还是要把自己的架构进行转变。

  如果说,我们运营商也要谈去 IOE 的话,是有我们自己的驱动原因,因为我们的业务也在发展,是 4G 时代背景下要求的。

  在这种情况下 IT 架构也需要做分布式的改造,我们应该能够支撑这样互联网式的业务,而且我们的能力也需要能够内化,逐渐加强我们运营商自己的核心能力掌控,包括成本,还有一些社会责任方面的考虑。

  我们能够正常的看到,要完成这些改变是很难的,曾经有过一个辉煌的过去,你要去改变这有多难。

  给大家举个例子,几千年来中国和英国的弓箭手都是非常有名的,有一个非常大的区别,英格兰长弓手大概在16世纪就逐步退出军队了,而我们中国的长弓手到1840年以后才逐步退出战场。

  给大家举个例子,几千年来中国和英国的弓箭手都是非常有名的,有一个非常大的区别,英格兰长弓手大概在16世纪就逐步退出军队了,而我们中国的长弓手到1840年以后才逐步退出战场。

  一个技术发展了,这就是两家企业是否能够比较好的拥抱新技术的结果,一个转型的公司损失可能只有10个人,没有转型的公司损失非常大,这必须要去调整。

  从这个角度来说,任何一个科技、技术都有时代性,如果到了不属于它的时代,我们就必须要颠覆我们自己,这是一种理念的变化。

  我们之前也做了相当多的事情,我们从 2009 年开始已经对云计算开始做研究和迁移,我们大概是在 2013 年开始把我们的核心数据库进行了 X86 化,我们数据库的去 IOE 工作已经基本上完成了。

  从2011年开始,我们的核心融合 CRM 系统,到 2015 年为止,我们所有的核心系统已经全部都跑在 X86 服务器上。

  另外这两年 Docker 技术比较热,从2014年开始我们引入 Docker 技术,到了2016年的6月份,我们全省的 CRM 前端已经全部实现了 DCOS 化,全部跑在容器上。到目前为止,我们把所有的核心系统正在往 Docker 上进行迁移。

  第一,在系统要云化要去 IOE,但是对我们的稳定性和可用性的标准没有降低,还是在提升。

  第一,在系统要云化要去 IOE,但是对我们的稳定性和可用性的标准没有降低,还是在提升。

  最后这项我觉得很重要,以前我们在 IOE 时代,团队定位就是一个实实在在的运维团队。

  面对现在这样的情境,我们是不是仍然是一个运维团队,还是说应该自己颠覆自己去做一些其他的事情,这是对我们很大的一种挑战。

  我们一共做了四个方面工作,一方面把我们的运维团队要走出来,自己推出新一代的云平台的技术架构的建设,由运维团队来推动技术栈的变化。

  再有我们的定位也发生了变化,从纯运维走向逐步的运维开发,再从运维开发逐步走向云平台的规划和建设,这是对我们团队本身定位的一种变化。

  另外一块是模式的变化,我们的运行模式也发生了变化,我们从一个抗拒变化的传统运维,到现在把自己构造成了一个运维开发团队,变成了一个 DevOps 团队,变成了一个建设规划团队。

  这种情况下我们把我们团队的理念和运行模式也发生了一些变化,而且我们的运维体系,从传统的逐渐向新的运维体系进行调整。

  有一个非常好的概念叫做轻量化的 ITSM,中国移动在国内 ITSM 的实践上也是走得比较领先的,现在可能是我们该从传统的 ITSM 逐步走向轻量型 ITSM 的时代。

  上图的是定位的变化,我们把我们的运维团队逐渐变成了一个运维经验平台的建设者和架构的管控者,不是直接守着 IOE 的平台不往前走,而是要去看我们的开发是怎么把能力输出给我们的运维团队的。

  同时在这样的一个过程中我们该在里面发挥啥作业,我们自己去建设我们自己的一个运营的平台,同时我们对 IT 的架构要有自己的理解和掌控的能力。

  另外一块,这个图左边是一只猫,右边是一个牛,其实在 IOE 时代我们都会发现,我们的 IT 系统稳定性是取决于我们的技术架构自身的稳定性。

  但是在去 IOE 的时候,特别是去“I”,单个 X86 服务器的稳定性不再重要,某一种意义上我们把我们的服务器从宠物变成了肉牛,这个对我们运维团队的挑战是非常大的。

  某种意义上说,去“I”后不再稳定,我们要用一个稳定的 DCOS 架构去颠覆它,总得有一个稳定的。

  这是我们运维体系的变化,其实在2010年以前走的是标准化的传统的架构,后面逐渐把我们的架构向轻量级的 ITSM 进行转移。

  下图是我们运维团队构成的转型,我们把自己的纯运维团队逐渐增加了一个开发的属性。

  另外,我们把曾经完全竖井化的运维架构,在中间我们培养出来的全栈工程师,把这些系统的维护进行拉通。

  上图我们的一个组织架构的转型。我们目前也成立了云计算中心,这个就是我刚才说的,我们把一个曾经的运维团队转型成一个架构的治理、建设、规划团队,这样我们的运维团队能做到 40岁也没问题。

  传统运维在自动化、可视化、效率方面问题是比较多的,我们当时在传统的时候会发现,我们的应用租户始终觉得我们的平台不透明。

  比如我们的租户在维护他的应用系统的时候,他会觉得是不是主机有问题、服务器有问题、数据库有问题,这样的一种情况下我们很难说服他。

  我们想办法做一个比较好的可视化工具,我们把自己的状态主动暴露给租户,这样做才能够极大提升租户运行的感知。

  举个例子,我们在做维护的时候,特地增加了一部分的自动化的运维能力,其中比较好的两个能力,现在对核心数据库的异常操作是我们目前实现了自动化查杀,另外一块我们已实现了通过手机 APP 对系统的灾备进行切换。

  上图是云平台规划的蓝图,详细不展开,我们的团队现在已经从一个系统的维护者转向一个系统的云平台的规划和建设者的角度去进行转型。

  下图我们一个技术预研体系,我们现在在实际在做的工作中,对我们运营商的 IT 团队,有些时候也比较被动。

  因为我们技术栈的引入很可能是由我们的开发团队去定的,但如果开发团队比较竖的话,会造成技术架构不标准,所以现在我们提出“预研一代、测试一代、推广一代”的工作策略。

  下图是我们的一个重头戏,我们现在已经把我们的核心系统中的包括手机营业厅、CRM 前端全部跑在云上。

  我们现在也已经把核心数据库全部都跑在了 X86 服务器上。应该说很多电信运营商目前都面临这样的挑战,希望可以在核心数据库服务器上进行去 IOE,这个我们浙江移动这边基本上也已经实现了。

  最后讲到实战的问题,刚才写到我们现在把容灾切换做到手机 APP 上,这个前提是我们的容灾切换必须是随便什么时间都能切换的。

  我们有一个比较好的灾备的管理体系,在巅峰时期大概每年的灾备演练有300次左右,现在因我们的技术架构发生了一些变化,目前没有这么多的演练次数。

  我们最早的时候用的灾备技术是用存储复制技术为核心区区别做的,这样的一种情况下数据中心处于冷备状态。

  我们通过技术和管理的结合,要保证灾备切换的成功率至少要达到两个9以上,这种情况下再通过手机 APP 实现移动端的灾备切换。

  我们最近一次在 APP 端的灾备切换大概花了8分钟左右。自己做灾备切换这么多年,我的感觉是,灾备切换本身是一个管理问题。

  现在我们心中也有一些思考和困惑,第一个是标准的问题,未来我们的团队会从运维转向平台,转向私有云的建设,在云的建设时候,我们该怎么样面临不同的租户提供不同的服务级别。

  我参考过国内很多网络公司公有云上开放的服务标准,但是越看越困惑,因为免责条款太多了。

  如果按照这样的免责条款,我们的团队 SLI 非常容易达到,但是面对私有云租户不能用这么低的 SLI,这是我们很困惑的问题。

  另外是价值,如何使IT产生价值,如何使我们的云平台产生价值,怎么让我的业务产生价值,因为有些时候我们做了很多技术创新。

  但是这些技术创新到底怎么样让我们的业务部门认可,让我们的领导能够认可,这是一个比较大的困惑。

  我们是运营商的传统企业,在传统企业的体制限制之内如何逐步发展我们团队的活力,这是一个非常大的挑战。

  还一块是当下技术发展特别快,当年在 IOE 时代,其实我们的 IOE 时代也持续了差不多有10年之久,我们曾经花了这么长时间,在 IOE 时代把我们的团队做到了应该说在业界还是比较可以的。

  但是现在技术发展很快,有时候我在想,可能我们花两年时间去研究透一个技术,可能两年后这个技术已淘汰了,这样的一种情况下我如何来管理我的技术栈,如何管理技术团队的稳定性,这可能是后面对我们 IT 团队非常大的一个挑战。

  运维都是说背锅侠,先请大家看一张图,我一直认为,从清朝开始,清朝是满清入关的开始,那时候开始把我们汉人连发式都进行了改变。

  后面经过曾国藩、孙中山先生等这么多年的奋斗,终究是建立了民国。从这个方面来说,我们的运维今天也应该有信心,我相信我们的运维能做到40岁,我相信我们的运维不会永远是背锅侠。

  梦想还是要有的,万一实现了呢。我们的很多先辈花了那么多的时间,可以把清朝变成民国,这么大一件事情都能做成,那我们运维为什么不能转型,这完全是可以的。

  还有就是心有多大,地有多宽。负重前进,实干创新,所有的事情都是你做出来的,我们运维的明天掌握在我们运维人自己的手里。

上一篇:IT行业工作分类有哪些
下一篇:运营维护费指哪些-运营维护费指哪些内容