Sistemas Empresarios Dirección de Sistemas

Transcripción

1 Sistemas Empresarios Dirección de Sistemas Claudio Schicht UCA 0 Introducción Antecedentes ITIL ITIL es Information Technology Infrastructure Library. A fines de los 80 s el gobierno británicoinicióunestudioentre empresas privadas de UK. Como resultado del estudio desarroll desarrolló un modelo general de procesos y publicó libros sobre temas relacionados con la administración de la infraestructura. Con el tiempo, sus principios y guías se convirtieron en bestpractices para los procesos del área TI, primero en Europa y luego en USA. Actualmente, es el compendio de best-practices más reconocido y aceptado para administrar la infraestructura y servicios TI. 1 1

2 Introducción Evolución ITIL En 1987 la CCTA, como resultado de un estudio, desarrolló un 1987 modelo general de procesos y publicó 26 libros sobre administración de la infraestructura para el sector público. En 1991, la CCTA respondió a pedidos del mercado y consolidó 1991 una primera versión de más de 40 libros. Estaba orientada a ambientes centralizados basados en mainframes. Entre 2001 y 2004 se editó la segunda versión compuesta por 8 libros. Empezó a privar el concepto de administración de servicios 2001 sobre el de administración de la infraestructura. La OGC reemplaza a la CCTA como responsable de la edición. En 2004 la OGC inició un proyecto para una nueva versión de ITIL. Concluyó con el lanzamiento de ITILv3 en Está 2007 compuesta por 5 libros. Se adopta el modelo de ciclo de vida de la administración de servicios. En Julio 2011 se lanza al mercado la actualización de ITILv3, 2011 denominada. Está compuesta también por 5 libros. La OGC pasa a depender del Cabinet Office. CCTA: Central Communications and Telecom Agency OGC: Office of Government Commerce 2 Administración de Servicios Introducción Administración Efectiva Una correcta y eficiente Administración de Servicios requiere: Una re-ingeniería de los procesos, para que se ajusten a la nea nueva tecnología y necesidades del negocio. Tecnologías que soporten a los procesos (process-enabled technologies) y herramientas para automatizar y apoyar la gestión del área TI. Una organización TI con objetivos diferentes: Orientada al Servicio. Focalizada en el Cliente. Cultura de Servicio. Preocupada por la mejora constante de la calidad. ITSM (IT Service Management) es un concepto/esquema que permite a las Organizaciones TI alcanzar estos objetivos. 3 2

3 Administración de Servicios Qué es Infraestructura? Es el conjunto de componentes TI (*) necesarios para desarrollar, entregar y soportar servicios i TI. (*): Incluye al hardware, software, redes de comunicación, ambiente físico, etc. pero no a las personas, los procesos y la documentación asociadas. 4 Administración de Servicios Qué es un Servicio? Es suna forma deentregar eg valor a clientes, facilitando un resultado que desean obtener, sin la responsabilidad por los costos y riesgos específicos requeridos para lograrlo. l Puede consistir en software, hardware e infraestructura de comunicaciones, pero los clientes lo perciben como una unidad. Es provisto a uno o más clientes por un proveedor de servicios TI. 5 3

4 Administración de Servicios Delegación La provisión ió de un Servicio i supone la delegación de ciertas responsabilidades de un Cliente hacia un Proveedor, buscando algún valor (mayor calidad, beneficios i económicos, etc.), por el que estaría dispuesto a pagar. 6 Administración de Servicios Cliente y Usuario Cliente es quien paga por el servicio TI. Usuario es quien lo utiliza. Cliente y Usuario pueden coincidir, aunque por lo general estos roles los ejercen personas distintas. 7 4

5 Administración de Servicios Características de un Servicio Un servicio es intangible. No se puede almacenar (non-storable). Los servicios son al mismo tiempo (o casi) producidos y consumidos. La demanda está íntimamente relacionada con los activos de un cliente, que son los que demandan y estimulan la provisión del servicio. El resultado de un servicio y la capacidad de un servicio son perecederos. El cliente percibe valor en la provisión continua de un servicio con una calidad consistente. Producto Servicio Desarrollo Entrega Desarrollo Entrega 8 ITIL Conceptos ITIL no es una metodología. Es un conjunto de bestpractices y guías. ITIL no es un estándar. Sin embargo existen estándares basados en ITIL y existe una norma de la ISO en este sentido. ITIL es no propietaria. Sus libros son de dominio público. ITIL no es una receta. Las organizaciones deben adaptar las guías de ITIL a su propio ambiente y estructura (best practices?). ITIL no es una revolución. Es un camino de evolución que debe transitar cada organización. 9 5

