关于运维:2020-年-SRE-报告BY-CATCHPOINT

2020 年是不寻常的疫情年，所有行业都受到了微小的影响，SRE 纯分布式工作形式的转型也是本报告的亮点之一。报告从 4 个方面具体介绍了疫情年中 SRE 的众生相。

本报告出自：https://pages.catchpoint.com/2020-sre-report

本文是集体学习的后果，非 Catchpint 官网出品，观点尽量与官网保持一致，但个别中央可能难免会呈现偏差，有任何质疑请参考原文，或者与我交换。

概要

SRE 考察贡献者

Catchpoint 要特别感谢 Sanjeev Sharma、Marc Hornbeek、Archana Joshi 和 Niladri Choudhuri。他们的见解和奉献为整个报告奠定了根底。

咱们还要特别感谢 Nithyanand Mehta。Nith 对于成熟度的外部白皮书为本报告的一些要害谈话点提供了灵感。

感激 Eveline Oehrlich 和 DevOps Institute 的共事。他们的反馈和工夫是至关重要的奉献，超过了本文档所能捕捉到的内容。

反对搭档

如果没有 Blameless、Gremlin、Honeycomb、NS1、LaunchDarkly 和 Packet 这些了不起的合作伙伴，Catchpoint 就 不可能发展本次‘SRE from Home’的考察。

前言

长期以来，人们始终在探讨客户期望值一直进步的恶性循环，认为这是推动在疾速、边缘分布式的环境中提供服务的复杂性一直减少的起因。牢靠的形式。往年，咱们特地思考到在家工作的忽然减少；咱们认为咱们的员工和客户一样散布在世界各地。

咱们真的很感谢大家为 2020 年的 SRE 报告提供数据，这样就有了两组清晰的数据。往年的报告包含“在家工作前“和“在家工作后“两个时间段的调查结果和数据，提供了业界最独特的视角之一，阐明了 2020 年里 SRE 的非凡意义。

咱们评估了 600 多百名考察对象的数据。在剖析数据的同时，咱们心愿能对当今 SRE 先锋们的趋势、现状和面临的挑战进行实在、人性化的察看。

咱们衷心感谢为本报告做出奉献的所有集体，当初咱们也同样感谢您，读者。咱们心愿您能像咱们享受钻研和写作一样，享受浏览的乐趣。

与 Catchpoint 以前的 SRE 报告一样，咱们思考了那些被认定为从事 SRE 类工作的集体的数据，只管头衔可能还没有用到 ” SRE“。

介绍

从 ” 当你要求软件工程师设计一个运维团队时会产生什么？”这个问题登程，将会得出的答案是：”SRE 团队负责其服务的可用性、提早、性能、效率、变更治理、监控、应急响应和容量布局。”如果说 SRE 是狭义的 DevOps 准则的广义施行，那么它们的次要区别就是 SRE 的外围重点是可靠性。

以上述问答为根底，往年的 SRE 2020 报告强调了一个指标，这个指标可能是对于与所有相干从业者的独特指标，无论他们的头衔是什么：通过设计可观测的零碎来避免服务中断，而不是去被动的修复服务中断。让咱们从一个明确的交融点开始，并向后延长，使大型或小型组织都能依据这个 2020 年的基线数据进行自我评估。

如果一个独特的指标是解决简单的问题，那么这个旅程应该是什么样的呢？在一个由边缘计算工作推动的微服务世界中，这个旅程波及到的组件比以前更多了，这些当初须要在在家工作的事实中从新评估这些组件。这包含暴露出那些可能会被忽视，或以前并不存在的畛域。思考诸如士气、员工体验和人类衰弱等问题，与传统的资产类别，如组织构造、工具堆栈、硬件和软件一起思考。

要害要点 1：可观测性组件存在，而可观测性存在么？

找出你所提供的服务在哪里汇聚成了典型的 数字 体验生产点；从那里往后梳理。不仅要思考到你的代码，还要思考到网络、第三方和所有交付链中的组件；从客户的利用体验好坏的角度来评估 可观测性 三个支柱。问本人：“客户的体验是因为那些代码、互联网和网络、第三方或其余交付链组件所形成的？”。

如果咱们提供的能力是通往踊跃业务成绩的门户，那么在当今这个边缘散布、以体验为核心的世界中，简直没有人能够争批驳，通过设计和构建可观测零碎来进行预防是一种必要的能力。

