行业里有个笑话:越高级的运维越像个隐形人!所以楼主是遇到困惑了,提供自己的能力吧!
说到运维,多半是甲方单位招聘的,乙方一般是研发和实施。项目结束后甲方需要运维。从基层职位看,运维和开发(含产品经理)的分工还是挺大的。
本人做软件开发多年,平时主要考虑功能和非功能的实现,运维负责系统上线后系统的稳定、高效运行。所以在所需技术上也大有不同。
开发重点在各种开发语言、开发框架、持续性集成环境、软件工程、算法以及对应的业务等等,对底层的运行环境 *** 心的不太多,尤其上了云环境之后,越来越少 *** 心负载均衡、高可用这些非功能需求。
运维的重点在于系统运行的各种环境,从机房、网络、存储、物理机、虚拟机这些更基础的架构,到数据库、中间件平台、云平台、大数据平台,偏重的也不是编程,而是对这类平台的使用和管理。
所以开发重建设、运维当然就是维护。所以运维比开发更不受重视也是可以理解的,很难出彩,不出事就是成绩,尽管付出的努力并不少,甚至更多。看过产品运营的人说过一句话“不要管开发做出的是什么垃圾产品,留住客户才是运维关心的“
但是在高层考虑中,尽管运维仍然受重视程度比不上开发,但已经不仅仅是考虑要尽快满足业务需求的问题了。基础架构越来越有话语权。一方面,确实这个是很耗钱的事情(有钱就有话语权)。开发个系统不是有代码就能运行的,养个机房(特别是高端机房),动辄投资也得上亿,上千台服务器也不是那么容易管的,每年的折旧、报废也是钱啊,光电费也够养几个高级RD了。另一方面基础架构,特别云化之后,更是要制约开发使用的语言和程序架构。还有越来越受重视的安全管理,更是巨大的投资,甚至上升到维稳层面。
但是总体来说,运维工程师是IT的后台,IT是一般甲方业务的后台。所以,重要是很重要,但是可能永远不如RD受重视。当然,小部分运维也很受重视,比如制造业,但毕竟是少数。
所以,it运维工程师选择就没有回头路,努力提供自己能力是王道!
IT行业管理模式分为服务外包管理模式、企业自主管理模式、混合管理模式。
服务外包管理模式:
这种模式指的是企业通过与外包公司签署运维外包协议,将所拥有的全部IT资源的运维工作外包,由外包公司为企业各单位提供IT运维服务。和经验,会使得过程管理流于形式或者半途而废。
企业自主管理模式:
这种模式指的是指企业自行负责对拥有的所有IT资源的运维工作。好处是企业自身的运维人员容易管控,可根据企业自身需要进行能力培训,完成企业所需的各项IT运维工作。缺点是企业内部IT人员数量有限,对于并行的跨区域的IT运维工作很难提供有效的支撑,并且由于IT运维相关的专业技能培养时间较长,往往无法满足企业IT运维工作的要求。
混合管理模式:
这种模式指的是指企业对所拥有的一部分IT资源自行运维;同时,通过与外包公司签署运维外包协议,将所拥有的另一部分IT资源的运维工作外包。这种IT运维管理模式下,企业需要充分考虑内外部运维人员的职责划分和人员比例,在合理的运维成本下,既保证IT运维工作的顺利完成,又确保企业自有运维人员能够得到充分锻炼和提升。
这个比例和公司的业务有关。
像金融行业,核心交易,国防,安全软件, 要求可靠性高的, 测试员会多一些。 差不多要1:1
也听说过有些公司都没有测试,就让程序员兼职测试。
一般情况下推荐比例是 3个开发:1个测试。
我个人认为:
c 相对开发,运维的经验学习成本是比较高的,就是说你不在一定的实用环境下是没法学会真本事的,而开发你坐在家里就可以摸索一个大概出来;而运维的知识更新 的速度相对慢,10年前的DBA知识更新可能只有50%,而他本人会非常值钱,而2年前java的一些内容可能都没有发明出来;除非你在开发做到管理职 位,否则纯技术开发学习更新的代价会非常高;反过来说:技术开发适合比较喜欢新鲜、喜欢创新的人,而运维适合循规蹈矩比较踏实的人;
– 所谓IT运维工程师发展空间是要结合你个人的性格,资深DBA之类的人在地球上还是很稀缺的,我知道ebay china operating center的DBA有开宝马上班的,而且运维不是吃青春饭,越老越吃香,可以说是个平滑的上升直线,而开发如果你只是一个执行者和coder,恐怕就是 一个开始猛涨后面猛跌的曲线,毕竟开发知识代谢成本太高,过了30就走下坡路;
在互联网行业,运维一直是一个被深深误解的位置,以至于很多人认为IT行业运维的技术含量很低,其实并非如此。
从本质上讲,运维其实就是你用自己的技术储备知识的岗位,保证你管理的IT服务能够正常运行。
在商业上也是一样。软件工程师的任务是通过编写代码将软件以图形化的形式提供给用户,而运维工程师的任务是使软件在计算机或系统上正常运行。但是一旦软件出现问题,大多数人想找的是软件工程师,而不是运维工程师。
就像我们盖房子一样。产品开发负责房子的规划,设计师负责房子的外观设计,开发工程师负责建造房子,运维负责打好房子的地基。而打好地基,并不意味着简单地挖个坑。里面的技术含量很高。必须彻底研究坑的大小、深度、大小、湿度等。
房子盖好后,大家只会关注房子盖好后的风格。很少有人会注意房子的地基,但是一旦房子倒塌,大家就会怀疑地基是否牢固,运维这时候就出来了。回到平底锅。
很多人片面地认为运维没有技术含量。这其实是一种错误的认识。因为运维也是分很多层次的,就看你达到了哪个阶段。基本上,现在一个运维除了掌握基本功,如果你还可以掌握云计算技术和一门编程语言(比如Python语言最适合运维人员),那你就已经是高人了级别,基本上是全栈开发运维人员。这种运维不用担心找不到工作,工资自然比其他普通运维高。
我自己在大公司和小公司都待过。我觉得主要是初级运维太多了,他们做了很多根本不能叫运维的事情。总结了以下几点:
运维必然会做基础工作,比如部署服务,上线,甚至搬机器,重装系统等等。但是运维不能只做这个,所以如何在剩余的时间内做有利于运维技术提升的事情就显得尤为重要。
举个简单的例子:当你做研发的时候,你在其中处于什么位置,你如何体现你的价值和技术能力?如果没有,你基本上是在帮助别人。
广泛的范围包括:硬件、网络、 *** 作系统、数据库、存储、开源软件;职责:部署和调试各种功能,如ldap、samba、nagios等;进一步细化的分工还包括:压力测试、性能优化、内核参数调优、系统问题跟踪等。
很多运维要在不同层次上做太多的事情,导致很多事情只是完成任务,缺乏深入研究,当然也可能缺乏深入研究场景。
其实和第一点关系比较大,因为目标本身没有足够的规划,总结性的介绍不够,技术的提升也比较有限。
举个真实的例子,我认识一个做运维7年多的人。这期间,他在几家公司干了很多事,时间也不短。通常情况下,会有相当多的积累。前段时间,我正要推荐他在内部击球时,我查看了他的简历。我有几个感受: 整个简历都是描述性词汇,没有数据支持;项目工作全是叙述性描述,充满服务搭建和问题解决,没有技术点;唯一的技术工作是一笔带过,没有方案选择和技术能力体现,技术水平无法体现;
我自己也面试过很多人,说实话,这种简历离及格还差得很远。应聘公司拿到这样的简历,怎么能快速的了解到你就是公司需要的人?
如果我们不知道运维的具体内容,我们无权评价运维的技术含量。一般来说,互联网公司的运维内容分为两个层次:
简单的说,就是部署服务、维修电脑、安装系统、安装软件、处理网络问题等等,做各种家务活,甚至弄个路由器、剪网线。
网络运维,即网络工程,必须精通各种网络协议和架构,Cisco、华为、H3C路由和交换,至少两项;
数据库运维,数据库运维应该理解为DBA,至少要精通,并且要精通数据库;
*** 作系统运维必须精通 *** 作系统,了解 *** 作系统内部工作原理,了解一些硬件知识,了解网络协议进行故障排除;
还有很多其他的事情,比如服务器运维,都需要覆盖面广,同时拥有多种技术;
运维技术差,可能只是因为公司小,如果公司规模小,大家看到的运维工作只能是表面和基础的工作,现在很多运维岗位都被云服务取代了。运维的内容是在云平台上运行软件。
事实上,有人认为在平台上 *** 作软件很简单,但实际上,如果没有计算机相关知识的积累,很难知道云平台上的功能实现。在这方面,技术含量不低。
如果公司逐渐成长为大型公司,运维的价值就会凸显。比如云资源和离线资源的管理、数据库管理、网络管理、计算资源、网络资源负载、调度处理,都需要丰富的计算机理论知识和实践经验,否则无法提供稳定、上层的可靠服务。
作为一家提供互联网服务的公司,用户能否稳定可靠地使用互联网服务,是他们生活的基础。想象一家公司每三天失败一次并且服务不可用。虽然强调了运维的存在,但大家还会相信你的产品吗?
运维功能:
首先,BAT在运维上的分工更加细化。通常,系统、数据库和应用运维是完全分离的。因此,它可能更侧重于功能,当然涉及的范围肯定会很窄。
在工作职能方面,运维主要围绕可用性、效率提升和成本控制三个主要方面,与公司和研发目标密切相关。运维所做的大部分工作都是基于这三个目标。拆卸。
在技术改进方面,主要是以项目的形式,利用对服务的理解和技术方案来解决常见问题。
技术工作:
以服务可用性为例。这不仅仅是处理警报。 *** 作时要小心。就像编写一些自动化工具一样简单。
在工作方式上:
严格按照既定计划安排工作、审查、总结。分工的实施是否有明确的规则,什么时间维度准确到季度?月?星期?天?我多久回顾一次?
结合这些方面,BAT运维的同学才有可能实现快速的技术提升。这是我所看到的。
最后说一下运维方向:
为了在运维方面有一个光明的未来,需要几个要素:
至少是已经发展起来并具有一定机器规模的业务。没有必要在这里击球,但选择适合您的。
很多人不喜欢处理问题,然后只想着做高大上的事情。我不想告诉你这个结果,但它没有接地,他们制作的东西没有使用,等等。
所以我觉得运维架构师一定是一个懂业务、熟悉业务、非常熟悉的人。我身边也遇到过这样的人。他们级别很高,通常不处理任何问题,但在关键时刻(例如出现问题时),他可以快速找到关键点并解决它们,有些细节甚至比您还要多。明白了,不得不佩服。运维一定是这样的人!
就算每天重复上线、处理故障问题、响应需求、开发维护脚本,也无所谓。关键是你有没有从你做过的问题中看到业务和运维中的痛点,并使用现有的。技术方案,处理解决!
有很多问题,并不是说解决了很多问题就是一个伟大的人。问题的关键在于如何解决问题,同时体现你的整体视角和技术能力。
举个最简单的例子,一台机器的磁盘快满了。这一定是一个特别小的问题。运维同学应该经常遇到。
如果你只检查磁盘使用情况,然后删除数据或调整删除磁盘的脚本,那是最糟糕的文件;检查磁盘使用情况,确认是单机还是批处理机有问题,为什么此时报告,确认清楚可以解决,这是一个更高的层次;我查看了磁盘占用,彻底发现了磁盘增长的原因,但发现磁盘增长是不可控的,现有的数据删除方法无法避免报警。那么有没有办法保证重要数据正常保留时磁盘不会报警呢?然后用技术方案解决,这是更高的层次。 有很多这样的例子。
你会发现运维其实就是利用你对系统、网络、硬件、规格、服务的熟悉,结合专业知识,用技术方案解决一系列研发测试无法解决或无法解决的常见问题。单独解决。并且可以形成工具、平台、框架,最终为运维部门甚至公司创造价值。这是一个很棒的 *** 作和维护。
所以还是同一句话:没有技术含量低的岗位,全看你怎么做。
随着时代的发展,我们现在使用的任何技术,很多事情都可以通过云计算解决,也有相应的产品和方案来解决,云计算也对运维产生了一定的影响。新的发展趋势由此而来。
第一个是从IOE到开源X86。其实去IOE也有一段时间了,为什么要去IOE? 2008年,全网印象比较深刻。当时,安全已逐渐上升到国家层面。此外,中国本土环境也日新月异。国产化需求和自主研发能力越来越强。一个强大的内部基因被定位。此外,还考虑到无论是国家层面还是企业层面,各行业都希望灵活控制结构的能力。这也是这个行业本地化的需求,这也是去IOE的第二个理由。从长远来看,IOE架构和非IOE架构会长期共存,因为技术系统的升级不是一两天就能解决的,尤其是一些核心数据库、核心应用、核心系统的核心系统。当年经常部署在IOE框架下。
第二个是运维自动化和智能化。这个已经提了好几年了,从接触实践到现在大概有五六年了,现在还在提。事实上,很多行业一直在迭代优化运维的自动化和智能化。它确实可以为我们的运维带来很多优势和优势。
第三个是双态IT运维。在传统向互联网和移动转型的过程中,一方面为了保证现有业务的运营,另一方面为了适应这种新的IT技术的变化。
第四个是研发与运营的融合,即DevOps。 DevOps 在过去的两三年里已经渗透到了千家万户。其核心理念包括精益管理、敏捷等理论,通过持续交付、持续集成工具链,以及一些轻量级的IT服务管理。基于这些概念和工具,形成了从研发到运营的全流程体系。IT运维效率更高,迭代更快,反馈更快,更好地满足内部业务需求和用户需求。这也是研发运营一体化理念的价值所在。
第五个是整合云资源,提供一个更大的平台来支撑大数据、AI智能、运维等一切各行各业 这也是互联场景的一大趋势。这对运维来说既是挑战,也是机遇。为什么?因为这个行业在不断变化,技术也在不断变化,只要顺应大势而变,我们就站在时代的潮流中。
如果我们在之前的运维理念上还是保守的,不上云,不摸云,那你肯定被淘汰了,因为我十年前很难部署一个数据库,各种配置,各种调用,现在就可以直接打开一个RDS,进行优化,集群就完成了。在效率和稳定性上,分分钟达到我们传统的运维水平,这也是我们运维要面对的大势所趋。
基于此,云原生的概念在过去一两年比较流行。事实上,它是对现有云架构系统技术栈进行更深更广的整合,采用Devops、微服务、敏捷的概念,采用类似中国大陆和台湾的概念或者开放的概念来构建和重塑技术体系,更好地支持新业务的快速迭代开发,这其实和DevOps的概念有很多相似之处。
第六个是数字化。这也是近两年在中国的热门话题。事实上,它也是。我们曾经建设过各种各样的信息化,建设了很多系统和平台,但往往也搭建了很多障碍,导致我们很多信息系统不可用,业务碎片化。组织也支离破碎。数字化要解决的问题是通过底层的数据和算法构建新的服务,打通我们的业务。这就是数字化要解决的问题。
大体上讲了这么多趋势,当然也有一些,大体是一样的。以前是用硬件,现在是软件自动定义;过去用服务器,现在用云,我们现在用云,未来可能更混合。云端,云端整合;以前是技术运维,现在从事技术运维的整合;另外,同样重要的是,无论我们现在做什么,网络空间安全现在都提升到了国家层面,在企业里面也提供了企业的最高点,这个网络安全是IT的一个标准。
以上就是关于IT运维工程师的发展方向是什么全部的内容,包括:IT运维工程师的发展方向是什么、IT行业的管理应该是什么样的模式、测试工程师与研发工程师比例调查等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)