6 ITIL ISO La BS15000 fue el primer estándar mundial orientado específicamente a IT Service Management. Fue desarrollado por la BSI (British Standard Institution) que elabora y mantiene estándares y soluciones estandarizadas en UK. La primera edición de la BS15000 fue publicada en el año Una segunda edición se editó en el año La BS15000 se ha convertido en un estándar internacional de la ISO. A través de un fast-track fue emitida la ISO La ISO apareció el 15.Dic En Abril 2011 la ISO emitió una nueva versión, conocida como ISO 20000: ITIL Esquema de Libros de ITIL ITIL consiste en un conjunto de publicaciones represen- tadas por un Core Best Practices Guidance y Value Added Products. Este enfoque permite que las Core Best Practices permanezcan razonablemente constantes y genéricas en el tiempo, mientras que el resto pueda ser revisado y actualizado más frecuentemente. Core Best Practices 11 6

7 ITIL Core Best Practices Guidance Se analizaron varias estructuras posibles para la organi- zación de las Core Best Practices Guidance. Hubo consenso generalizado para la adopción de un modelo que siga el ciclo de vida de la administración de servicios: Service Strategy Service Design Service Transition Service Operation Continual Service Improvement ITIL Principales Libros de ITIL 2011 SERVICE STRATEGY: Provee una guía para ver a la administración de servicios, no sólo como una habilidad organizacional, si no como un activo estratégico. Incluye tópicos para el desarrollo de la estrategia de servicios, la gestión del portafolio, la administración financiera, el desarrollo organizacional, la gestión de la demanda y la gestión de riesgos estratégicos. SERVICE DESIGN: Esta publicación provee guías para el diseño y el desarrollo de servicios TI y de procesos de la administración de servicios. Describe los conceptos y métodos de diseño para convertir los objetivos estratégicos del negocio en servicios TI. Cubre el diseño de nuevos servicios como así también de cambios a los servicios existentes. SERVICE TRANSITION: Provee guías para el desarrollo e implantación de habilidades para poner en marcha nuevos servicios o cambios en los ya implantados en el ambiente productivo. Describe como realizar la transición de la organización de un estado a otro controlando los riegos y soportando el conocimiento. Incluye la gestión de cambio, de configuraciones y liberaciones. 13 7

8 ITIL Principales Libros de ITIL 2011 SERVICE OPERATION: Presenta las pautas para la provisión y el soporte efectivo y eficiente de los servicios TI, asegurando valor para el negocio. Provee guías para mantener la estabilidad de los servicios TI implantados. Es a través de los procesos de este libro que el cliente concreta los objetivos estratégicos definidos. CONTINUAL SERVICE IMPROVEMENT: Esta publicación brinda guías para la creación y el mantenimiento del valor para el negocio a través del mejoramiento continuo de los servicios TI. Provee prácticas y métodos de administración de calidad, de administración del cambio y de mejora continua de la capacidad y habilidad. OFFICIAL INTRODUCTION to the ITIL SERVICE LIFECYCLE: Es una actualización de las guías anteriores. Presenta una introducción a los cinco libros principales y a los conceptos básicos de ITIL y de Administración de Servicios. Incluye también modelos de alto nivel de los procesos de ITIL. 14 ITIL Resumen de Procesos Design Coordination Service Catalogue Management Transition Planning & Support Service Level Management Change Management Strategy Management for IT Services Availability Management Service Asset & Configuration Mgm Event Management Service Portfolio Management Capacity Management Release and Deployment Mgm Incident Management Financial Management for IT Services IT Service Continuity Management Service Validation and Testing Request Fulfilment Demand Management Information Security Management Change Evaluation Problem Management Business Relationship Management Supplier Management Knowledge Management Access Management 7 Step Improvement Process 15 8

9 Service Operation Conceptos Fundamentales Propósito Coordinar y llevar a cabo las actividades y los procesos requeridos para proveer y administrar los servicios TI según los niveles acordados con los clientes y usuarios. Service Operation es también responsable por la operación y administración diaria de la TI que es utilizada para la provisión y el soporte de los servicios TI. Realiza el control y monitoreo sistemático de la performance y obtiene los datos para la mejora de los servicios TI. SO Incident Management Propósito Recuperar el normal funcionamiento de un servicio tan pronto como sea posible, para minimizar el impacto adverso en el negocio. 17 9

10 Incident Management Qué es un Incidente? Es una interrupción no planeada o una reducción en la calidad de un servicio TI. También es un incidente una falla en un componente TI que aún no ha impactado un servicio TI. 18 Incident Management Cuáles son Ejemplos de Incidentes? Una falla de hardware. Un error de software. Una caída en la red. Un pedido de cambio de clave. Un alta de un nuevo usuario. Un pedido de suministros. Un pedido de información. Un virus que ingresó a un equipo. Una consulta de un usuario. Un pedido de cambio de software. Un alerta en un equipo. Un pedido de mudanza de equipo. Una extensión de un servicio. Una baja performance. Una falta de espacio en disco. Una falla en el back-up nocturno. Un Pedido de Cambio (RFC Request for Change) no es un incidente. Un Pedido de Servicio (SR Service Request) tampoco