当提出 ” SRE 应用的工具类别是什么？“这个问题时，高达 93% 的人抉择了监控，而 53% 的人抉择了可观测性。当咱们深刻到进一步的指标问题时，一束夺目的光辉向咱们提出了挑战，并邀请咱们对一些监控性的进行深入研究。

• 监控和告警 93%
• 仪表板 73%
• 基础设施作为代码 71%
• 剖析与趋势 56%
• 应用程序公布和部署治理 55%
• APM 代码追踪 53%
• 可观测性 53%
• 平安 47%
• 测试 41%
• 遥测 38%
• 混沌工程 26%
• ITSM 工具 26%
• 价值流治理 10%

如果说可观测性的学术定义是：“依据零碎内部裸露的信息，能够推断出零碎外部工作状态的好坏”，那么咱们在说裸露的时候，肯定要附加一个情境性的定义，通常是只对于 _消费者、客户或者员工的体验_。

考虑一下: 如果一个用户的数字体验由第三方、网络（互联网和外部）、代码和基础设施组成，所有这些因素都汇聚在一个关键点上，就形成了咱们所谓的体验。

而不要拘泥于对于 可观测性 在实际、度量和追踪（三根支柱）的商业定义，谨防将过多的关注点放在 _白盒外部_。

71% 的受访者示意 错误率 是一种他们所跟踪的要害指标。示意客户满意度（数据见下一节）是一个高度优先级，但测量_错误率_而不是_最终用户响应工夫_，将导致继续关注 从内到外 而不是 从外到内 。与其争执各种白盒与黑盒监控实践，不如专一于 了解体验，进而钻研用户体验交付的组件之间的关联性。

贵组织跟踪以下哪些指标？

• 错误率 71%
• 终端用户响应工夫 69%。
• MTTR 60%
• MTTD 42%
• 谬误 / 性能估算 36%

同样值得探讨的是，第三方的关注度或可视性的泛滥。依据 HTTP Archive 的数据，93% 的页面至多包含一个第三方域名；均匀一个页面包含 9 个不同的第三方域名！这阐明，第三方域名的重要性。然而，只有 11% 的受访者示意他们的自动化工作流程扩大到了第三方供应商。

鉴于可观测性的支柱也必须实用于第三方组件，兴许能够了解为什么只关注白盒外部的引力。就像 SRE 致力于设计可观测性零碎是绝对陈腐的一样，应用数字体验监控来揭示第三方零碎，并收集数据也是比拟新的。不过，这里却蕴含着一个黄金机会，能够思考将黑匣数字体验监控延长到第三方。仅仅依附白盒监控意味着你并不知道用户看到了什么，尤其是与第三方无关的状况。例如，无奈加载的页面或无奈导航的应用程序可能是 CDN、传输网络或 DNS 供应商状态不失常的结果。

• 11% 的受访者示意，事件治理的自动化工作流程包含含第三方供应商的所有的工作流程。
• 37% 的受访者认为第三方是导致居家办公时事变减少的起因（仅次于流量 / 容量问题）。

应用了何种仿真监控策略？

• 测试 API
• 测试网络
• 多步骤交易
• 测试 DNS
• 压力测试
• 测试 CDN
• 没用应用

对于仿真用户测试，这里的一个要害指标是，只有 39% 的用户在应用了仿真的多步骤交易来模仿用户体验。

与其余监控特定组件（如 DNS 或 CDN）的用例相比，或与齐全不应用任何仿真监控的受访者相比。

SRE 团队在多大程度上施行了全面的应用程序和基础设施性能监控和告警？

• 监控和告警的自动化水平高。监控零碎足够智能，可能分别是否须要对特定事件收回告警。44%
• 咱们有零碎级的性能监控和主动告警，但没有利用级的。21%
• 咱们能够看到一些利用和零碎的状况，但在一些要害畛域，咱们没有能力监控。20%
• 有的只是实时监控的仪表盘。没有自动化的。12%
• 没有实时监控，值守的团队会收到来自客户反对的人工揭示。4%

89% 的受访者示意他们执行监控流动，44% 的受访者示意监控和告警是高度自动化的。这是个好消息，说明确盒外部思考的周全。但坏消息是，对外部的明确关注导致咱们想当然了，关注数字体验的外在黑盒监控依然被误会。对于这一点，咱们提供了以下观点，供企业在通过设计可观测零碎成熟到预防措施时进行评估。

