Capacidad de OI: Proceso de administración basado en ITIL/COBIT: del nivel estandarizado al racionalizado

En esta página

Introducción
Requisito: Procesos de funcionamiento, optimización y cambio

Introducción

Deben definirse procedimientos recomendados para todas las tareas destacadas en el modelo de optimización de infraestructura con el objeto de obtener un máximo rendimiento y beneficio. En la tabla siguiente se incluyen los desafíos, soluciones aplicables y ventajas de alto nivel de adoptar el nivel racionalizado en el proceso de administración basado en ITIL/COBIT.

Retos	Soluciones	Ventajas
Desafíos para la empresa Los contratos de nivel de servicio son informales o implícitos Una administración de la configuración informal se compone de listas de comprobación y hojas de cálculo básicas Desafíos de TI Administración de versión informal	Proyectos Implementación de la administración de nivel de servicio a través de las operaciones de TI Implementación de procedimientos recomendados de administración de versiones. Optimización de los procesos de administración de red y sistemas Implementación de procedimientos recomendados de programación de trabajos.	Ventajas empresariales Las operaciones de TI proactivas resuelven los problemas antes para evitar reducir la productividad del usuario Ventajas de TI Los servicios y herramientas automatizados liberan recursos para implementar nuevos servicios u optimizar los ya existentes Los contratos de nivel servicio formales conectan la TI con la empresa, mejorando así la credibilidad de la primera

El nivel racionalizado de optimización requiere que su organización disponga de procedimientos definidos para el soporte técnico a los usuarios y la administración de incidentes, problemas, configuración y cambios.

Requisito: Procesos de funcionamiento, optimización y cambio

Destinatarios

Debe leer esta sección si no cuenta con procesos para la programación de trabajos y la administración del nivel de servicio, versiones, sistemas y redes.

Introducción

La optimización de infraestructuras va más allá de los productos y tecnologías. Las personas y los procesos constituyen una gran parte de la madurez del servicio de TI de la organización. Algunos estándares y procedimientos recomendados tratan las áreas relacionadas con las personas y procesos en la administración del servicio de TI. Microsoft Operations Framework (MOF) aplica gran parte del conocimiento incluido en las normas Biblioteca de infraestructuras de tecnologías de la información (IT Infrastructure Library, ITIL) y Objetivos de control para la información y tecnología relacionada (Control Objectives for Information and related Technology, COBIT) y las hace aplicables y factibles para los clientes de Microsoft.

Fase 1: Evaluación

El objetivo de la fase de evaluación en la administración de las operaciones es valorar las capacidades y desafíos actuales de la organización. Para ser compatible con el proceso de evaluación de operaciones, Microsoft ha desarrollado la evaluación de administración de servicios (SMA) de MOF (Microsoft Operations Framework) como parte de la Guía para la mejora continua de MOF y una versión en línea más sencilla llamada Herramienta de autoevaluación de MOF.

Figura 16. Mejoría constante del ciclo de vida de MOF

La evaluación de administración de servicios de MOF se centra en mejorar el rendimiento de los procesos de administración de servicios de TI y personas, así como en habilitar tecnologías que mejoren el valor empresarial. Todas las recomendaciones generadas como resultado de la SMA se detallan y justifican por el valor empresarial, además se ofrece una guía básica de mejora detallada del servicio, fundamentada en indicadores de rendimiento clave específicos para supervisar el progreso a medida que se implementan las mejoras.

Fase 2: Identificación

Los resultados de la evaluación de administración de servicios de MOF ponen los cimientos de la fase de identificación. La evaluación, con frecuencia, expone varias áreas de mejora potencial en las operaciones de TI. Durante la fase de identificación consideramos estos resultados y establecemos las prioridades relacionadas con los proyectos de mejora en función de las necesidades empresariales. Las herramientas y ayudas de trabajo que se incluyen en la guía para la mejora continua de MOF tienen como objeto ayudarle en el establecimiento de prioridades.

Fase 3: Evaluación y planeación

La fase de evaluación y planeación de la mejora de las operaciones se basa en las áreas identificadas y establecidas como prioritarias para la mejora. La orientación proporcionada con el programa de mejora del servicio de MOF (SIP) habilita esta fase. SIP se divide en dos áreas principales de atención: mejora específica de los procesos de MOF/ITIL y orientación de mejora del servicio. Esta orientación se proporciona a través de una herramienta que ayuda a los usuarios a identificar sus puntos de problemas específicos, proporciona instrucciones específicas que ofrecen soluciones y cuenta con la asistencia de indicadores de rendimiento clave para medir la mejora del proceso.   

Proceso recomendado para la transición al nivel racionalizado

Las recomendaciones que se hacen en esta sección se basan en problemas frecuentes encontrados en el nivel estandarizado y en las áreas de mejora perseguidas por el nivel racionalizado. Se trata tan sólo de recomendaciones que pueden diferir de su organización o sector específico.

Aunque el nivel estandarizado conlleva un incremento del uso de herramientas de administración y supervisión de la infraestructura y las operaciones de TI y un entorno en el que procesos tales como la administración de cambios, configuración y versiones están estandarizados y resultan predecibles, existe margen de mejora en áreas clave. La administración del nivel de servicio resulta rudimentaria con contratos de nivel de servicio informales o implícitos. La administración de la configuración es informal y generalmente se compone de listas de comprobación y hojas de cálculo básicas. Además, la administración de versiones no está bien definida y carece de rigor.

