Manage Replication Status

La joya de la corona, unos de los primeros y de los que, a pesar de poder ser mejorado, nunca he querido modificarlo, mas por cariño y añoranza de saber que al ser de los primero es tal y como es él.

Comprobamos el status de la replicación de los controladores de dominio, de múltiples dominios, parseando las líneas y detectando si hay o no errores en la replicación. En función a estos podemos definir el texto del mensaje de correo y a las cuentas a las cuales lo vamos a dirigir.

Simple, conciso y efectivo, en un solo bloque y creo que no es necesario explicarlo…

image

Y el resultado….. mejor que lo ejecutéis en vuestros dominios y evaluéis por vosotros mismo la calidad y cantidad de información de la que podéis disponer.

Mi recomendación, es que lo ejecutéis a través de una tarea programada cada 45 minutos.

Anuncios

Health Status AD

Una de mis últimas incorporaciones, ese maravillo listado que de vez en cuando nos piden y como entre uno y otro pasa tanto tiempo, apenas tenemos ganas de acordarnos como lo hicimos la ultima vez. Pues bien, aquí esta el Script que básicamente comprueba;

  1. Inactive User
  2. Inactive Computer
  3. User Created in Week
  4. Pass Never Expire

El script es multi funcional, permitiendo que añadáis cualquier tipo de informe extra que necesitéis en vuestro día a día.

Comencemos por las variables

image

Recopilemos la información de los controladores de dominio

image

Vamos preparando nuestro excel

image

Segunda “Hoja”

image

image

Tercera “Hoja”

image

image

Cuarta “Hoja”

image

Quinta “Hoja”

image

image

Encabezado, terminamos y cerramos nuestro excel.

image

Y como no, un clásico, lo enviamos por mail…

image

Y como muestra un botón…

image

En este si que acepto, comentarios, aportaciones, mejoras y sobre todo, la actualización a utilizar Excel 2013…

Health Check Status (RtP)

A quien no le ha ocurrido alguna vez que creyendo que ese servidor magnifico estaba listo para ser puesto en producción,  se ha llevado la decepción del siglo ya que al ponerlo en marcha el pobrecito del “server” disparaba alertas por todos lados.

Para evitar esto, lo señores del ITIL ( que son un conclave de viejos raquíticos y tristes) decidieron declinar la importancia de este proceso al “Release to Production” o vulgarmente puesta en producción.

Pues bien, yo he sufrido en mis carnes eso de “ponlo, ponlo en producción si nunca ha tenido ningún problema…”, para lo cual me he creado este script (un todo formado por partes de otros scripts) que es un vistazo inicial, nos da el “status” real de la maquina y genera un informe para que podamos aportar “pruebas” a la decisión de ponerlos en producción. Todavía en “fase de pruebas”, pero muy funcional en esta versión.

Claro, en HTML, multi-servidor, y muy, muy gráfico.

Como es costumbre comencemos por declarar las variables que vamos a utilizar.

image

Creamos el gráfico…

image

Comprobamos el Up Time de nuestro servidor

image

Comenzamos con la cabecera del informe y el CSS (estilo que no falte) (ojo que son varias partes)

image

image

Comprobemos el espacio del que dispone en los discos

image

Localizamos la información del Sistema

image

Comprobamos los servicios

image

Comprobamos el Event Log de la maquina

image

Creamos y guardamos el gráfico al mismo tiempo que Up Time

image

Y nos metemos en faena, cual Quijote tecnológico para detallar el informe

image

image

Informe listo, pues démosle al email

image

Si lo ejecutamos, servidor a servidor, podemos añadir el grafico al mensaje de correo con un adjunto más, si ejecutamos un bloque de servidores no, ya que a fecha de hoy no he conseguido solventar el problema de que solo me deja que la cadena de caracteres del adjunto no supere los 260 (pero estamos trabajando en ello)

El ansiado resultado (todavía me sigue dejando con la boca abierta)

image

Prometo terminarlo y hacer que sea muy muy gestionable…

Security Management (Proceso)

La Gestión de la Seguridad esta estrechamente relacionada con prácticamente todos los otros procesos TI y necesita para su éxito la colaboración de toda la organización.

Para que esa colaboración sea eficaz es necesario que la Gestión de la Seguridad:

  • Establezca una clara y definida política de seguridad que sirva de guía a todos los otros procesos.
  • Elabore un Plan de Seguridad que incluya los niveles de seguridad adecuados tanto en los servicios prestados a los clientes como en los acuerdos de servicio firmados con proveedores internos y externos.
  • Implemente el Plan de Seguridad.
  • Monitorice y evalúe el cumplimiento de dicho plan.
  • Supervise proactivamente los niveles de seguridad analizando tendencias, nuevos riesgos y vulnerabilidades.
  • Realice periódicamente auditorías de seguridad.

