Bewährte Methoden für die Build-Phase

Die Empfehlungen in diesem Abschnitt tragen dazu bei, eine reibungslosere Erstellungsphase für Ihr Projekt zu gewährleisten. Die Buildphase umfasst Code-, Entwicklungs-, Bereitstellungs- und Implementierungsaktivitäten. Sie besteht häufig aus einer Sitzung zur Überprüfung und Genehmigung des Entwurfs sowie einem Kick-off-Meeting, bei dem festgelegt wird, was gebaut werden soll, der Zeitplan und die Ausgangskriterien. In dieser Phase wird Code geschrieben, von Experten geprüft und für alle Services bereitgestellt. AWS

Die folgenden Empfehlungen beziehen sich auch auf Test- oder Verifizierungsaktivitäten.

Veranstalten Sie tägliche Stand-up-Meetings

Achten Sie darauf, tägliche Stand-up-Meetings abzuhalten, unabhängig davon, welche Projektmethodik Sie verwenden. Obwohl tägliche Stand-Ups mit agilen Methoden in Verbindung gebracht werden, sind sie auch äußerst nützliche Verbindungsmechanismen für Teams bei anderen Methoden, einschließlich des Wasserfallmodells. Sie könnten sogar ein hybrides Projekt-Framework verwenden, das die bewährten Methoden verschiedener Methodiken verwendet.

Überlegungen:

• Verwenden Sie etwas Leichtes wie Jira-Boards, um Storys für jede Aufgabe zu erstellen. Diese Boards werden Ihnen als Leitfaden für Ihre täglichen Stand-ups dienen. Wenn Ihr Team über die nötige Bandbreite und das Fachwissen verfügt, können Sie auch die Scaled Agile Framework (SAFe) -Methode verwenden und Epics erstellen. Die meisten Infrastrukturteams möchten jedoch nicht den administrativen Aufwand für die Verwaltung komplexer Scrum-Boards in Anspruch nehmen, weshalb wir ein einfaches Tool empfehlen. Ein Board ermöglicht es Ihnen auch, Berichte über die Arbeit Ihres Teams zu erstellen, und bietet Ihnen Mechanismen zur Kontrolle des Umfangs.

• Bei einem Greenfield-SAP-Projekt ist es nicht ungewöhnlich, dass viele SAP- oder Grenzanwendungen hinzugefügt werden, nachdem der Geltungsbereich gesperrt ist. Wenn Sie nicht über einen geeigneten Mechanismus zur Kontrolle, Priorisierung und Transparenz des Projektumfangs verfügen, wird es schwierig sein, zusätzliche Ressourcen anzufordern oder Aufgaben neu zu priorisieren, um das Projekt auf Kurs zu halten.

Verwenden Sie ein einheitliches Build-Spezifikationsblatt

Verwenden Sie eine einzige Tabelle mit Build-Spezifikationen für alle Umgebungen und Landschaften. Dadurch wird ein einzelnes Dokument erstellt, das leicht gefunden und durchsucht werden kann. Wir empfehlen, die Versionsverwaltung zu aktivieren, um die Wiederherstellung von Pannen auf einfache Weise zu haben. Überlegen Sie sich in Zusammenarbeit mit dem SAP-Basis-Team ein Format. Das Basis-Team behält den Überblick über die Details rund um die SAP-Systeme, und eine einzige Spezifikation stellt sicher, dass das interne Cloud-Team nach Abschluss des Projekts schnell die Verantwortung übernehmen und alle Metadaten an einem Ort einsehen kann.

Hier ist ein Beispiel für eine Vorlage, die verwendet wird, um wichtige Serverbuild-Metadaten mit einer Beispiel-Serveranforderung zu erfassen.

Beachten Sie die AWS Servicekontingenten

Es gibt Kontingente für die Anzahl der virtuellen CPUs (vCPUs), die Sie für Amazon Elastic Compute Cloud (Amazon EC2) -Instances bereitstellen können. Wenn Sie eine EC2 Instance bereitstellen, ist je nach EC2 Instance-Typ eine bestimmte Anzahl von v CPUs erforderlich. Für jedes AWS Konto gibt es ein weiches Limit für die Anzahl von vCPUs , die für dieses Konto bereitgestellt werden können. Wenn Sie EC2 Instances bereitstellen, erhöht sich das Soft-Limit automatisch um etwa 100-150 v. CPUs Wenn Sie jedoch versuchen, mehrere (z. B. 20) EC2 Instances gleichzeitig bereitzustellen, überschreiten Sie möglicherweise das Soft-Limit. Wenn Sie glauben, dass Sie auf diese Einschränkung stoßen könnten, reichen Sie vor der Bereitstellung von EC2 Instances eine Anfrage zur Erhöhung des Kontingents ein. Auf diese Weise können Sie vermeiden, dass Sie die Limits der Service Quotas während der Bereitstellung erreichen.

Entwickeln Sie eine Strategie für die Schlüsselrotation im Sicherheitsbereich