La infraestructura racionalizada es donde los costos relacionados con la administración de escritorios y servidores se encuentran en su nivel más bajo y los procesos y directivas han sido optimizadas para comenzar a jugar un papel más importante en el soporte y expansión del negocio. La seguridad está bastante automatizada y las respuestas a amenazas y desafíos son rápidas y controladas. El uso de la implementación sin interacción ayuda a reducir los costos, el tiempo de implementación y las dificultades técnicas. El número de imágenes es mínimo y el proceso para administrar equipos presenta una escasa interacción. Estos clientes disponen de un claro inventario de hardware y software y sólo adquieren las licencias y equipos que necesitan. La seguridad es muy proactiva con directivas y control estrictos, desde el escritorio al servidor, al firewall o la extranet.

Microsoft proporciona Microsoft Operations Framework (MOF) como un modelo iterativo para la definición y mejora de las operaciones de TI. MOF define las funciones de administración de servicios (Service Management Function, SMF) como funciones operativas lógicas dentro de una organización de TI. Las SMF se agrupan en cuatro grandes áreas o cuadrantes: Cambio, funcionamiento, soporte técnico y optimización. Esta guía destaca las áreas que necesitan mejora y que generalmente se hallan en organizaciones que se encuentran en el nivel estandarizado de optimización:

• Administración del nivel de servicio

• Administración de versiones

• Administración del sistema

• Administración de red

• Programación de trabajos

Dependiendo de la organización, las mejoras realizadas a estas funciones de administración de servicios podrían o no tener un fuerte impacto sobre la eficacia y mejora operativas. Le recomendamos que su organización complete como mínimo la autoevaluación en línea y, en el mejor de los casos, una evaluación de administración de servicios completa para identificar las áreas más importantes que requieren mejoras de procesos o servicios.

Administración del nivel de servicio

Administración del nivel de servicio (Service Level Management, SLM) es un proceso crítico que alinea las necesidades empresariales con la puesta en marcha de servicios de TI. Provee la interfaz con la empresa que permite a las otras SMF proporcionar soluciones de TI que estén en línea con los requisitos de la empresa a un costo aceptable. Su objetivo principal es poner en marcha, mantener y mejorar los servicios de TI correctamente.

SLM se usa para alinear y administrar los servicios de TI a través de un proceso de definición, acuerdo, medida de las operaciones y revisión. El alcance de SLM incluye la definición de los servicios de TI para la organización y el establecimiento de sus SLA correspondientes. El cumplimiento de los SLA se asegura mediante el uso de contratos afianzados y contratos de nivel operativo para la puesta en marcha de los servicios a nivel interno y externo. La introducción de la administración del nivel de servicio en una empresa no generará una mejora inmediata de los niveles de servicio provistos. Se trata de un compromiso a largo plazo. Al principio, es probable que el servicio cambie muy poco. Sin embargo, con el tiempo, el servicio mejorará a medida que se cumplan y se superen los objetivos.

Si una organización desea implementar la administración del nivel de servicio, deberá primero evaluar los servicios proporcionados por TI a los clientes de la organización y determinar los contratos de servicio actualmente en vigor para esos servicios. Esta evaluación puede poner en conocimiento del departamento de servicios de TI, a menudo por primera vez, la gama completa de servicios que se espera de él. Con la información recabada mediante este ejercicio, la organización podrá desarrollar e implementar todas las ventajas del proceso de administración del nivel de servicio.

La administración del nivel de servicio precisa que la organización de TI entienda perfectamente los servicios que ofrece. La implementación de la administración del nivel de servicio consta de los siguientes pasos:

• Crear un catálogo de servicios.

• Desarrollar SLA.

• Supervisar y crear informes.

• Realizar revisiones periódicas del nivel de servicio.

Los SLA se desarrollan en línea con los requisitos y prioridades de los servicios documentados en el catálogo de servicios, los requisitos especificados en las negociaciones de los SLA, la supervisión del servicio frente a los criterios de acuerdo y los informes y revisiones de esta información para resaltar y quitar los errores de los niveles de rendimiento del servicio.

Fase 4: Implementación (administración del nivel de servicio)

Actividades de configuración

Las actividades de configuración son una serie de pasos de evaluación llevados a cabo al principio de un proyecto de administración del nivel de servicio. Estos pasos preliminares ayudan a la empresa a determinar si existe la necesidad de implementar la administración del nivel de servicio y si dispone de los recursos necesarios para hacerlo. Como parte de este proceso, el departamento de TI establece una línea base para la empresa mediante la toma de instantáneas de las actividades de administración y servicios existentes. El último paso consiste en analizar la información recopilada en los pasos anteriores y usar los resultados para planear la implementación de la administración del nivel de servicio para que la empresa obtenga el máximo beneficio.

Crear un catálogo de servicios

El catálogo de servicios incluye todos los servicios provistos en la actualidad, resume sus características, describe el perfil de sus usuarios y designa a los responsables de su mantenimiento permanente.

El servicio está definido por la percepción de la organización empresarial. Por ejemplo, tanto el correo electrónico como la impresión pueden considerarse servicios, independientemente del número de componentes de servicio necesarios para proveer el servicio al usuario final.

La formalización del catálogo de servicios es un paso importante en tanto que crea un registro reconocido oficialmente. Convertir el catálogo de servicios en un registro oficial dentro de la organización lo somete al control de cambios. Esto es importante, ya que el valor del registro depende del mantenimiento y precisión del mismo.

