工程师的未来10bet

来源:http://www.chinese-glasses.com 作者:Web前端 人气:92 发布时间:2020-03-31
摘要:如今开发软件的方式正在发生深刻的变革,回想起刚毕业的时候做软件开发工程师,和现在已经截然不同了。 作者 | 滕圣波策划 | 田晓旭 最早运维工程师往往是公司里一个独立的团队

如今开发软件的方式正在发生深刻的变革,回想起刚毕业的时候做软件开发工程师,和现在已经截然不同了。

作者 | 滕圣波策划 | 田晓旭

最早运维工程师往往是公司里一个独立的团队,公司租用公共机房的机器,大一些的公司也会选择自建机房。上架新机器是个流程繁复的事情,从公司决定采购到物理机器到位这中间有很长的时间间隔。

运维是从 IT 诞生之初就一直存在的重要角色,在 IT 类企业中,尤其是互联网企业,运维、开发和测试被称为是驱动技术进步的三驾马车。而金融、政府、医药、教育、制造、运输等其它行业,为了进行数字化转型,也纷纷建立了自己的或大或小的数据中心,并为了维持这些 IT 系统的正常运转,设立了大量的运维岗位。可以说,信息技术已经并且正在改变我们身边的一切行业,而只要有 IT 系统的地方,就有运维同学的身影和贡献。

在实际的业务开发过程中,开发工程师在项目结束之后需要正式的「移交」给运维工程师来处理后续的事情。然而全栈工程师的概念慢慢流行起来,推崇「You build it, you run it」。高级的工程师可以拿到线上本来只有运维才有的权限,自己写的代码自己考虑部署、监控、告警。

但最近几年,云时代的到来,让很多运维同学倍感焦虑,“云计算是未来”得到了大多数人的认同。2019 年 Q1,公有云 IaaS 市场同比增长 74%。越来越多的企业,开始把自己线下的数据中心和机房搬迁上公有云。而一旦企业放弃了自建的 IT 基础设施,甚至把员工的办公电脑都搬到了云上,由公有云厂商提供服务,那么企业是否还需要这么多运维人员呢?

DevOps 也开始深入人心,运维团队中出现了很多自己开发的工具,上线系统、配置管理、监控告警平台等等。

与此同时,DevOps 思潮席卷全球,大家纷纷尝试“组织机构变革”,打破开发 测试 运维之间的边界,由开发人员来直接负责自动化的测试和运维工作。更进一步,从 DevOps 进化出了 AI Ops 甚至 No Ops,人工智能开始在运维领域显露身手。而云计算与 DevOps 正好是天生一对。云是 DevOps 最好的平台,而 DevOps 是云上的最佳实践。

但无论怎么变化,所有软件和硬件都还在自己的机房里,直到云服务的到来。

在云计算和 DevOps 的双重压力下,运维的未来会何去何从?

也就是我们目前所处的环境,软件和硬件都走上了云端,即使那些还在自己经营机房的大公司,本质上也是一个内部的云服务商。云服务的核心是虚拟化,任何人都可以很轻松的在几分钟之内申请到新的虚拟机器。运维工程师进化为了可靠性工程师,以设计软件运行环境和管理软件配置为主。

云时代的运维是怎么样的?

说完现在,就要说未来了。

冲浪是一个非常刺激的极限运动。相比海浪的力量,冲浪者的个体力量是渺小的,每一次冲浪都是一次冒险。但智慧并且勇敢的冲浪者会仔细观察海浪的方向并调整冲浪板与海浪方向一致,当海浪抵达时,冲浪者会站起来,在海浪的冲击下急速前进,享受浪尖上的快感。

很久之前读过《代码的未来》,今天想讨论一下几类工程师的未来的工作方式。

冲浪者很清楚,自己成功的关键在于找准海浪的方向。我们技术人员也一样,只有保持对新技术的敏感性,并及时调整自己,才能借助浪潮的力量快速进步。

DevOps

