SRE是运维人员自下而上自我救赎，自我革命。武器就是自动化精益。避免被开发推动DevOps自上而下裹挟革命。所以我遇见的运维团队对于DevOps是疑惧交织，对于SRE大都欣然接受。

因为DevOps和SRE关注点不一样，甚者都不应该放在一起讨论，SRE仅仅是运维侧的一种方法论和实践，而DevOps不是。

去年和招商银行的领导有过一个有趣的探讨，即现在很流行的DevOps和SRE的定位和异同，讨论的结果倾向于认为：DevOps是开发拥抱运营，是从开发侧出发，解决开发运维一体化的问题；SRE是运维拥抱开发，是运维团队自身的一次深刻转型，我个人倾向于——殊途同归。

所有可以标准化自动化的东西，理论上都可以纳入运维的范畴，这样运维的定位可能会历史性地提升咸鱼翻身或可期，我用的词是花开两朵，殊途同归，鉴于立场不同，实践侧重自然不同。SRE是运维的自我革命。 

SRE是DevOps的最佳实践：

SRE和DevOps同属开发运维一体化时代的产物，有交集很正常，他们是“殊途同归”。 SRE可以是运维向运维研发的拓展，这可以适用于国内广泛的运维部门转型，事实上DevOps或者说“开发运维一体化”在国内刚刚开始落地，很多组织上仅仅通过引入DevOps理念，仍然需要面对“生产环境天天出问题，就是不知道问题出在哪”等问题。

SRE可以理解成Devops的具体实践。相比devops有更具体的工作或者角色定义。

1、SRE主要思想如下：

事故是正常的/变更应该循序渐进/工具和文化是相互关联的/度量的。

2、SRE主要原则或者核心如下：

2.1 软件问题：用软工思想来解决运维领域的问题；

2.2 通过SLOs进行管理：产品团队和SRE团队为服务及其用户群选择适当的可用性目标，并将服务管理到该SLO；

2.3 减少琐事：甄别琐事的来源以便可以最小化这些工作甚至消除；

2.4自动化：决定什么条件下做什么自动化以及怎么自动化；

2.5与开发者共享：工件透明，信息共享，工具同步；

2.6 持续改进：快速试错，快速改进，更高效，更可靠，提高收益；