先说最近遇到的两个事情:
第一个,最近几个群里都在讨论一个问题,中台是什么?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、中台)就是什么。”
建了个群,专门讨论云计算、SRE、运维转型及团队管理,大家如果想一起聊聊,可以加我微信(备注姓名+公司),我拉你入群。