QCon北京|3天沉浸式学习,跳出信息茧房。 了解详情
写点什么

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

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

关注

评论

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

SpringCloud-Hystrix服务熔断与降级工作原理&源码 | 京东物流技术团队

京东科技开发者

SpringCloud Hystrix 熔断降级 企业号 8 月 PK 榜

【PCSD考试笔记】

TiDB 社区干货传送门

TiDB 底层架构

绍兴市属于哪个省?是几线城市?有正规等保测评机构吗?

行云管家

等保 等级保护 等保测评 绍兴

【华秋推荐】物联网入门学习模块 ESP8266

华秋电子

物联网

JDK1.6在生产环境引起的坑

华为云开发者联盟

开发 华为云 华为云开发者联盟 企业号 8 月 PK 榜

合合信息与科瑞物业达成合作,数字名片提供企业数智化转型新机遇

合合技术团队

人工智能 合作 数字名片

关于搭建海外社交APP源码的干货

山东布谷网络科技

海外直播源码

一种新的告警收敛方式“先知预警”,为您的系统健康护航 | 京东云技术团队

京东科技开发者

系统稳定性 预警监控 企业号 8 月 PK 榜

入门级教程:使用Flask进行Python Web开发

Apifox

flask 后端 web开发 Python编程 Python Web框架

@ControllerAdvice注解使用及原理探究 | 京东物流技术团队

京东科技开发者

spring 注解 源码解析 企业号 8 月 PK 榜 @ControllerAdvice

从生态的角度看容器和虚拟化的区别

品高云计算

易点天下KreadoAI正式上架亚马逊云科技Marketplace全球商业化加速落地

新消费日报

华秋亮相2023世界汽车制造技术暨智能装备博览会,推动汽车产业快速发展

华秋电子

Duplicate File Finder Pro for mac(重复文件查找) 7.1.3中文版

mac

苹果mac Duplicate File Finder 查找删除重复文件

物理机是什么?有什么优势?可以上堡垒机吗?

行云管家

等保 堡垒机 等级保护 物理机

如何规划税务数智化建设

用友BIP

税务管理

通过docker安装单机版minio简单测试br通过s3存储备份恢复数据

TiDB 社区干货传送门

备份 & 恢复

数据库内核之Binder

MatrixOrigin

分布式数据库 云原生数据库 MatrixOrigin MatrixOne 超融合数据库

如何判断线程池任务执行完?

王磊

java面试

如何在数据库迁移中保证数据一致性?

java易二三

MySQL 数据库 编程 计算机

合合信息通过ISO/IEC国际标准双认证,为全球用户提供高合规标准AI服务

合合技术团队

人工智能 数据安全 个人信息保护

TiProxy 原理和实现

TiDB 社区干货传送门

新版本/特性发布 TiDB 源码解读 6.x 实践 TiKV 源码解读

【SOP】最佳实践之 TiDB 业务写变慢分析

TiDB 社区干货传送门

性能调优 管理与运维 故障排查/诊断 应用适配

基于Web3D+GIS智慧森林防火监测预警系统

2D3D前端可视化开发

智慧森林防火 森林火灾预警系统 森林火灾监测系统 森林数字防火 森林智能防火

创新赛制,顶尖赛题!| 2023第二届粤港澳大湾区(黄埔)国际算法算例大赛十赛道虚位以待!

ModelWhale

人工智能 深度学习 数据竞赛 琶洲 粤港澳大湾区

TiDB 多集群告警监控-初章-监控融合、自动告警处理

TiDB 社区干货传送门

监控 实践案例 集群管理

TiProxy 尝鲜

TiDB 社区干货传送门

实践案例 6.x 实践

TiDB 优雅关闭

TiDB 社区干货传送门

TiDB 源码解读 6.x 实践

火山引擎DataLeap:更强数据目录搜索能力,做到一步找数

字节跳动数据平台

大数据 数据中台 数据研发 企业号 8 月 PK 榜

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