找出你所提供的服务在哪里汇聚成了典型的 数字 体验生产点；从那里往后梳理。不仅要思考到你的代码，还要思考到网络、第三方和所有交付链中的组件；从客户的利用体验好坏的角度来评估 可观测性 三个支柱。问本人：“客户的体验是因为那些代码、互联网和网络、第三方或其余交付链组件所形成的？”。

在服务层面是否有衰弱监控，以便可能检测到中断或性能问题（在服务层面）？

• 每个服务都有本人的监控和告警，并且有本人的健康检查 API，能够插入到咱们的可观测性框架中。43%
• 有些服务有本人的监控和告警，有健康检查 API，但有些服务却没有。27%
• 每个服务都有本人的监控和告警。没有健康检查 API 或可观测性框架。19%
• 没有服务级监控。9%
• 不实用。咱们的零碎中没有独立的服务。咱们都是单体利用。2%

可观测性就是要答复以前无法回答的问题，因为它与“为什么 ” 无关。“为什么 ” 用户无法访问我的网站？“为什么 ” 用户无法访问本人的数据？“为什么 ” 用户的情绪如此悲观？

答复“为什么 ” 的能力应该由一个框架来驱动，而不是由某个单点工具。这是一个如此重要的指标性问题，咱们提出来作为本节的结尾。如果 43% 的受访者将他们的数据插入可观测性能力框架，那么 57% 的受访者则没有这样做。在下一节中，咱们将通过一些要害的“开发”与“运维 ” 数据来进一步摸索这一差距。

要害要点 2：人肉运维负荷的代价

施行 DevOps 的 SRE 准则，通过设计和构建可观测性的零碎来预防事变。致力将可靠性进一步向左挪动，取得降低成本、团队调整和业务收益等成绩。以开发工作与运维工作各占一半工夫为基准，在运维工作中 On-Call 值守的比例不超过 25%。而后，当你向着预防的最终目标进行治理场景的迭代时，找出制约因素，从而打消束缚点。达成最初成绩以奠定了一个 SRE 团队的根底。当你打消束缚点时，之后相应的更新你的场景。

如果维持零碎的老本有高达 90% 是产生在零碎的部署之后（即向右转移），那么为什么企业还是以操作型、被动式为主的形式来进行？在这本章的这个大节中，咱们探讨了这一问题，并提出企业的 SRE 有机会向左转移，帮忙企业履行所有的工作，并转化为成熟的、可观测性的能力。

Google 倡议应该有一个下限指标，即 50% 的运维工作和 50% 的开发工作（或者称为 ”55 分”）。在现实状况下，运维工作的数量应该比这少得多。运维工作中的 On-Call 局部应该不超过 25%。开发流动与运维流动各占一半工作量的指标仿佛是一个空想。依据考察数据显示，大部分工作都是以运维类流动为主。

SRE 的工作工夫中开发工作的比例占多少

当受访者被问到：“SRE 的工作工夫中开发工作的比例占多少？”这个问题时，只有 14% 的人示意超过 50%。

当被问到基本相同的问题时（但列出具体的抉择让人们抉择），如 ” 在这些流动中哪些流动是 SRE 工作的一部分？“时，后果令人大开眼界。

• 25% : 抉择开发流动（如：开发利用，写有助于运维的软件）
• 75% : 抉择运维流动（如：解决工单，事变响应）

在家工作两个半月后，净增 10% 的受访者示意，他们的流动曾经转变为蕴含更多的运维工作。

居家工作的 Dev vs Ops

在家工作以来，你的工作流动有什么变动？（Dev vs Ops）

• 太多的开发 5%
• 多了一些开发 11%
• 大致相同 57%
• 更多运维 17%
• 太多的运维 9%

在你的组织中，谁在执行 SRE 工作流动？

• 咱们有一个专门的 SRE 团队，独立于其余经营 / 治理团队。46%
• DevOps 团队解决 SRE 流动。19%
• 业务和系统管理小组负责 SRE 流动。16%
• SRE 流动在全组织范畴内发展，而不是局限于一个团队。13%
• SRE 对咱们来说还是个新事物，咱们还不分明这是否须要独自的。7%

如果咱们都在通过设计和施行可观测零碎来进行预防，那么咱们还有很长的路要走。首先，咱们要走的路很长。最重要的是，思考采纳”建设它，就会实现“的办法来革新一个 SRE 组织。首先要从辨认那些作为是 DevOps 的 SRE 工作开始。依据咱们的考察，83% 的人认为本人在做 SRE 流动。不过，咱们揭示大家，你认为正在从事的 SRE 流动，并不意味着你是一个 SRE。这是因为咱们必须将其作为一个整体来思考，而不是将其作为一部分或几块。SRE 团队的定义越来越明确，但跨度也越来越大。在不同的焦点上，的确使 SRE 工作被湮没或暗藏起来。

