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

阅读数:1 2020 年 3 月 18 日 21:19

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

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

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

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

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

个人观点:

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

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

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

个人观点:

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

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

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

个人观点:

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

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

个人观点:

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

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

个人观点:

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

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

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

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

最后

你都遇到过哪些反模式呢?你是怎么看待这些反模式的呢?欢迎留言讨论。

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/Mcs2bf0v8Z230FUeom4qKw

评论

发布