一、的定义
SRE 全称是 Site Reliability Engineering，最早是由 Google 提出，并且在其工程实践中发扬光大。 Google出版了一本同名书籍《Site Reliability Engineering》，让这个理念在互联网工程师圈子里广泛传播。 SRE（站点可靠性工程）是一门结合软件工程的各个方面并将其应用于基础架构和运维问题的学科，于2003年左右在谷歌创建，并通过SRE相关书籍进行宣传。
二、的定义
DevOps是字面上Dev 开发和 Ops 运维两者组合。DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
三、SRE与DevOps的具体区别有哪些？
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 持续改进：快速试错，快速改进，更高效，更可靠，提高收益；