46% 的人宣称有一个专门的 SRE 团队。然而，53% 的人示意，他们在生命周期的前期才参加其中，因而遇到了挑战，52% 的人示意说他们花了太多工夫排错（稍后再谈）：要害的 SRE 反模式指标。

对事变和问题作出反应是 SRE 生存的一部分。如果咱们从新提出了一个外围指标，即通过设计预防措施来实现可观测零碎，那么旅程的阶段可能是这样的。

被动的 -> 被动的 -> 前瞻 / 预防的

在这种状况下，咱们问 SRE 们都进行哪些被动性流动。在这一问题上，咱们问道：”SRE 从事哪些被动流动？这里的目标是帮忙确定公司可能在哪些方面开始成熟起来。依据本人的业务和组织的背景，从被动到被动。

从每一个问题的后果来看，预先回顾和应答零碎产生的告警别离名落孙山。然而，读者查看这些后果的另一种办法，是将他们分类看。而后判断你是否应该在某个分类上更成熟。例如，如果预先回顾类型与剖析包含 SLI 和 SLO 在内的度量指标有重叠，而后再思考是否能够将整体剖析作为预防之路的终点。

在你的组织内，SRE 参加了哪些“被动“流动？

• 通过打算的流动对问题进行预先剖析。80%
• 响应系统生成的告警信息 75%
• 剖析指标，包含 SLI、SLO、SLA 等指标 72%
• 文档记录所获的常识 69%
• 基础设施问题的培修 68%
• On-Call 轮值 68%
• 审查并回应客户报告的反对工单 58%
• 个别行政工作（如进度报告、内务治理）49%
• 重现客户报告的问题 47%
• 为客户装置、配置和 / 或调试应用程序。41%

如果没有人在做救火的反馈，那么咱们能够认为咱们所做的一切都是被动的。与其孤立地答辩一项流动的性质，不如转移话题，发问 ” 咱们这样做能避免什么事件产生？”。这样，在探讨 SRE 章程是什么样子的时候，对话就能够转向基于后果的形式。现实状况下，咱们心愿将服务运维优化到不再须要继续的人力工作的水平，这样 SRE 团队就能够专一于高价值的流动。

你在哪些“被动 ” 流动上破费了适度或大量的工夫？

• 自动化工作，使其无需手动执行。61%
• 监控和剖析零碎指标，以发现可能导致将来呈现故障或 SLA 问题的趋势。56%
• 反对部署后口头 54%
• SRE 专用零碎布局 53%
• 编写优化运维操作的软件 48%
• 与开发部门单干，帮忙开发应用程序 42%
• 零碎的预防性保护 41%
• 容量布局流动 38%
• 通过混沌工程等实际进行弹性查看。19%

作为 SRE 工作的一部分，SRE 要做哪些流动？

• 监控 89%
• 事变响应 / 故障单和解决降级问题 83%
• 指标剖析 78%
• 帮忙基础设施和业务能力布局的致力 74%
• 与开发部门单干，帮忙他们开发应用程序 74%
• 记录所获常识 71%
• 编写软件帮忙操作 65%
• 质量保证测试和公布 30%

当去掉被动或被动的限定词，问”SRE 在这些流动中，哪些是作为 SRE 工作的一部分 ” 时，咱们看到监控和事变治理被列为首要流动。同样重要的是，编写优化运维操作的软件被排在第五位。牢记开发应该是最次要的流动类型（绝对于运维），思考是什么起因导致了目前的状态。

• 章程是否不正确或不存在？
• 是否没有思考到 SRE 准则的必要性？
• 是否没有评估以客户为核心提供服务的办法？
• 还能问什么？接着问 ” 为什么”？

一旦 SRE 的工作和价值失去认可，就能够开始失去回报。为了帮忙取得反对，将对话与某种业务背景分割起来。例如，当可靠性被提前思考而不是推延思考时，就会升高零碎的领有老本。让一个牢靠的零碎，更加牢靠要容易得多。

将谈话的重点放在解决简单问题和实现业务指标的能源和欲望上；将这一数据点作为基线。

