问题定义概念 - 别被 BuzzWord 给带偏了

阅读数:5 2020 年 3 月 16 日 20:34

问题定义概念-别被BuzzWord给带偏了

先说最近遇到的两个事情:

第一个,最近几个群里都在讨论一个问题,中台是什么?DevOps 是什么?

看到大家很多交流和探讨,整体感觉就是对于这些概念和 BuzzWord,每个人,每个行业,每家公司都会有不同的理解,甚至在不同的阶段,大家也会有自己的理解。

而且这些理解谁是对的,谁是错的呢?其实大家理解的都没有问题,在自己所处的行业、背景和场景下,都是对的。

第二个,前面参加行业会议的时候,跟一家大型企业的 IT 管理团队做交流,他们非常想希望了解 SRE 到底是什么,怎么借鉴。

其实,我当时被问到这个问题时,我真的想说,SRE 其实没有什么神秘和高大上的,SRE 里面要做的事情,其实我们平时都在做,比如自动化、发布、监控、oncall、应急响应、故障复盘等等等。只不过 Google 的 SRE 把这些事情更加体系化系统化了,形成了一套方法论,更加便于我们去学习和理解。
如果仔细去想想,中台里面干的事情,DevOps 里面干的事情,有什么新鲜的东西吗?其实这没有,都是我们平时在干的事情。

但是为了解答大家的疑问,我又深入了解了一下,大家更想了解的是在业界更加强调 DevOps 的情况下,开发可以越来越多的承担起运维的工作,这个时候 Ops 应该如何转型?怎么具备更强的竞争力?

了解到 SRE 是运维行业里的最佳实践,所以就想知道是不是掌握了 SRE 就能够具备竞争力了?

再后来,我继续细问,针对一些具体的场景和问题,给出了一些具体解决方法,算是有针对性的答疑。

不过,我更想表达的内容是,我们不能总想着靠 DevOps、SRE、云计算、AIOps 这样的概念和 BuzzWord 就解决根本问题,我说的是根本,还不是全部,比如提升竞争力,解决转型问题等等。

因为我们一讲上面这些概念,就很容易去搞持续交付的流程体系去了,然后再去搞工具平台框架,对于 SRE 又要开始建稳定性架构体系等等。

我不是说这些东西不好,也不是说不要建,但是建设之前先看看我们当前自己的 IT 基础是什么状态。

比如标准化搞好了吗?别一堆线上应用连部署目录、启停命令、配置命名都不统一。我们说做持续交付,结果这些东西不统一,怎么做自动化发布和部署?

基础服务选型统一了吗?一个消息组件,不同的团队不同选择,我见过有的公司线上就运行着个 3、4 个不同的消息或缓存产品。

还有,搞 AIOps,我就见到过,日志格式不统一,有用没用的信息乱打,AIOps 再牛逼,也没法处理这种太多的垃圾信息,Garbage in,Garbage out,这个是一定的。

再就是,有很多元数据信息,压根都没落到 CMDB 这样的管理系统中管理起来,一个服务器信息,开发有一套、测试有一套、自动化有一套、监控还有一套,信息之间根本做不到流转和同步。

如果是这样的一个基础,不管是自动化,还是持续交付,就是算是 DevOps、SRE 和 AIOps,不管啥先进理念,到最后都落不了地。

为什么?因为基础没做好,再先进的东西嫁接上去也长不出来。就跟种庄稼一样,土壤不行,怎么实现大丰收,盐碱地上施再好再多的肥料,也收获不了粮食。

这个问题,别还不在意,不只是中小公司,很多大型企业都会存在这个问题,搞一堆的培训和咨询顾问服务,采购一堆的工具平台,建了一堆的流程体系,起了一堆高大上的名字,最后就是不见效果,啥原因,就是因为都把最基础的东西给摆到了最后面。

这个问题谁来解决呢?说到底只能靠自己,该统一的统一,该标准的标砖,该强制执行的强制执行,只有自己能干,靠第三方是不行的。其实怎么干,又是个很复杂的话题,这里先不细说了。

我不反对引入任何一个先进的理念,但是,万丈高楼平地起,一定要结合着自己的基础来,结合着自己的现状来,一步步稳扎稳打才会有效果。

当我们讨论这些 BuzzWord 是什么的时候,我觉得多深入研究下我们自己遇到的问题到底是什么,或许更有意义。

Why 比 What 和 How 更重要,千万别被这些 BuzzWord 给带偏了。

问题定义概念,如果,硬要给 SRE、DevOps 或中台一个概念,我觉得最好的解释就是“我们遇到的技术问题是什么,SRE(DevOps、中台)就是什么。”

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

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

评论

发布