项目和问题追踪
内容协作
高速 ITSM
可视化项目管理
查看全部产品
来自 Atlassian 的创新
浏览所有
团队工作目录
开发人员体验平台
为您的所有 Atlassian 产品连接数千个应用
从发现到交付和运营,运行世界一流的敏捷软件组织
让开发、IT 运营和业务团队以超快的速度交付出色的服务
在保证组织一致性的前提下,增强自主团队的能力
非常适合初创公司,从孵化到 IPO
为不断发展的企业提供适当的工具
了解我们如何让大型团队实现成功
规划、构建和发布优质的产品
整合制胜的策略
精简人员管理
安全可靠地运行
高效地运营业务
提供出色的服务和支持
简化所有财务流程
针对事件做出响应、解决问题并吸取经验教训
增强 Atlassian 产品的应用
创建 Atlassian 应用的文档和资源
合规性、隐私,平台路线图等
有关文化、技术、团队和技巧的故事
适用于我们所有产品的指南
迁移工具及指导
即将发布的功能版本
有关我们策略的常见问题
为大型团队提供个性化支持
值得信赖的第三方顾问
团队和管理员的资源中心
使命和历程
工作机会、价值观等
适用于各种技能层次的培训和认证
交流、共享和学习的论坛
大规模提供速度服务管理。
查看改善服务管理实践的技巧。
这些指南涵盖了从基础知识到深入的最佳实践的所有内容。
浏览我们的白皮书、案例研究、报告等,获取所需的所有信息。
在 Atlassian 呈现:高速 ITSM 中深入了解 Jira Service Management 以及其他强大的工具。
免费注册
事件产生的影响可以用每分钟损失数万或数百美元来衡量。风险如此之大,因此各个组织都在快速发展事件响应最佳实践。
如果组织不经常迭代其事件管理流程,他们将面临管理不善的事件、不必要的延误和相关的成本等风险。
下方列出了一些很常见和不太常见的最佳实践和提示。
事件响应者的“应急背包”存放着所有重要的信息,以便团队在需要时以最短的延迟加以访问。这很有可能是一份数字化文档,但为事件响应者提供一个集中的起点会有极大帮助。
其可能包括各种各样的内容:
运行手册提供在给定场景中应采取哪些步骤的指导。当系统专家可能无法立即到场时,它们对于待命轮换的团队来说尤为重要。若有一套维护良好的运行手册,团队能够更快地做出响应,并且建立事件响应实践的共享知识库。
混沌工程 (Chaos Engineering) 是通过故意注入错误对系统进行实验的方法,目的是了解如何更可靠地构建系统。Chaos Monkey 就是这样一个例子。Chaos Monkey 最初由 Netflix 开发,是一款通过故意使生产系统离线来测试网络弹性的工具。
在过去,Network Operations Centers (NOCs) 充当大型 IT 系统的监控和警报中心。现代事件管理工具可以大幅简化此过程。根据定义的警报类型、团队计划和上报策略自动化警报交付工作流,可以避免人为错误和/或延迟的可能性。
没有什么比持续从多个监控工具收到警报更糟糕的了。通过单一工具来集中警报流,团队能够更好地过滤干扰,快速将精力集中到需要注意的事项。
基本的警报会传达出了状况,但并不总会表述具体的问题。这会导致不必要的延迟,因为团队必须调查并确定问题缘由。通过将警报与触发原因技术细节相结合,可以更快地启动修复过程。
拉丁语词组“quis custodiet ipsos custodes”(“谁在保卫守卫?”)提出了一个普遍的问题。就像受其保护的系统容易受到事件和停机影响,IT 和开发人员团队所采用的监控工具也不例外。全面的警报流程可确保持续检查系统及其监控工具的运行状况。
分诊医生知道,如果他们深陷于试图在抵达时解决所有问题,他们会面临造成更大伤害的风险。他们的重点是短期行动,使患者病情稳定下来,足以转移到接受更多急诊护理的地方。在技术领域,遏制措施侧重于临时解决方案(隔离网络、回退版本、重启服务器等),这些解决方案至少会限制事件的范围,或者更理想的是使系统重新上线。
IT 和 DevOps 团队中的英雄文化是一种日薄西山的理念。因为是唯一能使系统恢复上线的人,而成为在夜晚和周末无休止地孤军奋战的工程师,这已不再是一种潮流。相反,团队就要以团队的方式工作。链条的牢固程度取决于其最薄弱的一节,因此要尽力培养整个团队,而不仅仅是一位孤星。
如果用户遭遇服务中断,相关事件通常会在短时间内公开。为了能抢先一步,团队应该制定事件沟通计划。目标是通过公开承认正在发生中断与客户建立信任,并向他们保证已在采取措施来解决中断。Statuspage 之类的工具非常适合分发这种信息。
绝大多数情况下,IT 和 DevOps 团队会表示,他们只花时间检查“重大中断”。虽然这是一个良好的开端,但往往会忽视可能产生持续影响的小事件。并非所有事件都需要冗长的报告,但事后分析总是有用的。
或者说有?在分析事件时,很少能指明单个可识别的“根本”原因。系统常常会太过复杂,而且它们相互依存,无法确定事件的单一根本原因。即使根本原因看似明显(比如,击键错误导致应用崩溃),通常也有理由去查明哪些外部因素可能造成应用崩溃(或未能阻止崩溃)。寻找多个根本原因,更深入地了解您的事件。
对于每一事件,事后分析的目标应该是了解出了什么问题,以及可以采取哪些措施来避免将来发生类似事件。重要的是,此过程不应被用来指责他人。那是因为,如果团队聚焦于“何人”而不是“何事”,引起的情绪会使分析偏离方向,无法真正了解发生了什么。
在现代事件管理环境中,唯有变化是永恒不变的。也就是说,系统将不断地以新的和不同的方式承受压力。知道这一点的团队也明白,问题不在于系统是否会出现故障,而在于何时出现故障。采取措施准备好应对这些故障,应被视为持续成功的关键要素,并将其融入工程团队的 DNA 中。
诸如 Jira Service Management 之类的事件管理解决方案对这 13 个要点皆有助益,包括从组织待命时间表和警报到联合团队以加强协作,再到开展事后分析等。
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.
借助这些资源和最佳实践,了解什么是事件指挥官、企业为何需要、具体负责什么,以及如何成为其中一员。