SRE导览
SRE的由来
很多公司都会有运维岗位，一些传统的企业也会有，连美团单车这种在外面维护车辆的也叫运维。这个全称是叫运行和维护，来自英文operation。
这个岗位是一个后端岗位，也是研发部门的成本中心。以前老领导说运维不能是运行和维护，应该是运筹帷幄。只是一般互联网公司这个岗位不是一个出彩的岗位，一切运行稳定的时候，老板可能看你就觉得浪费钱，出了事情就觉得你为什么没有做好。
从2000年开始，互联网公司都有这个岗位叫运维。相对其他岗位来说，这个岗位的职责从来不是明确的。
从起初的网络运维，服务器运维，操作系统运维。
随着整个互联网基础设施越来越复杂，于是就有了更细致的拆分。
比如应用运维，数据库运维，中间件运维等等，以及什么一线运维，二线运维等等。
伴随着云计算和微服务的产生，运维工作又随之进行了进化。
但是我这边还是概括为以下三点：
- 维护和提高生产环境可用性。这一块就是SLO制定，以及配套的监控和报警等等内容。也就是SRE相关的工作。
- 成本控制：运维部门是成本中心，但是不是运维部门本身产生的成本。因此这个岗位核心工作就是梳理好成本账单和业务之间的关系，以及未来成本的预警和预测工作。也就是所说的FinOps.
- 效率提升：负责所有编码，测试，产品，文档以外的所有工作。通过内部平台和工具链的建设来提升设计，开发，测试，上线的效率。这一部分也就是DevOps的内容。
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结合来搞可以不错的。