Aislamiento del entorno

Muchas organizaciones construyen sistemas informáticos utilizando un planteamiento multientorno, ya se refieran a estos sistemas como desarrollo, ensayo, preproducción, control de calidad, aceptación o producción, estos términos se utilizan para designar distintos entornos que tienen características diferentes y se utilizan con fines distintos. No existe una definición estándar de los entornos, ni de cómo se utilizan, aparte de un espectro general que va desde los entornos de desarrollo «inferiores» hasta un entorno final de «producción». En todos los casos, la definición y las limitaciones de estos entornos están totalmente definidas por la organización y deben definirse para que se correspondan con otros procesos o normas empresariales y admitan los requisitos empresariales de la organización. Aunque no existe una única práctica recomendada en esta área (ya que los distintos sistemas tienen requisitos diferentes), la siguiente sección ofrece algunas orientaciones sobre cómo plantear los temas de aislamiento del entorno en el proceso de arquitectura.

Los usuarios de los sistemas ArcGIS esperan que el sistema esté disponible cuando necesiten realizar su trabajo. Sin embargo, los cambios significativos en las configuraciones del sistema pueden provocar tiempos de inactividad si estos cambios no se desarrollan y prueban de forma segura en entornos separados de la producción. Aislar los entornos de cómputo es un planteamiento para mantener la fiabilidad y disponibilidad de los sistemas mediante la creación de sistemas separados para las actividades de producción, pruebas y desarrollo. Aunque no todos los cambios (como la configuración de la aplicación) deben probarse en cada entorno, las actualizaciones importantes y las nuevas funcionalidades pueden beneficiarse de un planteamiento estructurado de este tema.

En algunos casos, las expectativas de los usuarios pueden estar documentadas en un Acuerdo de nivel de servicio (SLA), o puede tratarse simplemente de una expectativa sobre cuándo debe estar disponible el sistema. Tenga en cuenta las expectativas de sus usuarios y las necesidades de su empresa a la hora de decidir el nivel de aislamiento del entorno y de gobernanza necesario para administrar los cambios del sistema.

Recomendaciones

Para mantener de la mejor manera posible la fiabilidad y disponibilidad del sistema para sus usuarios, se aplican estas prácticas recomendadas:

1. Si es factible para la organización, implemente entornos aislados de producción, ensayo y desarrollo.
2. Pruebe cambios en el sistema como parches, actualizaciones o cambios en la configuración del sistema operativo en un entorno de ensayo antes de realizar cambios en el entorno de producción.
3. Utilice un entorno de desarrollo para desarrollar y probar nuevas funcionalidades sin afectar a los usuarios de otros entornos.
4. Siga las prácticas de gobernanza estándar cuando promueva contenido y funcionalidades en distintos entornos.
5. Tenga un plan sobre cómo se administra la promoción del contenido: ¿quién lo consulta, quién lo aprueba y cómo se traslada?

Fines medioambientales

A efectos de estas prácticas recomendadas, Esri y nuestros clientes utilizan ampliamente las tres definiciones de entorno que aparecen a continuación.

1. El entorno de producción es el sistema en vivo que da soporte a los usuarios finales. Los requisitos de tiempo de actividad suelen definirse mediante un acuerdo de nivel de servicio y se cumplen a través de una administración y una gobernanza del cambio eficaces. Por lo general, los cambios en el software, las aplicaciones, la configuración o la red no deben introducirse en un sistema de producción sin haberlos probado en un entorno de ensayo. El personal que participa en el entorno de producción es el que suele ver las aplicaciones para tomar decisiones, recopilar y editar información dentro o fuera de la oficina y coordinarse para realizar el trabajo de misión crítica. Este entorno tiene a menudo una mayor monitorización, puede disponer de hardware dedicado para garantizar un buen rendimiento y tendrá el mayor esfuerzo de soporte informático adjunto a su mantenimiento.
2. Un entorno de ensayo suele estar diseñado para ser una réplica representativa del entorno de producción que le permita examinar los cambios del sistema antes de implementarlos en la producción. Se utiliza el término «representativo» porque mantener todo un entorno idéntico al de producción es costoso tanto en recursos como en personal de apoyo. Aunque un entorno de ensayo suele reflejar el de producción en cuanto a niveles, servidores, componentes y roles, es posible que necesite o no la misma capacidad de servidores individuales que el de producción, por lo que puede plantearse una implementación a escala reducida y ahorrar costes. Puede realizar pruebas de aceptación del usuario, pruebas de rendimiento, pruebas de carga y formación en un entorno de ensayo para evitar riesgos para su sistema de producción. Si es necesario, puede incluso implementar varios entornos de ensayo para diferentes actividades de prueba y formación. El personal que participa en un entorno de ensayo es el que suele realizar pruebas de carga, pruebas de rendimiento, pruebas de integración, control de calidad o incluso posiblemente formación.
3. Un sistema de desarrollo es un espacio de trabajo en el que los desarrolladores y analistas pueden crear y administrar contenido o realizar cambios sin afectar a una gran audiencia. Este entorno dedicado suele utilizarse para crear nuevas funcionalidades como aplicaciones, servicios, modelos de datos o modelos de geoprocesamiento, para realizar pruebas unitarias y para diseñar y construir flujos de trabajo empresariales. Las dimensiones y la complejidad del entorno dependerá del nivel de riesgo generado por los cambios, del número de creadores y del posible impacto de interrupciones e inactividad del sistema. Por lo general, solo el personal que trabaja activamente con el contenido en el entorno de desarrollo tiene acceso a este sistema, o no es accesible de forma general dentro de la organización.