您如何思考 SRE 和 DevOps 团队的关系？

• 41% 的人说 DevOps 和 SRE 是同一个团队的一部分。
• 26% 的人说 DevOps 和 SRE 是互补的。
• 19% 示意不晓得
• 11% 示意二者是竞争关系

在度量变更的业务影响方面，这些指标各有多重要？

• 客户满意度降落 82%
• 支出损失 79%
• 客户散失 79%
• 雇员生产力降落 69%
• 社交媒体的吐槽 59%

侥幸的是，考察对象可能说明如何从业务角度掂量胜利。

修炼能力是取得正向业务成绩的通道。当进行 ” 咱们为什么须要 SRE“的对话时，不要只谈能力或只谈踊跃的后果。相同，要将它们联合起来，说 ” 这些能力将帮忙咱们实现这些后果”。

有多少个专职与 SRE 流动的团队成员？

在本节完结时，有一个微小的机会，能够在晚期阶段将被动的业务工作向左移。从 ” 不仅仅是帮忙开发”，而是 ” 从工作后果中获取反馈，并将其作为一种投资，用于帮忙构建 / 晋升产品或服务的可观测性”。例如，在 SRE 拿起那个传呼机后（开始 OnCall 工作），他们所记录的注意事项，可能会引领导下一波服务的开发工作，以防止落入雷同的坑。

咱们最初的想法是，SRE 参加整体生命周期的想法实用于任何组织的规模。换句话说，旅程的各个阶段还是一样的。

施行 DevOps 的 SRE 准则，通过设计和构建可观测性的零碎来预防事变。致力将可靠性进一步向左挪动，取得降低成本、团队调整和业务收益等成绩。以开发工作与运维工作各占一半工夫为基准，在运维工作中 On-Call 值守的比例不超过 25%。而后，当你向着预防的最终目标进行治理场景的迭代时，找出制约因素，从而打消束缚点。达成最初成绩以奠定了一个 SRE 团队的根底。当你打消束缚点时，之后相应的更新你的场景。

要害要点 3：近程工作转型带来了时机和挑战

将新呈现的或以前被忽视的挑战转化为策略上差异化的机会。关注士气、员工体验、工作 / 生存均衡、员工参与度和情绪等挑战，能够展现公司员工至上的心态，吸引或留住顶尖人才。

任何其余头衔的 SRE 依然会发明商业价值。然而，企业是否器重他们的 SRE 呢？

如果说，“正确对待你的员工，他们就会正确对待你的客户“只是一句座右铭，那么当初愿它成为你的战斗口号。

在 SRE 2020 考察问卷的一组无关在家工作前的问题中，受访者指出了他们面临的一些要害挑战。而后，在两个半月的在家工作后，又有更多的挑战浮出了水面。

这包含以前可能被忽视的挑战，或者对一些人来说不存在的挑战，它们都浮出了水面。诸如士气、员工体验、工作 / 生存均衡、员工参与度和情绪等挑战；当初企业有机会将其转化为战略性的差异化资产了，公司展现出员工至上的心态。换句话说，如果说“正确对待你的员工，他们就会正确对待你的客户 ” 这句话，在以前只是一句座右铭，那么当初愿它成为一个战斗口号。

居家工作之前

哪些问题具备肯定或极强的挑战性？

• 经常在生命周期前期参加 53%
• 调试工夫过长 52%
• 不足其余团队的反对 47%
• 培训估算有余 46%
• 监控技术过于耗时 45%
• 在非办公时间常常提供反对 39%
• 工作压力过大，不足反对 38%
• 工具估算有余 36%

居家工作之后

‘在家’后，你面临着哪些问题？

• 工作 / 生存均衡 60%
• 团队沟通 56%
• 重点 / 清晰度 51%
• 设施，包含设施和宽带 42%
• 隔离 / 激励 41%
• 激励 39%
• 心理健康、压力或情绪衰弱 37%；
• 工具技术栈 23%
• 界定胜利指标 22%
• On-Call 值守 12%
• 其余 7%

“在这段经验中，我发现我发现：每天在家带孩子是压力最大的局部。一般来说，放弃工作与生存的均衡是很艰难的，但当你常常失去注意力时，很难不感觉本人和其他人是一样的致力工作（即便你的公司是反对你的）。”
– 受访者反馈

在咱们 2019 年的 SRE 报告中，得分高的 琐事泛滥 是最重大的，59% 的受访者认为组织中的琐事太多。在咱们的 SRE 2020 报告中，咱们从新验证了这一发现，并扩大到按分布式的数据模式展现。

