二零二零站点可靠性工程报告 9
P16关键要点2：成本带来了沉重的操作负担
谁在您的组织中执行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组织。通过识别DevOps SRE的工作来启动。根据我们的调查，83%的人被认定为从事SRE活动。不过，我们要提醒的是，认定为从事SRE活动并不意味着成为SRE。因为我们必须从整体而不是部分进行考虑。SRE团队正被更明确地定义着，但跨越不同的焦点确实令SRE工作被掩藏或隐藏。
46%的人声称有一个专门的SRE团队。然而，53%的人说他们在生命周期的后期受到了挑战，52%的人说他们花了太多的时间调试（在这之后还需要更多的时间）：关键的反SRE指标。
P17
关键要点2：成本带来了沉重的操作负担
对事件和问题做出反应是SRE生命的一部分。如果我们通过可观察系统的设计重新提出预防的核心目标，那么旅程的阶段可能看起来像这样：
被动式主动预防
因此，我们问SRE执行被动式活动的功能。目的是根据业务和组织的被动式来帮助公司确定从被动式到积极主动的成熟位置。
查看每个订单项结果，事后反思分析和对系统生成的警报的响应分别为1和2。但是，让读者查看这些结果的另一种方法是将一些响应归为一类，然后确定是否应该使给定的类别与给定的订单项成熟。例如，如果事后反思上的分析类型与包括SLI和SLO在内的指标的分析类型重叠，则应考虑是否可以将整体分析作为预防手段的起点。
------
被动响应事件和问题是SRE生活的一部分。如果我们重新引入一个核心目标，即通过设计可观察系统以进行预防，那么旅程的阶段可能如下：
在这方面，我们询问SRE执行哪些响应活动。目的是根据公司的业务和组织环境，帮助确定公司从被动响应到主动行动的成熟过程。
查看每行调查结果，事后分析和对系统生成的警报的响应分别居于1和2。然而，读者查看这些结果的另一种方法是将一些响应分类，然后决定是否应提升特定调查项所相对的特定分类的成熟度。例如，若事后分析的类型与包括SLI和SLO在内度量的分析类型重叠，那么考虑是否可以将整体分析作为预防路径的起点。
SRE在您的组织中使用哪个“被动式”活动？
事后反思通过计划的活动分析问题80％
响应系统生成的告警消息75％
分析指标，包括SLI，SLO，SLA 72％
文件知识增加69％
修复基础设施问题68％
通话轮换68％
评审并回复客户报告的支持票58％
一般管理任务（例如进度报告，内务管理）49％
重现客户报告的问题47％
为客户安装，配置和/或调试应用程序41％
页:
[1]