Prácticas recomendadas para la fase de creación - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas para la fase de creación

Las recomendaciones de esta sección ayudan a garantizar una fase de creación más fluida para los proyectos. La fase de creación abarca las actividades de código, desarrollo e implementación. Suele consistir en una sesión de revisión y aprobación del diseño y una reunión inicial para alinear lo que se crea, el cronograma y los criterios de salida. Esta es la fase en la que el código se escribe, los colegas lo revisan y se implementa para todos los servicios de AWS.

Las siguientes recomendaciones también abarcan las actividades de prueba o verificación.

Organice reuniones breves diarias

Asegúrese de organizar reuniones breves todos los días, independientemente de la metodología de proyecto que utilice. Si bien las reuniones breves se asocian a metodologías ágiles, también son mecanismos de conexión de equipos extremadamente útiles para otras metodologías, como el modelo en cascada. Incluso puede utilizar un marco de proyecto híbrido que tome las prácticas recomendadas de varias metodologías.

Consideraciones:

  • Utilice algo ligero, como los tableros de Jira, para crear historias para cada tarea. Estos tableros servirán de guía para las reuniones breves diarias. Si el equipo cuenta con el ancho de banda y la experiencia necesarios, también puede utilizar la metodología Scaled Agile Framework (SAFe) y crear epopeyas. Sin embargo, la mayoría de los equipos de infraestructura no quieren la sobrecarga administrativa que supone administrar tableros de scrum complejos, por lo que recomendamos una herramienta ligera. Contar con un tablero también permite generar informes sobre el trabajo que realiza el equipo y proporciona mecanismos para controlar el alcance.

  • En un proyecto de implementaciones desde cero de SAP, no es raro que se agreguen muchas aplicaciones de SAP o aplicaciones límite una vez que se bloqueó el alcance. Si no se cuenta con un buen mecanismo para controlar, priorizar y dar visibilidad al alcance del proyecto, será difícil solicitar recursos adicionales o cambiar las prioridades del trabajo para mantener el proyecto en marcha.

Utilice una hoja de especificaciones de creación unificada

Utilice una sola hoja de especificaciones de creación para todos los entornos y panoramas. Esto crea un único documento que se puede localizar y buscar fácilmente. Recomendamos habilitar la administración de versiones para recuperarse fácilmente de los contratiempos. Cree un formato en colaboración con el equipo de SAP Basis. El equipo de Basis realiza un seguimiento de los detalles de los sistemas de SAP, y disponer de una única especificación garantiza que el equipo interno de la nube pueda hacerse cargo de todos los metadatos con rapidez y pueda verlos en un solo lugar una vez finalizado el proyecto.

Este es un ejemplo de una plantilla utilizada para capturar los metadatos clave de la creación de un servidor con un ejemplo de requisito de servidor.


        Cree una especificación para capturar los metadatos del servidor para un proyecto de implementación desde cero de SAP en AWS

Tenga en cuenta las cuotas de servicio de AWS

Existen cuotas en el número de CPU virtuales (vCPU) que puede aprovisionar para instancias de Amazon Elastic Compute Cloud (Amazon EC2). Cuando se implementa una instancia de EC2, se requiere una cantidad determinada de vCPU, según el tipo de instancia de EC2. Cada cuenta de AWS tiene un límite flexible en la cantidad de vCPU que se pueden aprovisionar. A medida que se implementan las instancias de EC2, el límite flexible aumenta automáticamente entre 100 y 150 vCPU. Sin embargo, si intenta implementar varias (por ejemplo, 20) instancias de EC2 al mismo tiempo, es posible que supere el límite flexible. Si cree que podría tener este problema, envíe una solicitud para aumentar la cuota antes de implementar instancias de EC2. Esto evitará que alcance los límites de las cuotas de servicio a mitad de la implementación.

Desarrolle una estrategia de rotación de claves