11 Incident Management Qué es un Pedido de Cambio? Es una propuesta formal de un cambio que se desea realizar. 20 Incident Management Qué es un Pedido de Servicio? Es un pedido formal de un usuario de algo a ser provisto: una consulta, una requisición de un consumible, cambios pequeños y estandarizados (p. ej: mudanza de un equipo)

12 Usuario Availability Mgm. Capacity Mgm. Problem Management Change Management Incident Management Ciclo de Vida de los Incidentes Identificación Registro Categorización Diagnóstico Resolución Recuperación CI s Incidentes SLA KE s CMDB SKMS KEDB Informes Knowledge Mgm. Cierre SKMS: Service Knowledge Management System CMDB: Configuration Management Data Base KEDB: Known Error Data Base KE: Known Error CI: Configuration Item SLA: Service Level Agreement 22 Incident Management Categorización y Priorización La categorización del incidente es fundamental para su adecuado tratamiento y pronta resolución (o sea, eficiencia y eficacia). La categoría dfi define el recorrido dl del escalado ld (hardware, software, red, etc.). Una categoría equivocada puede hacer que un incidente navegue sin rumbo dentro del área TI. También se define una prioridad: Prioridad: secuencia en que se tratarán los incidentes. Se determina por el impacto, la urgencia y el esfuerzo. Impacto: desde el punto de vista del negocio. Urgencia: es la velocidad con la que debe resolverse el incidente. La prioridad y la urgencia no se definen en base a la presión del usuario sino según los procedimientos y los acuerdos de servicio. Deben usarse códigos uniformes y preestablecidos

13 1er. Nivel de Soporte Incident Management Escalado de Incidentes 2do. Nivel de Soporte 3er. Nivel o Especialista Detección y Registro Diagnóstico Escalado es el mecanismo que permite la resolución oportuna de un incidente. Es la base para lograr la eficiencia y la eficacia en la resolución de incidentes. No Resuelto Si Resoluc. y Recuper. Diagnóstico No Resuelto Si Diagnóstico Cierre Resoluc. y Recuper. Si Resuelto Resoluc. y Recuper. 24 Incident Management Escalado de Incidentes Escalado Funcional 1er. Nivel 2do. Nivel 3er. Nivel Proveedor Escalado Jerárquico Operador Supervisor Gerente de Director de S. Desk S. Desk Servicios Sistemas Tiene lugar en cualquier momento durante la resolución

14 Incident Management Cierre El Service Desk debe controlar que el incidente este completamente resuelto y que el usuario este satisfecho para producir el cierre. El Service Desk debe: Controlar y confirmar que la categorización original fue correcta, y en caso contrario, corregirla. Realizar una encuesta de satisfacción del usuario. Este paso es optativo (algunas organizaciones prefieren otras medios, dados algunos inconvenientes de la encuesta al cierre) o puede hacerse por muestreo. Asegurarse que toda la documentación del incidente esté completa. Evaluar si el incidente puede repetirse y alertar a Problem Management. Efectuar el cierre formal del incidente. 26 Incident Management Beneficios Reducción del impacto de los incidentes en la organización. Infraestructura mejor manejada y controlada. Mejor utilización de los recursos de TI e incremento de la productividad del personal de TI. Habilidad para alinear la actividad TI a las prioridades de plazo del negocio. Reducción de incidentes perdidos o desatendidos. Mayor satisfacción de los usuarios. Información más precisa y confiable sobre la infraestructura TI

15 Incident Management Resumen Incident Management es una tarea reactiva. La caracteriza un sentido de urgencia en la solución de incidentes. Su propósito fundamental es la coordinación ió de las distintas t áreas de soporte para agilizar la resolución. Esta coordinación busca romper los clásicos silos de la organización TI y mantener la calidad del servicio tal como fue definida en los SLA s. Logra su objetivo a través de: Un adecuado proceso de escalado. Una correcta categorización y priorización. El entrenamiento de sus recursos y el uso de bases de conocimiento y lecciones aprendidas. SLA: Service Level Agreement 28 Request Fulfilment Propósito Manejar el ciclo de vida de todos los pedidos de servicio de los usuarios

