SRE，了解一下？35+ 岁程序员新选择

本文分享自华为云社区《浅谈SRE角色认知》，作者： SRE 确定性运维。

一、什么是 SRE？

SRE（Site Reliability Engineer）从 2003 年被谷歌公司提出，已经将近 20 年，它不仅是一个岗位，而是一个体系化的工程。最早谷歌公司提出 SRE 是为了解决两个核心冲突点：1、开发、运维两个团队在上线速度和现网系统稳定性之间的冲突；2、软件的快速上线，模糊了运维和研发的边界。谷歌 SRE 通过软件工程技术，持续改进现网可用性和自动化运维能力，SRE 作为一个新的技术岗位走上历史舞台。

SRE 是站点可用性工程师：强调软件和系统工程能力，SRE 需要编写自动化脚本，优化和改进配置。写代码是必须的技能要求，因为代码是支撑工具开发和自动化的手段，但不鼓励写大量代码，希望能通过简单的工具或者配置解决问题。

SRE 素质能力模型主要有：软技能（合作、沟通、独立解决问题），实践经验（IT 运维、基础设施、安全等），流程和框架（DevOps、敏捷等），新技术（CICD 工具、微服务升级与 API）。

二、云为什么要走 SRE 道路

云业务相较传统业务存在两个变化，运维对象和运维模式都发生了本质改变，传统运维模式已不能满足要求，运维专业必定向 SRE 发展。

面向运维对象的四点变化：

1）传统产品局点规模海量，单局点规模有限。但云业务单系统就支持几十上百万的服务器规模；

2）传统 IPD 版本周期长达半年，DevOps 模式 1~4 周一个版本;

3）云计算 L0～L4 堆栈复杂，系统整体可用性依赖全栈可用性；

4）运维对象不是可批量交付的成熟产品，而是微服务架构下的不断演进的服务组件，同时各个行业的特质也会发生变化。

商业模式改变引起运维模式的变化：

1）商业模式转变导致运维的责任边界产生变化，传统模式客户服务运维，厂家做二线保障。现在需要端到端负责可用性设计以及 1/2 线运维，这种模式下，仅靠后端保障可用性是不够的，需要介入前端顶层架构设计。

2）传统模式只对交付的产品可靠性负责，不需考虑周边可用性制约因素，但是作为服务运营商，需要对服务全栈可用性负责。

3）传统模式，运维人员只是对运维系统的使用者，但是现在除了使用者外，还是运维系统的建设者，由最懂现网业务的 SRE 主导设计和开发运维工具。

三、SRE 角色认知

有别于传统运维工程师，SRE 在服务生命周期中扮演以下三个关键角色：

1）现网可用性的守护者。是现网的 Owner，守护现网稳定性是 SRE 的第一职责，围绕现网保障会建立一整套的事前、事中、事后的 SLA 保障体系和能力。事前：监控告警、变更管理、容量管理、重大保障、应急演练等一系列业务活动。事中：事件管理、warroom、应急恢复能力。事后：故障 Postmortem、现网数据分析、通过现网数据持续驱动产品改进。SRE 强调全栈、端到端能力，是系统性专家;

2）系统高可用性的设计者。是高可用设计的 Owner，联合产品研发围绕 SLI/SLO 目标设计服务高可用，将高可用软件架构和工程方法应用到产品。SRE 作为高可用性设计的专家参与到产品设计和上线活动中，运用系统和软件工程科学解决产品可用性问题；

3）运维软件工程能力的构建者。用软件工程的思维和方法管理现网，通过可信开发构筑系统可用性和自动化能力。打造安全可靠的运维平台，建设自动化运维服务，支撑云服务的高可用落地，提升运维安全和运维效率。持续关注业务和技术发展，引入并采用业界新软件技术，引导系统优化演进，围绕运维业务目标，构筑运维领域技术竞争力。

四、SRE 素质要求

相对传统运维，SRE 需要既懂开发，又懂运维，能端到端参与产品研发生命周期全过程，围绕高可用和自动化建立四大关键能力。

1）编码能力是 SRE 的基本技能要求，强调软件和系统工程能力;

2）具备"软件工程"思维，要有站点和服务高可用设计能力，同时将高可用架构和软件工程方法应用到产品研发过程；

3）有能力进行自动化研发，用自动化软件完成运维和系统高可用性工作；

4）SRE 要有 SLI/SLO 体系化设计能力，通过 SLO 将服务可用性显性化度量。

同时，SRE 要将现网优秀实践经验固化到流程规范中，形成一套可复制的标准化运维体系。

点击关注，第一时间了解华为云新鲜技术~