ITIL V3: Service Operation (Operacin 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 haba aburrido de escribir, djenme decirles que uno de mis principales defectos (o quizs virtud.) es estar siempre estudiando algo, lo que me resta tiempo para cosas como escribir en mi blog y dems 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: - Introduccin a ITIL v3 - Estrategia del Servicio - Diseo del Servicio - Transicin del Servicio Habamos dejado la accin en la implementacin del servicio (Transicin del Servicio ST), acurdense que en la ST habamos visto la gestin del cambio, gestin del activo servicio y configuracin, y la gestin del despliegue, lo recuerdan, verdad?. Pues la lgica me indica que despus 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 algn mantenimiento? Analicemos un poco, los desarrolladores siempre tienen nuevos requerimientos por parte de los usuarios, los DBA siempre tienen que monitorear que sus BDs estn funcionando, los sysadmin revisar que todo el sistema corporativo este funcionando y as podra pasarme todo el da 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 lneas arriba he tratado de resumir lo que hace la Operacin del Servicio y que entramos a analizar en este mismo instante: Definicin, metas y objetivos SO (Service Operation), conduce, gestiona y controla las operaciones del da a da 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 das, 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 logstica 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. Terminologa: En este tema existen muchos trminos nuevos y definiciones muy tcnicas as que me gustara explicarlo mejor con un ejemplo para que quede bien claro: Se tiene una aplicacin llamada ABC programada en Java que utiliza una BD Oracle, esta aplicacin es accedida mediante un browser por los clientes quienes agregan informacin de manera diaria. Cierto da, 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 das 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 da (y justo fin de mes) llama un cliente indicando que el sistema ABC no funciona y que no puede adjuntar informacin 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 pequea historia que es totalmente real, tenemos: Evento: Aumento del consumo del ancho de banda en un 40% (lo mas seguro es que algn usuario estaba agregando bastante informacin) 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 (Solucin 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 solucin y causa del problema esta documentada. Reactivo: Personas que actan solo frente a un aviso o problema. Proactivo: Personas que estn en bsqueda 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 podramos decirle al cliente que el tiempo de respuesta frente a la cada de un servicio ser de solo 10 minutos pero necesitamos: - Herramientas costosas de monitoreo, con un valor aprox de 30 mil dlares anuales - 25 personas dedicadas al rea de TI, con un valor de 100 mil dlares 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 Operacin del servicio son: - Gestin de Incidentes - Gestin de Eventos - Cumplimiento de Solicitudes - Gestin de Problemas - Gestin de Accesos GESTION DE INCIDENTES El objetivo principal de la Gestin de incidentes es restaurar los niveles normales del servicio lo mas rpido posible, asegurando el cumplimiento del SLA (calidad, tiempo y disponibilidad)

El diagrama explica la relacin entre un incidente, problemas, KE (error conocido), workaround (solucin 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 jerrquico (vertical): Cuando se necesita de autoridad para realizar una accin. Sobre los tipos de escalamiento, siempre vienen preguntas en el examen de ITIL.

Lo que hace la gestin de incidentes se puede resumir en un solo grafico.

La gestin de incidentes tiene un proceso bastante grande y por consiguiente complejo, voy a describir al detalle cada uno de las actividades del proceso: Deteccin, comunicacin y registro Parece sencillo poder describir la deteccin de incidentes y en efecto la descripcin es sencilla pero la implementacin no lo es, ITIL recomienda herramientas automatizadas para la deteccin de un incidente; cuando hablamos de herramientas automatizadas estamos hablando de SOFTWARE que nos ayude en dicha funcin. 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 deteccin de un incidente no sea la llamada de alerta de un usuario sino que sea un mecanismo de alerta automatizado. Entonces la deteccin debera 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 deteccin 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 podra resultar y parecer. Dnde 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 deberan concordar con nuestra BD de incidentes. Qu registro? Pues absolutamente todo!!! ITIL recomienda registrar lo siguiente: Numero de identificacin, clasificacin, fecha, quien detecto el incidente, sntomas, categoras, IMPACTO, PRIORIDAD, CIs, KnowError, fecha de resolucin y notas de seguimiento. Como habrn notado el xito de la implementacin de ITIL esta en NO SUPONER u OBVIAR DETALLES. A quin 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.

Clasificacin, comparacin y apoyo inicial La imagen superior muestra un ejemplo de clasificacin, ITIL no te dice como debes clasificarlo eso depende de los procesos de la organizacin, de la misma manera la clasificacin por prioridad debe regirse a polticas particulares dentro de la organizacin. Despus de haber detectado el problema la gestin de incidentes debe tratar de resolver de manera rpida, ellos son la primera lnea 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 sntomas de otros incidentes. Investigacin y diagnostico Despus de haber sido detectado, registrado, clasificado y no haber podido resolver el problema de manera rpida, pasamos a la investigacin del incidente hasta dar con la causa del problema. Este proceso puede pasar por distintos niveles de escalamiento y de expertos. Resolucin y Recuperacin 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 tambin hay tener en cuenta como por ejemplo MANTENER AL USUARIO SIEMPRE INFORMADO!, cmo 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 rpidamente distrayendo a los especialista en temas que no son importantes. (ESTA ES PREGUNTA DE CERTIFICACION ITIL).

Y por ultimo y quizs el mayor problema que presenta la gestin de incidentes es la falta de un SLA y Catalogo de servicios, cuando estos documentos no estn presentes cualquier problema relacin con tecnologa va ser automticamente 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 gestin de incidentes que respondan a las siguientes preguntas: - Cuntos incidentes se han presentado en un periodo de tiempo? - Cuntos incidentes de software hemos tenido? - Cuntos 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 rpida y presta deteccin de incidentes u acontecimientos irregulares dentro de la organizacin. CUMPLIMIENTO DE SOLICITUDES ITIL v3 establece un proceso para atender las solicitudes de los usuarios. Los objetivos de este proceso es:

- Establecer un procedimiento estndar de solicitud de servicios, por ejemplo el estndar podra ser ingresar a una pagina web y responder ciertas preguntas. - Realizar cambios menores que no sean crticos en la organizacin y que tampoco puedan tener un impacto en el servicio, por ejemplo la solicitud de cambio de contrasea de un usuario para algn 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 Gestin de problemas administra todo el ciclo de vida del problema, desde que se inicia hasta que se tiene una solucin 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 pequeo, algo asilado quizs 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 solucin, 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 Gestin de incidentes, el incidente es repetitivo (se convierte en un problema) y por ende pasa a la Gestin 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 (solucin temporal) y el problema sufre un cambio, una mutacin!!; 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 Gestin del Cambio se encargara de este proceso. Como habremos notado la Gestin de Incidentes y la Gestin de Problemas van de la mano y estn muy relacionados. De qu manera estn relacionados? Lo primero que debemos notar es que la gestin de problemas no va a estar preocupndose por todos los incidentes que ocurren en la organizacin, la Gestin del Problema NO SOLUCIONA INCIDENTES!!!, la gestin de problemas no busca una solucin rpida sino que toma cierto tiempo para investigar la causa del problema para poder eliminarla en la Gestin del Cambio. La nica manera en que la Gestin de Problemas apoya a la Gestin de Incidentes es proporcionndole soluciones temporales (workarounds).

La Gestin de Problemas tiene los siguientes procesos: Control de problemas - Define e investiga los problemas y su principal funcin es transformar los problemas en KE. - La principal fuente de informacin para el registro de problemas es la BD del registro de incidentes.

Control de Errores - Se ocupa de resolver Errores Conocidos (KE) mediante la Gestin de Cambios, la Gestin 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 Gestin de Cambios.

Como en todos los procesos de ITIL con la BD de los Errores Conocidos nosotros debemos poder sacar informes de gestin: cantidad de problemas resueltos, tiempo tomado para resolver problemas, costos asociados con los problemas, etc. GESTION DE ACCESO Hablar de seguridad de la informacin 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 Gestin de Acceso. La gestin de acceso lo que hace es brindar derechos a los usuarios para facilitarles el uso de uno o varios servicios. Por ejemplo el da de maana va ingresar un nuevo Director General a la organizacin, 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 Catlogo de Roles de Usuarios y Perfiles de Acceso Asegurar que el Catlogo de Roles de Usuarios y los Perfiles de Acceso de Usuarios sean apropiados para los servicios ofrecidos a los clientes, y prevenir una acumulacin 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 slo los usuarios autorizados tengan derecho a usar determinados servicios.