Existen muchas maneras de formalizar un catálogo de servicios. Al determinar qué método es el más adecuado, tenga en cuenta cómo quiere ver y usar el catálogo de servicios, así como los elementos en los que va a basar los informes. El catálogo de servicios se puede almacenar como parte de la base de datos de la administración de la configuración (Configuration Management Database, CMDB), ya sea como un componente (el catálogo de servicios) o como sus servicios. Las aplicaciones de Microsoft como Microsoft Excel o Microsoft Access, se pueden usar para registrar los servicios y detalles tales como los componentes, efectos, prioridades, SLA y SLO. Si la herramienta seleccionada permite que el catálogo de servicios forme parte de la CMDB, se puede agregar valor mediante la integración de la información en el catálogo de servicios con el elemento de configuración de la CMDB. A su vez, esto se puede usar para agregar valor a las SMF de administración de cambios, administración de incidentes y todas las demás SMF que usen la CMDB.

Desarrollar acuerdos de nivel de servicio (SLA)

Un SLA es un acuerdo entre el proveedor de servicios de TI y la comunidad de cliente/usuario. El SLA formaliza los requisitos de cliente/usuario para los niveles de servicio y define las responsabilidades de todas las partes participantes.

Los pasos necesarios para crear un SLA son los siguientes:

• Definir el tipo de SLA. Por ejemplo, ¿se trata de un acuerdo de nivel de servicio interno, externo, de nivel operativo o de varios servicios?

• Definir los SLA. Por ejemplo, qué niveles de servicio se proporcionarán, incluidos factores medibles como la disponibilidad, capacidad de respuesta, integridad, precisión y seguridad.

• Negociar y acordar los SLA. Por ejemplo, determinar si lo que se ha acordado se puede proporcionar a la empresa y al departamento de TI a un costo razonable.

• Documentar el SLA. Por ejemplo, registrar por escrito los acuerdos alcanzados y las partes implicadas.

Alineación de los compromisos de los contratos de nivel de servicio, los contratos de nivel operativo y los contratos afianzados

Los contratos afianzados —contratos legalmente vinculantes con un proveedor de servicios de terceros sobre los que se han edificado los servicios finales para el SLA— y los acuerdos de nivel operativo —un acuerdo interno que respalda los requisitos del SLA— deben tener métricas de servicios que estén alineadas con el compromiso del SLA.

Supervisión del nivel de servicio

La administración del nivel de servicio requiere un ciclo continuo de acuerdo, supervisión y creación de informes sobre los logros del servicio de TI, así como tomar las decisiones adecuadas para equilibrar los niveles de servicio con las necesidades y los costos de la empresa.

Una vez acordados e implementados los SLA, el siguiente paso de una administración del nivel de servicio eficaz es la supervisión del rendimiento de los servicios frente a los criterios especificados en los objetivos del nivel de servicio (SLO). Existen varios métodos de supervisión de la administración del nivel de servicio, pero la principal preocupación es si se rompe el rendimiento de cualquiera de los criterios o si se llega a una situación de práctica ruptura del SLA.

Revisión de contrato de nivel de servicio

La revisión del SLA es una de las cuatro revisiones de la administración de las operaciones de MOF (Operations Management Reviews, OMR). Se trata de un punto de control de administración clave que ocurre a intervalos especificados (tal y como se documenta en el SLA). Esta revisión tiene el propósito de asegurar que la empresa y la sección de TI tienen la oportunidad de evaluar el rendimiento en base a los objetivos del SLA y de revisar el funcionamiento de éste. La revisión de SLA está diseñada para incluir a la administración de alto nivel en el proceso de revisión, asegurando así la implicación y las comunicaciones de la sección de TI y de la empresa en todas la decisiones futuras relacionadas con la provisión del servicio.

Administración de versiones

La función de administración de servicios (SMF) Administración de versiones es responsable de implementar los cambios en los entornos de tecnología de la información (TI). Después de que uno o más cambios se hayan desarrollado, probado y empaquetado en versiones para su implementación, la administración de versiones es responsable de introducir estos cambios y administrar su lanzamiento. Además, la administración de versiones contribuye a la introducción eficaz de los cambios combinándolos en una versión única e implementándolos juntos.

El objetivo del proceso de administración de versiones es asegurar que todos los cambios se implementan correctamente en el entorno de TI de producción de la manera menos traumática posible. Por lo tanto, la administración de versiones es responsable de:

• Conducir la estrategia de la versión, que consiste en el diseño, planeación y enfoque de la implementación de un cambio en el proceso de producción en colaboración con el comité asesor de cambios (CAB).

• Determinar el nivel de preparación de cada versión en función de los criterios pertinentes (calidad de la versión, preparación del entorno de producción y paquete de lanzamiento, planes de aprendizaje y soporte técnico, planes de lanzamiento y devolución y planes de administración de riesgos).

Administración de versiones:

• Proporciona una versión empaquetada con todos los cambios implementados en producción, implementando sólo aquellos cambios aprobados por administración de cambios.

• Necesita que la administración de cambios apruebe los cambios y realice un seguimiento de los mismos a lo largo del proceso de lanzamiento.

• A medida que se realizan los cambios, se asegura de que éstos son puestos en conocimiento de la administración de la configuración para su ingreso en la CMDB.

• Necesita información de la administración de la configuración para crear y comprobar entornos válidos de pruebas durante la fase de desarrollo de la nueva versión.

• Necesita que la administración de la configuración evalúe el impacto de los cambios realizados en el entorno de TI y que proporcione un almacén definitivo para el paquete de lanzamiento.

Fase 4: Implementación (administración de versiones)

Planeación del lanzamiento

El primer paso del proceso de lanzamiento es la creación de un plan que identifique las actividades y los recursos necesarios para implementar correctamente una versión en el entorno de producción. Este plan implica determinar las tareas que hay que hacer, cuándo hay que acabarlas (escala temporal) y qué prioridad tienen en relación con otras tareas. Una vez comprendidos estos factores, el administrador de la versión puede diseñar un plan detallado de actividades y asignar los recursos apropiados al proyecto. En administración de versiones, el administrador es responsable de crear un plan de versión (proyecto) para cada RFC aprobado por administración de cambios.

