• No se han encontrado resultados

Herramientas para la distribución

3. Sun Microsystems

3.5. Desarrollo y puesta en marcha de la plataforma

3.5.2. Herramientas para la distribución

El departamento de operaciones de TI de Sun Microsystems utiliza un procedimiento denominado SoftDist para la distribución del software una vez hecha la puesta en marcha del mismo. El objetivo de este proceso consiste en garantizar que los servidores centrales de cada una de las zonas geográficas tienen disponible la última versión del software que se quiere hacer llegar a los empleados.

Antes de detallar los pasos necesarios para la distribución del soft- ware, es importante tener en cuenta los siguientes conceptos: • Submitter: persona de Sun Microsystems responsable de preparar

los paquetes que se van a distribuir.

• Paquete: aplicación software que puede utilizar cualquier em- pleado de Sun dentro del entorno de la empresa.

Requisitos previos a la distribución del software

• Identificación. Todos los paquetes que se van a instalar necesitan estar asignados a un empleado de Sun antes de llevar a cabo la distribución. Este empleado suele ser el responsable del departa- mento de operaciones de la zona geográfica. La información que se necesita es la siguiente:

– Nombre del individuo o grupo dentro de un departamento. – Identificación y provisión de los recursos necesarios para respon-

der a cualquier problema que pueda surgir relacionado con la aplicación, independientemente de que las preguntas estén rela- cionadas con la fecha del final de vida del producto, soporte, errores y mantenimiento.

ANOTACIONES

– Identificación del punto de contacto para cualquier tema relacio-

nado con el soporte del producto.

• Aprobación. Todos los paquetes que se vayan a instalar deben es- tar aprobados por el responsable del departamento de operacio- nes dentro de la zona geográfica correspondiente, de manera que se garantice la funcionalidad de la aplicación y la coordinación de la compatibilidad con otros productos, bases de datos y demás aplicaciones que sean relevantes para los objetivos de negocio. El responsable de operaciones debe ser una persona que conozca a la perfección los objetivos de la compañía, el riesgo de un fallo en la puesta en marcha del producto y los requisitos del producto, de manera que pueda determinar el número de recursos del depar- tamento que debe utilizar para garantizar el éxito de la distribución.

Requisitos para la distribución del producto

• Uso de la herramienta preptool. Esta herramienta, utilizada únicamente de forma interna dentro de Sun Microsystems, permi- te juntar y organizar los datos necesarios para preparar un pa- quete antes de su distribución. Todos los datos relevantes deben ser introducidos para garantizar la operabilidad del paquete den- tro del entorno de la empresa.

• Control de exportaciones. Debido a que Sun Microsystems es una compañía norteamericana con delegaciones en diferentes países, es necesario garantizar que el producto cumple con las normas de exportación/importación vigentes dentro de cada país. Estas normas están descritas en el departamento de control de expor- taciones de Sun (Sun International Trade Services).

La jerarquía de distribución SoftDist, así como la topología de red, permite distribuir paquetes de software a todas las oficinas de Sun repartidas por el mundo, incluso en aquellos países con los cuales Estados Unidos tiene limitaciones debido a los acuerdos guberna- mentales.

Los productos que se desarrollan dentro de un centro de I+D de Sun Microsystems ubicado en otro país que no sea Estados Unidos

ANOTACIONES

deben cumplir igualmente con las normas del departamento de control de exportaciones.

• Contacto con el centro de soporte del producto. El responsable del departamento de operaciones debe contactar con el respon- sable de centro de soporte como parte de los preparativos del pa- quete antes de ser distribuido. De esta manera se definen los mecanismos de soporte del producto así como los recursos y el punto de contacto de soporte.

Verificación de la funcionalidad de los paquetes durante

la distribución

• Test funcional. El responsable de operaciones debe garantizar que los paquetes que se van a instalar no afectan a la productividad o a la fun- cionalidad de otras aplicaciones y que no comprometen la operativa de negocio desde el punto de vista de rendimiento de los sistemas. Los paquetes que se van a distribuir deben funcionar correcta- mente en los dos sistemas operativos soportados por Sun: Solaris y GNU/Linux.

Como ya se ha mencionado previamente, es necesario validar los paquetes en un entorno simulado antes de su distribución a nivel mundial. La definición de los criterios que determinan si el paquete es apto para ser distribuido o no es responsabilidad del propietario del paquete, que, en la mayoría de los casos, será el responsable de desarrollo del producto o el responsable de operaciones TI. • Gestión de los fallos de aplicación. El departamento de operacio-

nes TI de Sun, y en su nombre el responsable de dicho departa- mento, debe ofrecer un período de garantía a los usuarios de la red mundial y responder ante cualquier problema que pueda sur- gir durante ese período a partir del momento de distribución del paquete. Las situaciones de riesgo se tratan de manera distinta que el procedimiento estándar.

Si no se ha identificado un bug (error) en la aplicación a distribuir y aparece durante la primera semana después de haber hecho la distribución, es el propio departamento de operaciones quien asu- me los gastos que puedan derivarse a partir de este momento. Lo

ANOTACIONES

mismo ocurre cuando el paquete que se ha distribuido impacta

severamente en el rendimiento de los sistemas de Sun, causando retrasos que afectan al curso normal de trabajo o impidiendo que los usuarios puedan, desde su puesto de trabajo, abrir otras apli- caciones. Los criterios para determinar si la distribución de un pa- quete se ha hecho correctamente o no son los siguientes:

– Los usuarios deben poder lanzar la aplicación desde su puesto de trabajo sin la intervención de un administrador.

– La aplicación no puede acceder a zonas en las que el usuario que la está lanzando no tiene permisos.

Una vez que se ha hecho la distribución del software, el responsa- ble del departamento de operaciones IT de cada zona geográfica debe obtener métricas de sus resultados. Para este fin, debe auditar las instalaciones e informar de los casos que no han tenido éxito detallando los motivos y el plan de actuación que se llevará a cabo.

La revisión de las instalaciones se realiza cada trimestre y el grupo de soporte debe cubrir las incidencias que se detecten a partir de la primera semana de instalación.

Otras de las métricas que debe tener en cuenta el departamento de operaciones de Sun es el DPMO (deficiencias por millón de opor-

ANOTACIONES

tunidades), que pretende reflejar el resultado final de las distribu- ciones de software llevadas a cabo cada trimestre.

Ya se ha comentado que el grupo de operaciones TI es el responsable del correcto funcionamiento de las aplicaciones (tanto de software li- bre como propietarias) dentro de Sun. Sin embargo, cualquier proble- ma detectado en los paquetes distribuidos, tanto de diseño como de desarrollo, es responsabilidad del grupo de desarrollo del producto. Los errores detectados podrían corregirse en la fase de mantenimiento del producto, sin embargo, en muchas ocasiones, un error dentro de un paquete puede impactar directamente en el rendimiento de los sis- temas y por tanto en el trabajo del día a día dentro de la empresa. Para evitar estos problemas, existe un procedimiento estándar que permite asignar mayor prioridad a la revisión de código del JDS, de manera que los ingenieros encargados del mantenimiento del produc- to puedan solucionarlo lo antes posible.

La detección de un error dentro de un paquete o una aplicación suele ser notificado al departamento de operaciones que debe abrir la vía de comunicación con el equipo de soporte del producto. Para tal fin, Sun pone a disposición de los usuarios una herramienta de notifica- ción de errores en la que se detalla información sobre el tipo de error, en qué parte de la aplicación se produce, etc.