ITIL V3: Service Operation (Operación del Servicio)

Ha pasado casi un mes desde que escribí mi ultimo material sobre ITIL y si alguno pensó que estaba vagando o simplemente me había aburrido de escribir, déjenme decirles que uno de mis principales defectos (o quizás virtud….) es estar siempre estudiando algo, lo que me resta tiempo para cosas como escribir en mi blog y demás actividades de ocio.

Bueno hoy pienso dar un paso mas para ir concluyendo mis materials sobre ITIL v3; hasta el momento ya he escrito 4 materials y no quiero caer pesado pero les recomiendo leer los materials anteriores para entender todo el contexto de ITIL.

Si quieres darle un review a los material anteriores, aquí lo puedes hacer:

- Introducción a ITIL v3 - Estrategia del Servicio - Diseño del Servicio - Transición del Servicio

Habíamos dejado la “acción” en la implementación del servicio (Transición del Servicio – ST), acuérdense que en la ST habíamos visto la gestión del cambio, gestión del activo servicio y configuración, y la gestión del despliegue, ¿lo recuerdan, verdad?. Pues la lógica me indica que después de implementar el servicio en un cliente viene algo que cae por su propio peso…. MANTENER EL SERVICIO SIEMPRE FUNCIONANDO.

¿Acaso existe un sistema de TI que funcione completamente solo y sin necesidad de algún mantenimiento? Analicemos un poco, los desarrolladores siempre tienen nuevos requerimientos por parte de los usuarios, los DBA siempre tienen que monitorear que sus BDs estén funcionando, los sysadmin revisar que todo el sistema corporativo este funcionando y así podría pasarme todo el día diciendo que este trabajo nunca tiene fin, por eso en ITIL v3 existe algo que se llama MEJORA CONTINUA que será el tema del siguiente y ultimo material.

Con esas cuantas líneas arriba he tratado de resumir lo que hace la Operación del Servicio y que entramos a analizar en este mismo instante:

Definición, metas y objetivos SO (Service Operation), conduce, gestiona y controla las operaciones del día a día de los procesos, con la finalidad de tener los servicios estables, registrar incidentes, registrar problemas y sugerir el uso de nuevos procesos. Seamos sinceros …. muchas personas desmerecen este tipo de trabajo, no? pero por el contrario este trabajo tiene una importancia estrategia importante! porque estas son las personas que dan la cara frente al usuario, son los que dicen: “Buenos días, el área de TI le habla; ¿en que puedo ayudarlo?” y nunca debemos olvidar que el área de TI brinda servicios a los clientes y son estos quienes perciben el valor del servicio.

Cuando hablamos de gente que esta constantemente monitoreando los servicios, atendiendo llamadas y dando soluciones temporales, hablamos de nuevos conceptos como: impacto, urgencia y prioridad. Imaginemos….. llama un usuario de logística indicando que no puede abrir un archivo PDF y llama el director general indicando que no le funciona el outlook, ¿a quien se atiende primero? ¿al que llamo primero?, pues…. eso depende de muchos factores como la cantidad de gente con la que se cuente, la cantidad de recursos y de tiempo.

Terminología: En este tema existen muchos términos nuevos y definiciones muy técnicas así que me gustaría explicarlo mejor con un ejemplo para que quede bien claro:

Se tiene una aplicación llamada “ABC” programada en Java que utiliza una BD Oracle, esta aplicación es accedida mediante un browser por los clientes quienes agregan información de manera diaria. Cierto día, los chicos de SO reciben un correo de sistema CACTI (sistema que monitorea el ancho de banda de la red) indicando que el consumo del ancho de banda de la red se ha incrementando en un 40% desde las 12pm hasta las 4pm. A los 2 días de recibido este correo, llega otro correo del sistema CACTI indicando que el disco duro

del servidor de BD ha pasado el 80% de su capacidad y que se recomienda liberar espacio. Al tercer día (y justo fin de mes) llama un cliente indicando que el sistema “ABC” no funciona y que no puede adjuntar información y que necesita hacerlo lo antes posible porque tiene que terminar su trabajo de fin de mes, a los 10 minutos de esta llamada se reciben 5 nuevas llamadas de otros usuarios con el mismo inconveniente.

De este pequeña historia que es totalmente real, tenemos:

Evento: Aumento del consumo del ancho de banda en un 40% (lo mas seguro es que algún usuario estaba agregando bastante información) Alerta: Uso del disco duro en un 80% Incidente: Primera llamada del usuario que no puede adjuntar archivos Problema: 5 clientes que no pueden usar el sistema el fin de mes Workaround (Solución temporal): Montar nuevo disco duro para aumentar el espacio en disco KnowError (Error conocido-KE): Este error se ha presentado con anterioridad y el procedimiento de solución y causa del problema esta documentada. Reactivo: Personas que actúan solo frente a un aviso o problema. Proactivo: Personas que están en búsqueda de la mejora continua

A partir de este punto se crean nuevos paradigmas: Calidad del Servicio Vs. Costo del servicio. Es que nosotros como TI podríamos decirle al cliente que el tiempo de respuesta frente a la caída de un servicio será de solo 10 minutos pero necesitamos:

- Herramientas costosas de monitoreo, con un valor aprox de 30 mil dólares anuales - 25 personas dedicadas al área de TI, con un valor de 100 mil dólares anuales - ETC

¿Es esto posible? la mejor idea es siempre buscar un equilibrio entre la calidad del servicio y el costo de modo que se pueda cumplir con los requerimientos del negocio.

Los procesos en la Operación del servicio son:

- Gestión de Incidentes - Gestión de Eventos - Cumplimiento de Solicitudes - Gestión de Problemas - Gestión de Accesos

GESTION DE INCIDENTES El objetivo principal de la Gestión de incidentes es restaurar los niveles normales del servicio lo mas rápido posible, asegurando el cumplimiento del SLA (calidad, tiempo y disponibilidad)

El diagrama explica la relación entre un incidente, problemas, KE (error conocido), workaround (solución temporal) y un RFC (solicitud de cambio). Cuando hablamos de incidentes es inevitable hablar de escalamiento, imaginemos que llaman por un problema de red,  la persona que le contesta no puede ayudarlo entonces pasa a otra persona que conoce mas del asunto y si esta persona no puede, pasa a un certificado en CCNA y así sucesivamente; a este proceso se le llama ESCALAMIENTO y existen 2 tipos:

- Escalamiento funcional (horizontal): Cuando se involucra a otra persona con mayores conocimientos en el tema. - Escalamiento jerárquico (vertical): Cuando se necesita de autoridad para realizar una acción.

Sobre los tipos de escalamiento, siempre vienen preguntas en el examen de ITIL.

Lo que hace la gestión de incidentes se puede resumir en un solo grafico.

La gestión de incidentes tiene un proceso bastante grande y por consiguiente complejo, voy a describir al detalle cada uno de las actividades del proceso:

Detección, comunicación y registro Parece sencillo poder describir “la detección de incidentes” y en efecto la descripción es sencilla pero la implementación no lo es, ITIL recomienda herramientas automatizadas para la detección de un incidente; cuando hablamos de herramientas automatizadas estamos hablando de SOFTWARE que nos ayude en dicha función. En el mercado existen diversas herramientas, desde OpenSource como CACTI o NAGIOS hasta herramientas de pago como TIVOLI o UNICENTER, lo ideal es que el principal mecanismo de detección de un incidente no sea la llamada de alerta de un usuario sino que sea un mecanismo de alerta automatizado.

Entonces la “detección” debería ser automatizada en primera instancia, recibida por el personal del centro de servicios, reportada por el mismo personal de TI o directamente reportada por el usuario final; cualquiera que sea el mecanismo de detección TODO INCIDENTE DEBE SER REGISTRADO Y DEBE SER ASIGNADO UN NUMERO.

¿Absolutamente todo debe ser registrado? Sí!!! absolutamente todo incidente debe ser registrado, ITIL insiste en registrar todo incidente por mas insignificante que podría resultar y parecer.

¿Dónde lo registro? ITIL v3 no especifica donde registrarlo pero se recomienda tener una herramienta de registro de incidentes que nos ayudara para los reportes y futuras auditorias de TI. No quiero irme por las ramas con el tema de auditoria pero en empresas serias existe algo que se llama CONTROL INTERNO (Auditoria Interna) que registra todos los incidentes que deberían concordar con nuestra BD de incidentes.

¿Qué registro? Pues absolutamente todo!!! ITIL recomienda registrar lo siguiente:

Numero de identificación, clasificación, fecha, quien detecto el incidente, síntomas, categorías, IMPACTO, PRIORIDAD, CIs, KnowError, fecha de resolución y notas de seguimiento. Como habrán notado el éxito de la implementación de ITIL esta en NO SUPONER u OBVIAR DETALLES.