Creación de la versión

Después de aprobar el plan de versión, los miembros del equipo de la versión identifican y desarrollan los procesos, herramientas y tecnologías necesarios para implementar la versión en producción. Aunque la práctica totalidad de las versiones puede implementarse en producción de forma manual, también se pueden utilizar numerosas herramientas y tecnologías para realizar la misma tarea. Para sacar el máximo provecho del tiempo y los recursos, el equipo de la versión debe identificar las herramientas y tecnologías que permitirán automatizar el proceso de implementación tanto como sea posible.

Una vez seleccionado el mecanismo de lanzamiento, el equipo de la versión crea un paquete de lanzamiento que contiene los procesos, herramientas y tecnologías necesarios para implementar la versión en producción usando el mecanismo seleccionado y quitándolo de producción si fuera necesario.

En el caso de algunas versiones, el paquete de lanzamiento puede constar simplemente de un conjunto de procedimientos documentados de instalación y eliminación.

El paquete de lanzamiento finalizado se debe probar en un entorno de laboratorio para que el equipo de la versión adquiera el convencimiento de que funcionará correctamente cuando se use en producción. Asumiendo que la prueba se desarrolle correctamente, la versión y el contenido del paquete de lanzamiento pasan a ser controlados por la administración de cambios.

Pruebas de aceptación

Hasta ahora, el propósito de las pruebas ha sido confirmar que la versión y el paquete de lanzamiento funcionan correctamente en un entorno de desarrollo. Las pruebas de aceptación permiten a los desarrolladores y representantes de la empresa comprobar el rendimiento conjunto de la versión y el paquete de lanzamiento en un entorno que prácticamente reproduce el entorno de producción. En algunos casos, las pruebas piloto son necesarias para adquirir la confianza necesaria para implementar cambios que son aplicables a toda la empresa.

Aunque las pruebas realizadas en un entorno de producción simulado proporcionan al equipo de la versión la confianza necesaria en la versión, no garantiza que el rendimiento de ésta en producción sea el esperado, ya que las condiciones pueden variar significativamente. En este sentido, puede ser necesario realizar varias pruebas controladas en el entorno de producción para confirmar que la versión cumple las expectativas. Las pruebas piloto realizadas sobre una versión en un entorno de producción comportan una serie de riesgos para dicho entorno y deberían llevarse a cabo sólo si los procedimientos de recuperación incluidos en el paquete de lanzamiento se han probado en el entorno de pruebas.

Preparación de la versión

Realizadas las pruebas piloto y de aceptación, el siguiente paso consiste en preparar el entorno de producción para la versión, moverse por el proceso de preparación y acordar un plan de acción, ya sea pasar a Revisión de preparación de la versión o devolver la versión al propietario del cambio o al administrador de la versión para continuar con el trabajo.

El administrador de la versión, el administrador de cambios y el propietario del cambio son los participantes principales en el debate en torno a la revisión de disponibilidad de la versión, al que también pueden agregarse representantes de otros grupos interesados, como los equipos de pruebas, servicios de ayuda y comunidades de usuarios (dependiendo de la naturaleza y el tamaño de la versión).

Aunque una versión no haya superado varias pruebas, tanto en el laboratorio como en el entorno de producción, puede que los errores no sean lo suficientemente significativos como para impedir la implementación. Incluso si hay implicaciones para el entorno de producción, pueden existir varias razones empresariales de peso que justifiquen la implementación de la versión.

Por ejemplo, puede que una característica como la de suscripción no funcione en un sitio de comercio compañía a compañía. Es fácil quitar esta característica y encontrar una solución manual. Por lo tanto, el equipo puede optar por prescindir de esta característica.

Se capturan y documentan las experiencias y las lecciones aprendidas durante la realización de las pruebas (además de las soluciones desarrolladas). Si se encuentran problemas durante la fase de pruebas que afectan a la comunidad de usuarios o a los niveles de servicio, será necesario discutir soluciones y problemas previsibles con los representantes del servicio de ayuda y asegurarse de que las soluciones se ponen a disposición del servicio de ayuda antes de la implementación. Puede que sea necesario iniciar RFC adicionales para que la versión funcione de la manera esperada. En cualquier caso, hay que actualizar el registro de cambios con la decisión adoptada y cualquier otra información relevante.

Implementación de la versión

El proceso de implementación de la versión en el entorno de producción depende del tipo y la naturaleza de la versión, así como del mecanismo de lanzamiento seleccionado. En todos los casos, el administrador de la versión debe recibir estados de informe y, si fuera necesario, herramientas y tecnologías para poder supervisar y realizar un seguimiento del progreso de la implementación. A medida que se realizan cambios a los componentes de TI durante la fase de implementación, deben efectuarse los correspondientes cambios a las relaciones y elementos de configuración que los modelan en la CMDB.

Una vez implementada la versión, el administrador de la versión confirma su correcto funcionamiento antes de proceder con otras implementaciones. En el caso de algunas versiones, el personal de soporte técnico puede obtener confirmación usando ciertas herramientas y tecnologías. En otros casos, puede que el administrador de la versión tenga que pedir al servicio de ayuda que se ponga en contacto con usuarios individuales para recabar sus comentarios.

Si la versión no cumple con las expectativas o si se encuentran problemas serios durante la implementación, habrá que recurrir a la administración de problemas para identificar y diagnosticar la raíz del problema. Si se encuentra una corrección o solución apropiada, habrá que documentarla y crear una solicitud de cambio para implementarlo en el entorno de producción. De lo contrario, quizás sea apropiado usar los procedimientos de devolución para quitar la versión de ese entorno.

