SRE导览

SRE的由来

在2000年前后，互联网公司都有这个岗位叫运维。它就是负责所有编码，测试，产品，文档以外的所有工作。

相对其他岗位来说，这个岗位的职责从来不是明确的。

从起初的网络运维，服务器运维，操作系统运维。

随着整个互联网基础设施越来越复杂，于是就有了更细致的拆分。

比如应用运维，数据库运维，中间件运维等等，以及什么一线运维，二线运维等等。

伴随着云计算和微服务的产生，运维工作又随之进行了进化。

SRE, DevOps, Finops这些岗位产生了。

SRE一词来源自当年google sre. 他们为了保障整个google的稳定运行，于是产生了这个岗位。

SRE的全称就是Site Reliability Engineer,核心原则为“Don’t Repeat Yourself”，追求“Automate Everything”的终极目标。

SRE : Google运维解密 这个是国内出版的第一本SRE相关书籍，本书翻译的也相当不错，是由孙老师翻译的。这本书是2016年出的，但是当时google习惯把前5年的东西给分享出来，所以可见当时Google在Jeff Dean的带领下，在工程上确实领先其他公司几代。

SRE的未来

现在随着AI的发展，这个岗位是否还有变化，现在有很多叫aiops的东西，但离真正可用的还是有很大的差距。n8n这些workflow的平台，理论上跟stackstorm差别不大，离上生产还是有点远。

看Qunar他们还是靠自建基础设施对报警内容进行AI判断，这个有效率大概80%左右。

至今AI可以做的事情都是有明显的上下文，同时上下文比较短的事情。比如AI code, 那你丢给AI做的就是一个各模块，最后再合起来，而不是说一下子丢给它说我要写一个淘宝平台，然后就给你生成出来，这个是不可行，你自己的很多需求其实并不明确呢。

运维这个岗位整体上是上下文非常多，有来自线上日志，有来自内部需求，有来自告警，有时候是成本要求，有时候是SLA的要求，也有时间是效能的问题。当然这些问题并不是不可解决，只是短期内有点困难。

同时SRE需要跟研发，产品，测试进行紧密的沟通。有时候还要跟老板沟通，还有跟云厂商沟通。

最近看来是AI代替的大部分是Junior相关的工作，同时让Senior的员工更有效率。

当然我的看法很多时候都是错误的，就跟2022年说GPT可以辅导小学生一样，还有当年没有看懂陌陌和快手一样。

现在看至少5年内运维和衍生出来的这些岗位不会消失，这种岗位不仅及是云厂商不会消失，各个互联网公司内部也不会消失。

从可行的角度来看，AI现在可以帮运维和SRE的部分是监控和预测这里，我觉得这里结合RAG应该是很有可为的。这些技术相对成熟，而且依赖的资源也都是现成的。这个可以用n8n结合来搞可以不错的。