开发者的黄金时代=运维人员的恶梦?

英文原文:Golden Age of Developers is a Nightmare for Ops

一款软件产品的发布离不开两类人的支持,即开发和运维。人们常常会把他们提到一起,如今 DevOps 开发模式的盛行也正是对他们的重新定义。目前软件环境的变化可以说是开发者的黄金时代,而对于运维来说,这些变化正给他们带来新的挑战和期望。

过去的十年给软件开发环境带来了翻天覆地的变化,其中最大的变化是通过开源和云来生产基础设施。就产品的灵活性和生产力而言,这绝对是对开发者利好的消息,但也给 Ops(运维)带来了一些新的挑战和期望。

Dev 的黄金时代

在过去,开发者的工具箱里仅有几个大型软件供应商提供的单片式解决方案,比如 Oracle、IBM、HP 等。这些解决方案一般都比较昂贵,并且还会伴随整合和更新较慢等特点。一旦公司购买了它们,无论它们是否适合你,你都必须好好地利用它们。

如今,丰富的开源和云解决方案的出现彻底把开发者从传统的工具依赖中解放出来,开发者可以在过去同等的条件下享受更好的基础设施。开发者也可以根据自己的工作需求选择合适的工具,并且它们是免费廉价的,这些工具能够更好更快的进行整合,根据需求进行规模化扩展。现在,一个公司使用多种数据库(Redis 用于缓存、Elasticsearch 用来搜索、MySQL 等等)已经变的非常普遍,这些工具分工明确,兼容多个平台。与此类似的各种分工工具还有:监控工具、计算环境、应用框架等。开发者可以因时制宜地选择各种工具,提高产品的开发灵活性、生产力、性能等。

持续部署给开发者带来了更多地福利,他们不再按月或者周期性地进行绑定发布,发布周期大大加快。这些都使得开发人员能够事半功倍地完成产品,产品的更新已不再是业务人员与开发者之间的一个瓶颈。

Ops 的恶梦

与此同时,工具的丰富与分工也创造了“Ops 恶梦”,比如 DevOps、SREs、IT 管理等一系列新的挑战和期望。

变更的速度:产品的监控和响应需求在数量上有了显著的提高。为什么?因为大量的产品问题都是来自内部的代码部署和架构变更。当进行持续部署(更不用提虚拟化和基础设施即代码了),变更的速度会大幅提升,速度地提升也很容易导致产品出错。由此可以得出一个论点,即持续部署可以减少潜在的、灾难性的错误,因为变化的周期变短、增量变少。

移动部分:现代基础设施之间的最佳组合给运维人员带来了不少灾难。可移动的部分越来越多、依赖关系更加复杂以及更多的监控工具会时不时地发出各种警报。在这样的环境中,故障排除已经成为一个永无止境地分类过程:过滤报警内容、优先考虑和应对潜在的事故,可以简称为报警疲劳。这已经是一个很常见的现象了,运维人员抱怨到:他们有 50%—70% 的时间都消耗在了响应报警上,以至于影响到了他们的核心工作:构建业务支持的基础设施架构。

运维人员的底线则是迫切需要一些工具来解决和处理这些警报疲劳。一个很好的出发点就是企业能够把噪音警报组织到一个更高层次的事件中,可以快速获得他们想要的流程,并能够有效地与利益相关者之间进行协作。

DevOps

DevOps 的滚滚而来正是为了解决文中所提及的开发与运维瓶颈,更加强调开发与运维之间的密不可分。在 DevOps 环境下,开发人员和运维人员会构建一些关系、流程和工具,从而更好的与用户互动。只有当人们愿意相互交谈,关心相互的工作时,才能更好更快地创造商业价值。

时间: 2024-10-10 21:32:36

开发者的黄金时代=运维人员的恶梦?的相关文章

运维人员应人手一个GitHub帐号

最近在学习一些新东西,在实验环境下自己写的一些程序或脚本,觉得以后还能用的上,就想保存下来: 如果保存在本地或者U盘之类的移动存储中,以后重装系统或者U盘丢失也就损失了,而且作为一个IT从业人员,这年头文件不存储在云端,都不好意思说自己是混IT圈的: 最终选择了GitHub这个代码托管的网站,以后如果写出点像样的开源软件,还可以得到众多开发者的跟进,想想就挺美的!!! 所以今天就花了点时间整理了一下官方的配置使用文档,以帮助有同样需求且看英文文档费劲的同行们! #################

谈谈运维人员谨慎操作系统环境和管理

很多时候,特别是初学者在搭建环境的时候,由于事先尝试了,导致软件残留,以至于部分软件安装失败.当然了,通常可以百度直接找到解决方案. 不过呢?有一点需要注意的,运维同志们再安装软件时,哪怕是尝试,尽可能本地虚拟机环境尝试,千万不要在生产服务器上. 卸载同删除一样,是一个极其危险的.有的时候一不小心咔擦,删错了东西,可能会导致系统没了,例如,记得刚刚做运维的时候,在公司电脑上,自己弄了几台虚拟机,其中有一台就是因为我不小心把boot给删了,导致很多东西都没了,不过幸好是本地虚拟机,如果是公司服务器