16 Request Fulfilment Alcance El proceso para manejar SR s varía de acuerdo con lo que realmente se solicita. Sin embargo, existe un conjunto de actividades comunes que debenrealizarse e para satisfacer s estas s demandas. d Algunas organizaciones prefieren manejarlos a través del mismo proceso de incidentes. En este caso, las Peticiones de Servicio son tratadas como un tipo especial de incidente. Sin embargo, en aquellas organizaciones que tienen un gran número y variedad de SR s conviene manejarlos a través de un proceso separado. Los incidentes son usualmente no planeados mientras que las peticiones pueden y deben ser planificadas. Cada organización debe definir qué SR s son manejadas a través de este proceso y cuáles son gestionadas por otros procesos. SR: Service Request 30 Request Fulfilment Conceptos Básicos (1) El término Petición de Servicio es usado en forma genérica para describir una variada gama de demandas que hacen los usuarios al áreati. Muchas de estas demandas son en realidad pequeños cambios, pero la frecuencia y cantidad de los mismos hace que sea mejor manejarlos con un proceso separado y específico, para no congestionar y obstruir el normal funcionamiento de los procesos de gestión de incidentes y gestión de cambios. Algunas peticiones se realizan de manera frecuente y deben ser manejados en forma consistente para cumplir con niveles de servicio acordados. En estos casos se suelen usar Modelos de Petición. Las SR s deben ser priorizadas teniendo en cuenta la urgencia y el impacto (de manera similar a los incidentes). SR: Service Request 31 16

17 Request Fulfilment Conceptos Básicos (2) Muchas Peticiones de Servicio (SR) son resueltas directamente por el usuario a través de herramientas de auto-ayuda. Un paso importante en la resolución de Peticiones de Servicio es la preaprobación financiera. Las SR s requieren también de otras aprobaciones, como compatibilidad con otros componentes o servicios, niveles de autoridad para requerir, licencias disponibles, etc. El cumplimiento de las SR s es realizado por el Service Desk y grupos de soporte local. Una vez cumplida, una SR debe ser cerrada siguiendo procedimientos similares a un incidente. SR: Service Request 32 Request Fulfilment Ciclo de Vida de los Pedidos de Servicio Usuario Recibir Pedido Registrar y Validar Categorizar y Priorizar CI s Pedidos SLA CMDB SKMS Financial Mgm. Access Management Autorizar Pedido Change Management Resolver Modelos SKMS Revisar Financial Mgm. Cerrar Pedido CI: Configuration Item SLA: Service Level Agreement SKMS: Service Knowledge Management System CMDB: Configuration Management Data Base 33 17

18 Funciones Funciones Definidas por ITIL 2011 Technical Management IT Operations Management Application Management Mainframe Server Network Database Desktop Internet Storage IT Operations Control Facilities Management ERP RR. HH. CRM Producción Logística Service Desk 34 Service Desk Definición Es el punto único de contacto entre el proveedor de servicios y los usuarios. El SD típicamente maneja incidentes y SR s y las comunicaciones i con los usuarios. SD: Service Desk SR: Service Request 35 18

19 Service Desk Objetivos Ser el único punto de contacto con clientes/usuarios (SPOC Single Point of Contact) para todas las comunicaciones desde y hacia el área TI. Recuperar el servicio tan pronto como sea posible, maximizando su disponibilidad según los acuerdos de servicio. Administrar todos los incidentes de punta a punta (ownership) hasta lograr el cierre con la conformidad del cliente/usuario. Es responsable por el escalado de los incidentes. Conocer las necesidades del negocio para evaluar mejor el impacto de una falla en los servicios. El Service Desk es el representante del cliente ante el área TI y, al mismo tiempo, el representante de TI ante el cliente. 36 Service Desk Consideraciones El SD actúa como filtro ante la organización TI para preguntas irrelevantes y temas sencillos. Ordena el trabajo de los RRHH de soporte. Sigue y mantiene actualizada la información de los incidentes. Se busca que sus recursos tengan un equilibrio entre habilidades blandas y conocimientos técnicos: Habilidades d de comunicación ió y escucha. Capacidad de trabajo en equipo. Empatía con el usuario y conocimiento del negocio. Cortesía y predisposición. Proactividad y venta de servicios. Notificación de logros. SD: Service Desk 37 19