Política de Seguridad

Es imprescindible disponer de un marco general en el que encuadrar todos los subprocesos asociados a la Gestión de la Seguridad. Su complejidad e intricadas interrelaciones necesitan de una política global clara en donde se fijen aspectos tales como los objetivos, responsabilidades y recursos.

En particular la Política de Seguridad debe determinar:

  • La relación con la política general del negocio.
  • La coordinación con los otros procesos TI.
  • Los protocolos de acceso a la información.
  • Los procedimientos de análisis de riesgos.
  • Los programas de formación.
  • El nivel de monitorización de la seguridad.
  • Qué informes deben ser emitidos periódicamente.
  • El alcance del Plan de Seguridad.
  • La estructura y responsables del proceso de Gestión de la Seguridad.
  • Los procesos y procedimientos empleados.
  • Los responsables de cada subproceso.
  • Los auditores externos e internos de seguridad.
  • Los recursos necesarios: software, hardware y personal.
Plan de Seguridad

El objetivo del Plan de Seguridad es fijar los niveles de seguridad que han de ser incluidos como parte de los SLAs, OLAs y UCs.

Este plan ha de ser desarrollado en colaboración con la Gestión de Niveles de Servicio que es la responsable en última instancia tanto de la calidad del servicio prestado a los clientes como la del servicio recibido por la propia organización TI y los proveedores externos.

El Plan de Seguridad debe diseñarse para ofrecer un mejor y más seguro servicio al cliente y nunca como un obstáculo para el desarrollo de sus actividades de negocio.

Siempre que sea posible deben definirse métricas e indicadores clave que permitan evaluar los niveles de seguridad acordados.

Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de seguridad coherentes en todas las fases del servicio y para todos los estamentos implicados. “Una cadena es tan resistente como el más débil de sus eslabones”, por lo que carece de sentido, por ejemplo, establecer una estrictas normas de acceso si una aplicación tiene vulnerabilidades frente a inyecciones de SQL. Quizá con ello podamos engañar a algún cliente durante algún tiempo ofreciendo la imagen de “fortaleza” pero esto valdrá de poco si alguien descubre que la “puerta de atrás está abierta”.


Aplicación de las Medidas de Seguridad

Por muy buena que sea la planificación de la seguridad resultará inútil si las medidas previstas no se ponen en práctica.

Es responsabilidad de la Gestión de Seguridad coordinar la implementación de los protocolos y medidas de seguridad establecidas en la Política y el Plan de Seguridad.

En primer lugar la Gestión de la Seguridad debe verificar que:

  • El personal conoce y acepta las medidas de seguridad establecidas así como sus responsabilidades al respecto.
  • Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo y responsabilidad.
  • Se imparte la formación pertinente.

Es también responsabilidad directa de la Gestión de la Seguridad:

  • Asignar los recursos necesarios.
  • Generar la documentación de referencia necesaria.
  • Colaborar con el Service Desk y la Gestión de Incidentes en el tratamiento y resolución de incidentes relacionados con la seguridad.
  • Instalar y mantener las herramientas de hardware y software necesarias para garantizar la seguridad.
  • Colaborar con la Gestión de Cambios y Versiones para asegurar que no se introducen nuevas vulnerabilidades en los sistemas en producción o entornos de pruebas.
  • Proponer RFCs a la Gestión de Cambios que aumenten los niveles de seguridad.
  • Colaborar con la Gestión de la Continuidad del Servicio para asegurar que no peligra la integridad y confidencialidad de los datos en caso de desastre.
  • Establecer las políticas y protocolos de acceso a la información.
  • Monitorizar las redes y servicios en red para detectar intrusiones y ataques.

Es necesario que la gestión de la empresa reconozca la autoridad de la Gestión de la Seguridad respecto a todas estas cuestiones y que incluso permita que ésta proponga medidas disciplinarias vinculantes cuando los empleados u otro personal relacionado con la seguridad de los servicios incumpla con sus responsabilidades.


Evaluación y Mantenimiento

Evaluación

No es posible mejorar aquello que no se conoce, es por la tanto indispensable evaluar el cumplimiento de las medidas de seguridad, sus resultados y el cumplimiento de los SLAs.

Aunque no es imprescindible, es recomendable que estas evaluaciones se complementen con auditorías de seguridad externas y/o internas realizadas por personal independiente de la Gestión de la Seguridad.

Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer mejoras que se plasmaran en RFCs que habrán de ser evaluados por la Gestión de Cambios.