SRE 的工作有百分之多少是琐事？

SRE 的工作有百分之多少是琐事？

41% 的受访者示意，他们的工作有一半或更多是琐事。思考到：1）高琐事率 2）附加问题中 60% 的受访者将工作 / 生存均衡列为在家工作后的头等挑战，咱们倡议企业从策略上思考升高职业倦怠（透支 /996）的计划。

在此，咱们将琐事（自身可能正是人们时常须要的精力激活剂）与倦怠（咱们要防止的后果）辨别开来。

一个组织在解决大量的工作时，要思考到不足自动化的根本原因。如果论断是因为不足技能或人力，那么后退的路线可能会与长期积攒的大量技术债权不同。

如果团队的指标统一，或者优先级统一，那么自动化能力是否能够扩充？首先梳理开发 + 运维是否有根本性的缺失？最起码，在 ” 开发 ” 与 ” 运维 ” 工夫各占一半的状况下，要有一个基准线，以理解工作量的差距。而后，与管理者对话，使团队有一个正当的冀望；而不是，例如，感觉他们应该做到‘零运维’的工作。

SRE 的琐事次要起源是那些？

• 能够自动化的人工保护工作 29%
• 对于可自动化的应用程序公布的工作 19%
• 能够自动化的人工值守工作 18%
• 解决假阳性 / 阴性问题 16%
• 非紧急服务相干信息 13%
• 解决与服务无关的信息 12%

应用自动化进行自修复的问题和事件的百分比是多少？

45% 的人说监控技术太耗时。这是一个机会，能够通过可观测性能力将重点放在预防措施上，同时还能够扩大到应用软件（而不是人）来解释数据，并判断是否须要采取行动。与其生成告警，再要求人来决定是否须要采取行动，到不如只在应该由人采取行动的时候，才触发告警。而后让零碎理论执行口头。

为了帮忙企业实现这种向可操作性告警方向转变，咱们说：“你不可能对所有的事件都进行监控和告警，所以先从最重要的事件：开始对‘用户体验’监控和告警”。在这种状况下，各种人工智能 (“AI”) 或机器学习 (“ML”) 能力才可能会有用武之地。

16% 的人认为解决假阳性 / 阴性是一个次要的苦恼起源。

您是否应用自动化工具进行容量布局和制备？

• 手工容量布局 + 自动化制备
• 手工制备 + 自动化容量布局
• 容量布局和制备都是手工的
• 是的，容量布局和制备都是自动化的
• 容量布局依据估算周期或者是否解冻走

看到这个数据，咱们有些诧异。在咱们的 2018 年 SRE 报告中，65% 的受访者示意，他们全副或局部应用云计算。咱们预计这个数字从那时起就会减少（只管咱们往年没有明确提出这个问题）。随着云提供的各种性能，包含各种“个性 / 函数即服务”，咱们对评估什么是可自动化的，以缩小琐事和随后的透支的倡议依然是雷同的：当在剖析组织中为何存在大量琐事时，不足自动化解决方案，最可能被认为是根本原因。那如果得出的根因论断却是：技能或能力的欠缺呢？那么在后方的路线上，可能就不会在长期的积攒大量技术债权了。

您的 SRE 团队成员有哪些培训和认证？

• 外部辅导和培训计划 78%
• 云厂商认证（如 AWS，GCP，Azure）51%
• 工具厂商的培训或非凡工具 40%
• 集体或者团队加入第三方 DevOps 课程 29%
• 集体或者团队加入第三方 SRE 课程 24%
• 集体或者团队加入第三方 ITILv3 课程 16%

不足估算和培训（来自后面的挑战清单），再加上大量的琐事，就会导致透支。正如咱们增编问题的数据所显示的那样，这些问题更加重大，工作 / 生存均衡（60%）和专一 / 清晰（51%）是在家工作之后，对于‘幸福感’（well-bing）的两个最高挑战。

外部辅导和培训是之间存在着关联性的计划 (78%)，但对 SRE 培训的估算有余。这表明 外部打算 可能不那么无效。该数据也让咱们不得不问，是否调试工夫过长（52%）？是因为培训在这里也是一个空白。既然外部培训是最次要的培训形式，那么就要看这些我的项目的成果。培训教练或团队首领是否是该畛域的专家？这是否是一个挑战？心愿做外部培训是否是没有估算的间接结果？牢记咱们的欲望是：让员工进步工作效率，那么深刻的 SRE 培训 和扎实的了解 SRE 角色是必不可少的，通过设计和施行零碎的可观测性，来施行预防措施的路线图。

