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