先说最近遇到的两个事情：
第一个，最近几个群里都在讨论一个问题，中台是什么？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、中台）就是什么。”
本文转载自成哥的世界公众号。
评论