Una vez concluida la fase de implementación, el proceso de versión debe garantizar que cualquier resultado e información acerca de las soluciones o RFC surgidas para asegurar el buen funcionamiento de la versión quedan registrados. Si es necesario devolver la versión, habrá que registrar esta circunstancia junto con la información que justifique la decisión.

Administración del sistema

La función Administración del sistema realiza tareas de administración de seguridad, supervisión y control de servicios, programación de trabajos, administración de red, administración de servicios de directorio, administración de impresión y resultados y administración de almacenamiento. El diseño, desarrollo e implementación de esta función estarán determinados por el tamaño y la arquitectura de la organización. Las grandes organizaciones dispondrán de modelos claramente definidos mientras que otras organizaciones más pequeñas posiblemente tengan que consolidar funciones para mantener el estado y la capacidad operativa de los sistemas.

El objetivo de la SMF Administración del sistema es administrar un entorno informático de manera cotidiana. Esto implica la administración y provisión de soporte técnico operativo para varios elementos del entorno de producción.

La función Administración del sistema es responsable de proporcionar servicios administrativos para mantener los entornos informáticos que contienen hardware centralizado y distribuido.

Además, la función Administración del sistema puede proporcionar asistencia para la administración funcional de otras SMF que no son directamente responsables de la implementación y administración. Esta asistencia puede incluir:

• Supervisión de la capacidad y rendimiento de primer nivel para la función de supervisión y control de servicios.

• Administración funcional cotidiana de la administración de cuentas, incluida la adición, eliminación y movimiento de cuentas. Consultas sobre recursos como impresoras o privilegios de acceso de seguridad para la administración de servicios de directorio y la administración de seguridad.

• Administración de los recursos usados para producir resultados e informes impresos para la administración de impresión y resultados.

• Las tareas administrativas necesarias para hacer copias de seguridad y restaurar datos críticos.

• Aplicación de una directiva de seguridad para proteger datos y recursos compartidos de la red como archivos, carpetas e impresoras.

Fase 4: Implementación (administración del sistema)

Implementación del modelo de administración centralizado

En el modelo de administración centralizado, todas o la mayoría de las operaciones y funciones de soporte técnico se encuentran centralizadas en un sitio único o en varios sitios. Con la maduración de las áreas locales y extensas, la computación distribuida, los entornos cliente/servidor y sus redes auxiliares, cada vez más organizaciones se esfuerzan por centralizar el soporte técnico para los recursos, aplicaciones y soluciones instalados.

La disponibilidad y asequibilidad del ancho de banda para sitios remotos y sucursales crece día a día. Las tecnologías básicas que proporcionan soporte técnico a la computación de sucursales (protocolos de transmisión, herramientas de acceso remoto, servidores sin periféricos, etc.) han mejorado hasta el punto que las sucursales ya no necesitan su propio personal de soporte técnico. De este modo, las compañías ganan cada vez más capacidad para centralizar las funciones fundamentales de soporte técnico que son necesarias para mantener la disponibilidad, confiabilidad, soporte técnico diario y administración de sistemas distribuidos a sucursales o sitios remotos.

Generalmente, la administración centralizada asume que todos o la mayoría de los sistemas y recursos informáticos administrados se encuentran en una ubicación centralizada. Aunque esto es cada vez más frecuente, aún existen casos en los que algunas soluciones específicas (aplicaciones personalizadas, bases de datos especializadas, etc.) no están centralizadas en el centro de datos corporativo, sino que se distribuyen al sitio o sucursal remotos. La distribución de algunas aplicaciones y bases de datos no impide tomar una postura centralizada con respecto al modelo administrativo.

Implementación del modelo de administración centralizado/remoto

El modelo de administración centralizado/remoto proporciona la mayoría de las ventajas de un modelo completamente centralizado. El grueso de la administración se sigue realizando en la ubicación central (por ejemplo, un centro de datos central), reteniendo así el máximo control y consolidación de los recursos necesarios para ejecutar la función administrativa.

No obstante, se pierde parte del control y la consolidación de recursos como consecuencia de la necesidad de mantener un entorno de centro de datos remoto con al menos un mínimo de presencia administrativa localizada. Entre los requisitos de mantenimiento correctivo del sistema distribuido pueden encontrarse actualizaciones del sistema que requieran volver a arrancar el equipo, así como obligaciones de copia de seguridad en cinta y almacenamiento. Pueden existir requisitos adicionales de administración de sitios locales, siempre en función de la aplicación o sistema específico que se esté administrando. Tendrá que decidir qué responsabilidades específicas son necesarias en base a su aplicación tecnológica.

El modelo de administración centralizado/remoto hace referencia a sistemas distribuidos en ubicaciones remotas cuyo control administrativo permanece, sin embargo, en una ubicación centralizada. Como hemos mencionado anteriormente, es preciso que exista cierta presencia del centro de datos en la ubicación remota o regional para hospedar los servidores o unidades de almacenamiento. Esto implica que incurrirá en los costos de la infraestructura del centro de datos, que incluye la planta física, el suelo, la energía, el cableado, AV/CA y los componentes de seguridad.

Si la aplicación tecnológica evoluciona hasta el punto en que este modelo deja de ser viable (es decir, el modelo no cumple los acuerdos de nivel de servicio) o rentable, es posible que tenga que adoptar un modelo administrativo distribuido. En el modelo administrativo distribuido, los recursos informáticos y humanos se encuentran físicamente en una ubicación remota. Este modelo se describe en la siguiente sección.

Implementación del modelo de administración centralizado/delegado