20 Service Desk Diferentes Alcances y Propósitos Call Center: maneja grandes volúmenes de transacciones/comunicaciones mayor- mente de entrada. Sólo registra llamadas. No da soluciones. Help Desk: maneja, resuelve y sigue sólo incidentes(esdecirfallasenocaídasde servicios). Dependiendo de la tecnología utilizada a veces se lo denomina también Hot Line. Service Desk: es más amplio que el Help Desk. Maneja, resuelve y sigue, no sólo incidentes, sino también consultas, pedidos de cambio (RFC s), pedidos de servicio (SR s), etc. También informa a los usuarios y vende servicios TI. 38 Service Desk Flujo de Información Cliente/Usuario Service Desk Soporte TI Se comunica por teléfono, vía mail, a través de Internet o por contacto personal. Fallas, cambios y extensiones, consultas, inquietudes, nuevos servicios. Recibe información por teléfono, mail, Internet o personalmente. También herramientas de autoayuda (Intranet). SD: Service Desk Identifica, registra, categoriza, diagnostica, resuelve. Escala el incidente al nivel correspondiente. También recibe incidentes automáticos. Verifica satisfacción y cierra el incidente. Informa al usuario estado de situación. Otras comunicaciones. Diagnostica y resuelve. Escala si no puede resolver (desktop, redes, desarrollo, proveedores internos y externos). También comunica incidentes al SD. Cuando resuelve informa al SD. Informa cortes en los servicios y mantenimientos, cambios en curso, etc

21 Service Desk Local Diseñado para soportar necesidades locales. El soporte está en el mismo lugar físico que los usuarios. Destinado a organizaciones pequeñas. SPOC: Single Point of Contact Service Desk Estructuras de Service Desk Service Desk Central Ideal para grandes organizaciones. El soporte está en una ubicación central mientras que los usuarios están dispersos geográficamente. Debe complementar- e se con recursos locales. Service Desk Virtual Tanto los recursos de soporte como los usuarios están dispersos geográficamente. Se requieren procesos uniformes y un SPOC por cliente. 40 Problem Management Propósito Minimizar i i el impacto adverso de incidentes y problemas en el negocio y prevenir la recurrencia de incidentes. SO

22 Problem Management Alcance La causa raíz de algunos incidentes no es obvia y estos pueden repetirse. También es importante prevenir incidentes. Por ello, Problem Management: Busca la causa subyacente de los incidentes para solucionarlos definitivamente, evitando su repetición. Trabaja en forma reactiva, ante incidentes repetitivos e incidentes mayores. Actúa en forma proactiva, buscando en la infraestructura aspectos que pueden derivar en incidentes. Mantiene una KEDB y propone mejoras en workarounds para ayudar a Incident Management a resolver incidentes más rápidamente. Conduce revisiones de incidentes mayores. Realiza revisiones programadas de los logs, operativos y de eventos, y de otros registros buscando patrones y tendencias que pueden indicar la existencia de algún problema. KEDB: Known Error Data Base SO Problem Management Incident Mgm. vs. Problem Mgm. Incident Management Más preocupado por reestablecer el servicio ii a los niveles acordados dd que por la calidad de la solución. No persigue la búsqueda de soluciones definitivas, aunque puede proponerlas. Trabaja en forma reactiva. Problem Management Más preocupado por la prevención y por la calidad d de la solución que por el plazo de resolución. Identifica soluciones permanentes. Este proceso puede llevar más tiempo que el requerido para resolver un incidente. Busca formas más eficientes y efectivasde solucionar incidentes. id Trabaja en forma reactiva y proactiva. Aunque Incident y Problem Management son procesos separados y con propósitos distintos, están muy estrechamente relacionados y comparten métodos de categorización y priorización y herramientas. SO

23 Problem Management Qué es un Problema? Un problema es la causa subyacente de uno o más incidentes. Cuando se encuentra esta causa, y se conoce la solución, un problema deja de ser tal y se transforma en un error conocido. SO 97 y Problem Management Qué es un Error Conocido? Un error conocido es un incidente o un problema para el cual se conoce la causa subyacente que lo produce y se ha identificado una solución transitoria (workaround) o una definitiva. SO 104 y

24 Problem Management Qué es un Workaround? Es la reducción o la eliminación del impacto de un Incidente o de un Problema, para los cuales no existe aún una resolución o solución definitiva. SO 104 y Problem Management Incidentes, Problemas y Errores Conocidos Un incidente tiene su propio ciclo. Nace y muere como incidente. Nunca un incidente se transforma en un problema. Un incidente mayor o un incidente no cerrado da lugar a un problema. El problema tiene su propio ciclo. RFC: Request for Change Un incidente menor que se reitera varias veces da lugar a un problema. Incidente Problema Cuando un error conocido se soluciona, generalmente a través de un RFC, se cierra. Error Conocido El error también tiene su propio ciclo. Un problema diagnosticado y con un workaround da lugar a un error conocido. El problema se cierra

25 Incident tmanagement KEDB Problemas Problem Management Ciclo de Vida de los Problemas Problema Detección Registro Categorización y Priorización Error Registro Necesita cambio? No Resolución Si KE s KEDB Change Management CMDB Investigación y Diagnóstico Knowledge Mgm. Cierre Revisión Problemas Mayores Seguimiento Informes KEDB: Known Error Data Base KE s: Known Errors SO 102 CMDB: Configuration Management Data Base 48 Problem Management Beneficios Disminución de la cantidad de incidentes. Mayor productividad de los RRHH de sistemas. Recuperación más rápida de incidentes y fallas. Mayor disponibilidad de los servicios TI. Aumenta la cantidad de incidentes que puede solucionar el Service Desk. El área TI incrementa el conocimiento sobre el comportamiento de la infraestructura a través de un proceso metódico de análisis de fallas y una revisión proactiva de los principales elementos

