项目和问题追踪
内容协作
高速 ITSM
可视化项目管理
查看全部产品
来自 Atlassian 的创新
浏览所有
团队工作目录
开发人员体验平台
为您的所有 Atlassian 产品连接数千个应用
从发现到交付和运营，运行世界一流的敏捷软件组织
让开发、IT 运营和业务团队以超快的速度交付出色的服务
在保证组织一致性的前提下，增强自主团队的能力
非常适合初创公司，从孵化到 IPO
为不断发展的企业提供适当的工具
了解我们如何让大型团队实现成功
规划、构建和发布优质的产品
整合制胜的策略
精简人员管理
安全可靠地运行
高效地运营业务
提供出色的服务和支持
简化所有财务流程
针对事件做出响应、解决问题并吸取经验教训
增强 Atlassian 产品的应用
创建 Atlassian 应用的文档和资源
合规性、隐私，平台路线图等
有关文化、技术、团队和技巧的故事
适用于我们所有产品的指南
迁移工具及指导
即将发布的功能版本
有关我们策略的常见问题
为大型团队提供个性化支持
值得信赖的第三方顾问
团队和管理员的资源中心
使命和历程
工作机会、价值观等
适用于各种技能层次的培训和认证
交流、共享和学习的论坛
大规模提供速度服务管理。
查看改善服务管理实践的技巧。
这些指南涵盖了从基础知识到深入的最佳实践的所有内容。
浏览我们的白皮书、案例研究、报告等，获取所需的所有信息。
在 Atlassian 呈现：高速 ITSM 中深入了解 Jira Service Management 以及其他强大的工具。
免费注册
发生事件时，最好的情况是，您的待命工程师或 SRE 可以自行快速解决事件。
当然，在现实世界中，情况并非总是如此。有时，解决方案需要更大的团队、专业知识或更高级的技能。因此，任何拥有两名以上技术专业人员的组织都需要事件上报的计划和政策。
事件上报是指员工自己无法解决事件，需要将任务交给经验更丰富或更专业的员工时的操作。
上报政策回答了您的组织如何处理这些移交的问题。它概述了事件警报到达时应通知谁，如果第一响应者没有时间，应将事件上报给谁，如果响应者无法自行解决事务，谁应该接管，以及这些移交应如何进行（通过服务台？直接从一位技术人员转到另一位技术人员？通过事件管理工具？）。
乍一看，这些问题看起来很简单，但是您的组织规模越大，技术生态系统越复杂，答案就越需要细节。例如，在确定事件警报到达时应通知谁时，答案可能不仅取决于谁在待命或有空，而且还取决于严重性级别、事件持续时间等。
对于某些公司，无论事件的严重程度如何，都可能首先通知一个待命人员。对于其他公司，如果事件是 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 如何提供事件升级协作解决方案以更快地解决问题，从而丰富事件管理实践。
In this tutorial, you’ll learn how to set up an on-call schedule, apply override rules, configure on-call notifications, and more, all within Opsgenie.
有效的待命时间表是维持健康的待命文化的关键。了解常见错误、轮换时间表的类型以及如何正确处理。
