|
|
51CTO旗下网站
|
|
挪动端

运维工程师要赋闲了?抛开噱头与讥讽,闲谈我心中的运维!

在知乎上,我常常受约请答复许多相似的题目:运维究竟是干什么的?运维任务有没故意思?运维有没有出路?运维是不是要被种种技能代替?

作者:温峥峰泉源:知乎专栏|2018-02-07 09:41

在知乎上,我常常受约请答复许多相似的题目:运维究竟是干什么的?运维任务有没故意思?运维有没有出路?运维是不是要被种种技能代替?

但是自己上知乎以休闲文娱为主,普通不答复正儿八经的技能或许专业相干的题目,这次盼望能经过本文向列位描绘清晰运维究竟是干什么的,至于有没有出路、开展以及会不会赋闲等,请读者自行判别。

运维是干什么的

「运维」二字能够有几层意思,辨别可以指代运维工程师、运维团队或许是整个运维效劳体系。

我们可以看出,这三层是从广义到狭义的递进。置信绝大局部人问的都是运维工程师,只要少少数人能认识到另有运维效劳体系这一层寄义。

我们常常会听到一些言论,比方:

  • 云效劳遍及了,运维工程师就要赋闲了。
  • 等 DevOps 或许 SRE 落地了,运维工程师也要赋闲了。
  • 容器技能遍及了,运维工程师也该赋闲了……

也记不清运维工程师究竟被赋闲了几多遍,但我以为就算运维工程师被代替了,运维效劳也不会灭亡,它将随同并支持着业务开展的整个生命周期。

为何如许说?我们照旧用业务的降生进程来剖析。

一个站点或许 App,大抵阅历着如许的降生进程:PM 设计生产品原型,交给 Dev 开辟完成、QA 测试,然后交付给 Ops 摆设到线上运转,最初供用户运用。

在这几个复杂步调中触及了浩繁的人、脚色、交付进程等工具,这是一个完好、庞大的零碎工程,而恣意一个关键的失误都能够影响终极出现给用户的体验以及结果。

我们重点思索从 Dev 把业务产物完成后交付给 Ops 到线上运转的这个阶段,Dev 同本家儿要担任业务产物的功用完好、逻辑准确等业务目标,而 Ops 同本家儿要担任业务产物的运转质量、波动性、可用性等零碎目标。

无论前面的交付步调是用 DevOps 照旧 SRE 的完成方法,都离不开一个狭义的运维效劳的实行关键。

以是说, Dev 照旧 Dev,Ops 照旧 Ops,没有谁被代替,只是运维效劳的实行方法晋级为愈加软件工程化的手腕,增加人肉操纵,DevOps 夸大主动化、拉动式来进步团队交付服从与质量。

而传统的运维需求追求技能转型,从原来只存眷操纵零碎层面的技能曾经不敷了,还要添加对顺序代码的功能调优、继续交付、容器化等软件根底架构方面的技艺提拔,也需求继续存眷整个业务、使用、效劳的生命周期办理。

复杂来说,便是把过来传统的黑盒运维的思想方法丢弃,进入白盒运维的期间,我们必需愈加深化代码、深化业务运营,让整个线上效劳运转于更优质高效的形态。

至于运维能否会被代替,取决于你属于哪种运维。

运维工程师和运维开辟工程师

要建立运维主动化或许理论 DevOps 离不开运维开辟工程师的到场,但要怎样才干更好地发扬运维开辟的作用呢?

我曾作为运维产物司理的脚色和种种范例的运维开辟一同协作过,团队中有原本就做运维开辟的,也有原本做其他业务(电商、平台)的开辟转来帮忙运维团队的。

和他们协作一段日子后,总体觉得如下:

  • 运维开辟起首是一个顺序员,不是运维工程师。
  • 一个好的运维开辟需求具有 「运维了解」+「开辟才能」。
  • 对「开辟才能」的技能要求低于其他业务形状(如游戏、电商、搜刮等)。
  • 对运维业务的了解难度会低于电商、游戏等业务形状,即对「运维了解」的要求不高。
  • 对运维相干技能栈的掌握水平要求高,如 通博8888官网、Git、Nginx、Zabbix、Docker、K8S 等。

综上所述,运维开辟是一个深度不算太深的职业分支,而如今之以是对运维开辟需求量热起来了,次要由于老一辈的资深运维广泛研发才能无限,而这是有汗青缘由的。

关于从业 8 年以上的资深运维来说,他们刚开端做运维的时分更多的是打仗机房、机架、主机、交流机、防火墙等硬件设置装备摆设。然后对接业务运维后,普通经过 Shell、Python 等剧本来辅佐任务。

比及业界提出 DevOps 的时分,他们每每曾经专注于团队办理、容量计划、架构调优、运维效劳质量等初级范围,以是根本不太能够抽出大块的工夫来重新学习编码并开辟主动化零碎。

以是,当我们有主动化零碎的建立需求时,需求更专业的顺序员来帮忙。

但普通的非专职运维开辟的顺序员做出来的零碎关于运维来说每每不太好使,这时分有局部年老的运维工程师晋级了研发技艺,转型运维开辟,把好使的运维零碎做出来了,博得了运维团队的好评,各人都为「运维开辟」点赞。

