miércoles, 17 de marzo de 2010

GESTION DE SERVICIOS : ITIL

ITIL (Information Technology Infraestructure Library) es el marco de procesos de Gestión de Servicios que proporciona un conjunto de mejores prácticas, extraídas de organismos punteros del sector público y privado a nivel internacional, que han sido recogidas por la Oficina Gubernativa de Comercio Británica (OGC, Office of Goverment Comerce).
Este framework (o marco de procesos) es utilizado por cientos de organizaciones en el mundo y ha sido desarrollado reconociendo la dependencia creciente que tienen éstas en la tecnología para alcanzar sus objetivos.

Beneficios
- Maximiza la calidad del servicio apoyando al negocio de una manera fiable.
- Visión clara de la capacidad del departamento de TI.
- Información precisa de qué cambios producrirán más beneficios.
- Mayor adaptabilidad de TI al negocio.
- Maximizar la satisfacción del trabajo mediante una mayor comprensión de las expectativas y capacidades del servicio.
- Aumentar la satisfacción del cliente como proveedores de servicios.
- Minimizar el tiempo de ciclo de cambios y mejorar los resultados de las métricas.
- Toma de decisión en base a indicadores de TI y de negocio.


Modelo ITIL


CASO PRÁCTICO
Todos estos casos prácticos se refieren a una compañía (ficticia) dedicada al catering, "Cater Matters", que ha optado por introducir la metodología ITIL para la gestión de sus servicios.
"Cater Matters" ofrece sus servicios de catering a un amplio abanico de clientes que incluye:

•Servicios de comedor de grandes empresas.
•Servicios de catering para colegios.
•Servicios de catering para eventos (congresos, actos institucionales, ...).
•Servicios de restauración para hoteles.

La logística del servicio es compleja y los niveles de servicio muy exigentes en lo que respecta a la calidad y los plazos de entrega.
Para mejorar sus estándares de servicio "Cater Matters" ha implementado un sofisticado sistema informático que le permite gestionar de una manera más ágil y eficiente sus relaciones con los clientes así como sus procesos de producción y distribución.
La dirección de "Cater Matters", tras un concienzudo análisis de la situación, ha decidido adoptar la metodología ITIL como la base de todos sus procesos y servicios. Entre las decisiones adoptadas consecuentemente caben destacar:

•Creación de un Service Desk o Centro de Servicios que centralice todas las relaciones con los clientes y el resto de la infraestructura TI.
•Organización de sus actividades en torno a los procesos.
•Designación de responsables o gestores para cada uno de los procesos críticos.
•Establecimiento de estrictos protocolos de monitorización de la calidad del servicio


Solución

1. Service Support


1.1 Service Desk
El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre los los usuarios y la Gestión de Servicios TI.
Un Centro de Servicios, en su concepción más moderna, debe funcionar como centro neurálgico de todos los procesos de soporte al servicio:
•Registrando y monitorizando incidentes.
•Aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas.
•Colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de datos correspondientes.
•Gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración con la Gestión de Cambios y Versiones
Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus contactos con usuarios y clientes.

Como paso imprescindible para la implantación de la metodología ITIL en la empresa la dirección de "Cater Matters" ha decidido implantar un Service Desk que centralice todos los contactos con clientes, proveedores y la organización TI.
Para ello se han adoptado las siguientes decisiones:
•Se ha nombrado un gestor responsable del Service Desk.
•Se han definido, tras un cuidadoso análisis de las necesidades de la organización y los usuarios, las funciones principales del mismo:
- Gestionar la primera línea de soporte de la Gestión de Incidentes.
- Supervisar la calidad del servicio ofrecido respecto a los SLAs.
- Ofrecer información de carácter comercial sobre los servicios ofrecidos.
- Realizar encuestas periódicas sobre el grado de satisfacción del cliente.
- Elaboración de informes periódicos con la información recopilada.
•Realizar una pequeña promoción para presentar los nuevos servicios a los clientes existentes y potenciales.
•Habilitar un espacio web para canalizar, en la medida de los posible, la interacción con los usuarios a través de este medio:
- Formularios de consultas y alta de incidentes.
- Consulta remota, mediante los web services asociados, del estado de los incidentes activos, históricos de incidencias y cumplimiento de los SLAs.
- FAQs actualizadas que permitan a los usuarios consultar directamente sobre los servicios prestados, errores conocidos, etc.
•Desarrollar un "Manual de Atención al Cliente" en donde se detalle los diferentes protocolos de interacción con los usuarios dependiendo de la situación en cuestión.
•Elegir una herramienta de software que ayude a registrar y gestionar todo el flujo de información del Service Desk.
•Impartir formación específica:
- Al personal encargado del trato directo con usuarios y clientes sobre la aplicación del "Manual de Atención al Cliente".
- Sobre las herramientas de software utilizadas.
•Creación de un detallado plan de implantación progresiva del Service Desk .


1.2 Gestión de Incidentes
La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible.
La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

El Service Desk de "Cater Matters" ha recibido una llamada del encargado de suministros del comedor de uno de sus clientes.
Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados hace unos días a través de la web ésta aún no se ha recibido y apenas quedan reservas en sus frigoríficos
El operador del Service Desk busca en la base de datos de pedidos y confirma que se realizo el pedido hace varios días pero también observa que éste se ha guardado defectuosamente.
El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando.
El operador toma, basándose en los protocolos establecidos, las siguientes decisiones:
• Evalúa la prioridad: aunque el impacto es bajo, el incidente es urgente pues el cliente necesita rápidamente el suministro.
• Registra los datos del incidente.
• Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un error conocido y cuales son las posibles soluciones temporales
• Propone una solución temporal al cliente: indica una zona reservada de la web desde la que se pueden realizar pedidos "urgentes" vía email.
• Contacta con el departamento de sistemas previendo que el incidente pueda repetirse a lo largo de la mañana.
• Consulta, mediante la aplicación que monitoriza las existencias de almacén, la disponibilidad de los helados solicitados.
• Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitados antes del mediodía.
Por otro lado el departamento de sistemas:
• Realiza una serie de pruebas y comprueba que, de manera general, el sistema funciona correctamente.
• No consigue identificar la causa del incidente.
• Contacta con el Service Desk y propone que se eleve el problema a la Gestión de Problemas pero pre-calificando su prioridad como baja.
El Service Desk recibe la información y determina que:
• Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al cliente una solución temporal satisfactoria no se requiere un escalado superior.
• Registra la solución temporal del incidente junto a la información proporcionada por el departamento de sistemas.
• Da por cerrado el incidente.


