Vorgang zum Patchen

Die Hauptnutzer der Patching-Lösung sind die Anwendungsentwicklungs- und Betriebsteams. Jede Anwendung wird in der Regel in mehreren Umgebungen bereitgestellt, z. B. in der Entwicklung, im Test (Integration, Benutzerakzeptanz usw.) und in der Produktion. Die Anwendungsteams müssen die Patch-Zeitpläne für jede Umgebung planen. Wenn also ein Patch auf die Produktionsumgebung angewendet wird, wurde er bereits getestet und es wurde festgestellt, dass er keine negativen Auswirkungen auf die Anwendung hat.

Der folgende Workflow bietet ein Beispiel dafür, wie Sie Patch-Fenster für eine Anwendung planen können, die in mehreren Umgebungen bereitgestellt wird, und wie Sie Tags konfigurieren können.

• Schritt 1. Jedes Anwendungsteam plant seine Wartungsfenster für seine Server in verschiedenen Umgebungen und richtet die Tags, die die Patchgruppen und Wartungsfenster der Server repräsentieren, entsprechend ein:

  • Das Tag Patch Group steht für die Server innerhalb einer Anwendungsumgebung, die die Ziele einer bestimmten Patch-Baseline sind. Mithilfe von Patchgruppen kann sichergestellt werden, dass die richtigen Patch-Baselines für die richtige Gruppe von Instanzen bereitgestellt werden. Patchgruppen tragen auch dazu bei, die Bereitstellung von Patches in der Produktionsumgebung zu vermeiden, bevor sie ausreichend getestet wurden.

  • Wenn die Anwendungsserver mehrere Betriebssysteme umfassen, erstellt das Anwendungsteam Patchgruppen auf der Grundlage der Kombination aus Umgebung und Betriebssystem. Eine Patchgruppe kann nur mit einer Patch-Baseline registriert werden, und eine Instanz kann nur Teil einer Patchgruppe sein.

    Zum Beispiel: appname-DEV-WIN und appname-DEV-RHEL

  • Das Tag Maintenance Window steht für den Zeitplan für das Patchen der Server. Alle Server in einer Patchgruppe sollten sich im selben Wartungsfenster befinden. Das Wartungsfenster-Tag sollte einem konsistenten Format für Cron- und Rate-Ausdrücke folgen, damit eine von Ihnen definierte Lambda-Funktion die Ausdrücke einfach analysieren kann. (In diesem Handbuch bezeichnen wir diese Lambda-Funktion alsautomate-patch.)

    Zum Beispiel: schedule-duration-cutoff-timezone

    cron(0 2 ? * SAT#3 *)steht für 02:00 Uhr am dritten Samstag eines jeden Monats. Ausführliche Informationen zu Cron- und Rate-Ausdrücken finden Sie in der Systems Manager Manager-Dokumentation.

• Schritt 2. Systems Manager Patch Manager stellt regelmäßig neue Patches über betriebssystemspezifische Patch-Baselines auf der Grundlage der definierten Konfigurationen zur Verfügung.

  • Für jedes Betriebssystem können Sie eine benutzerdefinierte Patch-Baseline definieren, die die Genehmigungsregeln und die Patches enthält, die auf die Instanzen in der gesamten Cloud-Umgebung angewendet werden müssen.

• Schritt 3. Ihr benutzerdefinierter Automatisierungscode konfiguriert Patch Manager so, dass Patches auf der Grundlage der Tags Patchgruppe und Wartungsfenster eingerichtet werden, und wendet die Patches auf die Entwicklungsumgebung an.

  • Nach Abschluss des Patches testen die Anwendungsentwicklungs- und Support-Teams die Anwendung und stellen sicher, dass alles ordnungsgemäß funktioniert.

  • Wenn bei der Anwendung Probleme mit dem neuen Patch auftreten, bitten die Anwendungsteams das Cloud-Services-Team, das Patchen für andere Patchgruppen und andere Umgebungen einzustellen, indem entweder die Wartungsfenster deaktiviert oder die Ausführung der Patch-Aufgabe aufgehoben wird.

• Schritt 4. Nachdem die Entwicklungsumgebung erfolgreich gepatcht wurde, wird das Patchen in allen anderen Umgebungen bereitgestellt, die nicht zur Produktion gehören. Wie bei der Entwicklungsumgebung wird die Anwendung getestet und überprüft, ob sie in allen Nicht-Produktionsumgebungen ordnungsgemäß funktioniert. Wenn es Probleme gibt, bitten die Anwendungsteams das Cloud-Services-Team, das Patchen für die Produktionsumgebung einzustellen.

• Schritt 5. Nachdem alle Nicht-Produktionsumgebungen erfolgreich gepatcht wurden, wird das Patchen auf die Produktionsumgebung angewendet.