Prácticas recomendadas para la fase de creación - AWSGuí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 construcción más fluida para su proyecto. La fase de creación abarca las actividades de código, desarrollo, implementación e implementación. Suele consistir en una sesión de revisión y aprobación del diseño, una reunión inicial para alinear lo que se está creando, el cronograma y los criterios de salida. Esta es la fase en la que se escribe el código, se revisa por pares y se implementa para todos losAWS servicios.

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

Organice reuniones de pie diarias

Asegúrese de organizar reuniones de pie diarias, independientemente de la metodología de proyecto que utilice. Si bien los monólogos diarios están asociados a metodologías ágiles, también son mecanismos de conexión de equipo extremadamente útiles para otras metodologías, incluido el modelo en cascada. Incluso puedes usar un marco de proyecto híbrido que tome las mejores prácticas de varias metodologías.

Consideraciones:

  • Usa algo liviano como las tablas de Jira para crear historias para cada tarea. Estas tablas te servirán de guía para tus monólogos diarios. 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 desean la sobrecarga administrativa que supone gestionar tableros de scrum complejos, por lo que recomendamos una herramienta ligera. Tener una junta también te permite generar informes sobre el trabajo que realiza tu equipo y te brinda mecanismos para controlar el alcance.

  • En un proyecto SAP totalmente nuevo, no es raro que se agreguen muchas aplicaciones SAP o de límites después de bloquear el ámbito. Si no cuenta con un buen mecanismo para controlar, priorizar y dar visibilidad al alcance del proyecto, será difícil solicitar recursos adicionales o volver a priorizar el trabajo para mantener el proyecto en marcha.

Utilice una hoja de especificaciones de construcción unificada

Utilice una única hoja de cálculo de especificaciones de construcción para todos los entornos y paisajes. Esto crea un único documento que se puede localizar y buscar fácilmente. Le recomendamos que habilite 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 SAP y, al disponer de una única especificación, el equipo de nube interno puede hacerse cargo rápidamente y ver todos los metadatos en un solo lugar una vez finalizado el proyecto.

A continuación, se muestra un ejemplo de plantilla que se utiliza para capturar metadatos de compilación de servidores clave con un requisito de servidor de ejemplo.


        Especificación de compilación para capturar metadatos de servidores para un proyecto de SAP onAWS greenfield

Tenga en cuenta las cuotas deAWS servicio

Existen cuotas en cuanto a la cantidad de vCPUs (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 vCPUs, según el tipo de instancia de EC2. CadaAWS cuenta tiene un límite limitado en la cantidad de vCPUs que se pueden aprovisionar para ella. A medida que implementa las instancias de EC2, el límite flexible aumenta automáticamente entre 100 y 150 vCPUs. Sin embargo, si intenta implementar varias (por ejemplo, 20) instancias de EC2 al mismo tiempo, podría superar el límite flexible. Si cree que puede encontrar esta limitación, envíe una solicitud para aumentar la cuota antes de implementar las instancias de EC2. Esto le permitirá evitar alcanzar los límites de cuota de servicio durante la implementación.

Desarrolle una estrategia de rotación clave

AWS Key Management Service(AWS KMS) facilita a los clientes la creación y gestión de claves criptográficas y el control de su uso en una amplia gama deAWS servicios y en diversas aplicaciones. Para las implementaciones de SAP,AWS KMS las 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 cubos de Amazon Simple Storage Service (Amazon S3) para almacenar soportes 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 KMSle brinda la flexibilidad de usar clavesAWS administradas o claves administradas por el cliente. Le recomendamos que documente y comparta 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 producen en la mitad del proyecto, como el cambio de claves gestionadas por el cliente a clavesAWS gestionadas, pueden requerir reconstrucciones completas de los entornos de SAP, lo que podría afectar a los plazos del proyecto.

Logre la aceptación de todas las partes interesadas en materia de seguridad en lo que respecta al uso y la rotación de las claves. Tenga en cuenta sus políticas de rotación de claves existentes para los entornos locales o en la nube y modifique estas políticas para usarlas enAWS. Si tiene dificultades para lograr un consenso sobre su estrategia de administración de claves, capacite a los responsables de la toma de decisiones para ayudarlos a entender las consideraciones de base de seguridad y establecimiento de niveles. Es crucial tomar decisiones clave de rotación antes de construir los entornos. Por ejemplo, si cambiara de claves gestionadas por el cliente a clavesAWS gestionadas, tendría un problema con Amazon EBS, que no permite cambiar las claves de cifrado en línea. Los volúmenes de EBS deben reconstruirse con nuevas claves. Esto requiere reconstruir sus instancias de SAP, lo que 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 a ellasAWS KMS, asegúrese de que los responsables de la toma de decisiones de seguridad conozcan las diferencias de rotación de claves entre las claves KMS externas yAWS KMS las claves (rotación automática). Al utilizar y rotar una clave de KMS externa de acuerdo con su política de seguridad, no solo cambia el material 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 gestionadas por el cliente o las clavesAWS gestionadasAWS KMS, el material clave cambia, pero el ARN de la 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 AWS KMSteclas, consulte Teclas giratorias en laAWS KMS documentación.

Eliminar los servidores que no se utilizan

Le recomendamos que desmantele los servidores de prueba de concepto (POC) inmediatamente después de que se agote su utilidad. Ejecutar servidores que no están en uso puede resultar costoso. Es importante realizar un seguimiento de todos los servidores que cree para su implementación de SAP totalmente nueva y detener y desmantelar los servidores que no esté utilizando activamente durante la fase de creación. Antes de desmantelar un servidor, puede realizar una copia de seguridad de Amazon Machine Image (AMI) de la instancia de EC2. A continuación, puede restaurar la copia de seguridad si necesita poner en marcha exactamente el mismo servidor en el future.

El desmantelamiento de servidores no debe ser un ejercicio que se guarde para el final del proyecto de implementación. Debe supervisar el uso, detener y, finalmente, destruir los servidores no utilizados durante la vida útil del proyecto y después de completar la implementación, en las fases de mantenimiento u operaciones.