写点什么

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:445117
用户头像
张婵 InfoQ 技术编辑

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

关注

评论

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

TracedModule: 更友好的模型表示方案,模型训练到部署的桥梁

MegEngineBot

深度学习 开源 MegEngine 模型训练到部署

直播|镜舟 x Smartbi《后疫情下如何利用数据驱动企业逆势破局》

镜舟科技

数据库 镜舟数据库

稳定支撑千万级月活,华为日历背后的英雄

华为云开发者联盟

数据库 后端 华为云 企业号 1 月 PK 榜

SLS:基于 OTel 的移动端全链路 Trace 建设思考和实践

阿里巴巴终端技术

数据采集 Trace 移动端

Mega 改进序列模型,引入移动平均捕捉时空依赖

Zilliz

计算机视觉

YonBuilder 应用构建教程之移动端扩展

YonBuilder低代码开发平台

【深入浅出Spring原理及实战】「源码调试分析」结合DataSourceRegister深入分析ImportBeanDefinitionRegistrar的源码运作流程

码界西柚

spring Spring Framework

软件测试/测试开发丨接口测试经典面试题:Session、cookie、token有什么区别?

测试人

软件测试 自动化测试 接口测试 测试开发

【iOS逆向与安全】系统推送服务(APNS)拦截

小陈

安卓 ios开发 逆向 iOS逆向 ios安全

报告下载 | DQMIS高端闭门论坛成果报告——《2022第六届数据质量管理国际峰会关于数据要素发展几点看法和建议》

数据质量管理智库

数据 数据治理 数据安全 隐私计算 数据要素

逃不开的安迪-比尔定律,在智能机器人时代该如何破解?

优必选科技

人工智能 机器人 视觉处理

FL Studio2024中文版水果电音舞曲制作软件

茶色酒

FL Studio21 FL Studio2024

架构实战营 - 模块 4- 作业

zealot0317

软件测试/测试开发 | 接口测试常用代理工具

测试人

软件测试 自动化测试 接口测试 charles 测试开发

ChatGPT中文版重装上阵

felix

openai ChatGPT AIMODELMARKET

合作升级|Kyligence 跬智智能分析平台入选华为云联营商品

Kyligence

数据分析

用无线控制LED显示屏的10个特点

Dylan

LED显示屏 全彩LED显示屏 led显示屏厂家

软件测试/测试开发 | 如何模拟真实使用场景?mock 技术来帮你

测试人

软件测试 自动化测试 接口测试 测试开发 Mock

从指标到洞察力的普罗米修斯

宋小生

Prometheus 普罗米修斯 普罗米修斯监控

又一重要进展发布!OpenMMLab算法仓支持昇腾AI训练加速

华为云开发者联盟

人工智能 华为云 昇腾AI 企业号 1 月 PK 榜

web 3d的开发技术方案选型

好孩子

web3d

书单 | 春节假期,我想把这几本书带回家!

博文视点Broadview

软件测试/测试开发 | 接口测试之HTTP 协议讲解

测试人

软件测试 HTTP 自动化测试 接口测试 测试开发

java 本地应用程序加载与修改properties配置文件

JefferLiu

震网(Stuxnet)病毒深度解析:首个攻击真实世界基础设施的病毒

华为云开发者联盟

安全 后端 华为云 企业号 1 月 PK 榜 震网

百度安全入选权威报告《联邦学习与可信AI市场机会分析》典型厂商

百度安全

软件测试/测试开发 | 接口测试之HTTP、HTTPS 抓包分析

测试人

https 软件测试 HTTP 自动化测试 测试开发

使用“宝塔一键迁移”工具,将单机版typecho博客系统迁移到京东云cvm云主机

京东科技开发者

服务器 京东云 安装宝塔 云迁移 企业号 1 月 PK 榜

logback 默认配置文件

JefferLiu

MYSQL数据库主从配置

Jackey

MySQL 数据库

[原生1v1视频源码]社交市场趋于饱和,出海成为1v1语聊平台的新选择

山东布谷科技胡月

社交APP出海 视频社交APP开发 1v1交友app开发 一对一视频语音系统搭建

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