Dependiendo de la tolerancia al riesgo de la organización y de las políticas de TI, puede ser necesario separar aún más ciertos tipos de actividades fuera de los constructos de producción, ensayo y desarrollo. Si es necesario, puede implementar varios entornos para diferentes actividades de prueba y formación, como por ejemplo:

• QA\QC
• Pruebas de integración o aceptación
• Pruebas de rendimiento
• Pruebas de carga
• Formación

Beneficios y costes del aislamiento medioambiental

El aislamiento del entorno aísla su entorno de producción de los riesgos conocidos y de los cambios que pueden afectar negativamente a su negocio, como actualizaciones, nuevo software o cambios inesperados, ayudándole a mantener mejor su funcionalidad, estabilidad y rendimiento. Los cambios no intencionados del sistema pueden hacer que los sistemas operativos no ofrezcan las funcionalidades y el rendimiento que esperan los usuarios. La implementación de estos entornos informáticos aislados le ayuda a ofrecer un sistema estable, extensible y de alto rendimiento.

El aislamiento de entornos también tiene costes, tanto en recursos informáticos (mantener varios sistemas en funcionamiento), como en licenciamiento de software y capital humano, ya que un mayor número de entornos necesita una red de apoyo más amplia y más personal implicado en el control de cambios y la implementación. Por lo general, los sistemas más grandes y críticos para el negocio eligen planteamientos de aislamiento del entorno más complejos, pero incluso las organizaciones más pequeñas pueden elegir implementar una versión de este planteamiento para ayudar a aislar los cambios y proteger sus sistemas. Es importante investigar los costes de estas opciones y comunicárselos a las partes interesadas para que se tome una decisión informada en lugar de elegir por defecto tener varios entornos solo porque «siempre lo hemos hecho así».

Implementación del aislamiento del entorno

La gobernanza juega un rol crítico en la correcta implementación del aislamiento del entorno. Es el método por el que se mitigan los riesgos, se optimizan los recursos y se obtienen beneficios empresariales. La gobernanza debe definir qué políticas, procedimientos y técnicas utilizarán los equipos para mantener estos entornos y promover cambios en ellos.

No existe un conjunto único de consideraciones ni una ruta estándar para administrar la amplitud de su software, aplicaciones, servicios y datos en todos los entornos. No obstante, existen algunos recursos que ayudan a implementar entornos de forma coherente, como Chef Cookbooks, Enterprise Cloud Builder, ArcGIS Enterprise Builder y herramientas de replicación de bases de datos y paquetes de activos. Consulte las herramientas de implementación de ArcGIS Enterprise para obtener más detalles. Además, se recomienda evitar la configuración manual para reducir la probabilidad de error humano siempre que sea posible. Considere la posibilidad de utilizar PowerShell DSC for ArcGIS, ArcGIS REST API y ArcGIS API for Python para automatizar algunas de estas tareas. Tenga en cuenta que la creación de estos scripts es una actividad apropiada para un entorno de desarrollo.

Cada elección realizada en el desarrollo conduce inherentemente a algo que alguien necesita saber o saber hacer en el ensayo y en la producción. Emplee buenas prácticas de implementación garantizando la transferencia adecuada de conocimientos y/o habilidades al personal de producción para que puedan operar según lo previsto.

Trabajar con varias implementaciones de ArcGIS Enterprise

