谈谈对 SRE 的理解
前言
在技术工作中,对于产品/基础技术研发和 SRE 两种角色,通常会有基于「是否侧重编码」的理解。对于产品研发转做 SRE ,经常会产生是否要「脱离编码工作」的看法,或者认为是否要「偏离对产品/基础技术的推进」。
基于过往的技术研发和稳定性保障的经验,分享下个人对 SRE 的理解,探讨「面向产品/基础技术的研发」和「稳定性保障」两种角色之间的协作关系,更好地为业务服务。
SRE 概述
最早讨论 SRE 来源于 Google 这本书《Site Reliability Engineering: How Google Runs Production Systems》。由 Google SRE 关键成员分享他们是如何对软件进行生命周期的整体性关注,以及为什么这样做能够帮助 Google 成功地构建、部署、监控和运维世界上现存最大的软件系统。
书的豆瓣链接:https://book.douban.com/subject/26875239/
从 wikipedia: Site reliability engineering 中可了解到 SRE 的定义:
Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems. The main goals are to create scalable and highly reliable software systems.
其中有句形象描述 SRE 工作的描述:
SRE is "what happens when a software engineer is tasked with what used to be called operations."
即 SRE 的目标是构建可扩展和高可用的软件系统,通过软件工程的方法解决基础设施和操作相关的问题。
在 Google SRE 书中,对 SRE 日常工作状态有个准确的描述:至多 50% 的时间精力处理操作相关事宜,50% 以上的精力通过软件工程保障基础设施的稳定性和可扩展性。
基于上述描述,我对 SRE 的理解是:
职责:保障基础设施的稳定性和可扩展性
核心:解决问题
方法:通过操作类事务积累问题经验,通过编码等方式提升问题的解决效率
软件生命周期
Google SRE 一书中,对软件工程从生命周期角度有一个很形象的描述:
软件工程有的时候和养孩子类似:虽然生育的过程是痛苦和困难的,但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。
一个软件系统的 40%~90% 的花销其实是花在开发建设完成之后不断维护过程中的。
项目生命周期中,设计和构建软件系统的时间精力占比,通常是少于系统上线之后的维护管理。为了更好地维护系统可靠运行,需要考虑两种类型的角色:
专注于设计和构建软件系统
专注于整个软件系统生命周期管理,包括从其设计到部署,历经不断改进,最后顺利下线
第一类角色对应产品/基础技术研发,第二类角色对应 SRE,二者的共同目标均是为了达成项目目标,协同服务好业务。
稳定性保障价值
针对稳定性的影响,直接参与处理客户问题的同学会更有体感:
通过问题发生时客户直接反馈的影响程度、紧急程度,感受到稳定性给客户带来的焦虑
通过问题处理结束后客户的反馈,感受到客户对稳定性保障的感谢或愤怒
通过事后在营收状况、客户规模变化,感受到稳定性对业务营收的影响
通过产品规划的的延期,感受到稳定性对产品迭代的影响
稳定性保障的价值由此凸显:
保障客户的产品体验,满足客户对约定的可靠性诉求
加速业务迭代,满足业务对稳定性诉求,业务注意力集中在更快速推出满足客户需求的功能
SRE 如何保障稳定性
稳定性问题通常会有这些特征:
人为导致,依赖专家经验
一系列因素综合导致
不可避免
100% 保障没有必要
线上稳定性问题,人为操作不当导致的比例很高,集中在 发布 和 线上运维 两个环节,均是高频操作。对于复杂系统,这两个环节对专家经验有较强的依赖。
发生的稳定性问题通常具有系统性的特征,即非单个功能组件缺陷导致,而是由一系列因素综合作用导致,如缺少监控告警导致不能及时感知,缺少日志不能有助于快速定位问题,缺少良好的问题排查流程导致依赖个人能力,缺少良好的协调沟通极致导致问题处理时长增加、客户影响程度加剧等。
问题是不可避免的,流量的突增、服务器/网络/存储的损坏、未覆盖的输入等,均会诱发问题的出现。
业务对外有 SLA,向客户承诺一定程度的稳定性,未达到时按照协议进行赔付,同时问题又不可不免,在满足内部 SLO 标准的前提下继续提升稳定性,会带来更高的实现成本,对业务的收益增量也会更小。
SRE 需要对问题特征有深入理解,系统性设计和实施解决方案,并抓住一段时间内的主要问题进行解决。
一种可参考的整体解决方案如下:
落地过程中,可先从如下三个抓手系统解决:
可控性
可观测
稳定性保障最佳实践
可控性方面,包括如下三个主要维度:
发布管理
重点解决发布导致的人为稳定性问题
包括发布前重要变更评审和发布中变更动作管理等
操作管理
重点解决黑屏操作导致的人为稳定性问题
包括统一集群操作入口、集群操作权限管理、集群操作审计等
设计评审
重点解决软件系统设计阶段应用稳定性保障最佳实践
包括集群方案评审和重要功能设计评审等
可观测方面,包括如下几个重要维度:
监控
重点解决软件系统运行态的感知能力
包括监控收集/可视化系统的搭建和维护等
日志
重点解决软件系统的问题可排查能力
包括日志收集/存储/查询/分析系统的搭建和维护等
巡检
重点解决软件系统功能是否正常的主动探测能力
包括巡检服务的搭建、通用巡检逻辑的开发维护等
告警
重点解决异常的及时触达需求
包括告警系统的搭建、告警配置管理、告警途径管理、告警分析等
稳定性保障最佳实践,是从历史问题和业界实践方面抽象出意识、流程、规范、工具,在系统设计之初就融入其中,并在系统整个生命周期中加以使用,如通过模板固化最佳实践:
项目质量验收标准
项目安全生产标准
项目发布前 checklist
项目 TechReview 模板
项目 Kick-off 模板
项目管理规范
etc.
一个例子:
维度 |
评估项 |
可观测 |
|
可灰度 |
|
可回滚 |
|
可保护 |
|
可控成本 |
|
易于运维 |
|
为了便于理解,可以再针对 check 项形成分级,便于交流和进行项目稳定性评估:
级别 |
标准 |
L0 |
|
L1 |
|
L2 |
|
L3 |
|
L4 |
|
L5 |
|
当最佳实践可以通过文档进行规范化,接下来就可以提供工具或服务将其低成本应用,使得稳定性保障最佳实践成为基础设施。
SRE 需要在稳定性相关的方法论和实践方面不断迭代,自上而下设计,自下而上反馈,合理、可靠保障稳定性。
共赢,携手服务业务
再回顾下软件系统生命周期中的两类角色:
产品/基础技术研发:专注于设计和构建软件系统
SRE:专注于整个软件系统生命周期管理,包括从其设计到部署,历经不断改进,最后顺利下线
这两类角色是相互协作、相互服务的关系,拥有共同的目标:满足业务需求,更好服务业务。
SRE 通常会横向支撑多个项目,对线上问题的类型、解决实践有更为全面的理解和思考,基于此会形成最佳实践的理论、工具或服务,为研发提供理论、工具的支持,也可以在此基础上产品化稳定性保障解决方案,为更多的客户服务,创造更大的价值。
产品/基础技术研发对业务需求、功能/技术细节有更深入的理解,一方面直接带来业务价值,一方面可通过实践为稳定性保障带来切合实际的需求,进一步和 SRE 共同保障稳定性。
两种类型的角色,需要朝着共同的目标并肩协作,与业务共同发展,实现共赢。
小结
SRE 由于工作的性质,在横向方面会服务大量的业务,以实践积累对稳定性保障问题域的深入理解和稳定性保障重要性的深刻认知,在纵向方面会通过技术手段将稳定性保障最佳实践进行沉淀和应用;同时眼光又是与研发、业务一齐向前看,综合技术和管理创造价值。
以上是从个人角度对 SRE 及稳定性保障的理解,重点在于解决问题和创造更大的价值。
文章来源:阿里巴巴中间件,点击查看原文。
Kubernetes管理员认证(CKA)培训
本次CKA培训在北京开班,基于最新考纲,通过线下授课、考题解读、模拟演练等方式,帮助学员快速掌握Kubernetes的理论知识和专业技能,并针对考试做特别强化训练,让学员能从容面对CKA认证考试,使学员既能掌握Kubernetes相关知识,又能通过CKA认证考试,学员可多次参加培训,直到通过认证。点击下方图片或者阅读原文链接查看详情。
谈谈对 SRE 的理解相关推荐
- Java面试之谈谈对Volatile的理解
谈谈对Volatile的理解 Volatile在日常的单线程环境是应用不到的 Volatile是Java虚拟机提供的轻量级的同步机制(三大特性) 保证可见性 不保证原子性 禁止指令重排 可能这么说,还 ...
- 谈谈对MVVM的理解
谈谈对MVVM的理解 什么是MVVM 不管是MVC,MVP,或者MVVM,都是常见的软件架构设计模式(Architectural Pattern),它通过分离关注点来改进代码的组织方式.不同于设计模式 ...
- 谈谈对this的理解
谈谈对this的理解 什么是this 每个函数在被调用时都会创建一个执行上下文,这个上下文包含了变量环境.this.作用域链等,this就是执行上下文中的一个属性,他是在函数运行时进行绑定的,this ...
- 什么是面向对象?谈谈对面向对象的理解?
提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档 文章目录 一.什么是面向对象?谈谈对面向对象的理解? 二.3大特征: 1.封装: 2.继承: 2.多态: 总结 一.什么是面向对象?谈 ...
- jvm对于java的意义_谈谈对JVM的理解
JVM可谓是学习JAVA基础中的基础了,但仍有不少同学对JVM概念还是比较模糊,甚至没有听说过,对java的理解也只是在基础语法 层面,本文就将对JVM进行初步介绍,因篇幅所限,只能介绍JVM基础,如 ...
- 谈谈对springioc的理解
https://www.cnblogs.com/xdp-gacl/p/4249939.html 转载 学习过Spring框架的人一定都会听过Spring的IoC(控制反转) .DI(依赖注入)这两个概 ...
- 读Java核心技术36讲有感——谈谈对Java的理解,谈谈Exception和Error
读过杨晓峰老师的36讲之后,想总结下自己的感想,写下来也有助于记忆,方便以后面试查阅和复习.题目所提到的话题本来是两讲,但是由于感想篇幅较短,所以合成一篇来写. 一.谈谈对Java平台的理解: 1.J ...
- 谈谈对python的理解_浅谈对python pandas中 inplace 参数的理解
这篇文章主要介绍了对python pandas中 inplace 参数的理解,具有很好的参考价值,希望对大家有所帮助.一起跟随小编过来看看吧 pandas 中 inplace 参数在很多函数中都会有, ...
- 谈谈对MVC的理解(View+Model+Controller)
1) 什么是MVC? MVC是一种设计思想,根据职责不同将程序中的组件分成以下3个部分. V(View视图):负责与用户交互.将数据展现,或者是接收数据 M(Model模型):负责业务处理.业务模型, ...
- 谈谈对 Spring 的理解
认识 Spring 框架 Spring 框架是 Java 应用最广的框架,它的成功来源于理念,而不是技术本身,它的理念包括 IoC (Inversion of Control,控制反转) 和 AOP( ...
最新文章
- 递归打印组合数、搜索模板
- wangEditor编辑器在laravel中上传图片(二)
- Google 团队效能研究 | 为什么雇用最聪明的人是远远不够的?
- mysql.sock的作用
- ASP.NET Core Filter与IOC的羁绊
- python冒泡算法_python_冒泡算法
- 跳转到系统默认的Home
- 一步一步写算法(之 回数)
- 自考那些事儿(九):再次学操作系统
- 数据结构实验5-递归
- ArcGIS教程 - 2 ArcGIS基础知识
- IEEE802.15.4、ZigBee、ZigBee协议栈、Zstack、ZigBee联盟、CC2530、IAR的关系?
- dorado 7 数据库配置
- python播放音频文件——playsound
- 2022年网络安全行业发展趋势
- andriod studio 开发
- 在网站中接入 客服QQ
- 低效率只因环境太乱?43 个方法帮你减少干扰
- 邮件服务器问题--邮件积压、传递延迟解决方法
- dfc trace performance anaysis
热门文章
- Element 表格序号问题
- 痞子衡嵌入式:ARM Cortex-M内核那些事(3.2)- 安全模块看特性(M23/33/35P)
- 网络可视化工具netron详细安装流程
- cocos2dx[3.x](11)——拖尾渐隐效果MotionStreak
- 数字孪生北京故宫,元宇宙推进旅游业进程
- 关于补天SRC新手入门详细介绍(通用漏洞篇)
- ps中怎么导出tif_TIF图片太大难以上传?
- 图片颜色和相机的一些基本知识
- 二元隐函数求二阶偏导_隐函数求二阶偏导
- 一台服务器​最大并发 tcp 连接数多少?65535?