AWS Key Management Service (AWS KMS) facilita a los clientes la creación y administración de claves criptográficas y el control de su uso en una amplia gama de servicios de AWS y en diversas aplicaciones. Para las implementaciones de SAP, las claves de AWS KMS se utilizan para cifrar los datos en reposo que se almacenan en los volúmenes de Amazon Elastic Block Store (Amazon EBS) y también para los binarios de SAP y los sistemas de archivos SAP HANA. Las claves de KMS también se utilizan para los datos que se almacenan en los buckets de Amazon Simple Storage Service (Amazon S3) para conservar medios de software y copias de seguridad, y en los sistemas de archivos de Amazon Elastic File System (Amazon EFS) para /usr/sap/trans y /sapmnt. AWS KMS ofrece la flexibilidad de utilizar cualquiera de las dos claves administradas por AWS o por el cliente. Recomendamos registrar y compartir su estrategia y decisiones de administración de claves de seguridad al comienzo de la fase de creación. Los cambios de la política de seguridad a mitad del proyecto, como pasar de las claves administradas por el cliente a las claves administradas por AWS, pueden requerir que deba volver a crear por completo los entornos SAP, lo cual podría afectar a los plazos del proyecto.

Obtenga la aceptación de todas las partes interesadas en la seguridad en cuanto al uso y la rotación de las claves. Tenga en cuenta las políticas actuales de rotación de claves para los entornos en las instalaciones o en la nube y modifíquelas para utilizarlas en AWS. Si tiene dificultades para llegar a un consenso sobre una estrategia de administración de claves, capacite a los responsables de la toma de decisiones para ayudarlos a comprender las consideraciones básicas y el establecimiento de niveles de seguridad. Es fundamental tomar decisiones sobre la rotación de claves antes de crear los entornos. Por ejemplo, si cambiara de claves administradas por el cliente a claves administradas por AWS, se produciría un problema con Amazon EBS, ya que no permite cambiar las claves de cifrado en línea. Los volúmenes de EBS tienen que volver a crearse con claves nuevas. Esto requiere volver a crear las instancias de SAP, lo cual no es un escenario ideal.

Del mismo modo, si en un proyecto utiliza soluciones de administración de claves externas, como Vormetric, e importa el material clave a AWS KMS, asegúrese de que los responsables de la toma de decisiones en materia de seguridad conozcan las diferencias de rotación de claves entre las claves de KMS externas y las claves de AWS KMS (rotación automática). Cuando utiliza y rota una clave de KMS externa de acuerdo con una política de seguridad, no solo cambia el material de la clave, sino también el nombre de recurso de Amazon (ARN) de la clave, lo que significa que habrá que volver a crear los volúmenes de EBS y todo el sistema SAP tendrá que someterse a una pequeña migración. Por otro lado, si habilita la rotación automática de las claves administradas por el cliente o por AWS en AWS KMS, el material de la clave cambia, pero el ARN de clave sigue siendo el mismo, lo que significa que los volúmenes de EBS no se ven afectados. Para obtener más información sobre la rotación de claves, consulte Rotación de claves de AWS KMS en la documentación de AWS KMS.

Elimine los servidores no utilizados

Se recomienda eliminar los servidores de prueba de concepto (POC) inmediatamente después de que se agote su utilidad. La ejecución de servidores que no están en uso puede resultar costoso. Es importante realizar un seguimiento de todos los servidores que haya creado para una implementación desde cero de SAP y detener y eliminar los servidores que no utilice activamente durante la fase de creación. Antes de retirar un servidor, puede realizar una copia de seguridad de la imagen de máquina de Amazon (AMI) de la instancia de EC2. A continuación, puede restaurar la copia de seguridad si necesita activar exactamente el mismo servidor en el futuro.

No debería dejar la eliminación de los servidores para el final del proyecto de implementación. Debe supervisar el uso, detener y, en última instancia, destruir los servidores no utilizados durante toda la vida útil del proyecto y, una vez finalizada la implementación, durante las fases de mantenimiento u operación.