咱们还是将 不足工具估算的问题 也纳入了培训的这一章节，因为不足估算是两者之间的独特主题。可怜的是，员工生产力降落的指标，是商业影响的第二低指标，因而投资于培训可能是应该开始做了。

在 2019 年的 SRE 报告中，琐事和压力是首当其冲的焦点。咱们可能用的是一些预期的反馈来考察。

你在家后面临哪些心理 / 集体幸福感的挑战？

• 工作 / 生存均衡 60%
• 专一 / 清晰 51%
• 隔离 41%
• 能源 39%
• 精力衰弱、压力或情感幸福感 37%
• 其它 2%

以上问题的解决思路包含：

• 应用自动化打消琐事
• 通过无职责文化，打消事变回顾的压力
• 通过可观测性的能力转换到被动度量，在基本上缩小事件

大多数组织的强制在家工作的政策，都凸显了更加关注员工的幸福感的必要性。当读者看到这个对于在家的数据集时，请问：“这个数据集的论断，如何使年初考察数据的论断变得更好或更坏？”。例如，那些感觉到被隔离的人，在之前，他们会感觉沟通或不足反对是问题么？会对其有什么影响？他们会不会可能感到失去了更多或更少的反对？

将新呈现的，或以前被忽视的挑战转化为策略上的差异化机会。关注士气、员工体验、工作 / 生存均衡、员工参与度和情绪等挑战，能够展现公司员工至上的心态，以吸引或留住顶尖人才。

要害要点 4：近程 SRE 光明的将来

从新评估各种业务连续性计划。思考是否须要调整 复原工夫 和复原工夫点。在进行劫难或连续性演习时，确定当初能够施行预防措施的机会畛域。在您的 SRE 章程中记录任何新的洞见。

在咱们的 SRE 2018 年考察中，按《纽约时报》的格调，这个题目是这样说的。

“如果你想近程工作，SRE 角色可能不适宜你。尽管有些 SRE 是近程工作的，但 81% 的 SRE 示意，他们团队的所有或大部分工作都在办公室里进行的。”

咱们想到的第一个问题是：“当世界从新凋谢时，你的员工中，有百分之多少会首选 ” 近程 / 在家办公”（有多少比例的人的主要抉择是 ” 现场 / 办公室”）？”在一个异步、世事纷纷的时代，这个数据可能不会让你感到诧异。

预期近程工作人员的百分比

思考到从全员现场、到分布式劳动力的转变，咱们心愿进一步钻研其余变动因素，为决策者提供一个投资方向。须要应答哪些新的挑战？事件治理 是什么样的？如果没有了办公桌，将如何运行他们的劫难复原桌面演习？

咱们不想在说 ” 近程 SRE 的将来很边远 ” 的时候，做出 ” 水很深“式的说法。而是说，近程 SRE 的将来是光明的，但也要留神以下几点。

“小学教师工资发的不够……”–考察对象

牢记本报告之前对于 心愿通过设计和施行可察看零碎 来预防事变的评论。而后思考这些间接、宏观的问题，对你的 SRE 章程有什么影响。

主动式与被动式相比（向更多的被动式净增 2%）没有开发与运维相比（向更多的运维净增 10%）的差距那么大。在这里，咱们再次参考在家工作前的数据，表明 75% 的受访者在做运维流动（而 25% 在做开发流动）。

自从“在家工作“后，你的流动有什么变动？(被动与被动)

• 太多被动了 4%
• 被动多些 14%
• 基本一致 60%
• 有点被动 16%
• 太被动了 4%

自从“在家工作“后，你的流动有什么变动？(开发与运维)

• 太多开发了 5%
• 开发多了一些 11%
• 差不多持平 57%
• 运维多了一些 17%
• 太多运维了 9%

咱们想理解事件的相对数量以及绝对数量（下一页）。须要揭示的是，“在家工作后 ” 这组考察问题，在家工作的两个半月后提出的。

在家后，你负责的站点或利用经验的事变更多 / 少吗？

• 无 / 零 17%
• 1 次 9%
• 2~5 次 42%
• 6~10 次 11%
• 要多得多 21%

对于，“自家工作以来，产生的事件多还是少”，数据造成了一条正态分布的钟形曲线。不过，在这个问题中，最突出的是 7% 的人不晓得!