26 Service Design Conceptos Fundamentales Propósito Diseñar nuevos servicios TI, o cambios en servicios TI existentes, para su introducción en el ambiente productivo. Adoptar un enfoque integral, que tenga en cuenta todos los aspectos del diseño, para asegurar la consistencia e integración de todos los elementos y de todos los procesos a lo largo del ciclo de vida. 50 Service Level Management Propósito Mantener y mejorar la calidad de los servicios TI a través de la definición, negociación y administración i ió de niveles de servicio

27 Service Level Management Consideraciones SLM debe asegurar que la calidad de los servicios que entrega el proveedor cubre las expectativas y percepciones del negocio y de los clientes. En este sentido, SLM es el representante de los clientes ante el proveedor y del proveedor ante los clientes. En algunos proveedores externos, los procesos de SLM se entrelazan con los de CRM y algunas responsabilidades son asignadas a Ejecutivos de Cuenta. SLM no sólo le conciernen los servicios TI actuales, sino también los requerimientos de cambios o de nuevos servicios. Se involucra en forma temprana en el diseño para analizar si los requerimientos podrán ser cumplidos por el proveedor. SLM: Service Level Management 52 Service Level Management Qué es Acuerdo de Nivel de Servicios? Es un acuerdo escrito entre un proveedor y un cliente, en el que se definen los objetivos clave del servicio (niveles) y las responsabilidades de ambas partes

28 Service Level Management Contenido de un SLA Servicios incluidos. Alcance y descripción del servicio. Días y horarios en los cuales el servicio estará disponible. Niveles de servicio. Medidas de disponibilidad y confiabilidad. Descripción del soporte: a quién contactar, cómo y cuándo. Tiempos de respuestadl del soporte y tiempos de reparación previstos. Extensión del servicio: cómo solicitarla, a quién, anticipación. Duración del SLA. SLA: Service Level Agreement Procesamiento batch: entregables, plazos, proceso de recepción y entrega. Solicitudes de cambio. Costos y forma de facturación. Responsabilidades y penalidades para el cliente y para TI. Acciones de contingencia: plazos de recuperación, nivel de servicio en la contingencia, etc. Reuniones de seguimiento. Reporting y proceso de revisión. Glosario. Firmantes. 54 Service Level Management Tipos Básicos de SLA s Acuerdo Basado en un Servicio Acuerdo Basado en un Cliente Cliente 1 Cliente 2 Cliente N Cliente Acuerdo de Nivel de Servicio Acuerdo de Nivel de Servicio Servicio Servicio 1 Servicio 2 Servicio N Infraestructura TI Infraestructura TI SLA: Service Level Agreement 55 28

29 Service Level Management Estructura de Soporte de SLA s Clientes Clientes SLA Service Level Agreements Operational Level Agreements SLA Infraestructura TI Service Level Agreements Underpinning Contracts SLA OLA OLA UC UC Proveedores Internos Proveedores Externos 56 S. Catalogue Mgm. AM, CM, ITSCM, ISM Service Level Management Principales Actividades SLR s Diseño Monitoreo Reportes de Seguimiento Soft Issues Manejo de Expectativas. Contratos y Acuerdos Revisados. Esquemas SLA s Estructura SLA Contratos Tipo Requerimientos y SLR s Monitoreo Satisfacción del Cliente OLA s y UC s SLA: Service Level Agreement OLA: Operational Level Agreement UC: Underpinning Contract SLA Piloto SLA Definitivo Reportes Revisión ió y Mejora Servicios Revisión SLA s, OLA s y UC s Desarrollo Contactos y Relaciones Manejo Quejas y Reconocimientos Reportes Periódicos SIP Reuniones Mejoras SLA s Mejoras UC s Mejoras OLA s Confianza Entendimiento Negocio Registro Resolución 57 29