1.3 Gestión de Problemas
Las funciones principales de la Gestión de Problemas son:
• Investigar las causas subyacentes a toda alteración, real o potencial, del servicio TI.
• Determinar posibles soluciones a las mismas.
• Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad del servicio.
• Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario.
La Gestión de Problemas puede ser:
Reactiva: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos.
Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que estos ocurran.

El Service Desk de "Cater Matters" ha informado a la Gestión de Problemas sobre una incidencia a la que no se le pudo asociar un error conocido y que causo una interrupción de bajo impacto en el servicio.
La Gestión de Problemas decide analizar el problema utilizando el protocolo establecido, que en este caso sigue el modelo de Kepner y Tregoe:
• Identificación del problema.
• Clasificación del problema.
• Establecimiento de las posibles causas.
• Comprobación de la causa más probable.
• Verificación de la causa verdadera.
Identificación: En nuestro caso el problema es sencillo de definir:
• La aplicación de pedidos online muestra, de forma no previsible, errores en el registro de ciertos pedidos, sin que este error parezca tener correlación con otros componentes de hardware / software.
Clasificación: La clasificación se adaptaría a los siguientes parámetros:
• Identificación: Problemas en el registro de pedidos.
• Origen: Módulo de pedidos online.
• Frecuencia: el problema no es recurrente, es la primera vez que se detecta.
• Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del servicio.
Posibles causas: Entre las causas más probables figuran:
• Errores en la programación del lado cliente de la aplicación.
• Errores en los módulos de registro del servidor web.
• Errores de configuración de la base de datos.
Los analistas deciden que el origen más probable del problema esté en los módulos de registro de la aplicación.
Comprobación de la causa más probable: con la ayuda de la información registrada por la Gestión de Incidentes:
• Se intenta reproducir el problema.
• Se comprueba que el error sólo se reproduce con una determinada marca de helados.
• Se comprueba que dicha marca de helados tiene un apóstrofe en el nombre y que eliminado éste se registra el pedido sin problemas.

Verificación:
• Se crea un entorno de pruebas que reproduce el módulo de interés en el entorno de producción.
• Se introducen las modificaciones necesarias en la programación.
• Se comprueba el correcto registro del pedido.
El problema se ha convertido en un error conocido, es ahora tarea del Control de Errores:
• Elevar una RFC con la solución propuesta.
• Llevar a cabo la revisión post-implementación en el caso de que la Gestión de Cambios considere oportuno implementar la RFC.


1.4 Gestión de Configuraciones
Las cuatro principales funciones de la Gestión de Configuraciones pueden resumirse en:
• Llevar el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel de detalle y gestionar dicha información a través de la Base de Datos de Configuración (CMDB).
• Proporcionar información precisa sobre la configuración TI a todos los diferentes procesos de gestión.
• Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versiones de manera que estas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de los problemas, realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB.
• Monitorizar periódicamente la configuración de los sistemas en el entorno de producción y contrastarla con la almacenada en la CMDB para subsanar discrepancias.

La gestión de Configuraciones, aunque de vital importancia, puede convertirse fácilmente en una "gran devoradora de recursos" si se establecen criterios excesivamente ambiciosos. Por ello la dirección de "Cater Matters" ha decidido, en una primera fase, limitar el alcance de la base de datos de configuraciones a los sistemas considerados críticos:
• Servidores de red local.
• Servidores de Internet.
• Infraestructura informática del Centro de Servicios.
• SLAs
Para simplificar aún más la gestión se ha decido uniformizar las configuraciones en una serie de "configuraciones de referencia" aplicables a los CIs arriba descritos.
Aunque esto ha supuesto una inversión inicial importante se ha considerado que sus ventajas eran obvias:
• Reducción a medio/largo plazo de los costes asociados.
• Mejora y consistencia de los servicios prestados.
• Simplificación de todos los procesos asociados al soporte al servicio: Incidencias, Problemas, Cambios, Versiones, etc.
El haber optado por una serie de configuraciones estándar permite alcanzar un gran nivel de detalle sin necesidad de realizar un esfuerzo desmedido por lo que se han registrado:
• Configuraciones de software:
-Sistemas operativos.
- Aplicaciones instaladas.
- Interdependencias: relaciones padre-hijo, propietarios,...
- Documentación asociada.
• Configuraciones de hardware:
- Servidores y estaciones de trabajo.
- Subcomponentes con sus interrelaciones: relaciones padre-hijo, interdependencias,...
- Documentación y controladores asociados.
• SLAs e informes de seguimiento asociados.
A su vez se han instalado herramientas de gestión que permiten la monitorización remota de todas esas configuraciones y la realización de auditorías periódicas automatizadas.


1.5 Gestión de Cambios
Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente así, es evidente que toda "evolución a mejor" requiere necesariamente de un cambio.
Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: "si algo funciona, no lo toques". Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizados.
Las principales razones para la realización de cambios en la infraestructura TI son:
• Solución de errores conocidos.
• Desarrollo de nuevos servicios.
• Mejora de los servicios existentes.
• Imperativo legal.
El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.