AWS Key Management Service (AWS KMS) erleichtert es Kunden, kryptografische Schlüssel zu erstellen und zu verwalten und deren Verwendung in einer Vielzahl von AWS Diensten und in verschiedenen Anwendungen zu kontrollieren. Bei SAP-Implementierungen werden AWS KMS Schlüssel verwendet, um ruhende Daten zu verschlüsseln, die auf Amazon Elastic Block Store (Amazon EBS) -Volumes gespeichert und für SAP-Binärdateien und SAP HANA-Dateisysteme verwendet werden. KMS-Schlüssel werden auch für Daten verwendet, die in Amazon Simple Storage Service (Amazon S3) -Buckets zur Aufbewahrung von Softwaremedien und Backups sowie in Amazon Elastic File System (Amazon EFS) -Dateisystemen für /usr/sap/trans und /sapmnt gespeichert sind. AWS KMS bietet Ihnen die Flexibilität, entweder AWS verwaltete Schlüssel oder vom Kunden verwaltete Schlüssel zu verwenden. Wir empfehlen Ihnen, Ihre Strategie und Ihre Entscheidungen zur Verwaltung von Sicherheitsschlüsseln zu Beginn der Erstellungsphase zu dokumentieren und zu teilen. Änderungen der Sicherheitsrichtlinien während des Projekts, wie z. B. die Umstellung von kundenverwalteten Schlüsseln auf AWS verwaltete Schlüssel, können komplette Neuerstellungen der SAP-Umgebungen erforderlich machen, was sich auf Ihre Projektzeitpläne auswirken kann.

Erlangen Sie die Zustimmung aller Sicherheits-Stakeholder in Bezug auf die Verwendung und Rotation von Schlüsseln. Berücksichtigen Sie Ihre bestehenden Richtlinien für die Schlüsselrotation in der Cloud oder in On-Premises-Umgebungen und ändern Sie diese Richtlinien für die Verwendung in AWS. Wenn Sie Schwierigkeiten haben, einen Konsens über Ihre zentrale Managementstrategie zu erzielen, bieten Sie Entscheidungsträgern Trainings an, um ihnen zu helfen, grundlegende Sicherheitsaspekte und Überlegungen zur Festlegung von Sicherheitsstufen zu verstehen. Es ist von entscheidender Bedeutung, wichtige Rotationsentscheidungen zu treffen, bevor Umgebungen erstellt werden. Wenn Sie beispielsweise von kundenverwalteten Schlüsseln zu AWS verwalteten Schlüsseln wechseln würden, würden Sie auf ein Problem mit Amazon EBS stoßen, das Online-Änderungen an Verschlüsselungsschlüsseln nicht zulässt. Die EBS-Volumes müssen mit neuen Schlüsseln neu erstellt werden. Dies erfordert einen Neuaufbau Ihrer SAP-Instances, was kein ideales Szenario ist.

Wenn Ihr Projekt externe Schlüsselverwaltungslösungen wie Vormetric verwendet und das Schlüsselmaterial in diese importiert, stellen Sie ebenfalls sicher AWS KMS, dass Ihre Sicherheitsentscheider die Unterschiede bei der Schlüsselrotation zwischen externen KMS-Schlüsseln und AWS KMS Schlüsseln kennen (automatische Rotation). Wenn Sie einen externen KMS-Schlüssel gemäß Ihrer Sicherheitsrichtlinie verwenden und rotieren, ändert sich nicht nur das Schlüsselmaterial, sondern auch der Amazon-Ressourcenname (ARN) des Schlüssels, was bedeutet, dass EBS-Volumes neu erstellt werden müssen und das gesamte SAP-System einer kleinen Migration unterzogen werden muss. Wenn Sie andererseits die automatische Rotation für vom Kunden verwaltete Schlüssel oder AWS verwaltete Schlüssel aktivieren AWS KMS, ändert sich das Schlüsselmaterial, aber der Schlüssel-ARN bleibt gleich, was bedeutet, dass EBS-Volumes nicht betroffen sind. Weitere Informationen zur Schlüsselrotation finden Sie in der AWS KMS Dokumentation unter Rotieren von AWS KMS Schlüsseln.

Ein weiterer Sicherheitsansatz ist AWS Secrets Manager die Kennwortrotation von Datenbanken und Betriebssystemen, die über ein Standard-Dashboard verfügbar ist. Stellen Sie außerdem sicher, dass die AWS Identity and Access Management (IAM-) Rollen für die Notfallwiederherstellungsumgebung von der Produktionsumgebung isoliert sind, um die Umgebungen vor böswilligen Aktivitäten zu schützen.

Ungenutzte Server außer Betrieb nehmen

Wir empfehlen, Proof of Concept-Server (PoC) sofort außer Betrieb zu nehmen, wenn ihr Nutzen abgelaufen ist. Der Betrieb von Servern, die nicht verwendet werden, kann kostspielig sein. Es ist wichtig, den Überblick über alle Server zu behalten, die Sie für Ihre Greenfield-SAP-Implementierung bauen, und die Server, die Sie während der Erstellungsphase nicht aktiv nutzen, zu stoppen und außer Betrieb zu nehmen. Bevor Sie einen Server außer Betrieb nehmen, können Sie ein Amazon Machine Image (AMI) -Backup der EC2 Instance erstellen. Sie können das Backup dann wiederherstellen, falls Sie in Zukunft genau denselben Server hochfahren müssen.

Die Außerbetriebnahme von Servern sollte keine Aufgabe sein, die Sie sich für das Ende des Implementierungsprojekts aufsparen. Während der gesamten Laufzeit Ihres Projekts und nach Abschluss der Implementierung in der Wartungs- oder Betriebsphase sollten Sie die Nutzung überwachen, ungenutzte Server einstellen und eventuell löschen. Stellen Sie sicher, dass Sie zu Beginn einen Prozess einrichten, um den Mitgliedern des SAP Basis-Teams die Außerbetriebnahme dieser Server beizubringen, da sich die Gebühren schnell anhäufen.