ITIL V3 SERVICE OPERATION (incident Management)

ITIL V3: es un marco de referencia para la infraestructura de TI, en el cual se siguen las buenas practicas a travs del ciclo de vida de los proceso que tiene cada etapa .

Son 5 los procesos en los que se esta conformada el ncleo de ITIL.

Estrategia del servicio: en esta se proporciona una gua sobre como se disea el desarrollo de los servicios y los servicios de administracin de procesos. Cubre principalmente el diseo de mtodos para convertir los objetivos estratgicos en un portafolio de servicios. Transicin del servicio: En esta parte se implementan los como deben ser utilizados los requerimientos que fueron enlistados en la parte del diseo.

Servicio de operacin: se proporciona como mantener estable el servicio, permitiendo cambios en el diseo. (proactividad) . Participantes proporcionan informacin para tomar mejores decisiones para mantener el servicio disponible.

Mejora continua del servicio: Se crean y se evalan las operaciones de servicio para mejorar los diseos . se combina principalmente mtodos de calidad.

Propsito Service Operation: es una fase critica para el ciclo de vida del ITSM. Es presentada como una practica el Service Management. Service management esta posicionado como una estrategia y un componente profesional de alguna organizacin.

4.2 Incident management En la terminologa de ITIL , un Incident es definido como:

Una interrupcin no planeada a los servicios de TI o una reduccin en la calidad de los servicios de TI. Falla en la configuracin de un ITEM, que no ha sido atendido es tambin un incidente, por ejemplo una falla en un disco espejo. IM es el proceso que atiende los todos los incidentes . tambin incluyen fallas como, preguntas, bsqueda de reportes por usuarios (normalmente por una llamada telefnica al Service Desk), por el personal tcnico, o alguna falla reportada por las herramientas de monitoreo.

4.2.1 Propsito /Objetivo El propsito principal de IM es restaurar el servicio de operacin lo mas inmediato posible . para minimizar el impacto en la operacin de negocios.

4.2.2 Alcance IM tambin incluye cualquier otro evento que interrumpa, o pueda interrumpir un servicio. Incluye eventos los cuales son directamente comunicados por los usuarios, a travs del Service Desk, o a travs de la interface de Event Management a las herramientas de Incident Management . Los incidentes tambin pueden ser reportadas por el personal tcnico (Ejemplo: pueden reportar algo inapropiado con algn componente de hardware o componente de la red, pueden reportar o iniciar un incidente y referirlo al Service Desk). Esto no quiere decir, sin embargo que todos los eventos son incidentes. Mucha clase de eventos pueden no estar relacionadas con la falla del todo, pero son indicadores de una operacin normal o solamente es informacin.

Ambos: incidentes y service request son reportadas a l Service Desk, esto no quiere decir que sean lo mismo. Un Service request no significa una falla o irrupcin, pero es una forma de conocer necesidades de los clientes para canalizar su peticin en un SLA. Service Reques t es tratado por el proceso de Request Fulfilment.

4.2.3 Evaluacin del negocio

La valoracin de Incident Management incluye:

La habilidad para detectar y resolver incidentes el cual el resultado en tiempos bajos, a los negocios, el cual este en turno es decir una alta disponibilidad del servicio. Es decir que el negocio es apto para un **** Exploit, del servicio como designado. La habilidad de alinear actividades de TI en tiempo real en las prioridades del negocio. Esto es por que incident Managemnet incluye la capacidad de identificar las prioridades del negocio y de forma dinmica emplear recursos como en la medida que estos sean necesarios. Habilidad para identificar mejoras potenciales al servicio. Esto sucede como resultado del entendimiento de lo que constituye un incidente y de donde se inicia el contacto con las actividades del personal de Business operational. El Service Desk puede, durante la posesin del incidente identificar servicios adicionales o requerimientos de entrenamiento encontrados en la parte de TI o el negocio.

4.2.4 Polticas / principios y bases Existen muchos elementos bsicos que se necesitan tomar en cuenta y decidir cuando se hace una consideracin en IM. Estos son cubiertos en esta seccin.

4.2.4.1 Escalas de tiempo (Timescales) Timescales estas deben ser agregadas para todos los incident-handling Stages (estos se diferenciaran dependiendo el primer nivel de prioridad del incidente) y basados sobre el responsable del incidente y objeto de resolucin SLAs. Y capturado como objetivos sin OLAs y Underpinning Contrac (UCs). Todos los grupos de soporte debe de estar totalmente informados sobre estas escalas de tiempo (timescale). Las herramientas de Service management deben ser usadas para automatizar Timescales y escalar los incidentes como estos sean requeridos basados en reglas pre-definidas.

4.2.4.2 Modelos de incidentes Muchos de los incidentes no son nuevos, estos incluyen algn tratamiento con algo/alguien que ya ha sido atendido antes y posiblemente ya ha pasado ms de una vez. Por esta razn, muchas organizaciones encuentran til el pre-definir una estndar, de Modelos de incidentes Incident Models y hacer uso de estos en los incidentes cuando estos ocurran. Un Incident Model es una forma de predefinir los pasos que deben ser seguidos de una proceso que se posea (en este caso un proceso atendido con un particular tipo de incidente) en una forma aceptable. Las herramientas de soporte pueden entonces ser usadas para administrar los procesos requeridos. Esto asegurara que el Estandar de los incidentes son una parte predefinida sin que se predefinan Timescales.

