首页 > 科技 > 云会“杀死”运维吗?解读运维的云上发展

云会“杀死”运维吗?解读运维的云上发展

​​​运维是从 IT 诞生之初就一直存在的重要角色,在 IT 类企业中,尤其是互联网企业,运维、开发和测试被称为是驱动技术进步的三驾马车。但最近几年,云时代的到来,让很多运维同学倍感焦虑,“云计算是未来”得到了大多数人的认同。


2019 年 Q1,公有云 IaaS 市场同比增长 74%。越来越多的企业,开始把自己线下的数据中心和机房搬迁上公有云。而一旦企业放弃了自建的 IT 基础设施,甚至把员工的办公电脑都搬到了云上,由公有云厂商提供服务,那么企业是否还需要这么多运维人员呢?在云时代的浪潮下,运维的未来会何去何从?


云时代的运维是怎么样的
既然上云势不可挡,我们何不顺势而为,看看云上运维是什么样子的?
首先,云上运维和传统的运维,操作的目标是不一样的。传统的运维人员,需要能够熟练的手动操作来自众多厂家的计算、网络、存储等硬件设备,而云上的运维人员完全接触不到物理设备,取而代之的是云上的虚拟资源,例如云服务器,云盘,虚拟交换机等。云厂商将对资源的操作全部抽象成了软件定义的 API 接口,并用统一风格的 SDK、命令行进行封装,提供给运维人员使用。云厂商提供的图形化的运维控制台,也不过是 API 的封装而已。

其次,云上运维是高度简化的。传统的运维,需要学习来自众多“大厂”的认证,例如,网络运维要学思科的认证,数据库运维要学 Oracle 的认证,系统运维要学 IBM 的认证,等等。而在云上,虚拟专有网络产品将网络设备的管理和运维变得统一和简单,云上数据库产品实现了智能化的数据库管理,云服务器实现了动态的扩缩容和热迁移,这些都大幅降低了运维操作的门槛。云上的运维人员不再需要感知底层基础设施的细节,更不需要考取高难度的认证。即使是创业阶段的小企业也可以拥有和大企业同等的运维能力。
但是运维简化,并不意味着运维的重要性降低,相反,在云上,运维变得比以前更加重要了。


云时代运维面临的挑战

为什么在云时代,运维变得更重要了呢?主要有两个原因,一是云上运维的范畴比以往扩大了,二是云上企业对于稳定性的要求更高了。

具体来说,云上运维主要面临着以下挑战:首先,运维排查问题的难度增加了。由于云上“黑盒子”的存在,当故障突然发生时,运维人员往往只能看到服务出现异常了,很难快速判定问题出在哪里,从而耽误了故障恢复时间。
第二,云服务发出的消息、日志、事件等难以有效处理。如果运维人员每天收到几千条短信或者邮件,一定是无法及时处理的,只能无脑忽略。但是又不能设置邮件规则将它们全部扔到垃圾箱里,因为会担心漏掉重要的通知。
第三,资源的膨胀带来了管理的复杂性。所有的资源都是软件概念,对于一个大企业来说,这些资源可能分布在全球的不同地区,分散在几百到几千台的服务器,这些资源也一直在变化。如何有效的跟踪、审计、创建、释放并保证无浪费?
第四,云产品的频繁升级带来了运维的频繁被动变化。云产品的选择非常多,实例类型纷繁复杂,运维人员的工作越来越多,从传统的机房巡检工作到需要实现监控告警、安全防护、日志审计等更多功能。如何选择适合自己的产品?新功能如何才能帮助到业务?...... 盲目的不停更换运维方案不是良策。


如何调整才能适应云时代的运维
云帮手可能是答案。
监控自动化。相信大家都走过人肉运维的痛苦阶段,尽管运维工程师 7*24 轮班待命,但客户仍然投诉不断,系统问题不断。因此,云帮手团队开始建设稳定性,通过监控报警将故障的平均发现时间从 1 小时缩短到1分钟,可以在故障发生前,提前预警并采取行动,帮助运维实现无人值守监控全过程。
信息分类化。由于监控项较多,当一起产生告警时,运维人员会应接不暇。云帮手通过告警信息分类展示,让用户可自行选择查看某一项告警信息,能够减少遗漏,快速找到问题根源并处理;同样,有效的日志分类能够帮助用户及时查看到自己某一项的操作记录,快速追溯到问题根源,提高运维效率。
管理集中化。当运维需求随着业务需求不断变化,服务器不断增多,我们需要对其进行统一集中化管理,并在数量不断增加的情况下保持稳定。云帮手支持多IP服务器集中可视化管理,功能覆盖整个业务流程,避免多系统繁杂管理,保障业务高效运行。
运维全面化。当用户需求开始变得复杂,我们需要以一抵十,所有运维功能一站式管理,减少产品更迭。云帮手能够同时实现巡检修复、监控告警、环境站点部署、安全防护、系统管理、日志审计等多项功能,有效实现全面化运维,满足不同用户需求。


要想实现云上运维的顺利升级,首要任务就是”自动化一切“。云帮手强调高度的自动化,帮助运维解决人为不可控制的难题,实现了一系列的可视化运维模块,并会朝着智能运维的方向持续演进。​​​​

本文来自投稿,不代表本人立场,如若转载,请注明出处:http://www.souzhinan.com/kj/278044.html