Los clientes y proveedores de "Cater Matters" están utilizando cada vez más los servicios online de la empresa para gestionar tanto los pedidos como la cadena de suministro.
El sistema implantado en la actualidad, aunque cumple básicamente con los objetivos de negocio, no estaba diseñado para soportar un nivel de actividad elevado. Tanto la Gestión de Disponibilidad como la Gestión de la Capacidad han informado de deficiencias en el proceso y de futuros cuellos de botella si se sigue con el ritmo de crecimiento actual.
Por otro lado, la dirección de la empresa ha decidido reforzar su presencia online y ofrecer a sus clientes unos más elevados niveles de servicio para incrementar su cuota de mercado.
Todo ello requiere un cambio sustancial en la estructura de software y hardware de los servicios de Internet y su interconexión con el software de gestión interna de la organización (ERP).
Por todo ello ha sido la propia dirección de la empresa la que ha elevado una RFC a la Gestión de Cambios que tiene por objetivos:
• Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.
• Desarrollar una serie de WebServices que permitan:
- Integrar directamente el sistema de pedidos online en el ERP de la empresa.
- Realizar un seguimiento de todo el proceso de pedido.
- Gestionar remotamente junto a los proveedores toda la cadena de suministro.
• Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.
Tras registrar adecuadamente la RFC:
• Se le otorga el estatus de "aceptado" y se le asigna provisionalmente una prioridad normal y un alto impacto.
• Se convoca una reunión del CAB para la cual se solicita la asistencia de los responsables de e-commerce y programación web.
• Se solicita una evaluación preliminar del proyecto a una consultora externa que supervisó todo el proceso de implementación del sistema actual.
Previamente a la reunión del CAB el Gestor del Cambio elabora, en estrecha colaboración con las Gestiones de la Capacidad, de la Disponibilidad, Financiera y de Niveles de Servicio, así como con la dirección y Gestión de Proyectos:
• Una evaluación inicial de costes y recursos necesarios.
• Una valoración del impacto de los cambios en la infraestructura TI.
• Un cronograma preliminar del proceso.
• Una encuesta para que el Service Desk sondee la opinión de los clientes respecto a los posibles cambios.
Sopesando la documentación aportada y la estrategia de negocio de la organización el CAB aprueba el cambio y:
• Determina el calendario definitivo del cambio.
• Asigna los recursos, internos y externos, necesarios.
• Desarrolla un plan que permita la convivencia temporal de ambos sistemas online para asegurar la continuidad del servicio:
- Duplicación de toda la estructura web: se compraran nuevos servidores para que los antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el "back-out".
- Se desarrollarán aplicaciones de "traducción" que permitan mantener actualizadas las bases de datos antiguas para evitar la perdida de datos en caso de "back-out".
• Informa a la Gestión de Configuraciones sobre todos los CIs afectados por el cambio.
• Solicita la colaboración de la misma consultora que implanto el sistema actual para que realice una auditoria externa de todo el proceso.
• Elabora toda la información necesaria para que la Gestión de Versiones comience todo el proceso de pruebas e implementación.


Tras la implementación del cambio y en colaboración con el "Soporte al Servicio" y la "Provisión del Servicio" la Gestión de Cambios:
• Confirma el éxito del cambio:
- El nuevo sistema dispone de la capacidad suficiente para proporcionar los niveles de servicio y disponibilidad previstos.
- El nuevo sistema funciona sin errores aparentes.
- Los clientes y proveedores han percibido el cambio como una mejora en la prestación de servicios.
- Ha mejorado la productividad.
• Se asegura que todo el cambio ha sido correctamente registrado en la CMDB.
• Evalúa el proceso.
• Da por cerrado el cambio.


1.6 Gestión de Versiones
La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción.
La Gestión de Versiones debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la CMDB de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.
La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se guardan copias de todo el software en producción, y el Depósito de Hardware Definitivo (DHS), donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción.

La Gestión de Cambios ha aprobado un RFC que tiene como principales objetivos:
• Aumentar la capacidad de los servidores de Internet para mejorar su conectividad y capacidad de respuesta.
• Desarrollar una serie de WebServices que permitan:
o Integrar directamente el sistema de pedidos online en el ERP de la empresa.
o Realizar un seguimiento de todo el proceso de pedido.
o Gestionar remotamente junto a los proveedores toda la cadena de suministro.
• Rediseñar el website para mejorar su usabilidad y optimizarlo para su indexación en buscadores.
La Gestión de Versiones es la encargada del proceso de desarrollo, compra, prueba y distribución de las nuevas versiones de hardware y software asociadas. Para ello:
• En colaboración con las Gestiones de Capacidad y Disponibilidad evalúa las necesidades del nuevo hardware y se encarga de su compra y configuración.
• Contacta con sus proveedores habituales de desarrollo web para establecer de forma precisa las especificaciones del nuevo software y establecer un calendario de desarrollo.
• Duplica la estructura web: se compran nuevos servidores para que los antiguos puedan prestar servicio permanentemente y estén dispuestos inmediatamente para el "back-out".
• Se crean scripts de traducción que permitan salvar los nuevos datos en la versión anterior para evitar su perdida en caso de back-out.
• Se establece un calendario de pruebas con usuarios reales para que estos puedan probar y "aprobar" el nuevo servicio.

• Se planifica un despliegue en dos fases:
I. Se implementa toda la estructura web pero los datos no se incorporan directamente en el ERP de la empresa.
II. Se completa el proceso con la integración mediante WebServices de los pedidos web en el ERP.
• Se desarrolla un manual de usuario para la nueva versión y se crea una página FAQs en la web que incluyen las dudas más frecuentes elevadas por los usuarios en la fase de pruebas.
• Se informa a los usuarios sobre la nueva versión y se avisa de posibles y cortas interrupciones del servicio en la fecha de instalación.
• Se procede a la instalación de la nueva versión.
• Se guarda una copia maestra de todo el software en la DSL.
• Se actualiza la CMDB.



2. Service Delivery

2.1 Gestión del Nivel del Servicio
El objetivo último de la Gestión de Niveles de Servicio es poner la tecnología al servicio del cliente.
La tecnología, al menos en lo que respecta a la gestión de servicios TI, no es un fin en sí misma sino un medio para aportar valor a los usuarios y clientes.
La Gestión de Niveles de Servicio debe velar por la calidad de los servicios TI alineando tecnología con procesos de negocio y todo ello a unos costes razonables.
Para cumplir sus objetivos es imprescindible que la Gestión de Niveles de Servicio:
• Conozca las necesidades de sus clientes.
• Defina correctamente los servicios ofrecidos.
• Monitorice la calidad del servicio respecto a los objetivos establecidos en los SLAs.

La dirección de "Cater Matters" ha decidido implementar una Gestión de Niveles de Servicio que adapte a las necesidades de su organización los principios y recomendaciones de ITIL.
Para llevar a cabo esta tarea de la forma más eficiente posible se han determinado una serie de acciones iniciales que se resumen en:
• Designación de un Gestor del proceso.
• Elaboración de un catálogo de servicios.
• Desarrollo de un Plan Integral de Calidad del Servicio.
• Creación de "plantillas" para la creación de SLAs asociados a sus principales servicios.

