武汉的开发者们注意啦!AI技术战略、框架以及最佳实战尽在Azure OpenAI Day 了解详情
写点什么

2019 SRE 调查报告:事故处理是主要工作,SRE 压力山大

  • 2019-04-02
  • 本文字数:3875 字

    阅读完需:约 13 分钟

2019 SRE 调查报告:事故处理是主要工作,SRE 压力山大

2019 年 1 月,网站监测服务公司 Catchpoint 通过邮件列表和社交媒体进行了一项 SRE 调查。来自不同行业的 188 名 SRE 参与了这项调查,回答了如何管理事故以及事故后压力等一些问题。


今年是 Catchpoint 连续第二年调查 SRE 这个新兴的职业角色。去年的调查专注于 SRE 是谁,主要做什么。报告中探讨了 SRE 所使用的技能,工具集和企业文化,以确定团队和组织之间是否存在一套核心原则。


今年的调查研究了团队结构,中断,事故和事故后员工的压力。该调查希望回答事故对组织和响应人员有什么影响。组织专注于构建弹性系统并快速恢复,但这一关注点是否扩展到员工的弹性以及事故后压力的恢复?


调查结果主要有以下这些结论:


  • 结论一:SRE 仍然是一种新兴的实践方式。64%的受访者表示组织中 SRE 存在了不到三年。

  • 结论二:事故处理占了 SRE 工作内容的大部分。49%的受访者表示过去一周处理过事故。

  • 结论三:事故处理很有压力。79%的受访者表示事故处理的工作内容很有压力。

  • 结论四:团队的支持可以减轻事故后的压力。在事故发生后感到有压力的 SRE 中,有 67%的人认为公司不在乎他们的精神感受。

关于 SRE

SRE 工作人员有各种各样的头衔:45%的受访者头衔为 SRE(站点可靠性工程师)。但其余的人自我认定为是 SRE 工作。当把 SRE 管理层(SRE 经理,SRE 主管等)包括在内时,这一百分比增加到 49%。29%的 SRE 担任高级职位(包括架构师,高级/资深 XX 等),16%担任领导职位(经理,董事,副总裁或高管)。剩下的是初级或中级职位。


组织规模


14%的受访者公司规模少于 50 人,36%的受访者公司规模在 50-999 人,19%的受访者公司规模在 1000-4999 人,31%的受访者公司规模在 5000+人员。

结论一:SRE 是新兴角色,还没有被完全定义

你的组织中有多少名 SRE?


大多数受访者的组织中 SRE 团队不超过 10 人。6%的受访者反馈自己是组织中唯一的 SRE 人员。


SRE 团队组建了多久?

SRE 概念的提出已经有 15 年了,但是这一角色仍然处于初始阶段。



26%的人反馈少于 1 年,38%的人反馈 1-3 年,13%的人反馈 3-6 年,6%的人反馈 6-10 年,15%的人反馈 10 年以上。

SRE 团队是如何组建的?

31%的受访者表示 SRE 团队是由运维/系统管理团队演变而来;


13%的受访者表示“我们把运维/工程/系统管理团队改名为 SRE 了”;


9%的受访者表示,高层说我们现在在做 SRE;


2%的受访者表示我们雇了初级人员培训他们成为 SRE。

琐事(toil)的影响

琐事(toil)是手动,重复,可自动化和可线性扩展的战术工作,是 SRE 的主要关注点,主要来源于维护任务和非紧急的、与服务相关的消息。59%的人认为他们的组织中有太多的琐事,而且没有足够的自动化工具/流程来减少这些琐事。


对于“我们使用自动化来减少琐事“这一说法,没有人表示强烈赞同,而 48.5%的人不同意或强烈不同意。

组织中有太多琐事

琐事的主要来源是:

  • 39%的人表示是维护任务;

  • 27%的人表示是非紧急性的服务相关消息;

  • 16%的人表示是发布;

  • 15%的人表示是 on-call 通知;

  • 7%的人表示是非服务相关的消息。

我们使用了自动化来减少琐事


40%的人反馈组织并没有使用自动化,没有人完全同意组织使用自动化来减少琐事。

SLO

设置和监控 SLO(服务级别目标)是 SRE 的一个关键方面。跟踪最广泛的 SLO 是服务可用性。


除了 27%的受访者表示组织中没有 SLO,其他所有具有 SLO 的 SRE 都会跟踪服务可用性。

我们为每个重要服务都设定了 SLO:


20%的人完全同意,10%的人完全同意

我们的 SLO 包括


72%的人提到可用性,47%的人提到响应时间,46%的人提到延时,27%的人表示没有 SLO。

事故对业务的影响

SLO 不达标会对业务产生明显影响。一个 SRE 指出事故的后果是“世界会变成一团糟。”这话没错。


86%的受访者表示事故会降低客户满意度;


70%受访者反馈事故会使公司收入减少;


57%的人反馈事故后员工生产力会下降;


49%的人表示事故会造成客户流失;


36%的人表示在发生事故的话会在社交媒体上产生不好的影响。

小结

