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, se revisa por pares y se implementa para todos los servicios. 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 su equipo tiene el ancho de banda y la experiencia, 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.

Tenga en cuenta las cuotas de AWS servicio
Hay cuotas en la cantidad de virtuales CPUs (vCPUs) que puede aprovisionar para las instancias de Amazon Elastic Compute Cloud (Amazon EC2). Al implementar una EC2 instancia, se requiere una cantidad determinada de vCPUs, según el tipo de EC2 instancia. Cada AWS cuenta tiene un límite flexible en cuanto al número de v CPUs que se le pueden aprovisionar. A medida que se implementan las EC2 instancias, el límite flexible aumenta automáticamente entre 100 y 150 v. CPUs Sin embargo, si intenta implementar varias (por ejemplo, 20) EC2 instancias al mismo tiempo, podría superar el límite flexible. Si cree que podría encontrarse con esta limitación, envíe una solicitud para aumentar la cuota antes de implementar EC2 las instancias. Esto evitará que alcance los límites de las cuotas de servicio a mitad de la implementación.
Desarrolle una estrategia de rotación clave para la seguridad
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 AWS servicios y en diversas aplicaciones. Para las implementaciones de SAP, las AWS KMS claves se utilizan para cifrar los datos en reposo que se almacenan en los volúmenes de Amazon Elastic Block Store (Amazon EBS) y se utilizan para los binarios de SAP y los sistemas de archivos SAP HANA. Las claves KMS también se utilizan para los datos que se almacenan en los depósitos de Amazon Simple Storage Service (Amazon S3) para almacenar los medios de software y las copias de seguridad, y en los sistemas de archivos Amazon Elastic File System (Amazon EFS) para y. /usr/sap/trans
/sapmnt
AWS KMS le ofrece la flexibilidad de utilizar claves administradas o claves AWS administradas 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 en las políticas de seguridad que se produzcan a mitad del proyecto, como el paso de claves gestionadas por el cliente a claves AWS gestionadas, pueden requerir una reconstrucción completa de los entornos de SAP, lo que 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 AWS administradas, se encontraría con un problema con Amazon EBS, 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 su proyecto utiliza soluciones de administración de claves externas, como Vormetric, e importa el material clave, asegúrese de que las personas encargadas de la toma de decisiones en AWS KMS materia de seguridad estén al tanto de las diferencias de rotación de claves entre las claves de KMS externas y las AWS KMS claves (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 las claves AWS administradas AWS KMS, el material clave cambia pero el ARN clave permanece igual, 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 AWS KMS claves en la AWS KMS documentación.
Otro enfoque de seguridad consiste en utilizar la rotación AWS Secrets Manager de contraseñas de bases de datos y sistemas operativos, que está disponible a través de un panel de control estándar. Además, asegúrese de que las funciones AWS Identity and Access Management (de IAM) del entorno de recuperación ante desastres estén aisladas del entorno de producción para ayudar a proteger los entornos contra las actividades maliciosas.
Elimine los servidores no utilizados
Le recomendamos que retire los servidores de prueba de concepto (PoC) inmediatamente después de que hayan agotado 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 Amazon Machine Image (AMI) de la EC2 instancia. 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. Asegúrese de configurar un proceso desde el principio para enseñar a los miembros del equipo de SAP Basis a desmantelar estos servidores, ya que los cargos se acumularán rápidamente.