30 Service Transition Conceptos Fundamentales Propósito Asegurar que un servicio pueda ser administrado, operado y soportado de acuerdo con los requerimientos y restricciones especificados en el diseño. Proveer un esquema consistente y riguroso para evaluar las características y el perfil de riesgo de un cambio, antes de que sea implantado. Establecer y mantener la integridad de todos los activos y configuraciones de un servicio, a lo largo de todo su ciclo de vida. Proveer un método eficiente y repetible de construir e implantar servicios. 58 Service Transition Integración de Procesos C h a n g e M a n a g e m e n t RFC1 RFC2 RFC3 RFC4 RFC5 RFC6 S e r v i c e A s s e t and C o n f i g u r a t i o n M a n a g e m e n t BL BL BL BL BL BL BL Service Transition Planning and Support Evaluation E1 E2 E3 Plan and Prepare Release Build and Test Service Testing and Pilots Plan and Prepare Deployment Transfer, Deploy and Retire Review and Close Release and Deployment Mgm. Early Life Support Service Validation and Testing K n o w l e d g e M a n a g e m e n t RFC: Request for Change BL: Baseline 59 30

31 Change Management Propósito Manejar todos los cambios que pueden impactar en la habilidad de la TI de proveer servicios. ii 60 Change Management Objetivos Evaluar el impacto de los requerimientos de cambios que se efectúan. Aceptar o rechazar los requerimientos de cambios. Controlar el proceso de cambio para asegurar que los mismos son efectivamente concretados. Seguir el proceso de cambio para evitar que se produzcan inconvenientes durante la alteración de la configuración. Recoger información del proceso de cambio para reportes y estadísticas futuras

32 Change Management Consideraciones (1) No todos los cambios a un servicio son benéficos. Por lo tanto, debe evaluarse el impacto de cada uno de los requerimientos. Los cambios a algunos CI s tienen un impacto mayor sobre un servicio y deben ser más cuidadosamente evaluados y controlados. El control de los cambios no es una tarea sencilla. Por el contrario, existen numerosas oportunidades para que se introduzcan cambios, aparentemente inocuos y/o simples, con graves consecuencias en la infraestructura. CI: Configuration Item 62 Change Management Cambios Estándar Son cambios a un servicio o a un componente cuyo enfoque ha sido preautorizado por Change Management. Tienen un procedimiento establecido y aceptado. Por lo general, se asocian con un Modelo de Cambio. Se aplican a cambios pequeños y repetitivos. En algunos casos, los Cambios Estándar son delegados a funciones específicas de la organización TI, como podría ser el Service Desk. Elementos cruciales: Existe un disparador d (trigger) )dfiid definido para iniciari i el cambio. ST 48 Las tareas son bien conocidas y han sido documentadas y probadas. Generalmente tiene una aprobación presupuestaria. El riesgo es bajo y bien conocido

33 Change Management Cambios de Emergencia Debieran estar reservados a la reparación de errores en un servicio TI que tienen un alto impacto negativo en el negocio. No debieran usarse para introducir nuevos requerimientos que el negocio necesita en forma urgente. Estos cambios deben manejarse como cambios normales. La cantidad de Cambios de Emergencia debe mantenerse estrictamente en un mínimo, porque son proclives al error y afectan la estabilidad de los servicios TI. En la aprobación de Cambios de Emergencia participa p un ECAB (Emergency CAB). Se debe seguir el procedimiento normal de cambios, excepto para la aprobación (ECAB), las pruebas (pueden ser reducidas) y la documentación (puede actualizarse más tarde). ST Change Management Principales Pasos de un Cambio Normal Registrar RFC Solicitado Revisar RFC Para Evaluación Crear RFC Propuesta (Opcional) Evaluar Cambio Autorizar Construcción y Prueba Para Decisión Autorizado Change Initiator Coordinar Construcción y Prueba Creado Change Management Change Authority Autorizar Despliegue Programado RFC: Request for Change ST 70 Revisar y Cerrar Cerrado Coordinar Despliegue Implantado 65 33

34 Change Management Change Advisory Board Debe existir un comité, denominado Change Advisory Board (CAB), cuyo propósito sea: Evaluar cambios desde el punto de vista técnico, financiero y del negocio. Evaluar riesgos. Aprobar los cambios beneficiosos. Definir el momento más oportuno para realizar el cambio en función a la urgencia, importancia y complejidad del mismo y a otros cambios en curso. Evaluar los cambios una vez realizados para comprobar que se han alcanzado los objetivos que se perseguían con el mismo. Analizar cambios que tuvieron que revertirse, sus causas y consecuencias. ST 58 y Asset and Configuration Mgm. Propósito Identificar, controlar, registrar, informar y auditar los activos de un servicio y los Configuration Items (CI) ST

35 Asset and Configuration Mgm. Objetivos Identificar y registrar la información requerida para administrar y manejar los servicios TI. Controlar la it integridad iddyprecisión iió de la información ió almacenada en la CMDB. Asegurar que la información de la CMDB está actualizada y que se corresponde con los componentes reales de la infraestructura. Proveer la base para gestionar, mejorar y soportar los restantes procesos ITIL. Brindar información gerencial para el control de gestión del área TI. Proporcionar información del estado de los componentes y sus interrelaciones. ST 65 CMDB: Configuration Management Data Base 68 Asset and Configuration Mgm. Definición de Configuration Item (CI) Cualquier compo- nente (*) que requiere ser controlado para proveer servicios TI. (*): Incluye servicios, hardware, software, edificios, personas y documentos formales, como por ejemplo los SLA s y los procesos. SLA: Service Level Agreement 69 ST

