IT 事件管理、响应和预防的未来
过去，负责应对技术事件的团队几乎一直是 IT 部门。通常，网络运营中心 (NOC) 的团队会监控系统并对中断做出响应。供应商可能已经构建了软件，但部署和操作则由客户的 IT 运营团队负责。如今，随着云服务激增，供应商构建了软件并进行了部署和运营。
然而，事件管理仍然是 ITSM 的核心实践。而且，IT 在制定指导方针、管理预算以及承担诊断、修复、记录和预防重大事件的各方面都有着悠久的历史。
当然，与科技领域的任何事物一样，过去不一定是未来的预测指标，而目前，事件管理的实践正在发生变化。DevOps、SecOps 和架构团队越来越多地参与其中。新技术和互联产品改变了我们管理事件的方式。为了跟上步伐，思维方式、实践和团队结构也在发生变化。
那么，事件管理如何转变，这对我们的角色、产品、流程和团队的未来意味着什么？
向去中心化迈进
倒退五年，询问负责事件管理的 IT 团队。得到的答案几乎都会是“我们”。
现在问同样的问题，您可能不仅会听到 IT，还会听到 DevOps、SecOps 和架构团队。许多组织正在慢慢转向“谁构建，谁运行”的概念。
这种方法的明显好处是，它通过将责任转移到最熟悉代码的员工身上，减轻了 IT 团队的压力并加快了响应时间。这样可以最大限度地减少停机时间并提高团队工作效率。它还激励优秀的代码。（如果您曾在凌晨 3 点被吵醒来解决错误，那么下次代码上线时，您很可能会再三检查代码，以保持凌晨 3 点不会再被电话吵醒。）
这种方法的挑战是组织仍然需要一定的集中化。领导层需要查阅报告和文档。业务利益相关者需要掌握最新消息。他们希望查看事件指标，如平均解决时间和平均确认时间。他们希望事件更新、事件事后分析报告和补救工作全都一目了然。
对于许多正在转向去中心化并且表现尚可的公司来说，应对这一挑战的答案是运用促进去中心化和团队自主的技术，以保持事件解决的灵活性，同时仍然将信息集中到一处以使业务部门掌握最新动态。
去中心化的缓慢之路
与任何其他可能扰乱工作流程并产生不可预见的后果的重大变化一样，许多组织正在初步采取去中心化措施是有道理的。
他们首先要确定一个在文化上适合此类变革的团队，该团队正在管理低风险应用或产品。然后，他们将该团队特定应用或产品的事件管理移交给该团队。他们对该团队进行培训，实施待命时间表，并跟踪他们在一段时间内的进度，然后提出以下问题：
- 他们是否缩短了恢复时间？
- 他们遇到了哪些文化障碍？
- IT 团队需要安装哪些工具？
- 他们需要什么流程来沟通？
- 该团队会提供更好的系统更新吗？
- 事件数量下降了吗？
- 如果我们决定将这种去中心化推广到其他团队，那么我们可以从最初的测试中得到什么？
这些测试用例为决定是否在整个公司实施“谁构建，谁支持”框架奠定了基础，如果是的话，如何有效地在团队中推广该框架。
去中心化意味着跨团队协作
这种去中心化的举措还需要转向跨团队协作。如果 DevOps 参与事件管理，则 DevOps 需要在 IT 事件管理流程会议上占有一席之地。如果 IT 部门仍在帮助指导事件管理实践，他们需要参与其他团队的事后分析审查。
每个团队都将自己的优势带到事件管理上。IT 团队擅长制定实践和文档并遵循指导方针。DevOps 团队擅长变更和学习。SecOps 可以提供安全性。
为了促进团队之间的更多协作，做得好的公司公开共享信息，培养团队之间的同理心，摆脱跨团队的责备，在事件发生时通过聊天来保持团队的联系，并优先考虑每个人都能参与事件审查。
从被动向主动的转变
在 ITIL 指导方针中，通常将事件管理视为与事件预防不同的实践。两者都是 ITSM 难题的重要组成部分，但它们并不经常同时发生。
这种方法的问题在于它使事件管理处于被动状态。待命员工的任务是解决问题，一旦问题解决，他们就会转向下一个问题。他们的唯一目标是恢复——让系统恢复正常运行。
但只有恢复还不够。随着时间的推移，越来越多的 IT 团队开始意识到并接受这一点，将预防纳入事件管理流程，并使用平均解决时间（而不是平均恢复时间）等指标来判断绩效。
这种方法通常被称为问题管理，其目标是使流程更紧密地联系在一起，以确保团队不仅是解决完一个问题后立即转向下一个问题，而且还要做出响应、恢复并从事件中吸取经验教训，将这些经验教训应用于他们目前管理的以及更大的产品和服务系统。
许多企业 IT 组织将有专门的问题管理实践。他们通常将其视为单独团队的单独流程。在 Atlassian，我们主张更进一步，使用混合方法，让 IT 运营和开发人员团队将问题管理实践纳入自己的事件实践。这样可以更好地了解整个事件，并确保不会在事件发生后很长时间才进行事件分析。
因为，从长远来看，预防事件比快速响应事件更有价值。
坚持使用流程和文档
这种在事件管理方面向跨团队协作的转变固有的挑战之一是，部分团队在流程和文档方面比其他团队更为宽松。
这是 IT 部门可以提供监督和显著价值的地方之一，即使其他团队负责管理自己的产品也是如此。因为没人愿意在凌晨 3 点处理重大事件，而且还没有一个可靠的计划。
在将团队纳入事件管理流程时，IT 部门可以帮助他们回答决定该计划的核心问题。例如：
- 您的事件响应是什么？
- 您要遵循的价值观是什么？
- 如果发生事件，您会如何响应？
- 您所支持的关键系统所需的信息在哪里？如果存在于多个系统中，如何将这些信息整合在一起，以便待命专家可以轻松访问这些信息？
- 您的流程和文档是否可以协作并由团队审核？
您的公司文化准备好迎接变革了吗？
这种向去中心化、协作以及事件和问题管理相结合的转变，所需要的不仅仅是重新分配职责和安排 IT 专业人员参加 DevOps 事后分析。这里成功的关键不在于技术，甚至不在于流程。而在于打造一种支持这些变更的内部文化。
这是太多公司试图跳过的部分，也是成功过渡的基础。那么，支持去中心化、协作、面向未来事件管理的文化是什么样子的呢？
在 Atlassian，我们认为核心组件包括：
开放和信息共享
如果团队不知道也无法访问其他团队的所作所为，那么我们就失去了机会，因为这些时刻可以带来更好的沟通、流程和产品。
以客户为中心的思维
当我们问“什么对客户最有利？”等问题时，有时候我们想出的答案与我们目前的实践不符。需要有意识地以客户为中心，才能使我们朝着沟通、流程和结构效率的方向发展，最终使我们的产品更适合客户。
定期进行运行状况检查
每个团队的表现如何？个别团队成员对事情的感觉如何？团队还能在哪些方面进行改进？他们有哪些技巧？在 Atlassian，我们有一本团队小技巧，可以帮助我们检查团队的健康状况，并向他们介绍新的工作方式。
同理心
如果 DevOps 指责 IT，而 IT 对更为宽松的 DevOps 方法视而不见，那就无法实现协作。如果我们希望团队进行沟通、创新和良好的合作，那么培养团队之间的同理心和联系至关重要。
赋权
应授权团队快速解决问题，并尽可能独立地做出决策。这些团队中的个人如果有问题、建议或疑虑，无论他们在团队中的职位或经验如何，都应该大胆提出来。
当初级开发人员觉得自己可以在会议中发言并举报问题时（即使是更高级的员工负责该代码），就会带来创新的新想法、改进的流程，并在错误进入代码之前将其捕获。