SRE 仍处于初始阶段。SRE 确保应用程序和服务的可靠性,这包括定义服务级别的可用性意味着什么。如果 API 可用,但响应请求需要 5 秒钟,能满足用户的期望吗?在组织准备好接受 SRE 工作之前(或者如果已经有 SRE 团队了),请考虑什么是可接受的 SLO。从多个角度建立当前应用程序和服务性能的基准,并使用这些基准来指导创建 SLO。


对于那些实践了很久 SRE 的公司,找到需要改进的地方。应该添加哪些额外的 SLO?组织中目前有哪些琐事?有没有可能通过自动化来减少这些琐事?实施新 SLO 或启动新服务时,可能会创建哪些新的工作?


考虑 SRE 使用的工具。它们会增加琐事吗?能准确跟踪 SLO 吗?

结论二:事故处理占据 SRE 的大部分工作

调查中将事故定义为降低应用或服务质量的意外中断。根据故障或中断的范围、影响、复杂性和紧急程度确定事故的优先级。


88%的 SRE 通过警报和通知工具接收相关通知,但仍有少数人通过同事或用户联系服务台后才知道出了事故。

你上次处理事故是什么时候?

49%:一周以内;


34%:一月以内;


10%:目前正在处理;


4%:我不负责处理事故;


4%:不记得了


事故不可知也没办法提前准备,有些容易处理,有些则很难。近一半的受访者表示在职业生涯中遇到过持续一天以上的中断。

一周内处理多少起服务事故?

92%:少于 5 起;


48%:少于 1 起;


44%:5 起;


4%:6-10 起;


4%:超过 10 起

团队里负责 on-call 轮班的有几个人?

On-call 轮换的情况各不相同。即使是少于 50 人的公司,他们的 on-call 轮换也有不同的规模。在少于 50 人的公司工作的受访者中,有 30%的人表示团队中有 2 个人负责 on-call。1%的人反馈团队中有 130 人负责 on-call,另外有 1%的人反馈团队中 on-call 轮班的有 150 人。


小结

考虑团队将有多少个 SRE,以及他们是否能够充分支持应用和服务。给 on-call 轮班安排适当的人员,并确保他们可以访问警报和通知系统。


检查事故发生时是否存在一个处理模式。代码部署后会发生更多事件吗?如果是这样,请考虑在预生产或开发过程中进行额外的监控或测试。

结论三:处理事故的压力很大

调查中将事故后压力定义为事故发生后两天时间内身体和心理健康状况的变化。事故后压力可持续几分钟到两天时间不等。

在处理事故后会感到有压力吗?


11%:每次事故后都有压力;


68%:一些事故后有压力;


21%:从来没感到过压力;


那些经历事故后压力的人中,有 67%在上周处理了事故,14%的人表示目前正在处理事故。


不想事故后有压力的话,一种方法是不对事故进行处理。18%的从未经历过事故后压力的人不记得上次他们处理事故是什么时候了,或者从来没有处理过事故。


另一方面,组织中唯一的 SRE 总会遇到一些压力。

事故后压力水平如何?

压力水平是主观的。某些人认为是低压力的事在另一些人看来可能是中等压力或高压力的事。


在处理严重问题时会感受到更多的压力吗?

最近一次处理事故之后有哪些身心变化?


52%:情绪


48%:注意力


38%:睡眠


38%:社交


32%:心情


9%:胃口


1%:无


即使那些从未经历过事故后压力的人也在事故后也感受到某些上述情况的变化,虽然他们可能不会将此归类为压力。

做啥可以减轻压力?

61%:运动或散步


52%:花时间做自己喜欢做的事


48%:晚上好好休息


43%:和朋友相处


35%:喝酒

小结

SRE 的工作很紧张。组织可以从流程和技术角度两方面采取措施来减轻他们的压力。一种方法是部署好警报,可及时进行通知。在总是遇到事故后压力的受访者中,20%是通过用户反馈服务台才发现事故的。如果员工在用户抱怨之前就收到通知,压力水平可能会降低。


如果组织已经有了警报和通知的解决方案,但 SRE 员工压力水平仍然很高,要考虑是否是由于警报疲劳造成的。是否因为没有对应用或服务的所有关键元素都监控到位而缺少了重要通知?


如果这些解决方案都已经到位,SRE 还是压力很大,那可能是人的原因,也就是调查的最后一个结论。

结论四:团队的支持可以减轻事故后压力

认为公司关心自己身心健康的员工压力会小一些。经历过事故后压力的人中,76%不认为公司关心他们的身心健康或者没感觉到公司有关心过。从调查结果来看,SRE 人员认为团队比公司更关心他们的精神状况。



公司在意我的身心健康。9%完全不同意;15%不同意;26%没感觉;32%同意,18%完全同意



团队在意我的身心健康。5%完全不同意;6%不同意;20%没感觉;29%同意,40%完全同意。

你的组织如何减轻 SRE 的事故后压力?

调查中这个问题并没有提供“无”这一选项,但仍然有 9%的回答是“无”。


61%:公司推行公平/免责文化


40%:有额外的休息时间


38%:关心你在做什么


