Bonnes pratiques pour l'étape de génération

Les recommandations de cette section aident à garantir une phase de génération plus fluide pour votre projet. La phase de génération englobe les activités de codage, de développement, de déploiement et d'implémentation. Il s'agit souvent d'une session d'examen et d'approbation de la conception, d'une réunion de lancement pour s'aligner sur ce qui est en cours de génération, d'un calendrier et de critères de sortie. Il s'agit de la phase au cours de laquelle le code est écrit, révisé par des pairs et déployé pour tous les AWS services.

Les recommandations suivantes concernent également les activités de test ou de vérification.

Organisez des réunions de présentation quotidiennes

Assurez-vous d'organiser des réunions de présentation quotidiennes, quelle que soit la méthodologie de projet que vous utilisez. Bien que les présentations quotidiennes soient associées aux méthodologies agiles, elles constituent également des mécanismes de connexion d'équipe extrêmement utiles pour d'autres méthodologies, notamment le modèle en cascade. Vous pouvez même utiliser un cadre de projet hybride qui utilise les bonnes pratiques issues de diverses méthodologies.

Considérations :

• Utilisez quelque chose de léger, comme les tableaux Jira, pour créer des histoires adaptées à chaque tâche. Ces tableaux vous serviront de guide pour vos présentations quotidiennes. Si votre équipe dispose de la bande passante et de l'expertise nécessaires, vous pouvez également utiliser la méthodologie Scaled Agile Framework (SAFe) et créer des épopées. Cependant, la plupart des équipes d'infrastructure ne souhaitent pas avoir à supporter les frais administratifs liés à la gestion de tableaux Scrum complexes. Nous recommandons donc un outil léger. Le fait de disposer d'un tableau vous permet également de générer des rapports sur le travail effectué par votre équipe et vous donne des mécanismes pour contrôler la portée.

• Dans un projet inédit SAP, il n'est pas rare que de nombreuses applications SAP ou limitrophes soient ajoutées une fois la portée verrouillée. Si vous ne disposez pas d'un bon mécanisme pour contrôler, prioriser et donner de la visibilité à la portée du projet, il sera difficile de demander des ressources supplémentaires ou de redéfinir les priorités du travail afin de maintenir le projet sur la bonne voie.

Utilisez une feuille de calcul des spécifications de génération

Utilisez une seule feuille de calcul des spécifications de génération pour tous les environnements et paysages. Cela crée un document unique qui peut être facilement localisé et recherché. Nous vous recommandons d'activer l'option de gestion des versions afin de vous remettre facilement d'un incident. Concevez un format en collaboration avec l'équipe SAP Basis. L'équipe Basis assure le suivi des détails autour des systèmes SAP, et le fait de disposer d'une spécification unique permet à l'équipe cloud interne de s'approprier rapidement et de consulter toutes les métadonnées en un seul endroit une fois le projet terminé.

Voici un exemple de modèle utilisé pour capturer les métadonnées clés de génération de serveur avec un exemple d'exigence en matière de serveur.

Soyez conscient des quotas AWS de service

Il existe des quotas sur le nombre de machines virtuelles CPUs (vCPUs) que vous pouvez provisionner pour les instances Amazon Elastic Compute Cloud (Amazon EC2). Lorsque vous déployez une EC2 instance, elle nécessite un certain nombre de vCPUs, selon le type d' EC2 instance. Chaque AWS compte est soumis à une limite souple quant au nombre de v CPUs qui peuvent être provisionnés pour celui-ci. Lorsque vous déployez EC2 des instances, la limite souple augmente automatiquement d'environ 100 à 150 v. CPUs Toutefois, si vous essayez de déployer plusieurs EC2 instances (disons 20) en même temps, vous risquez de dépasser la limite souple. Si vous pensez rencontrer cette limite, soumettez une demande d'augmentation du quota avant de déployer EC2 des instances. Cela vous permettra d'éviter d'atteindre les limites de quotas de service en cours de déploiement.

Développez une stratégie de rotation clé pour la sécurité