¿A quién comunico el incidente? Los incidentes de gran impacto deben ser comunicados a todo el personal de TI con el objetivo de mantenerse informado y alerta y no registrar 2 veces el mismo incidente.

Registrar 2 veces el mismo evento es uno de los principales errores que se comente en la GESTION DE INCIDENTES.

Clasificación, comparación y apoyo inicial La imagen superior muestra un ejemplo de clasificación, ITIL no te dice como debes clasificarlo eso depende de los procesos de la organización, de la misma manera la clasificación por prioridad debe regirse a políticas particulares dentro de la organización. Después de haber detectado el problema la gestión de incidentes debe tratar de resolver de manera rápida, ellos son la primera línea de defensa, son EL APOYO INICIAL. Para tratar de resolver el incidente y restablecer el funcionamiento correcto se ayuda de la BD de Errores conocidos y la BD de Workarounds (soluciones temporales), si a pesar de ello no se puede solucionar el incidente se procede a escalar el incidente.

Hay que tener cuidado en NO REPETIR EL TRABAJO y esto pasa por una COMPARACION de síntomas de otros incidentes.

Investigación y diagnostico Después de haber sido detectado, registrado, clasificado y no haber podido resolver el problema de manera rápida, pasamos a la investigación del incidente hasta dar con la causa del problema. Este proceso puede pasar por distintos niveles de escalamiento y de expertos.

Resolución y Recuperación Se dio con la causa del problema y se provee de un workaround y se restablece el servicio; si es necesario un cambio se le comunica a la GESTION DE CAMBIOS.

Cierre del incidente Se confirma que el incidente ha sido resuelto y se documenta el cierre del caso.

Hay otros temas que también hay tener en cuenta como por ejemplo MANTENER AL USUARIO SIEMPRE INFORMADO!, ¿cómo piensa el usuario? el usuario cuando nadie lo llama piensa que nadie se esta encargando de resolver su problema y luego vienen las quejas!!! es mejor mantener al usuario siempre informado.

Otro tema muy importante es el MAL ESCALAMIENTO, muchas veces se abusa del escalamiento y cualquier problema es ESCALADO rápidamente distrayendo a los especialista en temas que no son importantes. (ESTA ES PREGUNTA DE CERTIFICACION ITIL).

Y por ultimo y quizás el mayor problema que presenta la gestión de incidentes es la falta de un SLA y Catalogo de servicios, cuando estos documentos no están presentes cualquier problema relación con tecnología va ser automáticamente asignado al área de TI sin importar temas como tiempo y recursos.

No olvidar que ITIL cuantifica todo, por ello nosotros debemos ser capaces de tener reportes de la gestión de incidentes que respondan a las siguientes preguntas:

- ¿Cuántos incidentes se han presentado en un periodo de tiempo? - ¿Cuántos incidentes de software hemos tenido? - ¿Cuántos incidentes han sido escalados hasta los especialistas? - ¿Cual es el tiempo de respuesta ante un incidente? ¿Cumplo con el SLA? - ¿Qué área presenta mayores incidentes? - Etc

GESTION DE EVENTOS

La principal diferencia entre evento e incidente radica en que TODO INCIDENTE es un evento pero NO TODO EVENTO es un incidente, por ejemplo en el primer ejemplo de este material (que esta casi al comienzo) se tiene un evento en la red, un aumento del 40% del ancho de banca, este evento no es un INCIDENTE porque el aumento de 40% del ancho de banda en un red LAN esta dentro del rango de lo permitido. Sin embargo un incidente como la caida de un servicio definitivamente es un evento perjudicial.

Sobre los evento ITIL v3 no hace demasiado hincapié pero debemos tener bien claro lo siguiente:

- ITIL v3 no se puede implementar sin herramientas que monitoreen los eventos, necesariamente necesitamos herramientas que automaticen el trabajo! - Todos los eventos deben ser registrados, absolutamente todos, para la rápida y presta detección de incidentes u acontecimientos irregulares dentro de la organización.

CUMPLIMIENTO DE SOLICITUDES

ITIL v3 establece un proceso para atender las solicitudes de los usuarios. Los objetivos de este proceso es:

- Establecer un procedimiento estándar de solicitud de servicios, por ejemplo el estándar podría ser ingresar a una pagina web y responder ciertas preguntas. - Realizar cambios menores que no sean críticos en la organización y que tampoco puedan tener un impacto en el servicio, por ejemplo la solicitud de cambio de contraseña de un usuario para algún sistema especifico; por lo general este tipo de cambios no necesitan un RFC (Request For Change). - Establecer mecanismos y protocolos de respuesta a inquietudes y preguntas de usuarios.

GESTION DE PROBLEMAS

La Gestión de problemas administra todo el ciclo de vida del problema, desde que se inicia hasta que se tiene una solución al problema, entonces aquí salta una pregunta: “¿Que es un problema para ITIL?”. ITIL hace un diferencia importante entre incidente y problema, un incidente es algo pequeño, algo asilado quizás o cuyo impacto es menor; en cambio un problema es un incidente recurrente, un incidente que afecta a muchos usuarios o un incidente de un gran impacto.

Algunos conceptos:

KnowError (KE – Error conocido): ITIL apunta a que todo problema debe ser resuelto y dar como resultado un KE, un KE es entender la causa de la falla y no necesariamente conocer la solución, es decir ITIL recomienda tener registrado todos los errores en una BD, Base de Datos de Errores conocidos (KEDB).

ITIL v3 lo ve de la siguiente manera, todo comienza en la Gestión de incidentes, el incidente es repetitivo (se convierte en un problema) y por ende pasa a la Gestión de

problemas, se investiga las causas del problema hasta dar con el origen del mismo, cuando se tiene el conocimiento necesario de las causas del problema se genera un Workaround (solución temporal) y el problema sufre un cambio, una mutación!!; pasa de ser un problema a un Know Error (KE). Por ultimo KE debe generar un RFC para hacer el cambio correspondiente y solucionar el problema, La Gestión del Cambio se encargara de este proceso.

Como habremos notado la Gestión de Incidentes y la Gestión de Problemas van de la mano y están muy relacionados. ¿De qué manera están relacionados? Lo primero que debemos notar es que la gestión de problemas no va a estar preocupándose por todos los incidentes que ocurren en la organización, la Gestión del Problema NO SOLUCIONA INCIDENTES!!!, la gestión de problemas no busca una solución rápida sino que toma cierto tiempo para investigar la causa del problema para poder eliminarla en la Gestión del Cambio.

La única manera en que la Gestión de Problemas apoya a la Gestión de Incidentes es proporcionándole soluciones temporales (workarounds).

La Gestión de Problemas tiene los siguientes procesos:

Control de problemas - Define e investiga los problemas y su principal función es transformar los problemas en KE. - La principal fuente de información para el registro de problemas es la BD del registro de incidentes.

 

Control de Errores - Se ocupa de resolver Errores Conocidos (KE) mediante la Gestión de Cambios, la Gestión de problemas se encarga de todo el ciclo de vida del problema lo que quiere decir que debe estar monitoreando el cambio que sera realizado por la Gestión de Cambios.

Como en todos los procesos de ITIL con la BD de los Errores Conocidos nosotros debemos poder sacar informes de gestión: cantidad de problemas resueltos, tiempo tomado para resolver problemas, costos asociados con los problemas, etc.

GESTION DE ACCESO

Hablar de seguridad de la información es un tema demasiado relevante en la actualidad e ITIL v3 no puede estar totalmente aislado de este tema. Si bien es cierto que el negocio de ITIL no es la seguridad porque para eso existen ISOs como la 27001, ITIL de alguna manera quiere contribuir con la Gestión de Acceso.

La gestión de acceso lo que hace es brindar derechos a los usuarios para facilitarles el uso de uno o varios servicios. Por ejemplo el día de mañana va ingresar un nuevo Director General a la organización, esta persona debe tener acceso a ciertos sistemas que normalmente no son accedidos por cualquier trabajador convencional, ESTO ES EL TRABAJO DE LA GESTION DE ACCESO.

Mantenimiento al Catálogo de Roles de Usuarios y Perfiles de Acceso   Asegurar que el Catálogo de Roles de Usuarios y los Perfiles de Acceso de Usuarios sean apropiados para los servicios ofrecidos a los clientes, y prevenir una acumulación indeseada de derechos de acceso.  Procesamiento de Solicitudes de Acceso al Usuario Procesar pedidos para agregar, cambiar o revocar derechos de acceso, y asegurar que sólo los usuarios autorizados tengan derecho a usar determinados servicios.