Gestor de Niveles de Servicio
La dirección ha encargado a uno de sus directivos con más amplia experiencia en la relación con los clientes asumir el puesto de Gestor de Niveles de Servicio.
Su principal función es negociar y acordar, en representación de "Cater Matters", la provisión de servicios con los clientes.
Sus responsabilidades específicas incluyen:
• Elaborar y mantener actualizado un catálogo de los servicios ofrecidos por "Cater Matters".
• Determinar la estructura general de los SLAs, OLAs y UCs.
• Negociar los SLAs, OLAs y UCs con clientes y proveedores
• Supervisar el cumplimiento de los acuerdos de provisión del servicio con clientes y proveedores.
• Mantener informados a la Dirección y la organización TI sobre el rendimiento de todo el proceso.
• Determinar los Planes de Mejora del Servicio que solucionen las deficiencias en la calidad de los servicios prestados y/o adapten estos servicios a las nuevas necesidades de los clientes y a los últimos avances tecnológicos.
• Interactuar con los otros procesos TI para asegurar que todos ellos reciben y aportan la información necesaria para el óptimo funcionamiento de la organización.

Elaboración del Catálogo de Servicios
Se ha decidido estructurar el Catálogo de Servicios en función de los diferentes tipos de clientes que contratan los servicios de "Cater Matters":
• Particulares.
• Pequeñas empresas.
• Grandes corporaciones e instituciones y organismos públicos.
El objetivo del catálogo no es sólo dar a conocer los diferentes servicios sino mostrar claramente al (potencial) cliente cuales son las diferencias entre las diferentes opciones de un mismo "servicio base".
Para ello se elabora un catálogo online que permite comparar las diferentes "versiones" y realizar una estimación preliminar de los costes basándose en las diferentes opciones seleccionadas.
La descripción de cada servicio incluye información adicional sobre:
• Plazos de entrega.
• Disponibilidad del servicio (festivos, horarios nocturnos, etc.).
• Servicios auxiliares.
• WebServices asociados.
• Disposiciones legales aplicables.
• Programas de fidelización.
• Soporte online.


Plan de Calidad del Servicio
Para asegurar la calidad del servicio se desarrolla un SQP que determina:
• La responsabilidad de cada uno de los departamentos en el proceso de provisión del servicio.
• Planes de contingencia en casos de deterioro grave de la calidad del servicio.
• Indicadores clave de rendimiento y satisfacción del cliente.
• Métodos de supervisión y seguimiento en tiempo real de los procesos involucrados en la prestación del servicio, como, por ejemplo, el reparto y la provisión de mercancía.
• Protocolos de interacción del Service Desk con los clientes y usuarios.
• Los niveles de seguridad, disponibilidad, capacidad y redundancia necesarios para asegurar la correcta provisión del servicio en colaboración con los responsables de dichos procesos.


SLAs prototipo
A fin de evitar que la elaboración de los SLAs se convierta en una tarea excesivamente compleja y tediosa se desarrollan plantillas para los diferentes tipos de servicios y clientes.
Cada SLA prototipo incluye:
• Descripción general y no técnica de los servicios acordados.
• Responsables del acuerdo tanto por el lado cliente como proveedor.
• Plazos para la provisión del servicio.
• Duración del acuerdo y condiciones para su renovación y/o rescisión.
• Condiciones de disponibilidad del servicio.
• Soporte y labores de mantenimiento asociadas.
• Tiempos de respuesta.
• Tiempos de recuperación en casos de incidentes.
• Planes de contingencia si son de aplicación.
• Métodos de facturación y cobro.
• Criterios de evaluación de la calidad del servicio.


2.2 Gestión Financiera
Aunque casi todas las empresas y organizaciones utilizan las tecnologías de la información en prácticamente todos sus procesos de negocio es moneda corriente que no exista una conciencia real de los costes que esta tecnología supone.
Esto conlleva serias desventajas:
• Se desperdician recursos tecnológicos.
• No se presupuestan correctamente los gastos asociados.
• Es prácticamente imposible establecer una política consistente de precios.
El principal objetivo de la Gestión Financiera es el de evaluar y controlar los costes asociados a los servicios TI de forma que se ofrezca un servicio de calidad a los clientes con un uso eficiente de los recursos TI necesarios.
Si la organización TI y/o sus clientes no son conscientes de los costes asociados a los servicios no podrán evaluar el retorno a la inversión ni podrán establecer planes consistentes de inversión tecnológica.

La organización TI de "Cater Matters" lleva prestando, desde hace años, servicios esenciales tanto a la propia organización de la empresa como a los clientes externos de sus servicios de catering.
Sin embargo, hasta la fecha, los gastos TI no han sido contabilizados y presupuestados de manera específica y es, con los datos disponibles en la actualidad, imposible conocer el impacto de los servicios TI en los costes de cada uno de los servicios de catering prestados.
La gestión de "Cater Matters" quiere desarrollar una política de fijación de precios de los servicios TI que le permita trasladar sus costes al usuario final del servicio de catering,en la misma medida que ya se hace con los costes de transporte, materias primas, etc.
Para gestionar el proceso se ha nombrado a un senior manager del departamento TI y a un miembro del departamento financiero de la empresa como responsables del mismo.
El plan de trabajo a corto plazo incluye:
• En colaboración con la Gestión de Configuraciones elaborar un listado de todos los CIs que intervienen en la prestación de servicios directos a los clientes.
• Evaluar, prorrateando entre los diferentes servicios si esto fuera necesario, cuales son los costes asociados al uso de los mismos: amortización, mantenimiento, fungibles, etc.
• Evaluar los costes de personal y los costes operativos.
• Estimar los costes de difícil asignación u ocultos asociados a los servicios TI.
• Evaluar los costes indirectos: instalaciones, costes administrativos, etc.
• Establecer estrictos criterios contables para la administración de los costes TI.
• Establecer una política de precios de coste adicional o "coste + margen".
Todas estas actividades buscan determinar con precisión los costes asociados a los servicios TI ya prestados y proponer tarifas que sean trasladas a los clientes, ya sea directamente o incluidas en otras partidas de carácter general.
Pero los objetivos de una Gestión Financiera proactiva van más allá e incluyen una correcta planificación de gastos e inversiones futuras. Para ello y en colaboración con la Gestión de Niveles de Servicio, Gestión de la Capacidad y Gestión de la Disponibilidad se estudian:
• Los requisitos de los clientes y las tendencias de mercado.
• El impacto en los costes de los Planes de Mejora del Servicio (SIP).
• Necesidades futuras y proyecciones de la capacidad TI.
La información recopilada servirá de base para la elaboración de los primeros "presupuestos anuales TI" elaborados por la Gestión Financiera.


