2019 SRE 调查报告：事故处理是主要工作，SRE 压力山大                 
2019-04-02 15:38         来源:高效开发运维

原标题：2019 SRE 调查报告：事故处理是主要工作，SRE 压力山大

来源 | Catchpoint 发布的 2019 SRE Report
编辑 | 张婵
尽管 SRE 的概念提出有 15 年了，SRE 实践仍然处于初始阶段。调查结果显示，事故处理占据 了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 们是否也如此亚历山大？欢迎大家留言交流。
经过 AI 的洗礼，目前运维走向了精细化运维方向，需要更深入的分析数据，提升系统性能，利用机器学习技术对大规模流量数据进行监控，稳定支持应用。7 月深圳 ArchSummit 架构师峰会，来了解阿里云是如何炉火纯青应用这些技术的。

2019 SRE 调查报告：事故处理是主要工作，SRE 压力山大                 
2019-04-02 15:38         来源:高效开发运维

原标题：2019 SRE 调查报告：事故处理是主要工作，SRE 压力山大

来源 | Catchpoint 发布的 2019 SRE Report
编辑 | 张婵
尽管 SRE 的概念提出有 15 年了，SRE 实践仍然处于初始阶段。调查结果显示，事故处理占据 了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 们是否也如此亚历山大？欢迎大家留言交流。
经过 AI 的洗礼，目前运维走向了精细化运维方向，需要更深入的分析数据，提升系统性能，利用机器学习技术对大规模流量数据进行监控，稳定支持应用。7 月深圳 ArchSummit 架构师峰会，来了解阿里云是如何炉火纯青应用这些技术的。