Independientemente de estas evaluaciones de carácter periódico se deberán generar informes independientes cada vez que ocurra algún incidente grave relacionado con la seguridad. De nuevo, si la Gestión de la Seguridad lo considera oportuno, estos informes se acompañaran de las RFCs correspondientes.

Mantenimiento

La Gestión de la Seguridad es un proceso continuo y se han de mantener al día el Plan de Seguridad y las secciones de seguridad de los SLAs.

Los cambios en el Plan de Seguridad y los SLAs pueden ser resultado de la evaluación arriba citada o de cambios implementados en la infraestructura o servicios TI.

No hay nada más peligroso que la falsa sensación de seguridad que ofrecen medidas de seguridad obsoletas.

Es asimismo importante que la Gestión de la Seguridad esté al día en lo que respecta a nuevos riesgos y vulnerabilidades frente a virus, spyware, ataques de denegación de servicio, etcétera, y que adopte las medidas necesarias de actualización de equipos de hardware y software, sin olvidar el apartado de formación: el factor humano es normalmente el eslabón más débil de la cadena.


Control del Proceso

Al igual que en el resto de procesos TI es necesario realizar un riguroso control del proceso para asegurar que la Gestión de la Seguridad cumple sus objetivos.

Una buena Gestión de la Seguridad debe traducirse en una:

  • Disminución del número de incidentes relacionados con la seguridad.
  • Un acceso eficiente a la información por el personal autorizado.
  • Gestión proactiva que permita identificar vulnerabilidades potenciales antes de que estas se manifiesten y provoquen una seria degradación de la calidad del servicio.

La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Seguridad y aporta información de vital importancia a otras áreas de la infraestructura TI.

Entre la documentación generada cabría destacar:

  • Informes sobre el cumplimiento, en lo todo lo referente al apartado de seguridad, de los SLAs, OLAs y UCs en vigor.
  • Relación de incidentes relacionados con la seguridad calificados por su impacto sobre la calidad del servicio.
  • Evaluación de los programas de formación impartidos y sus resultados.
  • Identificación de nuevos peligros y vulnerabilidades a las que se enfrenta la infraestructura TI.
  • Auditorías de seguridad.
  • Informes sobre el grado de implementación y cumplimiento de los planes de seguridad establecidos.

Service Continuity Management(Proceso)

Las principales actividades de la Gestión de la Continuidad del Servicio se resumen en:

  • Establecer las políticas y alcance de la ITSCM.
  • Evaluar el impacto en el negocio de una interrupción de los servicios TI.
  • Analizar y prever los riesgos a los que esta expuesto la infraestructura TI.
  • Establecer las estrategias de continuidad del servicio TI.
  • Adoptar medidas proactivas de prevención del riesgo.
  • Desarrollar los planes de contingencia.
  • Poner a prueba dichos planes.
  • Formar al personal sobre los procedimientos necesarios para la pronta recuperación del servicio.
  • Revisar periódicamente los planes para adaptarlos a las necesidades reales del negocio.

Política y Alcance

El primer paso necesario para desarrollar una Gestión de la Continuidad del Servicio coherente es establecer claramente sus objetivos generales, su alcance y el compromiso de la organización TI: su política.

La gestión de la empresa debe demostrar su implicación con el proceso desde un primer momento pues la implantación de la ITSCM puede resultar compleja y costosa sin la contrapartida de un retorno obvio a la inversión.

Es imprescindible establecer el alcance de la ITSCM en función de:

  • Los planes generales de Continuidad del Negocio.
  • Los servicios TI estratégicos.
  • Los estándares de calidad adoptados.
  • El histórico de interrupciones graves de los servicios TI.
  • Las expectativas de negocio.
  • La disponibilidad de recursos.

La Gestión de la Continuidad del Servicio está abocada al fracaso sino se destina una cantidad de recursos suficientes, tanto en el plano humano como de equipamiento (software y hardware). Su dimensión depende de su alcance y sería absurdo y contraproducente instaurar una política demasiado ambiciosa que no dispusiera de los recursos correspondientes.

Una importante parte del esfuerzo debe destinarse a la formación del personal. Éste debe interiorizar su papel en momentos de crisis y conocer perfectamente las tareas que se espera desempeñe: una emergencia no es el mejor momento para estudiar documentación y manuales.


Análisis de Impacto

Una correcta Gestión de la Continuidad del Servicio requiere en primer lugar determinar el impacto que una interrupción de los servicios TI pueden tener en el negocio.

En la actualidad casi todas las empresas, grandes y pequeñas, dependen en mayor o menor medida de los servicios informáticos, por lo que cabe esperar que un “apagón” de los servicios TI afecte a prácticamente todos los aspectos del negocio. Sin embargo, es evidente que hay servicios TI estratégicos de cuya continuidad puede depender la supervivencia del negocio y otros que “simplemente” aumentan la productividad de la fuerza comercial y de trabajo.

