什么是 SRE(站点可靠性工程)?

概述

站点可靠性工程(SRE)是 IT 运维的软件工程方案。SRE 团队使用软件作为工具,来管理系统、解决问题并实现运维任务自动化

SRE 执行的任务以前通常由运维团队手动执行,或者交给使用软件和自动化来解决问题和管理生产系统的工程师或运维团队执行。 

在创建可扩展和高度可靠的软件系统时,SRE 是宝贵的实践。它可帮助您通过代码管理大型系统,对于管理成千上万台机器的系统管理员(sysadmin)来说,代码更具可扩展性和可持续性。 

站点可靠性工程的概念由 Google 工程团队的 Ben Treynor Sloss 第一个提出。 

SRE 可以帮助团队在发布新功能和确保用户可靠性之间找到平衡。

在这种背景下,标准化和自动化是 SRE 模型的两大重要部分。在这里,站点可靠性工程师寻求增强和自动化运维任务。

通过这些方式,SRE 有助于提高当今的系统可靠性,并且随着时间的推移不断提高。 

SRE 支持团队从传统 IT 运维方案迁移至云原生方案。

站点可靠性工程师的工作是什么?

站点可靠性工程师是一个独特的岗位,要么必须具有系统管理员背景、或有运维经验的软件开发人员;要么必须是有软件开发技能的 IT 运维人员。 

SRE 团队负责部署、配置和监控代码,以及生产服务的可用性、延迟、变更管理、应急响应和容量管理。

SRE 团队根据服务水平协议(SLA)确定新功能的推出,并利用服务水平指标(SLI)和服务水平目标(SLO)定义系统所需的可靠性。 

SLI 测量所提供服务水平的特定方面。关键 SLI 包括请求延迟性、可用性、错误率和系统吞吐量。SLO 基于根据 SLI 而指定的服务水平的目标值或范围。

然后,根据确定可接受的停机时间,确定所需系统可靠性的 SLO。这个停机时间称为误差量,即出错和中断的最大允许阈值。 

SRE 并不是要实现 100% 可靠性,而是针对故障做好计划并妥善应对。

一旦建立,开发团队就可以在发布新功能时允许出现这一定量的误差。利用 SLO 和误差量,团队随后可确定产品或服务是否能够在可用误差量的基础上启动。

如果某个服务在运行时处于误差量以内,则开发团队可在任何时间发布它,但是,如果系统当前有太多错误或停机时间超过误差量的允许范围,则必须使错误数减少至误差量以内后才能发布。   

开发团队可执行自动化运维测试以验证可靠性。 

站点可靠性工程师的时间要均衡分配给运维任务和项目工作。根据 Google 的 SRE 最佳实践,站点可靠性工程师最多只能将一半的时间花在运维上,所以应该监控确保不会超过这个时间。  

他们剩余的时间应专注于开发任务上,比如创建新功能,扩展系统,以及实施自动化。

额外的运维工作和表现欠佳的服务应重新指定给开发团队,这样站点可靠性工程师就不用将太多时间花在应用或服务的运维上。 

自动化是站点可靠性工程师的重要工作部分。如果他们一直在反复处理同一个问题,就会努力实现解决方案自动化。 

保持运维和开发工作之间的平衡是 SRE 的重要组成部分。 

DevOps 和SRE

DevOps 是指对企业文化、业务自动化和平台设计等方面进行全方位变革,从而实现迅捷、优质的服务交付,提升企业价值和响应能力。SRE 可视为 DevOps 的实施。

和 DevOps 一样,SRE 也与团队文化和关系密切相连。SRE 和 DevOps 都致力于搭建开发团队和运维团队之间的互通桥梁,以便加快交付服务。 

DevOps 和 SRE 实践都可以实现更快的应用开发生命周期、改进的服务质量和可靠性,以及缩短的 IT 应用开发时间等优势。

然而,SRE 与 DevOps 有所不同,因为它依赖于开发团队中的站点可靠性工程师,这些工程师也要有解决通信和工作流程问题的运维背景。

站点可靠性工程师本身要求职责重叠,兼具开发团队和运维团队的技能。 

DevOps 团队的开发人员常常疲于处理运维任务,需要拥有更专业运维技能,而 SRE 就能派上用场。 

在编码和构建新功能时,DevOps 专注于有效通过开发流程,而 SRE 专注于通过创建新功能来平衡站点可靠性。 

在这里,基于容器技术、Kubernetes 和微服务的现代化应用平台是落实 DevOps 实践的关键所在,可帮助企业交付安全的创新软件服务。

支持 SRE 的技术

SRE 要在应用的整个生命周期中确保日常运维任务的自动化和标准化。 红帽® Ansible® 自动化平台是一个全面的集成平台,可帮助 SRE 团队实现速度、协作和增长的自动化,从而为企业的技术、运维和财务职能提供安全性和支持。

具体而言,Ansible® 自动化平台可提供: 

云和本地基础架构编排,可用于实例、路由、负载平衡、防火墙等。 

基础架构优化,包括大小适当的云资源,以及根据需要添加或删除中央处理器(CPU)和随机存取存储器(RAM)等资源。 

云运维,包括具有持续集成和持续交付(CI/CD)管道的应用部署、操作系统修补和维护。

业务连续性,包括从云中移动和复制资源,创建和管理备份策略,以及管理中断和故障。

原文链接:https://www.redhat.com/zh/topics/devops/what-is-sre#%E6%94%AF%E6%8C%81-sre-%E7%9A%84%E6%8A%80%E6%9C%AF

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,968评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,601评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,220评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,416评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,425评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,144评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,432评论 3 401
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,088评论 0 261
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,586评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,028评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,137评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,783评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,343评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,333评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,559评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,595评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,901评论 2 345

推荐阅读更多精彩内容