什么是SRE

概述

SRE（Site Reliability Engineering）翻译成中文就是网站稳定性工程师，专门负载网站的稳定运行。说到这个职责可能很多人会联想到运维工程师，两者确实有相似之处，但是也不尽然。SRE本质上还是软件工程师，招聘时按照软件开发工程师的要求来招聘，通过软件工程理论来管理工程，力图重新定义运维，推进业务进化。

SRE的概念最早由谷歌提出，其他互联网公司争相跟进，目前实践的比较好的是谷歌和奈飞(neflix)。奈飞的核心SRE据说只有个位数，他们运营着全球190国家的上亿用户，用实践证明了SRE理论的正确性。

站点可靠性工程师(SRE)代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破。由一个简单的想法“我是一个软件工程师，这是我如何来应付重复劳动的办法” 而生，SRE模型已经发展成一套指导思想，一套方法论，一套激励方法，和一个拥有广阔空间的独立职业。

SRE 和 DevOps

站点可靠性工程的核心，就是对 DevOps 范例的实践。DevOps 的定义有很多种方式。开发团队（“dev”）和运维（“ops”）团队相互分离的传统模式下，写代码的团队在将服务交付给用户使用之后就不再对服务状态负责了。开发团队“把代码扔到墙那边”让运维团队去部署和支持。

这种情况会导致大量失衡。开发和运维的目标总是不一致 —— 开发希望用户体验到“最新最棒”的代码，但是运维想要的是变更尽量少的稳定系统。运维是这样假定的，任何变更都可能引发不稳定，而不做任何变更的系统可以一直保持稳定。（减少软件的变更次数并不是避免故障的唯一因素，认识到这一点很重要。例如，虽然你的 web 应用保持不变，但是当用户数量涨到十倍时，服务可能就会以各种方式出问题。）

DevOps 理念认为通过合并这两个岗位就能够消灭争论。如果开发团队时刻都想把新代码部署上线，那么他们也必须对新代码引起的故障负责。就像亚马逊的 Werner Vogels 说的那样，“谁开发，谁运维”（生产环境）。但是开发人员已经有一大堆问题了。他们不断的被推动着去开发老板要的产品功能。再让他们去了解基础设施，包括如何部署、配置还有监控服务，这对他们的要求有点太多了。所以就需要 SRE 了。

开发一个 web 应用的时候经常是很多人一起参与。有用户界面设计师、图形设计师、前端工程师、后端工程师，还有许多其他工种（视技术选型的具体情况而定）。如何管理写好的代码也是需求之一（例如部署、配置、监控）—— 这是 SRE 的专业领域。但是，就像前端工程师受益于后端领域的知识一样（例如从数据库获取数据的方法），SRE 理解部署系统的工作原理，知道如何满足特定的代码或者项目的具体需求。

所以 SRE 不仅仅是“写代码的运维工程师”。相反，SRE 是开发团队的成员，他们有着不同的技能，特别是在发布部署、配置管理、监控、指标等方面。但是，就像前端工程师必须知道如何从数据库中获取数据一样，SRE 也不是只负责这些领域。为了提供更容易升级、管理和监控的产品，整个团队共同努力。

当一个团队在做 DevOps 实践，但是他们意识到对开发的要求太多了，过去由运维团队做的事情，现在需要一个专家来专门处理。这个时候，对 SRE 的需求很自然地就出现了。

SRE的职责

SRE的职责是什么的？SRE的工作内容主要包括以下内容

• 容量规划
• 生产系统监控报警
• 部署，发布变更
• 值班

而SRE最明确的职责就是确保站点的稳定，这需要他对站点所涉及的系统、组件非常熟悉（大型网站的系统和组件依赖以及网站的发展史会在后面的文章给大家介绍），同时需要开发、维护很多工具和系统支撑其完成这项工作，比如devops系统，监控系统，日志系统，资源管理系统等。总的来说，SRE是一个综合素质很高的全能手，需要懂服务器、操作系统、网络、中间件…具备基础编程能力、架构能力、问题分析能力、抗压能力以及性能调优能力。

写在文末

博主是一名准SRE，校招中误打误撞上岸某互联网大厂，将在以后的日子里记录自己的SRE学习历程（目前在读SRE的经典作《SRE：Google运维解密》）。

本文节选自简书，链接原文，如有侵权联系删除