浙江移动云原生运维数智化转型实践

王晓征 2023-04-20 10:18:49

本文根据王晓征老师在2023 中国数据智能管理峰会-上海站〗现场演讲内容整理而成。(关注【dbaplus社群】公众号,回复“230331”可获取完整PPT)

 

图片

 

讲师介绍

王晓征,中国移动(浙江)信息技术和数据管理部总经理。教授级高级工程师,中国移动集团首席专家、中国移动科协信息技术学部专家,全国最早通过Oracle OCM认证的数据库专家,甲骨文Oracle数据库客户顾问委员会数据库专家委员,TGO鲲鹏会荣誉导师。

 

分享概要

一、云原生下的运维转型难题

二、运维数智化转型思考

三、浙江移动运维数智化转型实践

四、展望

 

一、云原生下的运维转型难题

 

图片

 

08年之前,中国移动的主营业务以语音、短信、流量为主,到了19年之后,中国移动紧跟潮流,积极探索连接、算力、能力,将充分发挥数据能力作为发展目标,以谋求数字化转型,高质量发展。

 

在这个过程中,我们关注到了两个要素:数据要素和技术要素。

 

图片

 

大家都在谈数字化,它的本质是什么?

 

我对数字化的理解:这是一场光速对音速的碾压,以往我们的肉身存在物理世界中,是一个原子化的存在,但是信息和能量是光速,用信息和能量去替代原子,就是数字化的过程。

 

同时,为什么要说技术要素?

 

如果没有新的技术架构创新,就无法做到成本、效率、质量三者平衡且放大,三者无法同时兼顾。更重要的是,技术要素是数据要素的基础,如果没有云原生技术架构的升级,数据要素则无法存在。云原生数据库、容器化、微服务体系等技术都不存在的话,数字化转型就是一个空中楼阁。

 

接下来,和大家共同探讨一个问题:1000-2×500=?

 

图片

 

大家的理解得出的答案可能都是0,但我认为,也有可能等于707。事实上,这个方程是用于红蓝对抗军事演练的一个测算模型,由此可以解释,云原生带来的碎片化、分布式,给运维工作带来的是量级的增加,于是,运维人员在云原生时代下难承其重。

 

图片

 

云原生架构下网元数量呈指数级增长,系统故障的发生是不可避免的。毋容置疑,云原生的稳定性目前是不如IOE的,特别是国产化趋势加速之后,传统意义上的以资源和个人能力的运维模式在理论上就是不可行性的,这就是运维要数字化转型的核心出发点。

 

二、运维数智化转型思考

 

 
1、运维数字化转型的实质是什么?

 

图片

 

我认为是“对等还击”,以传统方式肉身人肉对抗云原生的网元是不可行的,运维必须驾驭技术和数据,用算力替代体力、机器对抗机器,这才是运维数字化转型的实质。

 

在多年运维团队管理的过程中,我经常被下属问到类似的问题:领导,我明年运维的系统多了三倍,成本是否能增加三倍?

 

很明显这个答案是否定的。传统运维是一种服务,从可持续性的角度来看,必须把运维从服务做成产品,等到在规模化生产时候,边际投入所获得的效益是不一样的。

 

 
2、在传统行业AIOps到底是雪中送炭还是锦上添花?

 

图片

 

当前大模型盛行一时,ChatGPT的关注度逐步提高。但从本质上看,人工智能仍以数据为支撑,ChatGPT之所以存在,是因为它拿到了足够的公域数据和流量,然而运维场景更多属于私域数据和流量,在大模型上面的实践还为时过早,在小模型上也许会有点状突破。然而点状突破在整体上是否有价值呢?

 

我个人认为:有价值,但没有颠覆性价值。

 

业界有很多AIOps产品,但从业务方的角度来看,外部运维产品和具体的业务场景所关注的痛点是不一样的。再者,科学技术和工程也是不一样的,理论上的东西,不一定能解决实际的运维问题。

 

 
3、电信企业(传统行业)真的有必要做DevOps吗?

 

图片

 

我的结论是做不了且不要做,“没有公主的命,就不要得公主病”。纵观业界,做DevOps实践大多数都是国内外的大厂,其人才素质、组织架构、技术理念等和我们都是不尽相同的,特别是对于传统行业来说,在条件不具备的情况下,东施效颦式的DevOps只会造成 1 + 1 < 2。

 