Cuanto mayor sea el impacto asociado a la interrupción de un determinado servicio mayor habrá de ser el esfuerzo realizado en actividades de prevención. En aquellos casos en que la “solución puede esperar” se puede optar exclusivamente por planes de recuperación.

Los servicios TI han de ser analizados por la ITSCM en función de diversos parámetros:

  • Consecuencias de la interrupción del servicio en el negocio:
    • Pérdida de rentabilidad.
    • Pérdida de cuota de mercado.
    • Mala imagen de marca.
    • Otros efectos secundarios.
  • Cuánto se puede esperar a restaurar el servicio sin que tenga un alto impacto en los procesos de negocio.
  • Compromisos adquiridos a través de los SLAs.

Dependiendo de estos factores se buscará un balance entre las actividades de prevención y recuperación teniendo en cuenta sus respectivos costes financieros.


Evaluación de Riesgos

Sin conocer cuales son los riesgos reales a los que se enfrenta la infraestructura TI es imposible realizar una política de prevención y recuperación ante desastre mínimamente eficaz.

La Gestión de la Continuidad del Servicio debe enumerar y evaluar, dependiendo de su probabilidad e impacto, los diferentes riesgos factores de riesgo. Para ello la ITSCM debe:

  • Conocer en profundidad la infraestructura TI y cuales son los elementos de configuración (CIs) involucrados en la prestación de cada servicio, especialmente los servicios TI críticos y estratégicos.
  • Analizar las posibles amenazas y estimar su probabilidad.
  • Detectar los puntos más vulnerables de la infraestructura TI.

Gracias a los resultados de este detallado análisis se dispondrá de información suficiente para proponer diferentes medidas de prevención y recuperación que se adapten a las necesidades reales del negocio.

La prevención frente a riesgos genéricos y poco probables puede ser muy cara y no estar siempre justificada, sin embargo, las medidas preventivas o de recuperación frente a riesgos específicos pueden resultar sencillas, de rápida implementación y relativamente baratas.

Por ejemplo, si el riesgo de perdida de alimentación eléctrica es elevado debido, por ejemplo, a la localización geográfica se puede optar por deslocalizar ciertos servicios TI a través de ISPs que dispongan de sistemas de generadores redundantes o adquirir generadores que proporcionen la energía mínima necesaria para alimentar los CIs de los que dependen los servicios más críticos, etcétera.


Estrategias

La continuidad de los servicios TI puede conseguirse bien mediante medidas preventivas, que eviten la interrupción de los servicios, o medidas reactivas, que recuperen unos niveles aceptables de servicio en el menor tiempo posible.

Es responsabilidad de la Gestión de la Continuidad del Servicio diseñar actividades de prevención y recuperación que ofrezcan las garantías necesarias a unos costes razonables.

Actividades preventivas

Las medidas preventivas requieren un detallado análisis previo de riesgos y vulnerabilidades. Algunos de ellos serán de carácter general: incendios, desastres naturales, etcétera, mientras que otros tendrán un carácter estrictamente informático: fallo de sistemas de almacenamiento, ataques de hackers, virus informáticos, etcétera.

La adecuada prevención de los riesgos de carácter general dependen de una estrecha colaboración con la Gestión de la Continuidad del Negocio (BCM) y requieren medidas que implican a la infraestructura “física” de la organización.

La prevención de riesgos y vulnerabilidades “lógicas” o de hardware requieren especial atención de la ITSCM. En este aspecto es esencial la estrecha colaboración con la Gestión de la Seguridad.

Los sistemas de protección habituales son los de “Fortaleza” que ofrecen protección perimetral a la infraestructura TI. Aunque imprescindibles no se hallan exentos de sus propias dificultades pues aumentan la complejidad de la infraestructura TI y pueden ser a su vez fuente de nuevas vulnerabilidades.

Actividades de recuperación

Tarde o temprano, por muy eficientes que seamos en nuestras actividades de prevención, será necesario poner en marcha procedimientos de recuperación.

En líneas generales existen tres opciones de recuperación del servicio:

  • “Cold standby”: que requiere un emplazamiento alternativo en el que podamos reproducir en pocos días nuestro entorno de producción y servicio. Esta opción es la adecuada si los planes de recuperación estiman que la organización puede mantener sus niveles de servicio durante este periodo sin el apoyo de la infraestructura TI.
  • “Warm standby”: que requiere un emplazamiento alternativo con sistemas activos diseñados para recuperar los servicios críticos en un plazo de entre 24 y 72 horas.
  • “Hot standby”: que requiere un emplazamiento alternativo con una replicación continua de datos y con todos los sistemas activos preparados para la inmediata sustitución de la estructura de producción. Ésta es evidentemente la opción mas costosa y debe emplearse sólo en el caso de que la interrupción del servicio TI tuviera inmediatas repercusiones comerciales.