36 Asset and Configuration Mgm. Configuration Management Data Base (CMDB) En su forma básica la CMDB contiene la información de todos los CI s bajo control. Mantiene la historia de los estados y cambios de los CI s. Una CMDB puede consistir en varias bases físicas, con información muy diversa, que conforman una entidad lógica centralizada. Un Registro de Activos, a diferencia de la CMDB, sólo registra ítems por encima de cierto monto y no establece relaciones entre ellos, salvo la del responsable del activo. ST 226 y 230 IV.A6 70 Asset and Configuration Mgm. Planificación Actividades Planificar y definir el propósito del SACM, su alcance, su estructura y recursos, sus políticas y procesos y sus herramientas de software. Identificación Control Reporte de Estados Auditoría y Verificación ST 71 a 82 Seleccionar e identificar las estructuras de los CI s, sus atributos y relaciones, asignarles identificadores únicos, identificar al responsable de cada CI y definir cuándo ingresar un CI en la CMBD. Asegurar que existen adecuados mecanismos de control sobre los CI s y que sus registros son agregados, modificados o eliminados siguiendo adecuados procedimientos de control. Asegurar que toda la información y la documentación de un CI es registrada a medida que progresa en su ciclo de vida y proveer información actual e histórica de sus diferentes estados. Revisar y auditar la información almacenada en la CMDB, verificando que concuerda con la configuración y existencia física de los CI s. SACM: Service Asset and Configuration Management 71 36

37 Asset and Configuration Mgm. Objetivos de la Identificación Definir la granularidad de los componentes, es decir, hasta qué nivel se verá y como será la estructura de agregación. Establecer la información que deberá almacenarse de cada CI, en todos sus niveles. Determinar las relaciones estándar entre los distintos componentes. Definir el esquema de identificación (labelling) de cada CI. Identificar al responsable por cada CI. Elaborar procesos y mecanismos de detección de nuevos CI s. ST Release and Deployment Mgm. Propósito Administrar la implantación de cambios en componentes de la infraestructura TI. Es responsable por la protección e integridad it idddl del ambiente productivo. ST

38 Release and Deployment Mgm. Objetivos Definir y acordar planes de liberación e implantación con los usuarios. Asegurar que el release contiene CI s que son compatibles entre sí. Asegurar que la integridad del release, y de sus CI s, se mantiene a lo largo de todas las etapas del proceso de construcción, prueba y liberación y que su información se actualiza en la CMDB. Asegurar que existe el conocimiento en las áreas de soporte y en el negocio para un adecuado uso y operación del servicio TI. Asegurar que el release puede ser controlado, probado, instalado y desinstalado (remediation) si fuera necesario. ST 84 I Release and Deployment Mgm. Tipos de Librerías Librerías Controladas La Definitive Media Library (DML) es un lugar seguro donded se guardan las versiones definitivas y autorizadas de todos los CI s lógicos (p. ej: Software). Los CI s almacenados han sido controlados por calidad y se en- DML: Definitive Media Library cuentran en su estado definitivo iti listo para su uso. Puede haber varias DML s en diferentes ubicaciones físicas. Puede haber almacenamientos físicos (medios magnéticos) y lógicos (archivos en un servidor). ST

39 Release and Deployment Mgm. Tipos de Librerías Librerías Dinámicas O librería de desarrollo, es donded los componentes de software son creados y mantenidos mientras son producidos. No forma parte realmente de Release and Deployment Management, sino que están bajo la administración i ió del lárea de desarrollo. Normalmente existen varias librerías de desarrollo con diferentes propósitos: programación, prueba unitaria, prueba de integración, prueba de aceptación, etc. 76 Release and Deployment Mgm. Tipos de Librerías Librerías Estáticas O librería de producción, es donded los componentes de software son efectivamente utilizados. Normalmente están bajo el control del área de Opera- ciones. Librerías donde d están los CI s utilizados por los usuarios, y también los usados para pruebas de versiones alfa y beta. Los CI s en estas librerías no deben ser modificados por ninguna razón

40 Nuevos Servicios o Cambio os Mayores Release and Deployment Mgm. Interrelación de Conceptos Desarrollo Test S. Testing Producción & Validation SCMDB Build DML CMDB ITIL DML: Definitive Media Library CMDB: Configuration Management Data Base SCMDB: Software Configuration Data Base 78 40