给大家讲一个真实的故事。2009 年,阿里云刚刚成立的第二年,时任淘宝技术总架构师行癫宣布淘宝网将抛弃 Oracle,转投云上的自研数据库。获知此消息后,八十多个 Oracle DBA 把当时的 DBA 负责人后羿堵在会议室里,“如果上边铁了心要干,兄弟们的前途在哪里?”还好,技术人是讲理的,一场恶斗转化成了几十个工程师坐在会议室促膝谈心。既然上云是战略,为何不顺势而为?就这样,一群 Oracle DBA,开始亲手拆毁自己安身立命的系统。2013 年 7 月,淘宝最后一个 Oracle 数据库下线。时至今日,整个阿里集团,所有的核心业务 100% 跑在公共云上。

无论是自建机房还是云服务,运维工程师一直无法避免要知道「什么东西部署在什么机器」。然而 Docker 和 K8S 的出现将彻底的改变这个情况,无论多庞大的集群,交给软件自动来编排。软件的标准化、部署、迁移的方式得到了质的变化。

是啊,既然上云势不可挡,我们何不顺势而为,看看云上运维是什么样子的?

运维工作需要更加深入到业务中,了解项目打包的过程,管理公司内部的镜像,提供标准化的持续集成的工具,提供各个项目的 docker 开发环境。

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

数据工程师

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

说到这个感触就更深了,因为我们数据仓库的基础设施刚刚完成从自建 CDH 到云上服务的迁移。

但是运维简化,并不意味着运维的重要性降低,相反,在云上,运维变得比以前更加重要了。

一直以来,我们已经习惯了离线数据和大量计算的需求使用其他工具来完成,比如各种 ETL 工具和 Hive。然而现在的趋势是将存储和查询引擎解耦开来,无论是什么存储,都使用同一套协议来查询。

云时代运维面临的挑战

也就是说无论是分析师还是 ETL 工程师,只要会 SQL 语句就可以了,更重要的是代码层面完全统一。

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

开发工程师

从范畴上看,云上运维包含了从蓝图规划,到上云交付,再到云上管理的全过程。如果我们具体到流程和阶段,包括了设计选型、资源交付、系统交付、运维调优、扩缩容、资源运营、备份容灾,安全 审计等等。

开发工程师以后只关注生产业务逻辑即可,随着高级语言的发展,不需要懂底层的知识也可以开发出高效稳定的软件。

从稳定性方面看,通常云厂商只负责基础设施的稳定,上层应用仍由企业开发人员自主开发,同时云上应用本身的稳定性也由企业自己的运维人员负责。如果具体来说的话,企业运维人员需要负责持续发布过程中的蓝绿发布、灰度发布、分批发布、自动回滚等的实现,以及应用层的监控、事件告警体系的建设。另外,云上基础设施的稳定性不能单纯依靠云厂商,也需要企业运维人员的相互配合。例如阿里云的云服务器单台实例的可用性达到 99.975%,但仍然存在着万分之 2.5 的不可用时间。企业的云运维人员可以采用监控、负载均衡、多机热备、两地三中心等常用的高可用设计,在不是百分百可靠的基础设施上,搭建百分百可靠的应用。

以 Go 语言为例,代码层面交互的只有 goroutine,背后是协程还是线程还是进程,语言的底层来帮你解决。越来越多的第三方库帮你做掉了大部分的工作,工程师只需要看着文档会调用即可。

具体来说,云上运维主要面临着以下挑战:

Serverless 可能会成为主流,即写完业务逻辑不需要申请服务器,直接在云端运行。

首先,运维排查问题的难度增加了。由于云上“黑盒子”的存在,当故障突然发生时,运维人员往往只能看到服务出现异常了,很难快速判定问题出在哪里?是云服务商的基础设施出问题了,还是我自己的代码出 bug 了? 甚至就算排查出是云服务商某个服务的问题,部分运维人员也只能打电话给客服寻求帮助,而从客服得到的回复往往难以令人满意,从而耽误了故障恢复时间。

总结

第二,云服务发出的消息、日志、事件等难以有效处理。如果运维人员每天收到几千条短信或者邮件,一定是无法及时处理的,只能无脑忽略。但是又不能设置邮件规则将它们全部扔到垃圾箱里,因为会担心漏掉重要的通知,比如服务器宕机的通知。

无论是哪个领域,计算机软件的生产都走向了「使用越来越简单,背后越来越复杂」的方向。

第三,资源的膨胀带来了管理的复杂性。所有的资源都是软件概念,对于一个大企业来说,这些资源可能分布在全球的十几个 region,分散在几十个云产品的控制台,服务于几百种不同的负载或者在线服务。更可怕的是,这些资源一直在变化。如何有效的跟踪、审计、创建、释放并保证无浪费?