Por supuesto, existe otra alternativa que consiste en hacer “poco o nada” y esperar que las aguas vuelvan naturalmente a su cauce: una alternativa poco recomendable para alguien que esté hojeando este curso sobre ITIL y del que suponemos que los servicios TI jugarán un papel importante en su organización Risa


Organización y Planificación

Una vez determinado el alcance de la ITSCM, analizados los riesgos y vulnerabilidades y definidas unas estrategias de prevención y recuperación es necesario asignar y organizar los recursos necesarios. Con ese objetivo la Gestión de la Continuidad del Servicio debe elaborar una serie de documentos entre los que se incluyen:

  • Plan de prevención de riesgos.
  • Plan de gestión de emergencias.
  • Plan de recuperación.
Plan de prevención de riesgos

Cuyo objetivo principal es el de evitar o minimizar el impacto de un desastre en la infraestructura TI.

Entre las medidas habituales se encuentran:

  • Almacenamiento de datos distribuidos.
  • Sistemas de alimentación eléctrica de soporte.
  • Políticas de back-ups.
  • Duplicación de sistemas críticos.
  • Sistemas de seguridad pasivos.
Plan de gestión de emergencias

Las crisis suelen provocar “reacciones de pánico” que pueden ser contraproducentes y a veces incluso más dañinas que las provocadas por el incidente que las causo. Por ello es imprescindible que en caso de situación de emergencia estén claramente determinadas las responsabilidades y funciones del personal así como los protocolos de acción correspondientes.

En principio los planes de gestión de emergencias deben tomar en cuenta aspectos tales como:

  • Evaluación del impacto de la contingencia en la infraestructura TI.
  • Asignación de funciones de emergencia al personal de servicio TI.
  • Comunicación a los usuarios y clientes de una grave interrupción o degradación del servicio.
  • Procedimientos de contacto y colaboración con los proveedores involucrados.
  • Protocolos para la puesta en marcha del plan de recuperación correspondiente.
Plan de recuperación

Cuando la interrupción del servicio es inevitable llego el momento de poner en marcha los procedimientos de recuperación.

El plan de recuperación debe incluir todo lo necesario para:

  • Reorganizar al personal involucrado.
  • Reestablecer los sistemas de hardware y software necesarios.
  • Recuperar los datos y reiniciar el servicio TI.

Los procedimientos de recuperación pueden depender de la importancia de la contingencia y de la opción de recuperación asociada (“cold o hot stand-by”), pero en general involucran:

  • Asignación de personal y recursos.
  • Instalaciones y hardware alternativos.
  • Planes de seguridad que garanticen la integridad de los datos.
  • Procedimientos de recuperación de datos.
  • Contratos de colaboración con otras organizaciones.
  • Protocolos de comunicación con los clientes.

Cuando se pone en marcha un plan de recuperación no hay espacio para la improvisación, cualquier decisión puede tener graves consecuencias tanto en la percepción que de nosotros tengan nuestros clientes como en los costes asociados al proceso.


Supervisión

Una vez establecidas las políticas, estrategias y planes de prevención y recuperación es indispensable que estos no queden en papel mojado y que la organización TI esté preparada para su correcta implementación.

Ello depende de dos factores clave: la correcta formación del personal involucrado y la continua monitorización y evaluación de los planes para su adecuación a las necesidades reales del negocio.

Formación

Es inútil disponer de unos completos planes de prevención y recuperación si las personas que eventualmente deben llevarlos a cabo no están familiarizados con los mismos.

Es indispensable que la ITSCM:

  • De a conocer al conjunto de la organización TI los planes de prevención y recuperación.
  • Ofrezca formación específica sobre los diferentes procedimientos de prevención y recuperación.
  • Realice periódicamente simulacros para diferentes tipos de desastres con el fin de asegurar la capacitación del personal involucrado.
  • Facilite el acceso permanente a toda la información necesaria, por ejemplo, a través de la Intranet o portal B2E de la empresa.
Actualización y auditorías

Tanto las políticas, estrategias y planes han de ser actualizados periódicamente para asegurar que responden a los requisitos de la organización en su conjunto.

Cualquier cambio en la infraestructura TI o en los planes de negocio puede requerir de una profunda revisión de los planes en vigor y una consecuente auditoría que evalúe su adecuación a la nueva situación.