Este modelo pretende incorporar lo mejor de los modelos de administración centralizados y remotos, con todas sus características y ventajas inherentes. Además, ofrece algunos de los beneficios del modelo de administración distribuido. Estas ventajas se obtienen mediante el desplazamiento de un subconjunto relativamente pequeño y especializado de tareas administrativas a las sucursales locales y sitios remotos.

Como ocurre con el modelo centralizado, las principales funciones y recursos administrativos residen en el centro de datos corporativo (central), donde se origina toda dirección y control administrativo. La administración de los servicios y servidores centralizados y basados en el centro de datos continúa a cargo de los recursos centralizados. Éstos, además, se encargan de la administración remota de los servicios a través de la red siempre que sea posible, razonable y pertinente.

Algunas circunstancias marcan la necesidad de distribuir servicios, servidores y recursos específicos. En estos casos, puede resultar prudente y más eficaz permitir que algunas de las tareas administrativas se realicen en ubicaciones remotas o regionales. Esto se hace delegando algunas autoridades muy específicas en los recursos de las ubicaciones remotas. Por "autoridades muy específicas" nos referimos a un pequeño subconjunto de derechos administrativos y accesos que permiten a los administradores remotos realizar tareas específicas y discretas.

Implementación del modelo de administración distribuido

A diferencia de otros modelos, la administración distribuida depende de recursos auxiliares ubicados en sucursales o sitios remotos. Los recursos ubicados en sitios remotos desempeñan las funciones auxiliares fundamentales (y al mismo tempo críticas) que son necesarias para mantener el estado, disponibilidad y confiabilidad de los sistemas distribuidos en esos sitios.

Puede que siga habiendo controladores empresariales para el mantenimiento de los sistemas distribuidos en ubicaciones remotas. Algunos de estos controladores pueden estar relacionados con el rendimiento, la escalabilidad, un tipo específico de aplicación o el costo o disponibilidad del ancho de banda de la red necesario para admitir una solución centralizada.

Los recursos informáticos y humanos se distribuyen por completo a las oficinas remotas y a los sitios regionales. Como consecuencia, la organización puede obtener un rendimiento de sitio local mucho mejor para aplicaciones tecnológicas específicas.

Implementación del modelo de administración distribuida de centros de datos centralizados

La quinta posibilidad en cuanto a administración de sistemas se refiere, y a la que aquí aludimos como modelo "sigue al sol", podría llamarse también modelo de "administración distribuida de centros de datos centralizados".

En este contexto, "sigue al sol" significa proveer soporte técnico de manera global durante 7 días a la semana y 24 horas al día. Esto se logra transfiriendo la responsabilidad del soporte técnico a distintas regiones repartidas por el mundo a medida que unas oficinas cierran y otras abren.

En cierta manera, este modelo es único y no está tan ampliamente implementado como los cuatro modelos básicos previamente descritos. Conviene advertir, sin embargo, que tanto en el pasado como en la actualidad, las compañías intentan que este modelo funcione en sus organizaciones.

Administración de red

La función de administración de serviciosAdministración de red se centra en las redes de operaciones, que son los componentes de infraestructura a través de los cuales los sistemas informáticos y los periféricos de uso compartido se comunican entre sí. Se trata del nivel más básico de una infraestructura de TI: sin instalaciones de redes no hay infraestructura, sólo un conjunto de equipos individuales.

El objetivo de la SMF Administración de red es proporcionar una base sólida de procesos para la administración de un entorno de red de manera cotidiana. Esto implica la administración y provisión de soporte técnico operativo para varios elementos del entorno de producción. Los objetivos de la SMF incluyen la provisión de planeación e implementación de servicios para ampliar las instalaciones de redes actuales y de soporte técnico para solucionar problemas y reparar defectos en un entorno de red. Mediante una eficaz implementación de la SMF Administración de red, las organizaciones de TI pueden:

• Mejorar la implementación de la infraestructura de red.

• Mejorar los procesos de solución de problemas y los procesos asociados de administración de incidentes.

• Aumentar la confiabilidad de la red.

• Mejorar la disponibilidad de los servicios y soluciones de TI.

Una red típica consta del hardware (incluido el cableado, enrutadores, conmutadores, concentradores, servidores físicos y otros componentes) y del software o firmware que controla la forma en la que se usan los componentes físicos. En el modelo de redes descrito por la pila Interconexión de sistemas abiertos (Open Systems Interconnection, OSI), la infraestructura de TI típica se construye en capas, desde los componentes fundamentales usados por todos los servicios de la parte inferior de la pila hasta las aplicaciones especializadas de la parte superior.

Las capas que componen la pila OSI son (de arriba a abajo):

1. Aplicación

2. Presentación

3. Sesión

4. Transporte

5. Red

6. Vínculo (vínculo de datos)

7. Físicas

La administración de red se ocupa generalmente de las tres primeras capas de la pila, compuestas principalmente por hardware. En el nivel de transporte se produce cierta superposición entre la administración de sistemas y de red. Este nivel incluye los protocolos de redes y vínculos que hacen posible la transferencia de datos de un punto a otro. Desde la perspectiva de MOF, la administración de servicios tales como DNS, WINS y DHCP proporciona los servicios básicos de resolución de nombres requeridos por los servicios de TI que presentan una funcionalidad total. Dependiendo de la organización, estos servicios básicos se pueden incluir como funciones de servicios de red. Puesto que DNS, WINS y DHCP se ejecutan en servidores, los servidores de red se incluyen a veces entre los componentes de hardware administrados por la SMF Administración de red.

Fase 4: Implementación (administración de red)

Mantenimiento de la red