2.3 Gestión de la Capacidad
La Gestión de la Capacidad es la encargada de que todos los servicios TI se vean respaldados por una capacidad de proceso y almacenamiento suficiente y correctamente dimensionada.
Sin una correcta Gestión de la Capacidad los recursos no se aprovechan adecuadamente y se realizan inversiones innecesarias que acarrean gastos adicionales de mantenimiento y administración. O aún peor, los recursos son insuficientes con la consecuente degradación de la calidad del servicio.
Entre las responsabilidades de la Gestión de la Capacidad se encuentran:
• Asegurar que se cubren las necesidades de capacidad TI tanto presentes como futuras.
• Controlar el rendimiento de la infraestructura TI.
• Desarrollar planes de capacidad asociados a los niveles de servicio acordados.
• Gestionar y racionalizar la demanda de servicios TI.

Hasta la fecha, la Gestión de las Capacidad de "Cater Matters" había sido reactiva, o en otras palabras el incremento o redistribución de la capacidad se realizaba exclusivamente cuando aparecían los problemas.
Con el incremento de la importancia de los servicios TI, tanto para la organización de "Cater Matters" como para sus clientes, la dirección de la empresa ha decidido implementar las mejores prácticas ITIL para la Gestión de la Capacidad.
Para ello se ha nombrado un Gestor de la Capacidad que tiene como principales responsabilidades:
• Monitorizar el rendimiento de la infraestructura TI prestando especial atención al de los servicios online, especialmente importantes a la hora de prestar un buen servicio a sus clientes.
• Analizar en colaboración con la Gestión de Configuraciones el impacto de los diferentes CIs en la capacidad del sistema.
• Evaluar, en colaboración con la Gestión de Niveles de Servicio, la carga de proceso, almacenamiento y ancho de banda que suponen los SLAs vigentes y previstos.
• Evaluar, en colaboración con la Gestión Financiera, los costes reales de cada servicio.
• Realizar informes periódicos sobre el estado de la tecnología relevante a los servicios ofrecidos.
• Analizar tendencias y estadísticas de uso y carga sobre el sistema.
Los resultados de dicho trabajo deben permitir:
• Elaborar un Plan de Capacidad anual que se revisara trimestralmente frente a datos reales extraídos de la monitorización del sistema y de las previsiones de negocio.
• Poblar la Base de Datos de la Capacidad (CDB) para que contenga toda la información relevante a la capacidad.
• Proponer mejoras del servicio.
Con el objetivo de:
• Minimizar el número e impacto de futuros incidentes que degraden la calidad del servicio.
• Racionalizar el uso de la capacidad de la infraestructura TI.
• Disminuir los costes en infraestructura TI.
• Aumentar la productividad y satisfacción del cliente.


2.4 Gestión de la Continuidad del Servicio
La Gestión de la Continuidad del Servicio se preocupa de impedir que una imprevista y grave interrupción de los servicios TI, debido a desastres naturales u otras fuerzas de causa mayor, tenga consecuencias catastróficas para el negocio.
La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe combinar equilibradamente procedimientos:
• Proactivos: que buscan impedir o minimizar las consecuencias de una grave interrupción del servicio.
• Reactivos: cuyo propósito es reanudar el servicio tan pronto como sea posible (y recomendable) tras el desastre.
La ITSCM requiere una implicación especial de los agentes involucrados pues sus beneficios sólo se perciben a largo plazo, es costosa y carece de rentabilidad directa. Implementar la ITSCM es como contratar un seguro médico: cuesta dinero, parece inútil mientras uno está sano y desearíamos nunca tener que utilizarlo, pero tarde o temprano nos alegramos de haber sido previsores.

La organización TI de "Cater Matters" carece de una Gestión de la Continuidad del Servicio que merezca ese nombre.
La gestión de "Cater Matters" es consciente de la importancia que tienen en la actualidad los servicios TI en toda su cadena de producción y distribución y pretende corregir esa situación.
De entre todos los servicios TI, los asociados a la gestión de existencias, por estar compuestas de productos perecederos, y los servicios online de pedidos son considerados de importancia estratégica por la dirección de la empresa. Por ello se decide que en primera instancia la ITSCM debe garantizar la continuidad de dichos servicios en un plazo nunca superior a las 8 horas mientras que se establecen objetivos menos ambiciosos para otros servicios.
Se asigna a un ejecutivo senior del departamento TI el papel de gestor del proceso y se le encarga coordinar todas las actividades con la Gestión de la Continuidad del Negocio.

La Gestión de la Continuidad del Negocio ha firmado acuerdos de colaboración con otras empresas de catering para suministros de emergencia que cubran los clientes más importantes:
• Servicios de catering de colegios y hospitales.
• Congresos y eventos multitudinarios de todo tipo.
La coordinación en estos casos requiere el desarrollo de módulos especiales que permitan exportar las bases de datos de pedidos a formatos estándar de intercambio de datos para que estos puedan ser procesados por las otras organizaciones.
Por otro lado, se desarrolla una aplicación de gestión de emergencia de las existencias que permite administrar los pedidos a los proveedores y preservar la integridad de las existencias dependiendo de su información de caducidad y del impacto de la interrupción del negocio en las mismas.
Se establece asimismo:
• Un calendario periódico de pruebas de los planes de recuperación.
• Un calendario de cursos de formación sobre los protocolos de actuación en situación de emergencia.
Pero la Gestión de la Continuidad del Servicio no sólo debe aplicar medidas reactivas que mitiguen el impacto de una eventual interrupción del servicio, entre sus obligaciones se encuentran la elaboración de unos planes de prevención que eviten dichas situaciones.
Para evitar interrupciones de sus servicios online la ITSCM:
• Contrata servicios de "housing" con un proveedor que dispone de conexiones con varios operadores al "backbone de Internet" y asegura alimentación eléctrica interrumpida.
• Replica los sistemas críticos en diferentes localizaciones geográficas.
• Supervisa la política de back-ups de los servidores de datos.
• Instala sistemas de protección perimetral.