以是,各人将 「好使的运维零碎」 和 「运维开辟」 等价起来,以为我们只需招来一个运维开辟,那么一套完满的运维平台就能主动降生出来,这是个很大的误区。

实在「好使的运维零碎」真正等价于「运维了解」+「开辟才能」,这两种才能也是可以别离的,纷歧定要强加在运维开辟工程师一团体的身上。

相似其他业务形状的开辟进程,需求产物司理和顺序员两种脚色别离,企业也不会说要雇用既会写代码、又会出需求的顺序员。

以是,当资深运维能把运维主动化的需求过细地文档化上去,把主动化零碎的设计、架构等要害关键建立上去,这便是最好的「运维了解」。

这时把这份靠谱、好使、过细的需求文档交给具有强「开辟才能」的顺序员,终极就可以失掉「好使的运维零碎」。

固然,资深运维要获取产物司理才能也不是那么复杂,并且也需求和运维开辟无妨碍地讨论技能,团体以为必需具有且不限于以下技艺包:

产物计划、产物设计、面向工具、需求模子、范畴模子、设计模子、设计准绳、设计形式、产物东西和文档才能等。

以是,当运维需求被了解、剖析得充足透彻,以及资深运维取得了「产物司理」才能后,运维开辟便是一种平凡的开辟分支,按需求文档编码即可。

再往初级开展的话,运维开辟也可以替换资深运维出需求,晋级为运维产物司理,以顺序员的思想角度来处理运维效劳的工程服从和质量题目,我以为这也是相似 Google 所倡导的 SRE 文明。

最初,许多运维能够思索要不要转运维开辟,当你以为编码的兴趣远宏大于其他运维技艺的时分,虽然夺取高兴去转!

把本人当成一个真正的顺序员,以顺序员的评价规范来要求本人,不要以为运维才能和编码才能各自半桶水是坏事,正如我后面的那句话:“运维开辟起首是一个顺序员,不是运维工程师 。”

运维效劳体系与技艺程度量化

每个运维工程师心中实在都有本人的想法,无妨用思想导图的方式将其列出来,找出本人感兴味的点,继续深化,打造本人的中心竞争力。

而思想导图也可以持续往横向纵向扩展,构成本人心中完好的一套运维观点。

上面跟各人分享一张思想导图,展现我团体心中的运维效劳体系。固然,这外面另有许多可以睁开,但细节就不方便泄漏了,这属于团体经历未必能实用其他运维团队。

由于运维普通考究广度而疏忽了深度,以是容易招致本身的技能栈广而不精的状况,那怎样量化本人的技艺程度充足深化呢?

举一个各人都熟习的 MySQL 技艺作为例子,假如把 MySQL 程度界说成 1~10 级,上面是我对种种级别程度的了解。

为何要量化技艺呢?由于人的工夫、专注力终究无限,怎样把精神分派到差别的技艺上,需求肯定的战略。

正常状况下,各人把精神均匀分派到种种详细技艺,盼望可以做到八面玲珑,但不会太深化某项技艺,以是技艺程度到达的级别落在 1~3 之间。

如路人 A 的技艺程度表是如许的:(固然另有其他技艺项,如网络、平安等等,这里只是简化了方便讨论)。

最低要求

运维是一种需求技艺面比拟广的工种,各人广泛都是处于技能面广但不深的形态,我把 2 级界说为科普级,意思是到达该级就可以满意种种一样平常任务要求。

以是说下面的路人 A,最好尽快夺取把还在1级程度的 Shell 和 MySQL 都提拔到 2 级,就可以满意一样平常任务要求,这也是我们对运维工程师的最低要求。

进阶要求

除了满意最低要求之外,培育本人的中心竞争力,为日后的开展打下根底,引荐各人对 1~2 项深化学习,到达 4、5 级乃至更高的程度。

随着互联网运维行业的种种 PaaS、IaaS 遍及后,主动化水平越来越高,如今曾经不像曩昔那样需求那么多「操纵员」。

也便是说,技艺程度偏低的运维急需技艺晋级或许技艺转型,能支持你走多远的不是那些 1、2 级的技艺,而是 4、5 级以上的技艺。

写在最初

本文是笔者团体对运维以及其职业开展的一些浮浅了解,总的来说,运维照旧一个比拟故意思且有精良开展的职业分支,固然偶然也要背黑锅,但也欢送更多高兴、智慧、有才气的同窗参加运维行业。

【编辑引荐】

  1. 运维的将来:云效劳衰亡,运维职员会“下岗”吗?
  2. 运维工程师必备的18个网络带宽监控常用下令
  3. 从苦逼到牛逼,详解通博8888官网运维工程师的打怪晋级之路
  4. DevOps,便是开辟吃失运维?
  5. 从1到2,DevOps怎样变相成为SysAdmin?
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
各人都在看
猜你喜好

读 书 +更多

通晓ASP.NET 2.0+XML+CSS网络开辟混淆编程

本书以最新的ASP.NET 2.0为根底,细致论述了以后网络开辟的经典架构ASP.NET 2.0+XML+CSS的各个知识点,以及SQL Server 2005的相干知识。全...

订阅51CTO邮刊

点击这里检查样刊

订阅51CTO邮刊