En ocasiones en que el dinamismo del negocio y los servicios TI lo haga recomendable, estos procesos de actualización y auditoria pueden establecerse de forma periódica.

La Gestión de Cambios juega un papel esencial en asegurar que los planes de recuperación y prevención estén actualizados manteniendo informada a la ITSCM de los cambios realizados o previstos.


Control del Proceso

La Gestión de la Continuidad del Servicio debe elaborar periódicamente informes sobre su gestión que incluyan información relevante para el resto de la organización TI.

Estos informes deben incluir:

  • Análisis sobre nuevos riesgos y evaluación de su impacto.
  • Evaluación de los simulacros de desastre realizados.
  • Actividades de prevención y recuperación realizadas.
  • Costes asociados a los planes de prevención y recuperación.
  • Preparación y capacitación del personal TI respecto a los planes y procedimientos de prevención y recuperación.

Uno de los factores clave para el éxito de la Gestión de la Continuidad del Servicio es mantener la “concentración”. Tras largos periodos en los que la prevención o, simple y llanamente, la suerte han impedido la existencia de graves interrupciones del servicio se puede caer en un relajamiento que puede acarrear graves consecuencias.

Por esto es imprescindible llevar controles rigurosos que impidan que la inversión y compromiso inicial se diluyan y la ITSCM no esté a la altura de la situación cuando sus servicios sean vitales para evitar que “un desastre se convierta en una catástrofe”.

Pero si el control del proceso es importante en condiciones normales éste se vuelve crítico durante las situaciones de crisis. La ITSCM debe garantizar:

  • La puesta en marcha de los planes preestablecidos.
  • La supervisión de los mismos.
  • La coordinación con la Gestión de Continuidad del Negocio.
  • La asignación de recursos necesarios.

Service Continuity Management (Objetivos)

Los objetivos principales de la Gestión de la Continuidad de los Servicios TI (ITSCM) se resumen en:

  • Garantizar la pronta recuperación de los servicios (críticos) TI tras un desastre.
  • Establecer políticas y procedimientos que eviten, en la medida de lo posible, las perniciosas consecuencias de un desastre o causa de fuerza mayor.

Aunque, a priori, las políticas proactivas que prevean y limiten los efectos de un desastre sobre los servicios TI son preferibles a las exclusivamente reactivas, es importante valorar los costes relativos y la incidencia real en la continuidad del negocio para decantarse por una de ellas o por una sabia combinación de ambas.

Una correcta ITSCM debe formar parte integrante de la Gestión de Continuidad del Negocio (BCM) y debe estar a su servicio. Los servicios TI no son sino una parte, aunque a menudo muy importante, del negocio en su conjunto y no tiene mayor sentido que, por ejemplo, un sistema de pedidos online siga funcionando a la perfección tras un desastre si nos resulta imposible suministrar la mercancía a nuestros clientes.

Es importante diferenciar entre desastres “de toda la vida”, tales como incendios, inundaciones, etcétera, y desastres “puramente informáticos”, tales como los producidos por ataques distribuidos de denegación de servicio (DDOS), virus informáticos, etcétera. Aunque es responsabilidad de la ITSCM prever los riesgos asociados en ambos casos y restaurar el servicio TI con prontitud, es evidente que recae sobre la ITSCM una responsabilidad especial en el último caso pues:

  • Sólo afectan directamente a los servicios TI pero paralizan a toda la organización.
  • Son más previsibles y más habituales.
  • La percepción del cliente es diferente: los desastres naturales son más asumibles y no se asocian a actitudes negligentes, aunque esto no sea siempre cierto.

Los principales beneficios de una correcta Gestión de la Continuidad del Servicio se resumen en:

  • Se gestionan adecuadamente los riesgos.
  • Se reduce el periodo de interrupción del servicio por causas de fuerza mayor.
  • Se mejora la confianza en la calidad del servicio entre clientes y usuarios.
  • Sirve de apoyo al proceso de Gestión de la Continuidad del Negocio.

Las principales dificultades a la hora de implementar la Gestión de la Continuidad del Servicio se resumen en:

  • Puede haber resistencia a realizar inversiones cuya rentabilidad no es inmediata.
  • No se presupuestan correctamente los costes asociados.
  • No se asignan los recursos suficientes.
  • No existe el compromiso suficiente con el proceso dentro de la organización y las tareas y actividades correspondientes se demoran perpetuamente para hacer frente a “actividades más urgentes”.
  • No se realiza un correcto análisis de riesgos y se obvian amenazas y vulnerabilidades reales.
  • El personal no esta familiarizado con las acciones y procedimientos a tomar en caso de interrupción grave de los servicios.
  • Falta de coordinación con la BCM.