7%:提供免费按摩


7%:减少 on-call 轮班

你认为你的团队在事故中/后支持你吗?

在事故中和事故后,一名 SRE 人员是否感受到团队支持会影响他的压力水平。80%的受访者表示在事故后感受到了团队的支持。反馈在某些或事故中感到压力的人中,64%表示受到团队支持。每次事故都感到压力的人中,有 43%的人表示受到团队的支持。


小结

压力被认为是“工作的一部分”,但是不要忽视了压力对健康的影响。


免责文化(blameless post-mortem)的概念很好,但并不能消除 SRE 处理事故的压力。组织需要一些更具体的方法来减轻他们的压力。


对很多人来说,承认失败是有压力的。减少事故的发生,尤其是高优先级事故,将大大减轻压力。


对于 on-call 轮班或处理事故的 SRE,公司应该给予补偿。调查中受访者提到的一些补偿建议有:


  • 为 on-call 提供加班费或者额外假期,一家公司将此称为“过载保护”,还挺形象。

  • 定期进行事件后审查。

  • 记录出错的地方,确定是否需要额外的技术或人力投资来解决问题。

  • 在整个组织和团队中共享知识和信息。


你的公司有 SRE 团队吗,SRE 们是否也如此亚历山大?欢迎大家留言交流。


2019-04-02 15:444809
用户头像
张婵 InfoQ 技术编辑

发布了 87 篇内容, 共 51.4 次阅读, 收获喜欢 218 次。

关注

评论

发布
暂无评论
发现更多内容

入选首个开源贡献世纪榜,TDengine 亮相 FICC 开源计算机系统大会

TDengine

tdengine 时序数据库

上海国家会计学院第六届智能财务高峰论坛成功举办

用友BIP

智能财务

从互联网到云计算再到 AI 原生,百度智能云数据库的演进

百度Geek说

人工智能 云计算 云原生 企业号12月PK榜

浪潮云连续2年跻身中国分布式云市场领导者象限

浪潮云

云计算 数据云

如何为3D模型导入材质贴图

3D建模设计

3D渲染 纹理贴图 材质编辑

AnyGo for Mac(虚拟定位软件) 6.9永久激活版

mac

苹果mac Windows软件 虚拟定位软件 AnyGo

2024年程序员必须掌握的10款开发工具

伤感汤姆布利柏

敏捷开发 低代码 开发工具 测试工具 前端开发工具

Wireshark使用技巧

小齐写代码

注册中心元数据的应用

姚秋实(Nacol)

Java 架构 配置中心 元数据 metadata

31 | 深度和广度优先搜索:如何找出社交网络中的三度好友关系

鲁米

功能有更新 | Bonree ONE 权限版本新增环境、资源域、角色概念

博睿数据

软件测试/人工智能/PyTorch技术在软件测试中的应用

测试人

人工智能 软件测试

OpenHarmony创新赛人气投票活动,最佳人气作品由你来定!

OpenHarmony开发者

OpenHarmony

软件测试/人工智能丨掌握视觉CV处理技术对软件测试工作的帮助

测试人

人工智能 软件测试

mac专业视觉特效包处理工具 FxFactory pro 8 激活最新版

mac大玩家j

Mac软件 视觉特效插件

低多边形植物模型法线贴图

3D建模设计

3D渲染 材质贴图 纹理贴图 材质纹理 材质编辑

大算力与大模型的融合之力

百度开发者中心

nlp 大模型

新型生成式 AI 助手 Amazon Q 为 IT 专业人士与开发人员提供有力支持(预览版)

亚马逊云科技 (Amazon Web Services)

re:Invent Amazon EC2 生成式人工智能 Amazon Lambda Amazon Chatbot

云原生之旅:一年的变革、成长与启示

熬夜磕代码、

优化大模型的关键策略

百度开发者中心

大模型 深度学习、

Fine-tuning: 一种针对大模型的优化策略

百度开发者中心

nlp 大模型

从根上理解elasticsearch(lucene)查询原理(1)-lucece查询逻辑介绍

EquatorCoco

Elastic Stack 查询 优化工具

融合事项会计与用友BIP商旅及费控:提升企业运营效率和透明度

用友BIP

商旅费控 事项会计

强大的录屏截图标注工具:CleanShot X激活最新版

胖墩儿不胖y

Mac软件 屏幕截图工具 屏幕录屏软件

分布式基础概念-消息中间件[RabbitMQ]

派大星

Java 面试题

深度解读 Cascades 查询优化器

KaiwuDB

KaiwuDB Cascades

语音数据集:为AI注入听觉的力量

来自四九城儿

区块链铭文系统开发详情

l8l259l3365

软件测试/测试开发/人工智能丨人工智能是否会取代软件测试工程师

测试人

人工智能 软件测试

3D模型材质丢失怎么办?

3D建模设计

3D渲染 材质贴图 材质编辑

【教程】制作 iOS 推送证书

雪奈椰子

2019 SRE 调查报告:事故处理是主要工作,SRE 压力山大_DevOps & 平台工程_Catchpoint_InfoQ精选文章