Poner la infraestructura de red en funcionamiento consiste sobre todo en supervisar su rendimiento, evaluar los resultados en función de las expectativas y generar elementos de trabajo para solucionar problemas en caso de errores de rendimiento. La mayoría de componentes de hardware de una red deben funcionar sin mantenimiento ni intervención directa de acuerdo con las especificaciones del fabricante durante el tiempo medio entre errores y otros criterios de rendimiento. La SMF Administración de capacidad de MOF proporciona detalles para la planeación de la capacidad. Esta información ayudará al equipo de diseño de redes a optimizar el rendimiento de la red.

Sin embargo, los componentes de la red basados en servidores requieren atención periódica. Estos componentes precisan copias de seguridad regulares en algunos casos y evaluaciones del almacenamiento o los requisitos de capacidad de acuerdo con la SMF Administración de almacenamiento.

Soporte técnico de redes

El soporte técnico de redes está estrechamente vinculado a las actividades del cuadrante de compatibilidad, en particular a las SMF Administración de incidentes y Administración de problemas. Mediante el proceso de resolución de incidentes descrito en la SMF Administración de incidentes, los especialistas de redes de TI corrigen errores de la red, desarrollan soluciones y evitan o mitigan problemas inminentes de red. Aunque el proceso genérico para la resolución de incidentes se describe en el documento de orientación de la SMF Administración de incidentes, los procesos específicos para la solución de problemas de redes se proporcionan en las siguientes secciones.

Programación de trabajos

La función de administración de serviciosProgramación de trabajos se ocupa de asegurar el procesamiento eficaz de los datos a una hora predeterminada y en una secuencia recomendada para maximizar el uso de los recursos del sistema y minimizar el impacto sobre los usuarios en línea. Un proceso por lotes consiste en una interacción del sistema con una base de datos que se ejecuta en segundo plano y de forma secuencial sin la intervención de un usuario final. La ejecución de procesos por lotes se puede iniciar de manera automática o manual. Generalmente, los lotes se ejecutan después de las horas de oficina, cuando apenas se produce interacción entre los usuarios y el sistema.

Los lotes de ejecución requieren su propia arquitectura, ya que tienden a ser procesos repetitivos y de larga duración que consumen gran cantidad de recursos. Por lo general, el proceso implica la lectura de grandes cantidades de datos de una base de datos, el procesamiento de los datos y la devolución de los resultados a la base de datos. El proceso se completa a través de la lectura de secuencias de comandos.

Entre los tipos de trabajos por lotes que ejecutan las organizaciones se encuentran:

• Informes de administración financiera

• Informes de marketing

• Informes de administración de la cadena de suministro

• Informes de inventario

• Informes de facturas

• Procesamiento de cuentas de clientes (facturación mensual, etc.)

• Copias de seguridad automáticas de datos de aplicaciones y sistemas

• Resúmenes de procesamientos de sistemas e informes de planeación de la capacidad

Fase 4: Implementación (programación de trabajos)

Arquitectura de lotes

Una arquitectura de lotes consta de los procesos y componentes usados para administrar eficazmente el procesamiento por lotes. El propósito de la arquitectura de lotes es la optimización del procesamiento (mejorar el tiempo de respuesta y la utilización de los recursos del sistema) mediante lotes de ejecución durante los períodos de mínima actividad. La arquitectura debe proporcionar al administrador de la capacidad una interfaz fácil de usar y permitir un enfoque estándar y centralizado de la programación, supervisión, control y corrección de errores por lotes. La arquitectura debe ser altamente escalable para satisfacer las necesidades futuras de la organización. También debe ser altamente disponible, presentar tiempos de inactividad mínimos y reducir el impacto de las operaciones en línea que generalmente funcionan de manera simultánea con las operaciones por lotes. Algunas organizaciones pueden optar por los componentes de copia de seguridad, como el servidor de eventos, para garantizar la finalización de todos los trabajos por lotes críticos.

Los componentes básicos de la arquitectura por lotes son el servidor de administración, la base de datos de capacidad, el monitor, la impresora, los servidores de aplicación y las bases de datos. Además del monitor conectado al servidor de administración, cada servidor de aplicaciones debe disponer de un monitor para permitir la visualización de las actividades locales de procesamiento por lotes. Así se facilita el análisis de errores en el nivel local.

Procesamiento por lotes

Antes de abordar los lotes de ejecución programados, conviene entender la jerarquía del proceso por lotes y el contenido de una secuencia de comandos por lotes. Un lote de ejecución consta de varios trabajos por lotes independientes que están programados para ejecutarse de manera recurrente. Las grandes organizaciones pueden ejecutar varios lotes de ejecución a lo largo del día en función de los recursos que sean necesarios para procesarlos. Cada trabajo por lotes se compone de varios pasos que controlan las actividades específicas de la ejecución de un proceso.

Generalmente, las organizaciones procesan varios trabajos por lotes. Para asegurar un enfoque consistente de la ejecución de los procesos, es necesario concebir una matriz de trabajos por lotes que contenga el código estandarizado requerido para cada proceso. Es preciso codificar la información específica de los proyectos en un área designada de la matriz. La matriz también sirve para facilitar los requisitos de desarrollo y mantenimiento mediante la estandarización del contenido y la estructura de cada secuencia de comandos. Por ejemplo, cualquier tipo de acción estandarizada, como la notificación de la ejecución correcta o incorrecta de un trabajo por lotes y el archivado y eliminación de los datos de transacciones, debe incluirse en el código de todas las secuencias de comandos ejecutadas.

Los lotes de ejecución programados se inician por medio de una herramienta de programación a una hora predeterminada, generalmente cuando la actividad del sistema es mínima. Una vez programada la herramienta de programación, ya no será necesaria la interacción del administrador de la capacidad durante la ejecución de los lotes, a menos que se produzca un error del que no se pueda recuperar la herramienta.

