运维（技术）工作中的反模式

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

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

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

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

个人观点：

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

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

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

个人观点：

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

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

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

个人观点：

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

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

个人观点：

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

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

个人观点：

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

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

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

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