谷歌提出SRE的思想已有多年，国内各大厂学的千姿百态、参差不齐，还有些大厂直接摊牌，不玩了，觉得基础设施和平台足够成熟，取消SRE岗，取而代之是各种干着SRE活儿的新岗，换汤不换药。
也有些厂取消公共的业务SRE，把SRE下放到业务自治，确实解决了跨部门协作的问题，少了很多扯皮，但也是摁下了葫芦起了瓢，由于不成规模，成本比共享肯定是大的，体系和技术也难以共享，从公司的视角看到底是赔是赚还是笔糊涂账。
为什么都在折腾SRE的定为呢，其实有个浅显朴素的道理，如果公司的各种资源足够平台化，平台足够成熟易用，流程足够自动化，研发从服务上线到下线完全可以自助，那么SRE就可以足够的少，这笔钱对于公司是不是就可以省了。
现实中的情况呢，平台总是不好用，bug总是层出不穷，研发如果都耗在这些事儿上，拿什么时间写代码呢？所以SRE其中一块很大的事儿是在做客服，在各个平台之间承当技术润滑剂，推进平台完善，研发在平台使用上都做不到闭环的自助，更不用说在质量、成本一些琐碎的事儿上了。
国内一些从事云业务的厂，其实平台化做的还是非常好的，因为本来的一个目标也是让客户公司足够简单，节约运维成本，但其他厂绝大多数都还在系统烟囱时代，那么，系统做好了SRE的人力会不会省呢？答案是肯定的，但SRE的工作不会因此而没有了。
在小米感受这几年的变化，随着业务的容器化，容器平台将底层的复杂都屏蔽了，没有了物理机场景的复杂性，扩缩容点个按钮，环境也不用配置了，SRE在物理机下琐碎的工作消失了，转而看到的是容器团队的忙碌和团队的扩张，短期看省SRE那几个成本远比不上容器的投入，但我相信长期公司肯定是受益的，因为建设是一次性的行为，后面团队肯定会再缩回去的。容器相当于把物理机场景系统运维的工作全部承接了，而且研发的自助场景也越来越多，那后面SRE的出路在哪儿呢？
1是少而不是消失，2是系统运维只是SRE的一部分工作，3是可以转型，从团队同学的工作内容看，还是要提前做一些思考，大厂的业务多而复杂，短期看需要做的东西还是很多，方方面面都需要提效和规范，而且业务上、资源、平台层需要日常运营的事情太多了，管理SRE这些年，对日常工作总结了下，基本涵盖如下:
提供云、数解决方案
- 理解业务重点需求，将云、数的能力形成解决方案，赋能给业务。
项目管理和交付
- 在建设期，对于重点需求进行项目化管理，推进解决方案的交付工作。
日常运维需求和稳定性保障
- 日常业务支持提升研发效率，包括四七层管理、监控报警、环境搭建、问题排查等日常事务；
- 业务全生命周期的稳定性保障
- 业务的容灾、预案、架构优化等逃生能力的建设；
- 业务的变更、巡检等稳定性保障预防机制建设；
- 业务的容量管理，服务的扩缩容保障；
- OnCall值守，7x24小时故障应急响应及告警处理；
- 双十一、米粉节、618等重大活动的重保工作；
- 定期进行故障演练及复盘，对存在风险隐患的问题协同开发同学排查修复；
- 联合质量部门对业务故障的全生命周期管理，进行流程、制度、规范的制定和落地。
- 消除业务安全隐私风险，日常安全漏洞修复；
- 账单分析，协助业务降本增效，将降本增效的最佳实践赋能业务，并持续跟进；
- 研发运维自动化工具，赋能业务，解决业务各场景的难点问题。
随着环境变化，我感觉想要在SRE职业上发展，可能要聚焦下面几个方向：
- 业务支持+技术运营(方向是偏稳定性专家的业务SRE)
- 业务支持+DevOps(方向是偏效能的业务SRE)
- PaaS平台的SRE(容器SRE、存储SRE、大数据SRE、网络SRE、DBA...)
- 专职DevOps开发
一些小厂分工没那么细，很可能都来，如果在大厂，可以考虑根据自己的性格和喜好，提前做一些思考，在某个方向深耕，形成竞争力。
