¿Cómo debe ser un entorno de laboratorio FIM?

Esta pregunta siempre suscita un animado debate durante las sesiones de diseño de la FIM, ya que este tema tiene muchos puntos de vista diferentes.

Un proyecto FIM se diferencia significativamente de la mayoría de los proyectos informáticos en que se trata de un proyecto de "infraestructura típica" y un proyecto de "desarrollo típico" fusionados que, además, se integra con un montón de otros sistemas. Esta afirmación tomada al pie de la letra puede no parecer indicar que un laboratorio FIM sería radicalmente diferente al laboratorio de un proyecto típico, hasta que se empieza a pensar en el significado subyacente de lo que se necesita para alcanzar los objetivos de desarrollo y pruebas.

Aunque no existe un enfoque único para crear un buen entorno de laboratorio, he observado que cuanto más se asemeja el entorno de desarrollo al de producción, más éxito tienen el desarrollo y la implantación del FIM. La adhesión de la configuración de laboratorio a la configuración de producción ayuda a reducir el riesgo y conduce hacia una implementación exitosa por las siguientes razones:

• Valida los supuestos de diseño
• Valida las configuraciones de hardware y del servidor
• Aumenta la precisión del esfuerzo de desarrollo
• Aumenta la capacidad de realizar pruebas precisas
• Permite identificar y mitigar los problemas que se encontrarán con los datos de producción antes de la puesta en marcha.
• Puede reducir el número de problemas que pueden surgir al trasladar código y configuraciones de productos de un entorno a otro.
• Cambios de configuración más fáciles de trasladar de desarrollo a producción

Utilizo la siguiente serie de preguntas para guiar el debate e identificar cuáles son los objetivos de alto nivel del laboratorio:

• ¿Cuál es el perfil de riesgo (nivel de tolerancia) de la organización?
• ¿Cuál es el objetivo del laboratorio?
  • Desarrollo único
  • Desarrollo continuo tras el despliegue inicial
  • Pruebas de integración previas a la producción (por ejemplo, hotfixes, service packs, cambios de configuración, configuración del equilibrador de carga, etc.)
  • Pruebas de rendimiento previas a la producción

• ¿Qué sistemas hay que añadir al laboratorio?
  • Todos los sistemas a los que debe conectarse el FIM deben formar parte del laboratorio.
  • ¿Podemos hacer una copia de los datos de producción para utilizarlos en el laboratorio? (Exportación de físico a virtual (P2V) o de máquina virtual)

• ¿Qué tipo de información gestionará FIM en el diseño? (Por ejemplo, tipos de objetos: usuarios de AD, grupos de AD, contactos de AD, registros de RRHH, usuarios de Sun, etc.).

• ¿De qué equipo se dispone para montar el entorno de desarrollo?
  • ¿Qué plataforma de virtualización utiliza la organización?
  • ¿Pueden aislarse todas las fuentes de datos en el laboratorio? (Por ejemplo, algunos sistemas no pueden añadirse al laboratorio, como los sistemas de gama media o mainframe) ¿Puede configurarse un servidor TMG para permitir el tráfico desde un laboratorio aislado a un sistema de producción?

• ¿Qué tipo de pruebas quiere hacer?
  • Pruebas unitarias
  • Pruebas de integración
  • Pruebas del sistema
  • Pruebas de rendimiento
  • Pruebas de aceptación

• ¿Qué componentes del diseño quiere desarrollar y probar antes de la producción?
  • Hay una serie de pruebas diferentes que deben tenerse en cuenta como parte del proyecto. A continuación se indican algunas de las áreas de pruebas que deben tenerse en cuenta:

• ¿Qué conocimientos son necesarios para configurar y mantener el entorno?
  • Conocimientos de administración interna
  • ¿Se están introduciendo nuevas tecnologías como clustering o SCSM?

Buenas prácticas en torno a un laboratorio FIM:

Una vez comprendidos los objetivos que debe cumplir el laboratorio, es importante revisar y aplicar las siguientes buenas prácticas al diseño del laboratorio:

1. Reúna todos los requisitos antes de construir el laboratorio

• Los cambios en los requisitos del laboratorio después de su construcción pueden requerir una reconstrucción completa del mismo.

2. Los sistemas de laboratorio deben estar separados de los sistemas de producción

• Los errores de desarrollo pueden provocar problemas de producción
• La capacidad de probar los cambios en la configuración antes de la implantación en producción es limitada.

3. Si no hay suficiente hardware para construir un laboratorio adecuado, considere el uso de tecnologías de virtualización como Hyper-V

• Se necesita menos hardware
• Mayor facilidad para crear copias de seguridad de configuraciones puntuales y volver a configuraciones anteriores.

4. El entorno de laboratorio debe tener una representación de cada sistema al que se conectará el FIM

• Una representación de cada sistema que gestionará la FIM
  • Los sistemas deben ser de la misma plataforma
    • Identificar el nivel de versión del sistema operativo (hotfixes, service packs) y de los productos instalados.
    • Los sistemas deben tener la misma versión y el mismo nivel de parches.
    • El esquema de cada sistema debe reflejar el sistema de producción (por ejemplo, el esquema de la base de datos SQL, el esquema de AD, etc.).
    • Mantener la configuración de los sistemas existentes (por ejemplo, configuraciones de confianza de Windows, configuración de DNS , configuración de sitios AD, etc.).

• En un bosque multidominio, Active Directory debe tener el mismo número/ubicación de partición(es) de directorio que la producción.

• Todos los sistemas para los que FIM puede aprovisionar objetos deben existir en el laboratorio. Algunos ejemplos de sistemas adicionales que FIM puede gestionar son:
  • Intercambio
  • LYNC
  • Inicio Servidores de directorio

