浅谈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要将现网优秀实践经验固化到流程规范中，形成一套可复制的标准化运维体系。