2.5 Gestión de la Disponibilidad
Nuestras vidas, tanto personales como profesionales, dependen cada vez más de la tecnología. Ésta nos permite acceder a la información y a los servicios a una velocidad que ni siquiera podríamos haber soñado hace unos pocos años.
Nuestro ritmo de vida se acelera y exigimos como clientes una disponibilidad absoluta de nuestros proveedores tecnológicos. Con frecuencia una oferta diferente sólo se encuentra a un par de clics de distancia.
Por otro lado, el rápido desarrollo tecnológico implica una constante renovación de equipos y servicios. Como proveedores nos enfrentamos al reto de evolucionar sin apenas margen para el error pues nuestros sistemas han de encontrarse a disposición del cliente prácticamente 24/7.
La Gestión de la Disponibilidad es responsable de optimizar y monitorizar los servicios TI para que estos funcionen ininterrumpidamente y de manera fiable, cumpliendo los SLAs y todo ello a un coste razonable. La satisfacción del cliente y la rentabilidad de los servicios TI dependen en gran medida de su éxito.

La disponibilidad 12/7 es algo a lo que los clientes de "Cater Matters" otorgan una gran importancia.
Los servicios TI sólo juegan una pequeña, aunque importante, parte en los servicios prestados por la organización a sus clientes y los problemas de disponibilidad suelen proceder de procesos no directamente ligados con la tecnología. Sin embargo, una interrupción de los servicios online pueden presuponer un grave problema dado el alto volumen de pedidos que se reciben por dicho canal, la práctica totalidad, así como su importancia en el apartado de la gestión de stocks de materia prima.
La Gestión de la Disponibilidad, en colaboración con los responsables de otros procesos TI ha sido encargada de elaborar nuevos planes de disponibilidad que tengan en cuenta un rápido crecimiento del negocio que puede implicar una disponibilidad 24/7 para diferentes líneas de negocio.
La elaboración de este nuevo plan requiere:
• La revisión de los UCs en vigor con los proveedores de servicios de Internet.
• Definición de niveles de disponibilidad para los nuevos servicios.
• Diseño para la disponibilidad 24/7 de los servicios TI ofrecidos.
• Nuevos planes de gestión del mantenimiento que ahora requerirán una interrupción real del servicio.
Por otro lado, la gestión de "Cater Matters" ha decidido informar periódicamente a sus clientes sobre los niveles de rendimiento y disponibilidad de los diferentes servicios prestados. Para ello ha encargado a la Gestión de la Disponibilidad que implante los procedimientos necesarios para la medición del:
• Tiempo transcurrido entre incidentes.
• Tiempo de parada del servicio.
• Tiempo de respuesta para cada incidente.
• Retraso en el la entrega del servicio.
Que se complementarán con un módulo de cálculo estadístico y de generación automática de informes sobre el cumplimiento de los niveles de disponibilidad acordados para cada cliente.
De esta forma "Cater Matters" busca entablar una relación de confianza con sus clientes y mantener a la organización TI alerta sobre posibles degradaciones de los niveles de calidad del servicio.
martes, 16 de marzo de 2010

SUBREDES

Definicion de las Porciones de Red y de Host:
Una dirección IPv4 tiene una porción de red y una porción de host. Se hizo referencia a la duración del prefijo como la cantidad de bits en la dirección que conforma la porción de red. El prefijo es una forma de definir la porción de red para que los humanos la pueden leer. La red de datos también debe tener esta porción de red de las direcciones definidas.
Para definir las porciones de red y de host de una dirección, los dispositivos usan un patrón separado de 32 bits llamado máscara de subred. La máscara de subred se expresa con el mismo formato decimal punteado que la dirección IPv4. La máscara de subred se crea al colocar un 1 binario en cada posición de bit que representa la porción de red y un 0 binario en cada posición de bit que representa la porción de host.
El prefijo y la máscara de subred son diferentes formas de representar lo mismo, la porción de red de una dirección.
Como se muestra en la figura, un prefijo /24 se expresa como una máscara de subred como 255.255.255.0 (11111111.11111111.11111111.00000000). Los bits restantes (orden inferior) de la máscara de subred son ceros, que indican la dirección host dentro de la red.
La máscara de subred se configura en un host junto con la dirección IPv4 para definir la porción de red de esa dirección.
172.16.4.1 (/24)
Direccion IP 172 . 16 . 4 . 1
Binario 10101100 . 00010000 . 00000100 . 00000001
Máscara de Subred 255 . 255 . 255 . 0
Binario 11111111 . 11111111 . 11111111 . 00000000


Por ejemplo, veamos el host 172.16.20.35/27:
dirección
172.16.20.35
10101100.00010000.00010100.00100011

máscara de subred

255.255.255.224
11111111.11111111.11111111.11100000

dirección de red
172.16.20.32
10101100.00010000.00010100.00100000

Como los bits de orden superior de las máscaras de subred son números 1 contiguos, existe solamente una cantidad limitada de valores de subred dentro de un octeto. Sólo es necesario ampliar un octeto si la división de red y host entra en dicho octeto. Por lo tanto, se usan patrones de 8 bits limitados en las máscaras de subred.

Estos patrones son:

00000000 = 0
10000000 = 128
11000000 = 192
11100000 = 224
11110000 = 240
11111000 = 248
11111100 = 252
11111110 = 254
11111111 = 255

Si la máscara de subred de un octeto se representa con 255, entonces todos los bits equivalentes de ese octeto de la dirección son bits de red. De igual manera, si la máscara de subred de un octeto está representada por 0, entonces todos los bits equivalentes de ese octeto de la dirección son bits de host. En cada uno de estos casos, no es necesario ampliar este octeto a binario para determinar las porciones de red y host.