【IT运维监控】集团宕机引发对运维人员的思考 

前不久某大型集团官网和APP突然无法正常使用引发热议,不少人幸灾乐祸,也引发出了各种的谣言和段子,根本难以体会集团内部所受的压力,特别是作为一个大集团内部的运维人员所承受的各种压力和不安. 后 来,原支付宝运维团队负责人针对此事发表了一篇文章,让不少的运维人员深有感触,作为肩负运维监控使命的运维监控工具--PIGOSS BSM 也同样感同身受.面对层出不穷的运维安全隐患,当下运维人员急需一套高效的7*24小时都能担负监控任务的工具,为自身的运维工作减负,告别之前加班熬夜 但没有工作成绩的"怪现像

02、alex 说过“普通运维人员就是秋后的蚂蚱”

我非常认同这篇文章 http://3060674.blog.51cto.com/3050674/1598255 刚工作的时候,搞开发很辛苦,没人带,所以果断选择了运维,从而快速升职.但是现在认识到,并且alex明确说过:普通的运维人员已是秋后的蚂蚱,蹦跶不了几天了,他们已经走在了被淘汰的路上,IT自动化必将砸掉大多数不思进取的运维人员的饭碗,寿终正寝只是时间问题, alex讲过农村电工被淘汰的事情,类似的案例还有很多,例如邮递员被快递公司取代.电报被固话取代,然后是移动通信.互联网.... 运维

01.运维人员需要学编程

老男孩写过<不懂编程的运维人员到底还能走多远?> http://oldboy.blog.51cto.com/2561410/1749513 从本人工作经验来看,认同他的观点:IT岗位需要的是综合能力强的人员,运维.开发.数据库.网络,技术岗位对上述知识体系都要会一些,才能很好的胜任对应岗位工作. 1.运维人员要会运维.开发.数据库.网络,但侧重点是运维, 2.开发人员要会运维.开发.数据库.网络,但侧重点是开发, 3.数据库人员要会运维,开发,数据库,网络,但侧重点是数据库, 4.网络人员要会

Linux运维人员需要掌握一门编程语言吗?

最近经常有同行的朋友或者Linux初学者问我:运维人员是否需要学一门语言,那么该学哪种语言呢? 对于这个问题,我分两个方面回答: 首选,在大数据.云计算发展迅猛的今天,系统运维人员如果不懂一点开发语言的话,确实会举步维艰,因为在运维工作中,业务系统的繁多,线上服务器规模很大时,只能通过写脚本的方式(自动化也是脚本一种哦)自动化完成,不然,如此重复和繁琐的工作,靠人力是无法负担的,所以,学习一门可以让运维工作批量完成的语言,就显得很重要了. 那么应该学习一门什么语言呢? 对于Linux系统运维人员

【运维者说】程序员玩跨界,错在运维人员

在很多交流场合,我们或多或少能听到有小伙伴抱怨运维岗位工作没有得到老板或者公司同事的认可,这怪谁呢?私以为只能怪运维岗位的各位同行,为什么这么讲呢?我这个攒了很久的大招,今天终于可以释放出来了. 恰逢看到田逸老师写的博客<程序员,请不要抢系统管理员的饭碗>以及文章下面各位同仁的评论内容,很多小伙伴基本上是从一个系统管理员的角度出发说出了安全问题的原因是程序员不应该这么做而这么做了,那程序员应该怎么做,他们知道吗?从这篇博客中描述的安全问题出发,田逸老师作为系统管理人员排查问题的思路非常清晰,对

【IT运维监控】讨论哪种运维监控工具才是IT运维人员的最爱?

选择运维工具的几大要素:一是看我哪些指标需要监控,二是看我监控到什么 三是看这种运维监控工具能监控到什么程度 有可能,这几个问题IT运维人员自己都没有弄的很明白,那么我们先看一下整个运维行业目前的现状: 目前来说,传统企业的IT运维大部分还是用户在使用过程中发现故障,然后通知运维人员,再邮运维人员确定是什么问题,采用哪种方式可以解决.大部分的运维人员目前还是充当的只是一个救火员的身份,没有起到真正的IT运维监控的作用.运维人员的大部分时间和经历都花在了处理简单而重复的问题上,导致同事及领导的不满

运维人员处理服务器故障的方法总结

运维人员处理服务器故障的方法总结 一.尽可能搞清楚问题的前因后果 二.查看有谁在线 who last 三.查看之前执行了什么命令  history 四.查看现在在运行的进程是什么 pstree -a ps aux 五.查看监听的网络服务 netstat -nxlp netstat -ntlp netstat -nulp 六.查看CPU 和内存 free -m uptime top htop 七.查看硬件 lspci dmidecode ethtool 八.查看IO 性能 iostat -kx 2