Capacity Management (Proceso)

Las principales actividades de la Gestión de la Capacidad se resumen en:

  • Desarrollo del Plan de Capacidad.
  • Modelado y simulación de diferentes escenarios de capacidad.
  • Monitorización del uso y rendimiento de la infraestructura TI.
  • Gestión de la demanda.
  • Creación y mantenimiento de la Base de Datos de Capacidad (CDB).

El proceso de Gestión de la Capacidad puede segmentarse en subprocesos que analizan las necesidades de capacidad TI desde diferentes puntos de vista:

  • Gestión de la Capacidad del Negocio: que centra su objeto de atención en las necesidades futuras de usuarios y clientes.
  • Gestión de la Capacidad del Servicio: que analiza el rendimiento de los servicios TI con el objetivo de garantizar los niveles de servicio acordados.
  • Gestión de la Capacidad de Recursos: que estudia tanto el uso de la infraestructura TI como sus tendencias para asegurar que se dispone de los recursos suficientes y que estos se utilizan eficazmente.

Planificación

Plan de Capacidad

La elaboración del Plan de Capacidad es la tarea principal de la Gestión de Capacidad.

El Plan de Capacidad recoge:

  • Toda la información relativa a la capacidad de la infraestructura TI.
  • Las previsiones sobre necesidades futuras basadas en tendencias, previsiones de negocio y SLAs existentes.
  • Los cambios necesarios para adaptar la capacidad TI a las novedades tecnológicas y las necesidades emergentes de usuarios y cliente.

El Plan de Capacidad debe incluir información sobre los costes de la capacidad actual y prevista. Esta información es indispensable para que la Gestión Financiera pueda elaborar los presupuestos y previsiones financieras de manera realista.

Aunque, en principio, el Plan de Capacidad puede tener una vigencia anual o bianual es importante que se monitorice su cumplimiento para adoptar medidas correctivas en cuanto se detecten desviaciones importantes del mismo.

Modelado y Benchmarking

Cuanto más compleja sea una infraestructura informática más difícil es prever las necesidades de capacidad futura. En esos casos, es imprescindible realizar modelos y simulaciones sobre posibles escenarios de desarrollo futuro que aseguren la correcta escalabilidad de las aplicaciones y hardware.

El nivel de detalle al que se lleve este modelado dependerá de varios factores:

  • Costes asociados al incremento de la capacidad.
  • Costes inherentes al proceso mismo de modelado y simulación.
  • Alcance de los incrementos de capacidad previstos.
  • La “criticalidad” de los sistemas implicados.

Sopesando los anteriores factores podemos optar por:

  • Un simple análisis de tendencias que permita evaluar la carga de proceso esperada en la infraestructura informática y escalar consecuentemente su capacidad actual.
  • Realizar modelos y simulaciones sobre diferentes escenarios para llevar a cabo previsiones de carga y repuesta de la infraestructura informática.
  • Realizar benchmarks con prototipos reales para asegurar la capacidad y el rendimiento de la futura infraestructura.

Recursos

Un aspecto esencial de la Gestión de la Capacidad es el de asignar recursos adecuados de hardware, software y personal a cada servicio y aplicación.

El correcto dimensionamiento requiere que la Gestión de la Capacidad disponga de información fiable sobre:

  • Los niveles de servicio acordados y/o previstos.
  • Niveles de rendimiento esperados.
  • Impacto de la aplicación o servicio en los procesos de negocio del cliente.
  • Márgenes de seguridad y disponibilidad.
  • Costes asociados a los equipos de hardware y otros recursos TI necesarios.

Es importante que la Gestión de la Capacidad participe en las primeras etapas de desarrollo de un producto, servicio o definición de un SLA para asegurar que se dispondrá de la capacidad necesaria para llevar el proyecto a buen término.

Es relativamente frecuente que se obvien aspectos relativos al correcto dimensionamiento de una aplicación debido a expectativas injustificadas sobre la tecnología. Se puede caer en el equivoco de que los costes asociados a la capacidad se limitan a la compra de mas servidores, o más espacio de almacenamiento, etcétera, olvidando que sistemas más complejos implican uno mayores gastos de mantenimiento y administración, o ignorando los problemas que pueden conllevar dichos cambios.


Supervisión del Proceso

La Gestión de la Capacidad es un proceso continuo e iterativo que monitoriza, analiza y evalúa el rendimiento y capacidad de la infraestructura TI y con los datos obtenidos optimiza los servicios o eleva una RFC a la Gestión de Cambios.

Tanto la información obtenida en estas actividades como la generada a partir de ella por la Gestión de la Capacidad se almacena y registra en la Base de Datos de la Capacidad (CDB).