当前,国内外都在讨论这个问题,运维跟开发是两条平行线,开发人员是面向业务的,本质上不愿意对生产环境负责,这里面有利益导向和驱动力的问题。所以从这个角度上来,我认为,研发不能运维化,但是运维可以尝试研发化,反其道而行之。

 

 
4、行业新技术对运维能力演进有哪些技术红利?

 

图片

 

(1)数字免疫:事先预测、事中发现、自动修复、基础管理,数字免疫跟当前运维数字化的方向完全相符;

 

(2)应用可观测性:个人认为应用可观测性的本质应该是业务可观测性,从应用到业务是深维度的,让运维团队产生业务价值是应用可观测性的核心,当前大厂在这方面的实践相对成熟,传统企业仍需要继续探索;

 

(3)元宇宙:运维团队不需要肉身到场进行运维工作,是一个很值得去探索的问题。

 

 
总结:必须坚持AIOpsDev,打造技术风险防控体系,才能赋能业务稳妥创新

 

(1)数字化、自动化、智能化

 

尽管AIOps存在很多落地问题,但仍然是我们追求的大方向,智能化是我们的长期目标,中间过程中的数字化、自动化是不能忽视的。

 

(2)运维架构化、运维研发化、运营持续化

 

  • 运维架构化:就是把架构治理的职能放到运维团队,让运维团队有手段自由。很多单位的架构是运维不参与,只由研发或者规划团队参与,这个生产关系是不顺的,运维工作很难实现敏捷和闭环;

 

  • 研发化:运维有了生产环境编排自由,能进一步提升运维效率;

 

  • 运营持续化:运维才是真正对生产环境负责的团队,运维团队需要持续运营、持续培养。

 

所以我们的结论是, AIOpsDev是当前最佳选择。

 

三、浙江移动运维数智化转型实践

 

浙江移动运维数智化转型主要围绕这六“可”进行:

 

 
1、可预测

 

传统的运维模式是出现故障处理故障,在故障还没有发生之前,消灭可能会产生的故障,就是运维数智化转型的基础。

 

图片

 

 
2、可灰度

 

实现可灰度的关键三要素是全面云原生化、应用全面AZ化、控制中心化,这方面浙江移动的实践是较好的,目前已经实现了80%需求可灰度上线、95%的bug可线上处理、SRE的离职率降低了50%(大大减少了后半夜的运维工作)、100%的研发无需到场。

 

图片

 

 
3、可观测

 

可观测本身并不重要,关键是要靠可观测性打好运维的数字基础。当前众多IT团队的数据都是相对封闭的,让数据实现共享,是可观测性的关键。

 

同时,不要过于追求可观测性,将可观测性做到极致,受益无非就是定位根因。但是,恢复业务不一定需要定位根因,定位根因不一定能恢复业务,这一点值得大家深思。

 

图片

 

 
4、可协同

 

运维数智能化转型仍需要时间,未来也许我们能做到L4、L5无人驾驶,但在这之前仍需要运维人员参与线上故障的处理,在这种情况下,协同效益提高也是战斗力。

 

图片

 

 
5、可逃生

 

诊断或分析在复杂的应用架构中不断消耗,影响业务中断时间加长,如果基于异地多活的容灾体系,运维专家就可以通过沉淀更多的经验到预案中,实现应用由L3往L4自动逃生能力演进,以业务恢复为首要目标是很重要的。

 

 

图片

 

 
6、可守底

 

企业赖以生存的是业务,业务系统的稳定性是为业务成交的重要支撑,运维不是万能的,有的时候需要有个守底的措施以维持运营,方舟则是基于BASE理论,开辟第二通道,实现业务自动接管,挽回高峰业务损失。

 

图片

 

四、展望

 

展望一:从时间角度,持续加强运维场景建设,推动数字免疫或者自动驾驶从局部场景到全部核心领域的覆盖,从1-5-10突破至1-1-1。

 

展望二:从空间角度,持续推进元宇宙协同的数字化、智能化演进,探索基于元宇宙分布式协同运维新模式,提升跨域交付能力并降低多跨协同成本,实现多跨协同作战降本增效。

 

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告