我们经常会面临产品上线出现问题，开发团队和运维团队就开始互相踢皮球，很难直接定位问题根因。的出现，正是为了更好解决此问题。
谷歌SRE的初始定义:
站点可靠性工程(SRE)是一门结合软件工程并将其应用于基础架构和运维问题的学科，2003年左右由谷歌创建，并通过SRE books进行宣传。
SRE是什么：
1.SRE是一个学科
2.SRE是一种最佳实践
3.SRE是一类创新岗位
谷歌SRE解决了哪些问题？
1.如何创建和运维超大规模和高可靠的分布式软件系统
2.如何使用软件工程手段，解决运维的核心问题——系统可靠性；
3.如何管理SLO，并在确保SLO的前提下，最大化迭代速度；
4.如何消灭“琐事”，解放IT生产力，让IT成为真正的"人"；
5.如何建立自动化，实现SRE领导下的服务自动化；
6.如何减少故障成本以及可能引起的损失
7.如何实现职责分享，打破部门边界，统一激励机制（消除鄙视链）；
8.如何实现运维能力的“左移”，为开发团队提供“生产智慧”
谷歌指出，IT的核心问题就是软件问题，需要在原有的开发/测试/运维之上，新建SRE岗位和能力，从规划、设计、开发、测试、部署、上线、运维入手，全程领导“服务自动化”，以实现持续的系统可靠性目标。
并在此过程中，引入来自“生产的智慧”，领导建立统一的自动化、自服务平台（监管控、自动化、智能化），以及建设和优化的IT流水线。
SRE解决的核心问题是开发不懂运维、运维不懂开发的问题，开发懂运维才能在软件研发的时候关注部署运行可靠性、伸缩性、性能、等问题；运维懂开发才能运用软件工程的思想和方法解决运维过程遇到的自动化、体系化工具匹配，快速找到异常根因等。
SRE和传统运维的本质区别是什么？
我们现在对传统运维的定义很宽泛，按英文字面，SA(system admin)，DBA，CE（client engineer）, MCE(mission critical engineer)，ASR （Account Service Representive），都可以归类到传统运维，当时要做的事情一点也不少，什么主动性预防，巡检，脚本检查，配置检查，甚至机房检测，能想得到的活恨不得都干一遍，而且是会检查源代码的。传统运维关注的是效率和紧急的眼前事项，是被动的支撑运维。 传统运维始终忙于奔命，运维的琐事无穷无尽。
SRE是在云化、云原生化背景下诞生的，天然就要求运维左移，向开发能力靠拢，并提出了 SLO 这个有效的指标。很多 SRE，本身就是维护对象的编码者，并且所需关注的底层硬件大幅度减少，更偏软件开发和软件工程能力。
SRE采用一套经过深思熟虑的方法，对可靠性工作的机会成本作出数据驱动型的决策，将可靠性工程工作安排到一个合理的优先级，从而保证创建足够的可靠性。
SRE重大贡献如下：
1.SRE提出建立基于六大原则的SRE方法论和实践体系；
2.SRE提出从传统运维到SRE运维（基于SLO）的建设转型路线图；
3.SRE提出减少琐事-最小化琐事-消灭琐事的“IT生产力解放”三部曲；
4.SRE基于理论实践的不足，提出运维能力“左移”；
5.SRE提出SRE领导的“服务自动化”，自动化平台体系，以及平台工程；
6.丰富和完善自动化流水线的运维环节，明确SRE可以Say No；
7.SRE简化流程体系，提出重点是实现3个核心流程以及相应的自动化能力。
8.SRE首次提出可观测性、混沌工程，在服务自动化的未来影响和重要作用。
SRE和传统运维的最显著区别就是，有没有构建起自己的一套东西。工作不再是全配合别人，具备围绕稳定性的独立的发展路线。从配合支撑到协作，指导业务/平台改进。
SRE的方法论为DevOps的提出提供了实践和方法论基础，DevOps是开发主导，注重效率；而SRE是运维主导，注重稳定性。所以也说SRE是DevOps的一种实践。SRE和传统运维的本质区别在于认知和思维，表现在工具和方法上。
国际知名的学院(DOI)推出的SRE认证代表了这个领域的最新知识体系，该认证介绍了SRE的发展及其未来的方向，并为学员提供了SRE的最新理念、实践方法和日常工具，可以帮助现有的SRE团队将现有的SRE实践和国际理论标准结合，强化SRE实践能力。雅菲奥朗携手DevOps Institute推出SRE Foundation和SRE Practitioner认证培训，成为国内独家SRE全系列课程的授权培训和考试机构。