La herramienta de programación inicia todos los lotes de ejecución. Si el lote no se inicia de acuerdo a la programación, la herramienta detendrá la ejecución y registrará un error en el registro de errores. Algunas herramientas de programación tienen capacidad para intentar reiniciar el lote de ejecución. Si la inicialización se produce de manera correcta, se ejecutará el primer trabajo por lotes. El programador administra la ejecución de procesos en cada servidor de aplicaciones de destino para realizar el procesamiento por lotes. Si no se encuentran errores durante la ejecución del trabajo, la herramienta registra la correcta conclusión del trabajo en el registro de lotes y se ejecuta el siguiente trabajo (y así sucesivamente).

Si se produce un error durante la ejecución de un trabajo por lotes, la herramienta de programación interrumpe el procesamiento de ese trabajo y se envía un error al registro de errores. La ejecución de un trabajo por lotes depende de varias entradas que pueden ser la razón de que un trabajo no se ejecute. Por ejemplo, las siguientes entradas pueden ser necesarias:

• Disponibilidad de los datos de producción

• Conclusión de un trabajo del que otro trabajo en cola es dependiente

• Disponibilidad de recursos para ejecutar el trabajo

• Prioridad del trabajo y la ventana de lotes

Es posible que se generen advertencias durante el procesamiento del trabajo si, por ejemplo, la capacidad de la CPU o del espacio en disco excede el valor de umbral del servidor de aplicaciones que procesa el trabajo por lotes. Las advertencias no deben impedir la conclusión de un trabajo por lotes. Sin embargo, el administrador de la capacidad debe atender a todas las advertencias tan pronto como sea posible, ya que pueden conducir a futuros errores de procesamiento de trabajos. Cuando la ejecución de un trabajo se interrumpe a consecuencia de un error, algunas herramientas de programación intentan recuperar automáticamente el procesamiento del trabajo tomando como punto de partida el momento de la interrupción. La recuperación resulta muy útil cuando se procesan trabajos por lotes muy largos, ya que no es necesario reiniciar los trabajos interrumpidos desde el principio. Si la recuperación no es posible, habrá que reiniciar el trabajo.

Si la herramienta de programación no puede reiniciar o recuperar el procesamiento a partir del momento de la interrupción (o reiniciar o recuperar en una sesión específica), el administrador de la capacidad tendrá que poner en marcha manualmente procedimientos de reinicio o recuperación.

Actividades de programación de trabajos

En condiciones ideales, la arquitectura de lotes debe configurarse de modo que la interacción del administrador de la capacidad quede reducida al mínimo. Sin embargo, existen varias tareas diarias de las que el administrador de la capacidad debe hacerse cargo. Entre ellas:

• Supervisión

• Análisis

• Ajuste

• Implementación

• Administración de eventos

• Atención a solicitudes específicas

• Cambio de programación

• Copia de seguridad de sistemas

• Archivado

• Auditoría

• Entrada de registros del administrador de la capacidad

• Informes

Cada una de estas actividades forma parte integral del proceso de programación de trabajos. Las actividades de supervisión, análisis, ajuste e implementación componen un proceso iterativo. Las entradas realizadas en el proceso incluyen la utilización de recursos y los umbrales de los contratos de nivel operativo sobre los que se supervisa la arquitectura de lotes. Hay actividades continuas cuyo objetivo es optimizar el rendimiento y la utilización de la arquitectura. El resto de las actividades se realizan en respuesta a eventos, solicitudes o requisitos.

Documentación y aprendizaje

Todas las directivas y procedimientos deben estar claramente documentados para proporcionar al administrador de la capacidad una referencia para las operaciones cotidianas. La documentación debe incluir información sobre:

• Procedimientos para iniciar y detener los lotes de ejecución.

• Procedimientos para cambiar la prioridad de los trabajos.

• Procedimientos para atender las alertas y los errores.

• Procedimientos para atender los errores comunes.

• Procedimientos para analizar las causas de los errores.

• Procedimientos para escalar los errores.

• Procedimientos para enviar RFC.

• Procedimientos para documentar las tareas en el registro del administrador de la capacidad.

• Procedimientos para determinar qué hay que supervisar y cuándo.

• Procedimientos para atender y ejecutar solicitudes específicas como las de revisión y pruebas.

Sin el aprendizaje correcto, el administrador de la capacidad no tendrá recursos para desarrollar las actividades descritas en este documento. Es importante que el administrador de la capacidad disponga del aprendizaje adecuado para que los errores de procesamiento puedan obtener la respuesta correcta en el momento oportuno. El administrador de la capacidad debe asistir a cursos de proveedores sobre la herramienta de programación utilizada por la organización siempre que éstos estén disponibles.

Más información

Para obtener más información, visite el sitio web de Microsoft Operations Framework.

Para ver cómo Microsoft IT usa Microsoft Operations Framework y los procedimientos recomendados para la administración del servicio de TI, vaya a https://www.microsoft.com/technet/itshowcase/content/mofmmppt.mspx.

Punto de control: Procesos de funcionamiento, optimización y cambio

	Requisito
	Implementación de la administración de nivel de servicio a través de las operaciones de TI.
	Implementación de procedimientos recomendados de administración de versiones.
	Optimización de los procesos de administración de red y sistemas.
	Implementación de procedimientos recomendados de programación de trabajos.

Una vez completados los pasos anteriores, su organización habrá cumplido los requisitos mínimos del nivel racionalizado para operar, optimizar y cambiar procesos del modelo de optimización de infraestructura principal. Le recomendamos que atienda a la orientación de los recursos de procedimientos recomendados adicionales para la administración de operaciones en Microsoft Operations Framework.