我认为公司需要的技术专家和架构师将大幅度减少,与此同时云服务使用专家将成为新的需求。

第四,云产品的频繁升级带来了运维的频繁被动变化。云产品的选择非常多,实例类型纷繁复杂,包括预付费、后付费、预留实例券,什么性能突发型、计算型、通用型、GPU 实例、专有宿主机、裸金属实例,容器服务、Kubernetes 或者 Swarm、弹性容器实例,等等。更要命的是,这些云产品还在不停地发布升级,如何选择适合自己的产品?新功能如何才能帮助到业务? 盲目追随云厂商的脚步不是良策。

普通工程师也许真的可以变成简单培训即可上岗的职业,普通工程师的可替代性会进一步提高,核心技术掌握在极少数大型公司,尤其是云服务公司之中。

如何调整才能适应云时代的运维?SRE 可能是答案

开源软件将走向「社区孵化,云服务商私有化」的道路,最终开源软件将被头部云服务商垄断,然后变成 SaaS 最终成为云服务商的现金流。

如前面所说,企业上云之后,仍然有大量的运维需求。但此时的运维,却又与传统的运维截然不同。企业应该如何进行结构调整以适应上云后的新形势呢?

从企业家的角度来看,生产软件的成本可能会降低。但从工程师的角度来看,其实有点悲观的,要么努力成为顶部的技术专家,要么就会变得随时可以被代替了。

DevOps 是现在提到的很火的概念,DevOps 实践的整个生命周期是从计划 -》编码 -》构建 -》测试 -》发布 -》部署 -》操作 -》监控,再回到计划,是一个循环。其中发布、部署、操作和监控是属于运维领域的。

原文

DevOps 实践打破了开发和运维之间的壁垒,开发人员可以直接负责运维。云上的运维已经和软件开发融为一体,强调高度的自动化,沉淀了一系列的运维工具和运维平台,并朝着 AIOps 和 NoOps 的方向持续演进。

而反过来,运维人员如果能掌握开发技能,结合自动化工具的使用,是否能够做的更好呢?答案是肯定的。运维人员可以转型升级为兼具开发技能和运维技能的站点稳定性工程师。Google 最早推出了 SRE 这一概念,并使得 SRE 部门成为其承担运维职责的一个研发部门。越来越多的上云后的企业,开始把自己的运维部门改造升级为 SRE 部门。

SRE 听上去很美,但真正要做到并不容易。以阿里云为例,早年阿里云也走过人肉运维的痛苦阶段,尽管运维工程师 7*24 轮班 on call 待命,但客户仍然投诉不断,系统问题不断。后来,阿里云团队开始建设稳定性,通过监控报警将故障的平均发现时间从 1 小时缩短到 10 秒钟,同时借助 AI 预测算法,在某些情况下可以在故障发生前,提前预警并采取行动。现在阿里云每年发布上千次变更,难免会出现变更导致的故障和异常,但是 SRE 团队蓝绿发布、灰度发布、分批发布、自动回滚、热迁移等技术,实现了发布全过程无人值守。

如何才能升级成为 SRE 呢?这三点建议可能对你会有所帮助:

一是学习 DevOps 的实践,熟练掌握至少一种编程技能,从思想和技术上,保持工程师的先进性;二是学习云厂商提供的各种自动化运维工具,并灵活运用,尝试帮助自己企业搭建高效率的自动化运维平台;三是积极参与开源和云厂商的生态建设,伴随运维生态一起成长,如果能产生出运维平台级的解决方案产品,广泛应用于整个行业,那么个人价值和商业价值都会得到体现。自动化一切是云时代运维的首要任务

要想实现云上运维的顺利升级,首要任务就是”自动化一切“,如果列出 Top3,应该是:监控自动化、运维操作代码化、基础设施代码化。

监控自动化

先来看监控,包括了“监”和“控”两个方面。

监控的“监”

“监”,从横向划分,包含了事件,日志,指标,告警四个维度;从纵向划分,分为底层基础设施的“监”和上层应用的“监”。

横向看:事件、日志、指标和告警

本文由10bet发布于Web前端,转载请注明出处:工程师的未来10bet

关键词:

最火资讯