SRE，Site Reliability Engineering，中文翻译为站点可靠性工程师，这个词诞生于谷歌内部。将这个词语展开来说：首先，SRE的关注点在于可靠性；其次，SRE中的"S"指的是google.com网站(站点)。简单的从这个词来看，SRE就是负责维护google.com运行可靠性的工程师，当然随着时间的推移，SRE的维护对象不再局限于单一的网站服务，也包括非网站类的基础设施和系统。从以上解释来看，这不就是我们平常说的运维工程师嘛！那么SRE与我们传统认知的运维工程师有什么不同呢？
传统运维模式
传统运维模式的普遍做法是招聘运维工程师来运维计算机系统。运维工程师负责将现成的软件组件部署在生产环境中，主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门的变更需求。随着系统变得越来越复杂，组件越来越多，用户流量不断上升，相关的事件和变更需求也会越来越多。于是公司需要招聘更多的运维工程师来应对日益增多的事件。可以看出，传统运维工程师的日常工作与研发工程师相差甚远，他们通常分属两个不同的团队：开发（Dev）和运维（Ops）。
优势
很多第三方工具厂商及系统集成厂商都有现成的工具和软件解决方案帮助一个相对初级的运维团队应对简单的系统维护操作，避免重新发明轮子。
劣势
- 直接成本。传统的运维工程师大部分依赖人工操作来处理系统维护事件以及变更的实施。随着系统复杂度的增加，部署规模的扩大，团队的大小基本与系统负载成线性相关，共同增长。
- 间接成本。从本质上来说，由于研发团队和运维团队背景各异，技术能力与工具使用习惯差距巨大，工作目标也截然不同。两个团队对产品的可靠程度要求理解不同，具体执行中对某项操作的危险程度评估与可能的技术防范措施也有截然不同的理解。这些细节上的分歧累积起来，最后逐渐演变成目标与方向上的分歧并形成内部沟通问题，这就是所谓的开发与运维之间的“混乱之墙”。
混乱之墙混乱之墙
传统的研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。研发部门最关注的是如何能够更快速地构建和发布新功能，而运维部门更关注的是如何能在他们值班期间避免发生故障，因为绝大部分生产故障都是由于部署某项变更导致的，不管是部署新版本，还是修改配置，甚至有时只是因为改变了用户的某些行为。
这两个团队的目标从本质上来说是互相矛盾的。极端的说，研发团队想要“随时随地发布新功能，没有任何阻拦”,而运维团队则想要“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动”。
SRE模式
针对以上传统运维模式带来的问题，SRE模式从Google内部诞生：通过招聘软件工程师开发软件系统来维护系统运行以替代传统运维模式中的人工操作。换句话说，SRE就是在用软件工程的思维和方法论，通过设计、构建自动化工具完成以前由运维工程师手动操作的任务。
SRE和DevOps的关系
DevOps旨在打破IT组织中开发、运维、测试和安全各自为政的局面，它不是一个平台，不是一个岗位，也不是什么组织团体和角色，它是一种基于人与技术互动以改善关系和结果的指导原则和文化运动。SRE可以是一个工作岗位，也是我们探索的一系列工作的实践方式,如果认为DevOps是一种理念和工作方法，那么就可以认为SRE实现了DevOps中所描述的部分理念，换句话说，SRE是DevOps文化的具体实践。
