如何处理IT事件管理以避免混乱

简介:

摘要:IT系统已经宕机,它正在影响业务。发生了什么事,以及需要采取哪些措施才能让所有的事情恢复稳定?这种困境在技术平台上建立商业能力的现代企业中经常出现。IT事件响应不能留给纯粹的反应过程,企业不能无序发展,而是需要一个周密的管理和解决系统。

当一个重要的应用程序崩溃时,用户最好有适当的IT事件管理流程和程序来解决它。

IT系统已经宕机,它正在影响业务。发生了什么事,以及需要采取哪些措施才能让所有的事情恢复稳定?

这种困境在技术平台上建立商业能力的现代企业中经常出现。IT事件响应不能留给纯粹的反应过程,企业不能无序发展,而是需要一个周密的管理和解决系统。

IT事件管理和解决是组织如何在其技术平台上维持系统可用性和正常运行时间的核心。

在ITIL服务管理框架下,IT事件管理被描述为记录和解决事件的定义过程。目的是尽快恢复对客户的服务,通常是通过解决方法或临时修复,而不是永久解决方案。

快速解决是值得称赞的,但IT部门如何确保这种情况发生在物理,虚拟和云环境的混合组合,伴随异构IT带来的所有复杂性?

IT事件类型

工具应确保事件不会成为问题。ITIL将事件与问题区分开来:事件是一种易于影响用户并单独发生的事件;问题是在事件发生之前重复事件或识别IT基础设施中的问题。跟踪事件和使用模式匹配算法有助于处理问题。让人们专注于产生IT组织响应的一次性事件。

事件属于硬故障,软故障,以及软件故障:

·硬故障是IT平台中的物理资产(例如服务器,网络链路或存储阵列)或其中任何组件的故障。

·由于IT平台内的虚拟结构(例如虚拟服务器,存储卷或网络链路)中的故障,会发生软故障。

·软件事件是软件中由编码错误或应用程序所依赖的数据损坏引起的故障。

IT事件管理过程

任何IT事件管理方法的第一个方是根本原因分析:首先是到底什么导致事件的发生?因此,管理工具的第一个重点是发现事件是否发生在软硬故障或软件问题上。

第二个重点必须是尽快修复或规避问题,以尽量减少事故造成的损害。完全修复是IT事件响应的最佳结果。将系统恢复到之前的状态,而不会因为业务连续性而损失性能或数据计数,但并不总是可能的。完整的修复可能需要时间来实现。部分修复其中可能对用户体验有轻微的负面影响,或已知数据量丢失,应该是其最低目标。

最终安全措施灾难恢,只能用于完整的灾难。灾难恢复总是导致一段时间的能力损失和数据的明显丢失。

工具还应确保事件不会成为问题,这意味着任何最终解决方案都是长期的,并阻止未来事件再次发生。如果适当的IT事件响应首先需要战术性修复作为解决方案以启用客户,则较长的进程应识别并实施长期修复。

留下痕迹

在IT审计的情况下,这些工具可以证明是有用的。例如,从即时通讯工具中添加详细信息有助于证明所做的工作,何时,如何处理事件以及采取了什么步骤阻止它们成为问题。一个经过审计的公司,无论是遵守内部标准,ISO90001还是法规遵从性要求,都可能需要IT事件管理工具到位。

工具格式

许多服务台系统(例如BMCRemedyIT服务管理套件,VivantioPro和Zendesk)嵌入了IT事件管理工具,但有些服务台系统只是监督IT事件管理的过程,并且不提供实施完全补救的实际能力。

有人问:你希望如何改善企业业务的IT事件管理?其他工具完全集成到服务台系统中,提供用于IT资产管理,根本原因分析和修复的功能,以及使用服务台系统处理提高故障单并向管理员通知正在发生的情况。IT管理供应商,如ManageEngine,BMC软件,SolarWinds,ServiceNow和Cherwell软件,提供全面的事件解决功能,而不是单个故障。

你选择用于安装有效IT事件响应的工具必须具有以下功能:

·了解所管理的IT平台的物理体系结构;

·了解管理下的IT平台的虚拟架构,包括公共云平台;

·完全理解虚拟和物理实体之间的所有依赖关系;

·快速找到发生的IT事件并记录日志;

·对事件进行根本原因分析并记录;

·确定事件是否可以通过自动化方式修复,如果不能,则通过故障单提醒管理员;

·创建补救方法,或向补救系统提供足够的数据,以便可以修复事件;

·在只能进行部分修复的情况下,提供完整修复的故障单;

·记录所做的全部细节,并以可以识别事件的任何重复,并记录结果问题的细节的方式存储它们;

·根据所有记录的信息,为发现的所有事故,包括采取的步骤,结果等提供有意义和有用的报告。

在需要人为干预,例如物理系统失效的情况下,IT事件管理工具应当与允许手动工作的操作工具(例如服务台软件)双向地集成。一旦更换或固定硬件,IT事件管理工具应接收此信息,以使其记录保持最新。如果同样的事件再次发生,工具的记录将有助于确定它是否是地方性的。

组织应该考虑如何最好地实施这些工具,以支持不断变化的IT平台所需的灵活性,确保它涵盖私有的和公共的基础设施。

本文转自d1net(转载)

目录
相关文章
|
前端开发
多次请求同一数据接口造成数据混乱问题解决办法
在进行前端开发过程中,经常会遇到需要请求同一个数据接口但不同参数的需求,这种情况下当用户通过页面操作频繁请求该接口,而接口的不同参数响应时间差异较大时,容易引发数据渲染混乱的bug。
2193 0
|
10天前
|
程序员
项目中的全局异常是如何处理的
项目中的全局异常处理通常包括对预期异常(程序员手动抛出)和运行时异常的管理。项目已提供`BaseException`作为基础异常类,用于手动抛出异常,并通过`GlobalExceptionHandler`进行全局处理。`
23 4
|
16天前
|
前端开发 程序员
项目中异常是如何处理的
项目中设定了全局异常处理器,统一处理预期和运行时异常。预期异常由程序员手动抛出,用于异常情况的接口返回;运行时异常为不可控错误,提供统一返回格式便于前端提示和后端排查。全局异常处理器借助@RestControllerAdvice和@ExceptionHandler注解,前者标识处理器,后者按异常类型定制前端响应,如预期异常直接返回,运行时异常则调整响应内容。
13 0
|
2月前
测试沟通不畅时该如何解决?
测试沟通不畅时该如何解决?
158 0
|
4月前
|
消息中间件 存储 中间件
消息流是指在计算机系统中,消息从一个地方传递到另一个地方的过程
消息流是指在计算机系统中,消息从一个地方传递到另一个地方的过程
36 1
|
8月前
|
存储 监控 数据可视化
01.崩溃捕获设计实践方案
01.崩溃捕获设计实践方案
131 3
|
9月前
|
前端开发 NoSQL Redis
项目实战典型案例5——发送调查问卷流程图例子(将不必要的逻辑放入前端)
项目实战典型案例5——发送调查问卷流程图例子(将不必要的逻辑放入前端)
79 0
|
9月前
|
前端开发 NoSQL Redis
案例05-将不必要的逻辑放到前端(发送调查问卷)
案例05-将不必要的逻辑放到前端(发送调查问卷)
|
9月前
|
SQL 安全 关系型数据库
案例07-在线人员列表逻辑混乱
在线人员列表逻辑混乱
|
前端开发
前端工作小结52-错误的处理方式
前端工作小结52-错误的处理方式
64 0
前端工作小结52-错误的处理方式

热门文章

最新文章