AWS Key Management Service (AWS KMS) permet aux clients de créer et de gérer facilement des clés cryptographiques et de contrôler leur utilisation dans un large éventail de AWS services et dans diverses applications. Pour les implémentations SAP, les AWS KMS clés sont utilisées pour chiffrer les données au repos qui sont stockées dans les volumes Amazon Elastic Block Store (Amazon EBS) et sont utilisées pour les fichiers binaires SAP et les systèmes de fichiers SAP HANA. Les clés KMS sont également utilisées pour les données stockées dans des compartiments Amazon Simple Storage Service (Amazon S3) destinés à contenir les supports logiciels et les sauvegardes, et dans les systèmes de fichiers Amazon Elastic File System (Amazon EFS) pour et. /usr/sap/trans /sapmnt AWS KMS vous donne la flexibilité d'utiliser des clés AWS gérées ou des clés gérées par le client. Nous vous recommandons de documenter et de partager votre stratégie et vos décisions en matière de gestion des clés de sécurité dès le début de la phase de génération. Les modifications apportées aux politiques de sécurité en cours de projet, telles que le passage de clés gérées par le client à des clés AWS gérées, peuvent nécessiter une refonte complète des environnements SAP, ce qui peut avoir un impact sur le calendrier de votre projet.

Obtenez l'adhésion de toutes les parties prenantes en matière de sécurité en ce qui concerne l'utilisation et la rotation des clés. Tenez compte de vos politiques de rotation des clés existantes pour le cloud ou les environnements sur site et modifiez ces politiques pour les utiliser sur AWS. Si vous éprouvez des difficultés à parvenir à un consensus sur votre stratégie de gestion des clés, proposez une formation aux décideurs afin de les aider à comprendre les points à prendre en compte lors du référencement de sécurité et de l'établissement des niveaux. Il est crucial de prendre des décisions en matière de rotation des clés avant la génération d'environnements. Par exemple, si vous deviez passer de clés gérées par le client à des clés AWS gérées, vous rencontreriez un problème avec Amazon EBS, qui n'autorise pas la modification des clés de chiffrement en ligne. Les volumes EBS doivent être régénérés avec de nouvelles clés. Cela nécessite de régénérer vos instances SAP, ce qui n'est pas un scénario idéal.

De même, si votre projet utilise des solutions de gestion de clés externes, telles que Vormetric, et y importe le contenu clé AWS KMS, assurez-vous que vos décideurs en matière de sécurité sont conscients des différences de rotation des clés entre les clés KMS externes et AWS KMS les clés (rotation automatique). Lorsque vous utilisez et effectuez une rotation d'une clé KMS externe conformément à votre politique de sécurité, non seulement les éléments de clé, mais aussi l'Amazon Resource Name (ARN) de la clé changent, ce qui signifie que les volumes EBS devront être recréés et que l'ensemble du système SAP devra subir une petite migration. En revanche, si vous activez la rotation automatique pour les clés gérées par le client ou les clés AWS gérées en entrée AWS KMS, le contenu clé change mais l'ARN de la clé reste le même, ce qui signifie que les volumes EBS ne sont pas affectés. Pour plus d'informations sur la rotation des touches, voir Rotation AWS KMS des touches dans la AWS KMS documentation.

Une autre approche de sécurité consiste à utiliser la rotation AWS Secrets Manager des mots de passe des bases de données et des systèmes d'exploitation, qui est disponible via un tableau de bord standard. En outre, assurez-vous que les rôles AWS Identity and Access Management (IAM) de l'environnement de reprise après sinistre sont isolés de l'environnement de production afin de protéger les environnements contre les activités malveillantes.

Mettez hors service les serveurs inutilisés

Nous vous recommandons de mettre hors service les serveurs de preuve de concept (PoC) immédiatement après leur épuisement. L'exploitation de serveurs inutilisés peut s'avérer coûteuse. Il est important de suivre tous les serveurs que vous créez pour votre implémentation inédite de SAP, mais aussi d'arrêter et de mettre hors service les serveurs que vous n'utilisez pas activement pendant la phase de génération. Avant de mettre hors service un serveur, vous pouvez effectuer une sauvegarde Amazon Machine Image (AMI) de l' EC2 instance. Vous pouvez ensuite restaurer la sauvegarde si vous devez lancer exactement le même serveur à l'avenir.

La mise hors service des serveurs ne doit pas être un exercice que vous devez réserver pour la fin du projet d'implémentation. Vous devez surveiller l'utilisation, arrêter et éventuellement détruire les serveurs inutilisés pendant toute la durée de vie de votre projet et une fois l'implémentation terminée, pendant les phases de maintenance ou d'exploitation. Assurez-vous de mettre en place un processus dès le début pour apprendre aux membres de l'équipe SAP Basis à mettre hors service ces serveurs, car les frais s'accumuleront rapidement.