El Proceso de Aplicación de AND
Dentro de los dispositivos de redes de datos, se aplica la lógica digital para interpretar las direcciones. Cuando se crea o envía un paquete IPv4, la dirección de red de destino debe obtenerse de la dirección de destino. Esto se hace por medio de una lógica llamada AND.
La lógica AND es la comparación de dos bits que produce los siguientes resultados:

1 AND 1 = 1
1 AND 0 = 0
0 AND 1 = 0
0 AND 0 = 0

Estas propiedades de la aplicación de AND se usan con la máscara de subred para "enmascarar" los bits de host de una dirección IPv4. Se aplica la lógica AND a cada bit de la dirección con el bit de máscara de subred correspondiente.


Motivos para utilizar AND
La aplicación de AND a la dirección host y a la máscara de subred se realiza mediante dispositivos en una red de datos por diversos motivos.
- Los routers usan AND para determinar una ruta aceptable para un paquete entrante. El router verifica la dirección de destino e intenta asociarla con un salto siguiente. Cuando llega un paquete a un router, éste realiza el procedimiento de aplicación de AND en la dirección IP de destino en el paquete entrante y con la máscara de subred de las rutas posibles. De esta forma, se obtiene una dirección de red que se compara con la ruta de la tabla de enrutamiento de la cual se usó la máscara de subred.
- Un host de origen debe determinar si un paquete debe ser directamente enviado a un host en la red local o si debe ser dirigido al gateway. Para tomar esta determinación, un host primero debe conocer su propia dirección de red.
Un host obtiene su dirección de red al aplicar la lógica AND a la dirección con la máscara de subred. La lógica AND también es llevada a cabo por un host de origen entre la dirección de destino del paquete y la máscara de subred de este host. Esto produce la dirección de red de destino. Si esta dirección de red coincide con la dirección de red del host local, el paquete es directamente enviado al host de destino. Si las dos direcciones de red no coinciden, el paquete es enviado al gateway.

Ejemplo:
Utilización de la máscara de subred para determinar la dirección de red para el hos aplicando la lógica ANDt:
IP:     172.16.132.70/20
MK:  255.255.240.0



Subnetting:
  • Es un segmento físico de una red separado del resto de la red mediante uno o varios enrutadores
  • Consiste en dividir una red en partes más pequeñas. 
  • Permite reducir la congestión de la red mediante la segmentación del tráfico y la reducción del número de difusiones enviadas a cada segmento
Cuando se trabaja con una red pequeña, con pocos host conectados, el adminitrador de red puede fácilmente configurar el rango de direcciones IP usado para conseguir un funcionamiento óptimo del sistema. Pero conforme la red va creciendo se hace necesaria una división en partes de la misma.
En primer lugar, porque conforme se va extendiendo la red va aumentando de forma pareja el dominio de colisión, llegando un momento en el que el rendimiento de la red se ve afectado seriamente. Esto se puede mitigar segmentando la red, dividiendo la misma en una serie de segmentos significativos, de tal forma que mediante switches podremos limitar estos dominios de colisión, enviando las tramas tan sólo al segmento en el que se encuentra el host destino.
En segundo lugar, y aunque segmentemos la red, conforme aumenta el número de host aumenta también el número de transmisiones de broadcast (cuando un equipo origen envía datos a todos los dispositivos de la red), llegando un momento que dicho tráfico puede congestionar toda la red de forma inaceptable, al consumir un ancho de banda excesivo. Esto es así porque todos los host están enviando de forma constante peticiones de este tipo: peticiones ARP, envíos RIP, peticiones DNS, etc.
Para solventar este hecho es preciso dividir la red primaria en una serie de subredes, de tal forma que cada una de ellas va a funcionar luego, a nivel de envío y recepción de paquetes, como una red individual, aunque todas pertenezcan a la misma red principal (y por lo tanto, al mismo dominio). De esta forma, aunque la red en su conjunto tendrá una dirección IP única, administrativamente, a nivel administrativo podremos considerar subredes bien diferenciadas, consiguiendo con ello un control del tráfico de la red y una limitación de las peticiones de broadcast que la atraviesan.

Máscaras de Subred Predeterminadas

Clases de Dirección
Bits Usados para la Máscara de Subred Notación Decimal con Puntos
Clase A 11111111 00000000 00000000 00000000 255.0.0.0
Clase B 11111111 11111111 00000000 00000000 255.255.0.0
Clase C 11111111 11111111 11111111 00000000 255.255.255.0

Ejemplo con Clase B:
Dirección IP 131.107..16.200
Máscara de Subred 255.255.0.0
ID de Red 131.107.y.z
ID de Host w.x.16.200

Consideraciones para crear un Subred
  1. Determine el número de segmentos físicos de la red.
  2. Determine el número de direcciones de host necesarias para cada segmento físico. Cada interfaz del segmento físico requiere al meno un dirección IP.
  3. En función de los requisitos determinados en los pasos 1 y 2, defina lo siguiente.
    - Una máscara de subred para toda la red.
    - Un identificador de subred exclusivo para cada segmento físico.
    - Un intervalo de identificadores de host para cada subred.
Números IP de las Máscaras de Subred
Números IP de la máscara se utilizan para dividir las direcciones de Internet en bloques denominados subredes.
La primera dirección de un bloque de subred (todos los 0s) es la dirección de red o el identificador de red. La última dirección (todos 1s) es la dirección de difusión de la red. Normalmente la dirección de red +1 o la dirección de difusión -1 es la puerta de acceso a Internet. La 'barra' anotación (es decir, / 24) es conocido como formato CIDR mientras que las notaciones más convencionales 255.255.255.0 se considera una máscara de subred.
El prefijo de red de la dirección CIDR indica cuántas direcciones IPv4 hay disponibles para los hosts de su red. Tenga en cuenta que estas direcciones de host se asignan a las interfaces de un host. Si un host tiene más de una interfaz física, debe asignar una dirección de host para cada interfaz física que se utilice.

