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…

Printer Status / Queue Status

Este es un problema relativamente “joven”, hasta hace poco tiempo no tenia que preocuparme del estado de los servidores de impresión ni del estado de las “colas”, pero ahora tengo un servidor de impresión crítico para el negocio y he generado este script que me muestra el estado del servidor y los trabajos que están en curso. Tengo una tarea programada que lo ejecuta cada hora y envía el reporte por correo electrónico.

Iniciamos las variables que necesitamos en nuestro script.

image

Comprobamos y generamos el fichero del reporte, y limpiamos los antiguos. En esta versión del script y por necesidades del servicio, acumulamos estos reportes en la carpeta de Report.

image

Escribimos el encabezado del informe que vamos a generar.

image

image

Creamos la primera fila con los títulos de los campos

image

Ahora comenzamos a comprobar el estado de las “colas” de nuestro servidor de impresión.

image

Una vez que obtenemos los datos, comprobamos el estado de la “cola” y determinamos el color que debería de tener …

image

Escribimos la fila con la información obtenida

image

Colocamos el pie del informe o en su defecto la leyenda que queramos indicar en función a los colores …

image

Enviamos el correo electrónico con el contenido del informe (reporte)…

image

La estructura que nos queda al final es la siguiente:

image

Check Disk Space for Multiple Server

No me digáis que nos habéis sufrido el “ataque loco” de esa aplicación que por la noches es capaz de fagocitar todo el espacio libre de los discos de nuestros servidores. Pues bien, yo me he generado un script que de manera gráfica me envía un mensaje de correo con el espacio disponible en los discos de los servidores.

Sencillo a la vez que sutil.

La primera parte del script, es de rigor, cargamos las variables que vamos a necesitar para controlar todo el proceso.

image

Leemos el contenido de nuestro fichero de servidores y limpiamos los informes antiguos, aunque en el caso que os muestro, se almacenan en la carpeta report para mantener un histórico de los mismos.

image

Generamos el diseño de nuestro formato de informe, en HTML

image

image

Creamos el formato de la tabla y escribimos las primeras columnas

image

Comenzamos a evaluar los espacios en disco de la lista de servidores que hemos leído inicialmente.

image

Una vez que disponemos de la información, escribimos la columna con los datos

image

Añadimos el “pie de página” con la leyenda de los colores que hemos utilizado.

image

Una vez que tenemos “toda”la información de nuestros servidores, comenzamos la generación y envío del correo electrónico.

image

Y la verdad es que el resultado, es digno

image

image

Como siempre, agradezco vuestros comentarios y/o aportaciones para mejorar el funcionamiento y/o rendimiento del script y espero que os sirva de ayuda.

Network Protocol Time (windows OS)

Desde hace bastante tiempo, siempre he sufrido los problemas ocasionados por la des sincronización horaria de las maquinas con OS Windows. Pues bien, hace poco he generado un script en PowerShell que me permite tener un control sobre la sincronización de los controladores de dominio y sobre mis dos servidores que utilizo para que sincronicen la hora con las fuentes externas.

Mi infraestructura esta diseñada de la siguiente manera;

– Dos DataCenter y en cada uno de ellos 2 servidores de sincronización de tiempos (NTP01 y NTP02) con 8 fuentes externas; 3 de un proveedor (en tres continentes diferenciados) y 5 de otro (en 5 continentes diferenciados)

El resto de los controladores de dominio de la organización, sincronizan la hora con estos dos servidores, en orden inverso; primero el 02 y segundo el 01. Inicialmente el controlador de dominio con el ROL de PDC es el que marca la hora para el resto de maquinas de la infraestructura.

El script se divide en las siguientes partes;

Definimos las variables del mensaje de correo electrónico

image

Comprobamos que los ficheros que tenemos de control y si existe el fichero que utilizamos para almacenar el contenido de la comprobación lo borramos. Aprovechamos para crear el fichero correspondiente a la comprobación.

image

A continuación cargamos la variable para realizar las comprobaciones de tiempo sobre las maquinas indicadas.

image

