专栏首页Forrest随想录运维(技术)工作中的反模式

运维(技术)工作中的反模式

前面几篇主要讲了应该怎么做好运维,期间就会想到很多反模式,但是限于篇幅就没有多写。

这篇单独说说,运维过程中的一些反模式,也就是——为什么道理都懂(文章看到了不少,大会参加了不少,业界方案也都懂),却依然做(guo)不(bu)好(hao)运(yi)维(sheng)?

下面的这些反模式,仔细看看其实也适用于各类技术岗位,不信你对比下看看:

1、只谈技术和工具,不考虑场景。比如,一说做运维,上来就是自动化,就是做工具,Puppet、Ansible啥的先搞起来再说,别人有发布系统,我们照着也来一套。什么标准化、流程规范,都甩一边,场景?是啥?没关系,反正有了工具就都解决了;

个人观点:

反了,不从实际场景出发,做出来的工具能好使不,见过哪个开源工具或别人家的系统照搬过来,就能立马解决现有问题的不?如果没有,先立足现状,找准痛点再下手,慢慢来,磨刀不误砍柴工。

其实,我们讲做运维,为什么一上来都是讲从场景入手,然后标准化,说白了,梳理场景和标准化的过程其实就是解决实际问题、梳理清楚现状的最佳切入点。标准先行,标准先行,标准先行,重事三。

2、玩概念,比如发布系统没做好,就已经是DevOps了;自动化还没成型,就已经是xxx的云平台了;服务发现还没做好,可以快速申请个资源就叫弹性伸缩了;做个KVM虚拟机,就号称是IAAS了;KVM换成Docker,再配上点编排和调度就是PAAS了,或者叫CAAS更高端,不对,CAAS还不够,得叫容器云。。。。。

个人观点:

注意力都被吸引到概念上去了,反而忽略了真正的问题所在。对于一个以业务为主的公司,玩了这么多概念,到底解决了啥问题呢?概念背后的原理和逻辑搞清楚是不是更重要?

通过问题和场景找到合适的技术解决方案,技术要适配业务,解决问题才行,千万不要搞一堆概念堆砌出来的技术功能点,宣称着技术多么强大,然后反过来让业务来适配这些技术,这样就又反了。在公司内部,没有解决问题前,先别说什么先进和强大。

3、炫技,已经有很好的开源的东西或者经过实践的解决方案不用,非要自己从新做一套,费时耗力,出了问题还hold不住;还有另一个极端就是,本来很简单的一个事情,非要做的非常复杂,一定得采用业界的xxx先进框架或解决方案才行。

个人观点:

这是对公司资源最大的浪费,公司聘请我们的目的是让我们解决问题的,不是练习技能的,当然,在解决问题的过程中来提升自己的水平能力,这个是无可厚非的,但是千万别把前面目标给丢了,在职场上混,这点道理还是要懂的。

4、专家的思维模式,这一点在一些工作经验和背景比较资深的老鸟身上很明显,带着之前经历的光环来到一个新环境中,只要是跟自己经验范围内不太相符的东西,就这也看不惯,那也看不惯。然后就开始发挥自己的专家经验模式,按照自己的性子和模式去做事情,期待着做出破旧立新的效果来,反而很少考虑跟周边的配合以及是否是解决实际问题的,因为这一切的出发点是:我是专家,不听我的,难道要听你们的?(面试上,这一点一定要注意有这种倾向的人,水平能力很好,但是合作上和自我认知上问题很大)

个人观点:

不管是不是专家,踏踏实实立足现状,找准痛点,结合自己的经验优势,实实在在地解决现有问题,才是正道。千万别想着一上来就破旧立新,打造一个新世界出来。

5、视野局限,做技术只考虑技术,做运维只关注运维,这个是最要命的,不能全面的考虑问题,以运维举例,如果我只考虑运维的事情,其实只要做做网络管理、硬件和操作系统管理就好了,因为这才是只跟运维相关,跟其它团队无关的事情,至于什么发布、稳定性和用户体验啥的,跟我无关。

个人观点:

这种想法我也不能说错,但是你这样做,就把自己给局限住了,把自己就置于一个非常末端和被动的位置上了。

有时候,我听到很多同学习惯性的说出“关我啥事”这种表达时,更多的是一种无奈,如果是运维,我会有一些失落。其实你习惯性的表达这个意思,就是在不断的给自己设限,是自己局限自己。有时候,先别着急把这种意思说出口,哪怕是说“让我想一想”、“让我考虑一下”,都会让你变的不一样,到最后带来的真正的变化可能也是你意想不到的。

现在业界经常说什么攻城狮,特别是运维地位不高、不受重视、背锅侠等等,除了一些客观因素外,其实很大一部分原因也要从自身找找。再就是尊重也好,认可也好,关键是要靠自身能够创造价值才可以。

先写这么多吧,之前写过一篇《谈谈运维的价值》,也可以看看。

本文分享自微信公众号 - Forrest随想录(forrest_thinking),作者:赵成

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-08-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 有运维专家推荐吗?

    因为工作行业的原因,会有很多的同行或朋友找我推荐一些有运维经验的人,或者直接希望要运维专家。

    赵成
  • 谈谈运维的价值

    2016GOPS上海大会参加完有一些感受和感想,最近一直在思考,再就是前两天在高效运维的群里,大家又谈到运维苦逼,没有成就感的事情,也促使我更加的想表达一下运维...

    赵成
  • DOIS大会参会总结和思考

    上周去参加DOIS(DevOps International Summit,缩写:DOIS)会议。除了自己的分享外,也看了一些其他公司当前在做的事情,谈谈个人的...

    赵成
  • 从70万字SRE神作提炼出的7千字精华文章

    最近在做一些运维架构转型的工作,某些思想其实是借鉴了SRE的理念,就和DevOps一样,SRE已经不是一个新鲜的词汇了,尤其是在互联网的行业,无论从组织架构,还...

    bisal
  • 智能时代下的冷思考:回归ITOA

    运维人员每天面临很多零碎的工作,有各种渠道而来的问题咨询、多个监控工具的报警,以及各种非计划性和计划性的工作,相比于其它工种,运维人员更需要一个综合性的...

    彭华盛
  • 谷歌SRE与运维工作的思考

    运维部门要保障产品业务稳定性,开发部门要想随时随地快速上线新功能,而线上的故障往往是由新的变更导致的——不管是新发布了版本,还是修改配置,或者是改变了用户某些行...

    小小科
  • 运维工程师:而立之年,路在何方

    豌豆贴心提醒,本文阅读时间5分钟 上周末约部门新人一起吃饭,闲谈间说起了未来。 小伙子才20多岁,吃饭间都止不住眉飞色舞。 我知道他为了给自己充满不确定的未来...

    小小科
  • 【重磅】大众点评运维架构图文详解 @高效运维

    本文根据高效运维系列群「运维讲坛」的嘉宾分享整理而成。运维讲坛,邀请国内运维领域优秀技术专家作为分享嘉宾,其中线上分享每周一次,线下沙龙活动每月一次。欢迎点击上...

    小小科
  • 一文帮你理解整个 SRE 运维体系!

    在任何有一定规模的企业内部,一旦推行起来整个SRE的运维模式,那么对于可观测性系统的建设将变得尤为重要,而在整个可观测性系统中,通常我们会分为如下三个方面:

    杰哥的IT之旅
  • 精华 | 问答式解释什么是运维工程师,以及其发展途径是啥!

    运维工程师:Google称之为SRE,网站可靠性工程师,维护服务器安全与稳定高效运行工程师。

    网络技术联盟站

扫码关注云+社区

领取腾讯云代金券