什么是上报政策？

核心要点：上报策略定义在触发事件警报时通知谁，如果第一响应者不能就位或无法解决事件，事件将转交给谁，以及这些交接如何进行，通常根据严重性、持续时间和范围而有所不同。

• 定义：一套成文的流程，通常记录在上报矩阵中，使用三种类型的上报：层级上报（按职级）、职能上报（按专业能力）和自动上报（按规则，当警报未及时确认时触发）。

• 重要意义：若没有上报策略，事件处置会因人员确认对接对象而停滞；具备该策略时，合适的响应者可在数分钟内介入，同时不会出现因无关事项呼叫相关人员的情况。

• Jira Service Management 的作用：其待命值班表和警报功能让团队能够按服务和严重性定义上报规则，自动上报未确认的警报，并在事件记录内进行上报，以便跟踪每一次交接。

上报策略是一套成文的计划，规定当第一个收到事件警报的人员无法单独处理时该如何应对：先通知谁，如果该人员不能就位或无法解决事件由谁接管，交接的速度有多快，以及通过哪个渠道。它与待命值班表互为配套：值班表明确在岗人员，上报策略规定事件如何在这些人员之间流转。

理想情况是待命工程师可独立解决事件。但当问题处置需要更大团队、专业知识或更高阶技能时，往往……只要组织拥有数名以上技术人员，就应当具备上报计划。本指南介绍上报类型、上报矩阵以及编写有效策略的最佳实践。

什么是事件上报？

事件上报发生在员工无法自行解决事件，需要将任务交给经验更丰富或更专业的员工时。

什么是上报政策？

这些问题看似简单，但您的组织规模越大，技术生态系统越复杂，答案就越需要详细说明。例如，在确定收到事件警报时应通知谁时，结果不仅取决于谁在待命或有空，还取决于严重级别、事件的持续时间等。

对于某些公司，无论事件的严重程度如何，都可能首先通知一个待命人员。对于其他公司，如果事件是 SEV 3，则提醒初级开发人员，如果是 SEV 1，则通知更高级的人员或专业团队，这样可能比较合理。

同样，一些公司可能会依靠第一响应者在需要时上报事件。如果事件超过一定时间或开始影响更多系统或用户，其他人可以触发自动上报给更高级的开发人员或专业团队。

上报政策不仅应说明您的公司将如何上报事件和上报给谁，以及基于事件的类型、SEV 级别、持续时间和范围是否存在细微差别。

事件上报流程

对于遵循 ITSM 最佳实践的公司，服务台通常是事件上报的中心。如果第一响应者无法解决事件，他们会转回服务台，这会将事务上报到相应的下一道防线。使用 Jira Service Management，响应者可以在事件工作单中上报事件。他们可以访问工作流程来指导解决流程，并可以根据需要实施自动化或自定义操作。指定严重性级别可以引导响应者进入相应的工作流程。

其他公司，例如 Google，则让 SRE 负责事件，由此人负责任何必要的上报（以及如果事件使团队超过其 SLA/SLO 规定的可接受的停机期间阈值，则冻结新版本）。

对于其他公司来说，第一响应者可能是开发人员或事件经理，或者可能有多个第一联系人（尤其是在高严重性事件的警报到达时），并且可能在这些团队内部和团队之间直接通过预定义的流程进行上报。

无论该流程是通过服务台、由 SRE 推动、还是在事件跟踪系统中自动进行，上报政策通常遵循三条途径。

分层上报

分层上报是指根据团队或个人在组织内的经验水平或资历将事件传递给团队或个人。

例如，待命的第一响应者可能是团队中新进的初级开发人员。如果他们无法解决事务，则在分层组织中，他们会将该事务传递给更高级的开发人员。如果更高级的开发人员也无法解决该事务，他们将再次转交给比其更高级的开发人员，直到事务解决为止。

职能上报

职能上报是指根据团队或人员的技能或系统知识而不是资历，将事件传递给最有能力的团队或个人来解决。

例如，待命的第一响应者可能是来自专注于产品 X 后端的团队的初级开发人员。如果他们发现核心问题似乎来自与产品 Y 的集成，他们可以将事件上报给产品 Y 团队中的另一位初级开发人员。

自动上报

对于使用 Opsgenie 等平台的团队，您还可以设置规则，告诉系统在主要待命人员未确认或未关闭警报时自动上报事件。

有些团队可能偏爱一种上报方法而不是另一种方法，但它们并不相互排斥，而且许多团队混合使用分层、职能和自动上报方法。

上报矩阵

上报矩阵是一种文档或系统，用于定义何时应进行上报以及应由谁来处理每个上报级别的事件。

该术语在许多行业中使用。人力资源可能有内部事务的上报矩阵。呼叫中心可能有客户服务事务的上报矩阵。而且，IT 和 DevOps 团队可能有一个或多个矩阵来帮助工程师了解如何以及何时上报事件。

矩阵中的详细程度因公司而大不相同。有些组织可能有一个简单的层次结构图，每个开发人员都会根据需要上报给具有更高技能水平的开发人员。其他组织可能有针对具体情况的矩阵，告知开发人员针对不同类型的事件或不同的严重性级别应联系哪些团队。与事件管理中的大多数事情一样，制定组织的上报矩阵不存在放之四海而皆准的方案。

制定上报政策的良好做法

将您的上报政策视为指导方针，而不是一套严格和快速的规则

技术不是一成不变的，您的团队也不是一成不变的。Google 建议，如果您的 SRE 认为某个具体案例需要不同的上报策略，那就让他们自由做出判断。这里的重点不是要制定僵化的规则，而是要制定适用于大多数情况的指导方针。

定期审核您的待命值班表

时间表中有空白吗？您有合适的人待命吗？您的待命的第二层和第三层有合适的人吗？您的待命时间表和上报政策应协同工作，以加快事件管理。

为上报设置智能阈值

并非每个事件都是平等的，这意味着并非每个事件都可以或应该遵循相同的上报政策。

对于小事件，您可能不想在工作时间之前提醒待命工程师。对于重大事件，无论一天中的什么时间，您可能都需要该工程师介入。如果发生多个事件，您的工程师将需要知道首先要处理什么，以及他们是否应立即将一个事件上报给另一位工程师。

在确保您的系统有最长的正常运行时间并实现其 SLA 承诺和 SLO 目标与确保工程师不会倦怠、过度劳累、睡眠不足和警报疲劳之间，存在一个平衡操作。

设定明确的上报流程

上报的开发人员应该直接联系相应的团队或人员吗，还是需要通过帮助台？是否有开发人员应该使用的系统？您将如何追踪上报？为了确保下一个人接管事件，第一响应者有哪些责任？

您的政策应当明确解决这些问题，并明确传达给所有待命开发人员，以使上报顺利进行并更快地解决事件。

详细了解 Jira Service Management 如何提供事件升级协作解决方案以更快地解决问题，从而丰富事件管理实践。