Formato CIDR Máscara de Subred Total de Direcciones Direcciones de Host Disponibles
/8 255.0.0.0 16777216 16777214
/9 255.128.0.0 8388608 8388606
/10
255.192.0.0
41943044194302
/11255.224.0.0
20971522097150
/12255.240.0.0
10485761048574
/13255.248.0.0
524288524286
/14255.252.0.0
262144262142
/15255.254.0.0
131072131070
/16255.255.0.0
6553665534
/17255.255.128.0
32768
32766
/18255.255.192.0
16384
16382
/19255.255.224.0
8192
8190
/20255.255.240.0
4096
4094
/21255.255.248.0
2048
2046
/22255.255.252.0
1024
1022
/23255.255.254.0
512
510
/24255.255.255.0
256
254
/25255.255.255.128
128
126
/26255.255.255.19264
62
/27255.255.255.22432
30
/28255.255.255.24016
14
/29255.255.255.2488
6
/30255.255.255.2524
2


Explicación - Subneteo:
Supongamos que tenemos una direccion IP de clase C:192.168.100.x

Mascara = /24 
Dirección IP Máscara de Subred Formato CIDR Binario # de SubRedes Host Válidos
192.168.100.x 255.255.255.0 /24 11111111 11111111 11111111 00000000 1 254

# de SubRedes

El número de Subredes se calcula teniendo en cuenta el número de 1s(unos) del último octeto de bits que identifican la máscara de subred. 
Fórmula:  2^m (2 elevado a la m)
m= número de 1s ( unos )
Calculando  # de SubRedes: 2^0=1



# de Host Válidos
El número de host válidos se calcula teniendo en cuenta el número de 0s(ceros) del último octeto de bits que identifican la máscara de subred. 
Fórmula:  ((2^n) -2).
n= número de 0s ( ceros )
Calculando # de Host Válidos: ((2^8)-2)=254



Rango de Direcciones:
  • 192.168.100.0  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.1 - 192.168.100.254 (Rango de Direcciones Válidos)
  • 192.168.100.255: Dirección de Broadcast (Dirección NO utilizable)
___________________________________________________________________________________



Mascara = /25
Dirección IP Máscara de Subred Formato CIDR Binario # de SubRedes Host Válidos
192.168.100.x 255.255.255.128 /25 11111111 11111111 11111111 10000000 2

126

# de SubRedes

Calculando  # de SubRedes: 2^1=2


# de Host Válidos
Calculando # de Host Válidos: ((2^7)-2)=126


Rango de Direcciones:
Primera Subred:
  • 192.168.100.0  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.1 - 192.168.100.126 (Rango de Direcciones Válidos)
  • 192.168.100.127 Dirección de Broadcast (Dirección NO utilizable)

 Segunda Subred:
  • 192.168.100.128  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.129 - 192.168.100.254 (Rango de Direcciones Válidos)
  • 192.168.100.255 Dirección de Broadcast (Dirección NO utilizable)

___________________________________________________________________________________

Mascara = /26
Dirección IP Máscara de Subred Formato CIDR Binario # de SubRedes Host Válidos
192.168.100.x 255.255.255.192 /26 11111111 11111111 11111111 11000000 4

62

# de SubRedes

Calculando  # de SubRedes: 2^2=4


# de Host Válidos
Calculando # de Host Válidos: ((2^6)-2)=62


Rango de Direcciones:
Primera Subred:
  • 192.168.100.0  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.1 - 192.168.100.62 (Rango de Direcciones Válidos)
  • 192.168.100.63 Dirección de Broadcast (Dirección NO utilizable)

 Segunda Subred:
  • 192.168.100.64  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.65 - 192.168.100.126 (Rango de Direcciones Válidos)
  • 192.168.100.127 Dirección de Broadcast (Dirección NO utilizable)

Tercera Subred:
  • 192.168.100.128  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.129 - 192.168.100.190 (Rango de Direcciones Válidos)
  • 192.168.100.191 Dirección de Broadcast (Dirección NO utilizable)

 Cuarta Subred:
  • 192.168.100.192  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.193 - 192.168.100.254 (Rango de Direcciones Válidos)
  • 192.168.100.255 Dirección de Broadcast (Dirección NO utilizable)
___________________________________________________________________________________

Mascara = /27
Dirección IP Máscara de Subred Formato CIDR Binario # de SubRedes Host Válidos
192.168.100.x 255.255.255.224 /27 11111111 11111111 11111111 11100000 8

30


# de SubRedes

Calculando  # de SubRedes: 2^3=8


# de Host Válidos
Calculando # de Host Válidos: ((2^5)-2)=30


Rango de Direcciones:
Primera Subred:
  • 192.168.100.0  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.1 - 192.168.100.30 (Rango de Direcciones Válidos)
  • 192.168.100.31  Dirección de Broadcast (Dirección NO utilizable)

 Segunda Subred:
  • 192.168.100.32  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.33 - 192.168.100.62 (Rango de Direcciones Válidos)
  • 192.168.100.63  Dirección de Broadcast (Dirección NO utilizable)

Tercera Subred:
  • 192.168.100.64  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.65 - 192.168.100.94 (Rango de Direcciones Válidos)
  • 192.168.100.95 Dirección de Broadcast (Dirección NO utilizable)

 Cuarta Subred:
  • 192.168.100.96  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.97 - 192.168.100.126 (Rango de Direcciones Válidos)
  • 192.168.100.127 Dirección de Broadcast (Dirección NO utilizable)

Quinta Subred:
  • 192.168.100.128  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.129 - 192.168.100.158 (Rango de Direcciones Válidos)
  • 192.168.100.159 Dirección de Broadcast (Dirección NO utilizable)

 Sexta Subred:
  • 192.168.100.160  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.161 - 192.168.100.190 (Rango de Direcciones Válidos)
  • 192.168.100.191 Dirección de Broadcast (Dirección NO utilizable)

Séptima Subred:
  • 192.168.100.192  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.193 - 192.168.100.222 (Rango de Direcciones Válidos)
  • 192.168.100.223 Dirección de Broadcast (Dirección NO utilizable)

 Octava Subred:
  • 192.168.100.224  : Dirección de Red (Dirección NO utilizable)
  • 192.168.100.225 - 192.168.100.254 (Rango de Direcciones Válidos)
  • 192.168.100.255 Dirección de Broadcast (Dirección NO utilizable)

Copyright © 2014 Trujillo - Perú