Ejecutamos el comando de comprobación de tiempos para cada servidor, cargamos el ficheros de datos inicial y parseamos el contenido al fichero final de reporte.

image

Una vez que completamos el contenido de los ficheros con la comprobación, evaluamos si cualquiera de ellos tenga un  delay superior o inferior a  10s con un offset superior a 250.

image

Si esto valores se superan o son iguales a los valores de la comprobación, enviamos el mensaje de correo electrónico. En este punto, también podemos ampliar el script con la ejecución del comando de sincronización horaria en aquellos servidores que sufren este desfase. Inicialmente, en esta primera versión del script, el scope solo es la comprobación de la correcta sincronización de los mismos.

image

Este script, almacena un reporte cada vez que es ejecutado en la ruta indicada. El formato de mi estructura para este y otros script es:

image

Así controlamos la sincronización de nuestros servidores. Como siempre, estoy abierto a cualquier tipo de comentarios o mejoras que se puedan implementar en el script, para mejorar el control de la sincronización de tiempos en los servidores.

Configuration Magament (Proceso)

Las principales actividades de la Gestión de Configuraciones son:

Planificación: determinar los objetivos y estrategias de la Gestión de Configuraciones.

Clasificación y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura predefinidos.

Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual.

Realización de auditorías: para asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.

Elaboración de informes: para evaluar el rendimiento de la Gestión de Configuraciones y aportar información de vital importancia a otras áreas de la infraestructura TI.


Planificación

La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus interrelaciones e interdependencias con el resto de procesos. Por ello su implantación es particularmente compleja.

Aunque ofrecer un detallado plan de implementación de la Gestión de Configuraciones va mucho más allá de lo que aquí podemos ofrecer, creemos conveniente, al menos, destacar algunos puntos que consideramos esenciales:

  • Designar un responsable: una descentralización excesiva puede generar descoordinación y llevar al traste todo el proceso.
  • Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organización manual es impracticable.
  • Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks, activos, etc.
  • Establecer claramente:
    • El alcance y objetivos.
    • El nivel de detalle
    • El proceso de implementación: orden de importancia, cronograma, …
  • Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Versiones y los Departamentos de Compras y Suministros

Una falta de planificación conducirá con total certeza a una Gestión de Configuraciones defectuosa con las graves consecuencias que esto supondrá para el resto de los procesos.


Clasificación y Registro

La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible, para llevar esta labor con éxito, predeterminar la estructura del CMDB de manera que:

  • Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la organización y resultar, a la larga, en una dejación de responsabilidades.
  • La información sea suficiente: debe existir, al menos un registro de todos los sistemas críticos para la infraestructura TI.
Alcance

En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en la CMDB:

  • Es esencial incluir al menos todos los sistemas de hardware y software implicados en los servicios críticos.
  • Se debe determinar que CIs deben incluirse dependiendo del estado de su ciclo de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados.
  • Es recomendable incorporar, al menos, la documentación asociada a proyectos, SLAs y licencias.

En general cualquier servicio o proceso es susceptible de ser incluido en la CMDB pero unos objetivos en exceso ambiciosos pueden resultar contraproducentes.

Nivel de detalle y Profundidad

Una vez determinado el alcance de la CMDB es imprescindible establecer el nivel de detalle y profundidad deseados:

  • Determinar los atributos que describen a un determinado CI.
  • Tipo de relaciones lógicas y físicas registradas entre los diferentes CIs.
  • Subcomponentes registrados independientemente.

Por ejemplo, si se decide incluir los equipos de sobremesa en la CMDB:

  • Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc.
  • Relaciones: conexión en red, impresoras conectadas, etc.
  • Profundidad: tarjetas de red, discos duros, tarjetas gráficas, etc.
Nomenclatura

Aunque este sea un aspecto muy técnico es de vital importancia predefinir los códigos de clasificación de los CIs para que el sistema sea funcional:

  • La identificación debe ser, por supuesto, única y si es posible interpretable por los usuarios.
  • Este código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir físicamente unido al mismo (mediante una etiqueta de difícil eliminación).
  • Los códigos no deben ser sólo utilizados para componentes de hardware sino también para documentación y software.

Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede ser de gran utilidad, por ejemplo, a la Gestión de Disponibilidad para conocer que CIs han sido responsables de la degradación de la calidad del servicio.