5. Además de los sistemas que gestionará la FIM, también se necesitan servicios de infraestructura adicionales para soportar una red funcional. Los siguientes servicios también deben ser considerados para su colocación en el laboratorio:

• DNS
• Sistema de reserva
• Autoridad de certificación
• Sistema de correo electrónico para actividades de notificación de flujos de trabajo
• Repositorio de código (por ejemplo, Team Foundation Server)
• DHCP
• Software Despliegue (SCCM)
• Cortafuegos (TMG/UAG) - para la publicación de aplicaciones

6. En función de la solución diseñada y de los requisitos de las pruebas, también deben tenerse en cuenta los siguientes sistemas para completar la información:

• Hardware equilibrador de carga
• UAG/TMG/cortafuegos
• Dispositivos cliente (IPADs/IPhones/Smart Phones)
• Posibilidad de conectarse a un servidor de correo electrónico externo para OTP
• Posibilidad de conectarse a la pasarela de SMS para OTP
• Autenticación de dos factores (RSA/tarjetas inteligentes)

7. Todos los sistemas operativos cliente que deben probarse antes del despliegue del cliente FIM.

• Sistemas operativos compatibles
  • OS
  • Versión (x86 o x64)
  • Niveles de paquetes de servicios
  • Versiones y niveles de parches de Microsoft Office
• Varias versiones de los sistemas operativos compatibles

8. Representación de datos - Cuando construyo un laboratorio IDM, me gusta exportar los datos de producción e importarlos a mi entorno de laboratorio para poder ver todos los cambios que se producirán en los datos existentes.

• Los datos deben ser actuales y pertinentes
• Los datos deben existir a partir de una instantánea en un momento dado en todos los sistemas para permitir la alineación de los datos (por ejemplo, el sistema de recursos humanos debe tener registros que puedan compararse con una cuenta AD).
• Los datos deben contener una representación de todos los datos que se importarán/exportarán en cada sistema
  • Diferentes clases de objetos deben estar presentes (por ejemplo, usuarios, grupos, contactos)
  • Los objetos deben colocarse en la misma ubicación que la producción (por ejemplo, en relación con la partición de directorios del entorno)
    • La ubicación de producción OU de los objetos: ou=Company Users, dc=prod, dc=company, dc=com se traduciría a ou=Company Users, dc=dev, dc=company, dc=com en desarrollo
    • Los atributos deben rellenarse con valores de producción (givenName, SN, DisplayName, etc...). Esto permite probar cómo se modificarán los atributos.
• Las cuentas de usuario deben estar habilitadas para buzones de correo con el fin de facilitar los procesos de flujo de trabajo.

9. Calidad de los datos - Una vez construido el laboratorio inicial y poblado con datos, hay una serie de decisiones tomadas en el diseño que requerirán que examine los datos actuales para determinar si los datos actuales son suficientes para cumplir con las decisiones de diseño.

• ¿Cuál será el atributo de enlace entre los distintos sistemas? Deberá existir un atributo de enlace en cada sistema para facilitar el proceso de unión de los objetos de los distintos sistemas (registro HR, cuenta AD) a una identidad FIM (objeto MV).
• Si los datos no están disponibles en un sistema, ¿hay otro u otros sistemas que puedan aportar los datos de atributos que necesito?
• ¿Los datos tienen un formato coherente? Los datos mal formateados pueden dificultar la toma de decisiones lógicas.
• ¿Qué datos de atributos se necesitan para determinar los derechos?
  • ¿Quién puede tener una cuenta?
  • ¿Quién puede tener un buzón?
• ¿Qué datos de atributo se necesitan para las reglas de provisión?
  • ¿Cómo se determina el DN?
  • ¿Cómo se calcula el nombre de la cuenta?
  • ¿Quién recibe un buzón?
  • ¿A qué base de datos están asignados?
  • ¿Estarán aprovisionados para LYNC?
• ¿Qué datos de atributos se necesitan para las transformaciones de atributos?
  • Para las transformaciones de un nombre para mostrar, ¿existen los datos de atributo para construir un nombre para mostrar válido?
• ¿Qué datos de atributos se necesitan para la personalización de aplicaciones?
  • ¿Dónde tiene que existir?
  • ¿En qué formato deben estar los datos?
• ¿Qué datos de atributos se necesitan para crear grupos basados en criterios?
• ¿Qué datos de atributo se necesitan para realizar autorizaciones delegadas?
  • MPR que delegan derechos utilizando una relación con el objeto. (Por ejemplo, un gestor al que se le permite actualizar las cuentas de usuario de sus informes en el Portal FIM, requiere que el atributo de gestor se rellene en cada uno de sus informes).
  • Los MPR que delegan derechos administrativos requerirán que los objetos tengan uno o varios atributos rellenados que permitan a FIM identificarlos en conjuntos. Por ejemplo, los atributos de todos los usuarios de una determinada unidad de negocio y ubicación deberán contener la unidad de negocio y la ubicación del usuario.
  • Las actividades de flujo de trabajo, como los flujos de trabajo de aprobación del propietario, deben tener el atributo de propietario mostrado rellenado con el propietario del grupo.

10. Confidencialidad de los datos

• ¿Hay datos sensibles en alguno de los sistemas que deban protegerse o enmascararse?
  • Nómina
  • SSN
  • Fecha de nacimiento

11. Pruebas

• Como en todos los proyectos de desarrollo, conviene separar el papel del desarrollador del del probador. Los probadores suelen encontrar formas de romper el código que no estaban previstas por el desarrollador.
• Construir un gran laboratorio, aunque importante, es sólo la primera parte del proyecto. Se necesita un plan de pruebas exhaustivo para validar que el diseño implementado hace lo que se quiere.