【运维】站点可靠性工程介绍：研发，运维，SRE，Devops的关系

站点可靠性工程（SRE） 是 IT 运维的软件工程方案。

SRE 团队使用软件作为工具，来管理系统、解决问题并实现运维任务自动化。 SRE 执行的任务以前通常由运维团队手动执行，或者交给使用软件和自动化来解决问题和管理生产系统的工程师或运维团队执行。
站点可靠性工程师是一个独特的岗位，要么必须具有系统管理员背景、或有运维经验的软件开发人员；要么必须是有软件开发技能的 IT 运维人员。
SRE 团队负责部署、配置和监控代码，以及生产服务的可用性、延迟、变更管理、应急响应和容量管理。

SRE的起源：

10多年前，谷歌出现了一种新的岗位叫做SRE，它重视运维人员的开发能力，要求运维工作在50%以内，另外50%精力开发自动化工具减少人力需求，谷歌的这种模式大获成功，不仅解决了运维和开发之间的矛盾，还降低了人力成本，这个岗位发展到现在有1000名以上的SRE！这就是SRE的历史起源。
谷歌的一名SRE出了一本书叫《SRE：Google运维解密》，通过这本书，我们知道了谷歌SRE的一些方法论：

1、运维工作50%，另外50%精力用于开发自动化工具；

2、保障服务的前提下最大化迭代速度，不追求100%可靠性；

3、通过监控预案缩短平均恢复时间MTTR；

4、部署变更管理：渐进发布，精确检测，安全回滚；
从这里我们就可以看出传统运维和SRE的区别了：相对传统运维，SRE重视开发，重视效率，追求自动化，专注于整个软件系统的生命周期管理。

总体来说，SRE就是运维开发一体化的一套方法论，而在国内这种运维开发一体化的模式叫做Devops。

现在国内传统运维都在向Devops转，所以问题描述上说的SRE和传统运维相似度很高其实是没搞明白SRE是什么。

SRE的需求背景有这么几个：

1 和 2 促使需要一个专门的工种，而 3 则提供了 SRE 的稳定来源。因为 SRE 是在研发和运维之后出现的工种，所以第一批的 SRE 就是从那两个工种里转型而来。又因为 SRE 的很大一部分工作还是保障业务稳定性，所以从运维转型而来的占大多数。

SRE对岗位能力要求较多，一般包括：

研发能力： 软件开发是SRE很重要的一项工作内容。为提高运维的效率和质量，SRE会专注于开发各种自动化的运维工具，因此，对于SRE 对研发能力提出了较高要求。
问题分析能力： SRE要善于分析问题，从问题中提取用户需求，进而将其沉淀为一个运维工具或产品。
项目管理能力： 运维和研发都属于SRE的日常工作范畴，良好的项目管理能力可以帮助SRE合理安排时间，协调资源投入，保证各项工作的顺利进行。
虽然在线各大厂发布的JD各不相同，但是能力要求是类似的
各一线大厂对 SRE 的工作要求集中在：
网络层（VPN、专线、防火墙、http协议、Tcp协议、BGP协议等）
中间件（接入层、消息队列、缓存、文件存储、搜素、大数据等）
容器（容器编排、容器、容器网络、镜像管理等）
操作系统（CPU管理、内存管理、磁盘I/O、网络I/O、内核等）
基础服务（日志、监控、容器云等）

下图描绘了研发 (Dev)，SRE，运维 (Ops) 的交叉关系。研发和运维基本上是没有交集的，而 SRE 就像前面说的是具备研发能力的运维，但整体还是更偏运维一点。

研发，SRE ，运维是工种，而 DevOps 是体系。如果拿足球来打比方，研发，SRE ，运维对应的就是前锋，中场，后卫这样的位置，而 DevOps 则是诸如 4-3-3 这样的阵型。

在这里插入图片描述

2.1 研发和运维

研发工程师，工程师，Software Engineer (SWE)，Software Developer 或者简称 Developer (Dev)。主要职责是写代码，实现软件业务功能。比如打车功能就是研发工程师用代码实现的。研发主要和代码打交道。
运维工程师，Operations (Ops), Production Engineer (PE)。主要负责机房管理，装机，网络，监控报警，故障应急。早期运维很大比例的工作是和物理机器设备打交道，需要大量的手动操作，操作风险也很高，后来逐渐引入软件或者自己写一些脚本，代码来自动化工作。近 10 多年随着云服务逐渐取代物理机，传统运维的职能被大幅度缩减，成为了一个逐渐要消亡的工种。

2.2 运维和SRE

简单来说，SRE 是传统运维的升级版，区别于传统运维的地方：
1. 不再负责和物理设备打交道，这部分交给云服务了。
2. 通过体系化的手段来保障业务稳定性，比如构建自动化工具，和研发团队一起制定 SLO (Service Level Objective)，让双方有可以一起遵守的契约，来保证服务的健康度。
3. 工程研发能力。SRE 也可以说是具备研发能力的运维，有些 SRE 还具备很强的研发能力，比如监控软件 Prometheus 的作者就曾是 Google 的 SRE。

2.3 DevOps 和 SRE

DevOps 是一种体系，研发 Dev 和运维 Ops 这两个工种是没有交集的，DevOps 就是要把这两个工种融合在一起，更确切的讲，是要让 Dev 去承担 Ops 的工作。
在 DevOps 的体系里，是没有传统运维这个角色的，运维的职能可能由研发和 SRE 共同分担，也有可能由研发独自承担，连 SRE 角色都没有。 后一种情况下，研发等于变成了全干工程师。
和 DevOps 一样，SRE 也与团队文化和关系密切相连。SRE 和 DevOps 都致力于搭建开发团队和运维团队之间的互通桥梁，以便加快交付服务。
然而，SRE 与 DevOps 有所不同，因为它依赖于开发团队中的站点可靠性工程师，这些工程师也要有解决通信和工作流程问题的运维背景。 站点可靠性工程师本身要求职责重叠，兼具开发团队和运维团队的技能。
DevOps 团队的开发人员常常疲于处理运维任务，需要拥有更专业运维技能，而 SRE 就能派上用场。在编码和构建新功能时，DevOps 专注于有效通过开发流程，而 SRE 专注于通过创建新功能来平衡站点可靠性。
在这里，基于容器技术、Kubernetes 和微服务的现代化应用平台是落实 DevOps 实践的关键所在，可帮助企业交付安全的创新软件服务。 也是研发支撑软件的搭建。