共计 1397 个字符，预计需要花费 4 分钟才能阅读完成。
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 文化的具体实际。
本文由 mdnice 多平台公布