Puede ser de gran utilidad para el análisis el uso de herramientas de software que ofrezcan representaciones visuales del ciclo de vida de las componentes, organizados por diferentes filtros (tipo, fabricante, responsable, costes, etc.).


Control

La Gestión de Configuraciones debe estar puntualmente informada de todos los cambios y adquisiciones de componentes para mantener actualizada la CMDB.

El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estar correctamente registrado todo el software “en producción”.

Las tareas de control deben centrarse en:

  • Asegurar que todos los componentes están registrados en la CMDB.
  • Monitorizar el estado de todos los componentes.
  • Actualizar las interrelaciones entre los CIs.
  • Informar sobre el estado de las licencias.

Auditorías

El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.

Existen herramientas que permiten una gestión remota, centralizada y automática de los elementos de configuración de hardware y software. La información recopilada puede ser utilizada para actualizar la CMDB.

Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesario complementar estos datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y al menos:

  • Tras la implementación de una nueva CMDB.
  • Antes y después de cambios mayores en la infraestructura.
  • Si existen fundadas sospechas de que la información almacenada en la CMDB es incorrecta o incompleta.

Las auditorías deben dedicar especial atención a aspectos tales como:

  • Uso correcto de la nomenclatura en los registros de los CIs.
  • Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, …
  • Estado de los CIs actualizado.
  • Cumplimiento de los niveles de alcance y detalle predeterminados.
  • Adecuación de la estructura de la CMDB con la de la estructura TI real.

Configuration Management (Definición)

A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos de configuración (CI) y base de datos de gestión de configuraciones (CMDB) es por lo tanto conveniente que nos detengamos en dar una definición precisa de ambos.

Elementos de configuración: todos, tanto los componentes de los servicios TI como los servicios que éstos nos ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo citaremos:

  • Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus componentes: tarjetas de red, teclados, lectores de CDs, …
  • Software: sistemas operativos, aplicaciones, protocolos de red, …
  • Documentación: manuales, acuerdos de niveles de servicio, …

En resumen, todos los componentes que han de ser gestionados por la organización TI.

Base de Datos de la Gestión de Configuraciones: esta base de datos debe incluir:

  • Información detallada de cada elemento de configuración.
  • Interrelaciones entre los diferentes elemento de configuración, como, por ejemplo, relaciones “padre-hijo” o interdependencias tanto lógicas como físicas

La CMDB no se limita a una mera enumeración del stock de piezas sino que nos brinda una imagen global de la infraestructura TI de la organización

Operation Management (Objetivos)

Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad, eficiente y continuo e independiente de su localización geográfica.

Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que están recibiendo una atención personalizada y ágil que les ayude a:

  • Resolver rápidamente las interrupciones del servicio.
  • Emitir peticiones de servicio.
  • Informarse sobre el cumplimiento de los SLAs.
  • Recibir información comercial en primera instancia.

El punto de contacto con el cliente puede tomar diversas formas dependiendo de la amplitud y profundidad de los servicios ofrecidos:

  • Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.
  • Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio.
  • Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización con un enfoque centrado en los procesos de negocio. Aparte de ofrecer los servicios citados anteriormente ofrece servicios adicionales a clientes, usuarios y la propia organización TI tales como:
    • Supervisión de los contratos de mantenimiento y niveles de servicio.
    • Canalización de las Peticiones de Servicio de los clientes.
    • Gestión de las licencias de software.
    • Centralización de todos los procesos asociados a la Gestión TI.

Los principales beneficios de una correcta implementación del Centro de Servicios se resumen en:

  • Reducción de costes mediante una eficiente asignación de recursos.
  • Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo.
  • Apertura de nuevas oportunidades de negocio.
  • Centralización de procesos que mejoran la gestión de la información y la comunicación.
  • Soporte al servicio proactivo.

Esta gestión no deja de ser el correcto proceso de la gestión de incidencias / cambios / peticiones.

Escalate incident process

Make a decision to escalate incident