Incident Model debe incluir:

Los pasos que deben ser seguidos para manejar el incidente. El orden cronolgico en los que los pasos deben ser seguidos, con alguna dependencia o algn otro co-proceso definido. Responsabilidades : Quien debe hacer Que Timescale y Threshold para completar la accin Procedimientos para escalar ; quien debe ser contactado y cuando. Alguna evidencia necesaria de actividades (particularmente relevante para la seguridad y capacidad-relacionada a los incidentes ).

Los modelos deben ser introducidos a las herramientas de soporte del incident-handling que se utiliza y las herramientas deben entonces automatizar el manejo, administracin y Escalacin de los procesos.

4.2.4.3 Major incidentes Incidentes mayores Un procedimiento separado, con un Timescale corto y con gran urgencia, debe ser usado major incidente (incidente mayor). Una definicin de que constituye un incidente mayor tiene que ser aceptado y mapeado de forma ideal en la priorizacin del sistema de incidente, as como deben ser manejados a travs del proceso de major incident Nota: las personas algunas veces confunden la terminologa de major incident con el de Problema. Realmente, un incidente siempre ser un incidente, este puede crecer en su impacto o prioridad convertirse en un incident major, pero un incidente nunca se convierte en un problema. Un problema es parte de la causa de uno o mas incidentes y continuara siempre un ente separado.

Algunos incidentes de baja prioridad pudiesen tambin ser atendidos a travs de este procedimiento. Un doble impacto de negocios potencial - y algunos incidentes mayores Major Incidents no pueden ser atendidos de esta forma si es que la resolucin y causa son obvios y el proceso normal del incidente puede ser fcilmente atendido sino agregado a una resolucin en tiempo- proporciona un impacto siempre bajo.

Cuando sea necesario, el major incident el procedimiento debe incluir la dinmica de establecimiento de un equipo separado major incidente bajo la direccin de los de Incident manager, formulado a que se debe concentrar en este incidente de forma aislada que adecuen los recursos y el nfasis para encontrar una solucin.

El Administrador del Service Desk, es tambin alguien que maneja el rol de Incident Manager (dicho en una pequea organizacin), entonces una persona podra ser designada para atender el liderazgo de un equipo de investigacin para Major Incidents, entonces como el permitir un conflicto de tiempo o prioridades, pero debera reportar ltimamente al Incident Manager.

Si la causa del incidente necesita ser investigada al mismo tiempo, entonces el Problem Manager seria el involucrado, ***** , tambin el Incident Manager debe asegurarse que la restauracin del servicio y el entendimiento de que se mantienen por separado. Fuera del Service Desk asegurara que todas las actividades son grabadas y los usuarios son informados por completo del progreso.

4.2.5 Proceso de actividades, mtodos y tcnicas. El proceso a seguir durante la administracin de un incidente es mostrado en la siguiente figura, este debe contener los siguientes pasos:

Figura 4.2.5.1 Identificacin de un incidente

El trabajo no puede iniciar en un manejo con un incidente hasta que este es conocido que un incidente ha ocurrido. Esto es usualmente inaceptable, desde la perspectiva del negocio, esperar hasta que un usuario sea impactado y contactar al Service Desk. Tan lejos como sea posible, todos los componentes claves deben ser monitoreados entonces los fallos o potenciales fallos son detectados de forma temprana desde que el proceso Incident management pueda ser usado lo

mas pronto. Idealmente los incidentes deberan ser resueltos antes de tener un impacto en los usuarios.

5.2.5.2 Iniciando un incidente Pag. 61 Todos los incidentes deben ser dados de alta etiquetando la fecha y la hora, independientemente si son a travs del Service Desk por una llamada telefnica o automticamente detectado va Event Alert .

Nota : si el Service Desk y/o el personal de soporte visitan a los clientes para manejar el incidente, deben de haber hecho la peticin para manejar el incidente mientras ellos permanezcan ah es importante que esto se haga, un incidente grabado por separado es registrado por cada incidente adicional atendido. Asegurarse que una grabacin historia es mantenida y acreditada dada por el responsable.

Informacin necesaria para cada incidente: nico nmero de referencia. Categorizacin del incidente Urgencia del incidente Impacto del incidente Fecha y hora de registro Nombre/Id de la persona y/o grupo que registro el incidente Mtodo de notificacin (Telfono, automtico, e-mail, en persona, etc.) Nombre/Departamento/Telfono/Localizacin del usuario Mtodo Regreso de llamada Descripcin de sntomas Estatus del incidentes (activo, espera, cerrado, etc.) CI relacionado Grupo/Persona de soporte al cual el incidente es canalizado. Problema relacionado/ Error Conocido Actividades a realizar para resolver el incidente. Fecha y hora de la resolucin Categoria