QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

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

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

关注

评论

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

湖南长沙正规等保机构名单以及地址看这里!

行云管家

等保 等保测评 长沙

人工智能 | 文生图大模型

测吧(北京)科技有限公司

测试

压力测试,探索服务器性能瓶颈

测试人

软件测试

解析Go切片:为何按值传递时会发生改变?|得物技术

得物技术

golang 扩容 切片

【教程】第二章:设计任务管理系统 —— 胸有成竹,步步为营

NocoBase

开源 低代码 教程 无代码

8+ 典型分析场景,25+ 标杆案例,Apache Doris 和 SelectDB 精选案例集(2024版)电子版上线

SelectDB

数据库 数据分析 经验分享 大数据 开源 案例集

【等保小知识】等保测评等级从高到低怎么排序?

行云管家

等保 等级保护 等保测评

Sentieon软件快速入门指南

INSVAST

基因数据分析 生信服务 Sentieon

MongoDB面试专题33道解析

威哥爱编程

数据库 mongodb 面试

探索电商平台API接入的多样路径

代码忍者

API 接口 pinduoduo API

JAVA 应用实现 APM 自动注入(主机篇)

观测云

Java

GreptimeDB 首位独立 Committer Eugene Tolbakov 是怎样炼成的?

Greptime 格睿科技

开源 时序数据库

阿里云 DataWorks 正式支持 SelectDB & Apache Doris 数据源,实现 MySQL 整库实时同步

SelectDB

数据库 大数据 数据分析 数据迁移 整库同步

怎么自动保存ppt?3个必备的ppt使用技巧分享!

职场工具箱

人工智能 效率工具 办公软件 AIGC AI生成PPT

主机上云,八仙过海?!

白洞计划

AI

万字长文2024最全Go面经汇总

王中阳Go

Go 面经 大厂

制作并量化GGUF模型上传到HuggingFace和ModelScope

GPUStack

大模型 ModelScope LLM huggingface GGUF

启信宝产业洞察:广东领跑低空经济,无人机产业强势崛起

合合技术团队

人工智能 算法 无人机 科技

南开大学携手和鲸科技,以 AI 赋能交叉学科人才培养与课程建设

ModelWhale

Python 人工智能 新文科 南开大学

Reviewbot 开源 | 为什么我们要打造自己的代码审查服务?

大卡尔

DevOps Code Review 工程实践 静态代码检查

香港 Web3 一周大事记: 香港财政司司长表示,年内有望再发出多个虚拟资产交易平台牌照

TechubNews

在后LLM时代,关于新一代智能体的思考

澜舟孟子开源社区

人工智能 智能体 大模型

RK品牌双十一狂欢,高颜值低延迟键盘超值体验!

科技热闻

高性能日志结构化引擎 — GreptimeDB Piepline 设计与实现技术揭秘

Greptime 格睿科技

时序数据库 日志储存 日志引擎

《深入浅出Apache Spark》系列③:Spark SQL解析层优化策略与案例解析

数新网络官方账号

sql 大数据

【JIT/极态云】技术文档--模型简介

武汉万云网络科技有限公司

低代码 开发工具

Grafana GreptimeDB 数据源插件上线啦,全面替代 Prometheus 插件

Greptime 格睿科技

Grafana 时序数据库 Promethues

鸿蒙接入Flutter3.22

龙儿筝

GeoAI驱动土地价值重塑!中国地质大学(武汉)&和鲸社区Workshop圆满结束!

ModelWhale

Workshop 地球科学 geoai 遥感数据

制作并量化GGUF模型上传到HuggingFace和ModelScope

SEAL安全

大模型 ModelScope LLM huggingface GGUF

王慧文回归带队美团探索 AI 应用;对话音频开源模型 Hertz-dev:120 毫秒超低延迟丨 RTE 开发者日报

声网

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