在家后，你所负责的站点或利用经验了更多 / 少的事变

• 更少 9%
• 差不多雷同 73%
• 更多事变 9%
• 不晓得 7%

• 流量增长和 / 或容量问题 54%
• 第三方问题 37%
• 公布治理相干变更 25%
• 测试和品质管制 25%
• 平安 4%
• 其它 16%

流量和 (或) 容量问题的减少被认为是导致事变减少的首要因素。第三方 被认为是第二大因素，这也是为什么，咱们在本报告的第一局部中，探讨了有必要思考如何解决第三方依赖的策略。

咱们想指出，只有那些示意自从在家工作后产生更多事变的受訪者们，才被问及这个问题。但咱们想把数据包含在内，思考到渎职。

净 +9% 的受访者示意，自从在家之后，事件治理变得更加无效。这是一个令人振奋的数据，咱们不晓得更好的事件治理是否与公司做更少的公布无关（依据 Atlassian 的这个数据，66% 的受访者曾经加快了他们软件的公布频率) 留神 14% 的受访者抉择了 无奈评估 和辨认机会，看看是否是因为在家的起因。

请评估贵公司自 ” 在家 ” 以来事变治理流程的有效性

• “在家“时，成果较差（MTTR 较高）5%。
• 大概雷同的 MTTR 66%
• “在家 ” 时更无效(MTTR 较低) 14%。
• 无奈评估 14%

咱们在“在家后”考察中问的最初一个间接问题是：“你或你团队中的任何人，是否不得不去现场？”对于答复 ” 是 ” 这个问题的 14% 的人，咱们后续的开放式问题：“有多少次？他们的答案各种都有，有总是和每班一个人（跟着太阳走）的，有只有一次和每两周一次的。

从’在家’开始，你有没有不得不去现场过？

• 是的 14%
• 不是 86%

‘在家’后，事变治理在哪些方面变得更具挑战性？

• 检测事变产生 / 宕机 9%
• 查明事变根本原因 9%
• 向正确的团队降级 28%
• 修复根因 8%
• 验证修复是否胜利 13%。
• 以上的都不是 51%

在咱们致力完结往年的报告之际，咱们提供最初一个数据点。公司从新评估他们将如何持续经营。咱们问道：“你们多久执行一次针对在家场景的劫难复原演练”当你思考到你的各种复原工夫可能是如何 受影响的状况下，思考到以前的门路，到预防性的座右铭，因而你要致力设计和施行零碎的可察看的问题。

你们多久执行一次针对在家场景的劫难复原演练？

• 齐全没有 40%
• 还没有；咱们正在打算 26%
• 随机 19%
• 每月 5%
• 每周 5%
• 其它 5%

可观测性是指可能答复 ” 为什么咱们客户体验到了这个成果？”是不是因为第三方，利用代码、传输网络或其余交付链中的组件，如 DNS 或 CDN？而后应用这些答案来迭代改良现有的，或新建的产品或服务。

当 ” 内建 ” 可靠性时，要思考到开发和运维之间的决裂。在您制订 SRE 章程时，您能够将其与业务工作进行比拟。这里的指标是：尽早将可靠性纳入其中，因为晋升一个曾经靠谱了的零碎，还是要来的要更容易些。

最初，思考到您的员工队伍的散布性质，并抵赖可能被忽视或被忽视的一系列挑战。无论存在与否，都要思考到诸如，琐事、不足反对、工作 / 生存均衡，以及，孤独感可能会导致的某些操作规定或流程被勾销，都要从根上从新进行评估。

方法论

2020 年 1 月，Catchpoint 进行了一项通过电子邮件列表和社交媒体推广的 SRE 考察。该考察询问了来自不同行业的技术业余人员，考察对于他们作为 站点可靠性工程师 SRE 角色。通过报告，这组问题被称为 ” 事后 ” 问题集。

2020 年 6 月，Catchpoint 又进行了一项增补考察，退出了对于新冠疫情（COVID 19）后，居家办公的思考。这组问题旨在询问各种 ” 产生了什么变动 ” 的问题，被称为 ” 后疫情 ” 或 ” 在家“问题集。

在编写本报告时，收到了共有 594 名考察对象的反馈。在预约的工夫里，其它人在格式化本报告和编写附录的过程中在也络绎不绝，统计周期的只对本报告的统计数字产生了较小的影响，不超过 1%。