Monitorización

Su objetivo principal es asegurar que el rendimiento de la infraestructura informática se adecua a los requisitos de los SLAs.

La monitorización debe incluir, además de aspectos técnicos todos aquellos relativos a licencias y otros aspectos de carácter administrativo.

Análisis y Evaluación

Los datos recogidos deben ser analizados para evaluar la conveniencia de adoptar acciones correctivas tales como petición de aumento de la capacidad o una mejor Gestión de la Demanda.

Optimización y cambios

Si se ha optado por solicitar un aumento de la capacidad se elevará una RFC a la Gestión de Cambios para que se desencadene todo el proceso necesario para la implementación del cambio. La Gestión de la Capacidad prestará su apoyo en todo el proceso y será corresponsable, junto a la Gestión de Cambios y Versiones de asegurar que el cambio solicitado cumpla los objetivos previstos.

En el caso de que una simple racionalización de la demanda sea suficiente para solventar las posibles deficiencias o incumplimientos de los SLAs será la propia Gestión de la Capacidad la responsable de gestionar ese subproceso.

Base de Datos de la Capacidad

La CDB debe cubrir toda la información de negocio, financiera, técnica y de servicio que reciba y genere la Gestión de la Capacidad relativas a la capacidad de la infraestructura y sus elementos.

Idealmente la CDB debe estar interrelacionada con la CMDB para que esta última ofrezca una imagen integral de los sistemas y aplicaciones con información relativa a su capacidad. Esto no es óbice para que ambas bases de datos puedan ser “físicamente independientes”.


Gestión de la Demanda

El objetivo de la Gestión de la Demanda es el de optimizar y racionalizar el uso de los recursos TI.

Aunque la Gestión de la Demanda debe formar parte de las actividades rutinarias de la Gestión de la Capacidad ésta cobra especial relevancia cuando existen problemas de capacidad en la infraestructura TI.

El origen de los problemas que la Gestión de la Demanda debe subsanar a corto plazo incluyen:

  • Degradación del servicio por aumentos no previstos de la demanda.
  • Interrupciones parciales del servicio por errores de hardware o software.

La Gestión de la Demanda es la encargada en estos casos de redistribuir la capacidad para asegurar que los servicios críticos no se ven afectados o, cuando menos, lo sean en la menor medida posible. Para llevar a cabo esta tarea de forma eficiente es imprescindible que la Gestión de la Capacidad conozca las prioridades del negocio del cliente y pueda actuar en consecuencia.

Pero una tarea no menos importante es la Gestión de la Demanda a medio y largo plazo. Un aumento de la capacidad siempre conlleva costes que muchas veces resultan innecesarios. Una correcta monitorización de la capacidad permite reconocer puntos débiles de la infraestructura TI o cuellos de botella y evaluar si es posible una redistribución a largo plazo de la carga de trabajo que permita dar un servicio de calidad sin aumento de la capacidad.

Por ejemplo, una incorrecta distribución de tareas puede provocar que el ancho de banda contratado por la organización se muestre insuficiente en horas punta porque se estén enviando miles de correos electrónicos asociados a procesos automáticos (tales como campañas de marketing promocional, informes de rendimiento para clientes, etcétera). En la mayoría de los casos esos procesos pueden desplazarse fuera de horas punta sin degradar la calidad del servicio, ahorrando a la organización una gravosa ampliación del ancho de banda.

Ahora bien, si el coste añadido por aumentar el ancho de banda es marginal, puede resultar más eficiente su contratación directa que invertir el precioso (y costoso) tiempo de personal altamente especializado en la optimización del sistema.

La Gestión de la Capacidad debe evaluar a priori, basandose en la experiencia y las tendencias del mercado, cuándo la solución “más potente, más grande” es económicamente más rentable (teniendo en cuenta los costes indirectos) que un análisis pormenorizado de la situación.


Control del Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de la Capacidad.

La documentación elaborada debe incluir información sobre:

  • El uso de recursos.
  • Desviaciones de la capacidad real sobre la planificada.
  • Análisis de tendencias en el uso de la capacidad.
  • Métricas establecidas para el análisis de la capacidad y monitorización del rendimiento.
  • Impacto en la calidad del servicio, disponibilidad y otros procesos TI.

El éxito de la Gestión de la Capacidad depende algunos indicadores clave entre los que se encuentran:

  • Correcta previsión de las necesidades de capacidad.
  • Reducción de los costes asociados a la capacidad.
  • Más altos niveles de disponibilidad y seguridad.
  • Mayor satisfacción de los usuarios y clientes.
  • Cumplimiento de los SLAs.