Algunas organizaciones utilizan varios entornos ArcGIS Enterprise para separar estos otros niveles. Puede resultar complicado trasladar y administrar el contenido de un entorno a otro de forma coherente y correcta. Sin embargo, existen herramientas que puede utilizar para ayudarle a automatizar estas tareas. Por ejemplo, hay operaciones disponibles con ArcGIS REST API que facilitan el traslado de capas, mapas y aplicaciones cuando se mueven entre entornos, denominadas Exportar contenido de grupo e Importar contenido de grupo.

Por ejemplo, imagine un escenario en el que ha desarrollado una aplicación personalizada de Experience Builder que hace referencia a un mapa web y a un conjunto de capas de entidades dentro de un grupo en su entorno de desarrollo, y ya lo tiene todo para trasladarlo a un sistema de ensayo para una revisión estructurada. Para hacerlo mediante estas operaciones de migración de grupos de exportación/importación, deberá seguir estos pasos:

1. Exporte el contenido del grupo desde el desarrollador a un paquete.
2. Agregue el paquete como elemento en su entorno de ensayo.
3. Importe el contenido del paquete a un grupo del entorno de ensayo.
4. Implemente su aplicación personalizada en su entorno de alojamiento de ensayo y apunte la configuración a las URL del entorno de ensayo.

En este punto, los elementos del paquete pueden ser descubiertos, compartidos, editados y utilizados en el entorno de ensayo, según determine la configuración del grupo de ensayo. El mismo flujo de trabajo puede utilizarse para pasar los elementos a producción cuando estén listos. Este flujo de trabajo también se puede programar mediante scripts utilizando el módulo GroupMigrationManager de ArcGIS API for Python.

Implementaciones azul-verde

La implementación de algunos tipos de cambios, como una actualización del sistema o una modificación importante de la configuración, puede resultar perturbadora. Algunas organizaciones utilizan una estrategia denominada implementación azul-verde para desplegar sin problemas los nuevos cambios para los usuarios. Una implementación azul-verde es una estrategia de implementación en la que se crean dos entornos separados pero idénticos. Un entorno (azul) está ejecutando la versión actual de la aplicación y otro entorno (verde) está ejecutando la nueva versión de la aplicación o el conjunto de configuraciones. El tráfico se dirige a uno u otro entorno utilizando mecanismos estándar como enrutadores, equilibradores de carga, proxies inversos o servidores web.

El azul y el verde se turnan para desempeñar el rol de producción. Solo uno de los entornos está activo en cada momento. Por ejemplo, cuando llegue el momento de actualizar ArcGIS Enterprise, la actualización se realizará primero en el sistema verde. Una vez que el equipo de pruebas está satisfecho de que todo está plenamente operativo y listo para su uso en producción, lo único que cambia es la dirección del tráfico que fluye desde el proxy o equilibrador de carga: a verde en lugar de azul, sin ningún cambio perceptible para los usuarios finales de producción. En este punto, los nuevos contenido y funcionalidades se desarrollarían en azul, hasta que se hayan realizado correctamente las pruebas suficientes para justificar de nuevo el cambio de tráfico.

Mantener dos entornos todo el tiempo puede salir caro.  Afortunadamente, la nube hace más factible la implementación «azul-verde». Todos los principales proveedores de plataformas en la nube disponen de herramientas que nos permiten crear y desmantelar la infraestructura en función de la demanda. Por ejemplo, puede iniciar y detener servidores con la infraestructura como código y automatizar el tiempo de actividad y la configuración del sistema hasta detalles específicos.

Recomendaciones finales

La implementación de estos entornos informáticos aislados le ayuda a ofrecer un sistema estable, extensible y de alto rendimiento. Si aprovecha estos entornos para apoyar una administración eficaz de los cambios, podrá proteger su sistema de fallos inesperados y evitar interrupciones en las operaciones empresariales. Como mínimo, la mayoría de las organizaciones deberían disponer de al menos dos entornos informáticos: el de producción y el de ensayo, ya que es posible que no participen en ninguna actividad de desarrollo personalizada que haga uso de un entorno de desarrollo, o que utilicen principalmente aplicaciones de bajo y ningún código. Sin embargo, puede tener más en función del apetito de riesgo de su organización.

Considere cómo va a implementar y gobernar el aislamiento de entornos (y las actividades aisladas dentro de cada entorno) lo antes posible. Aunque no existe un planteamiento único para todas estas opciones, hay muchas herrmientas y prácticas comunes a las que puede recurrir para orientarse.

Un recurso adicional que se ha publicado recientemente cubre el concepto de promoción de contenido entre entornos, con un ejemplo de planteamiento con script de este tema: Publicación de la Esri Community: Promoción del contenido de ArcGIS Enterprise.