Umgebungsisolation

Viele Organisationen verwenden zum Erstellen von IT-Systemen mehrere Umgebungen. Dabei bezeichnen die Begriffe “Entwicklung”, “Staging”, “Vorproduktion”, “Qualitätssicherung”, “Abnahme” oder “Produktion” unterschiedliche Umgebungen, die jeweils unterschiedliche Merkmale aufweisen und für unterschiedliche Zwecke verwendet werden. Es gibt keine Standarddefinition von Umgebungen oder für ihre Verwendung, außer einer allgemeinen Skala, die von “niederen” Entwicklungsumgebungen bis zur finalen Produktionsumgebung reicht. Die Definition und die Einschränkungen für diese Umgebungen werden immer vollständig von der Organisation festgelegt. Die Definition sollte sicherstellen, dass sie mit anderen Geschäftsprozessen oder Standards übereinstimmt und die Geschäftsanforderungen der Organisation unterstützt. Es gibt in diesem Bereich keine einheitliche Best Practice (da verschiedene Systeme unterschiedliche Anforderungen haben), jedoch bietet der folgende Abschnitt einige Anleitungen für die Umgebungsisolation im Architekturprozess.

Benutzer von ArcGIS-Systemen erwarten, dass das System verfügbar ist, wenn sie es für ihr Arbeit benötigen. Wesentliche Änderungen an Systemkonfigurationen können jedoch zu Ausfallzeiten führen, wenn diese Änderungen nicht sicher in von der Produktion isolierten Umgebungen entwickelt und getestet werden. Die Isolierung von Computing-Umgebungen ermöglicht die Aufrechterhaltung der Zuverlässigkeit und Verfügbarkeit des Systems, indem jeweils einzelne Systeme für Produktions-, Test- und Entwicklungsaktivitäten erstellt werden. Auch wenn nicht alle Änderungen (z. B. die App-Konfiguration) in jeder Umgebung getestet werden müssen, kann eine strukturierte Herangehensweise für wichtige Updates und neue Funktionen von Vorteil sein.

In einigen Fällen können die Erwartungen der Benutzer in einem Service-Level-Agreement (Service Level Agreement, SLA) dokumentiert werden, oder es gibt lediglich einen erwarteten Zeitpunkt für die Verfügbarkeit des Systems. Berücksichtigen Sie die Erwartungen und Geschäftsanforderungen der Benutzer, wenn Sie den Grad der Umgebungsisolation und Governance wählen, die für die Verwaltung von Systemänderungen erforderlich sind.

Empfehlungen

Mit den folgenden Best Practices sollen die Zuverlässigkeit und Verfügbarkeit des Systems für die Benutzer bestmöglich gewährleistet werden:

1. Sofern für die Organisation möglich, implementieren Sie eine jeweils isolierte Produktionsumgebung, Staging-Umgebung und Entwicklungsumgebung.
2. Testen Sie Systemänderungen wie Patches, Upgrades oder Änderungen an den Betriebssystemeinstellungen in einer Staging-Umgebung, bevor Sie Änderungen an der Produktionsumgebung vornehmen.
3. Verwenden Sie eine Entwicklungsumgebung, um neue Funktionen zu entwickeln und zu testen, ohne Benutzer in anderen Umgebungen zu beeinträchtigen.
4. Befolgen Sie standardmäßige Governance-Verfahren, wenn Sie Inhalte und Funktionen von einer Umgebung in eine andere überführen.
5. Erstellen Sie einen Plan für die Überführung von Inhalten: Wer überprüft Inhalte, wer genehmigt sie und wie werden sie migriert?

Zwecke von Umgebungen

Für diese Best-Practice-Empfehlungen verwenden Esri und unsere Kunden häufig die folgenden drei Umgebungsdefinitionen.

1. Die Produktionsumgebung ist das Live-System, das Endbenutzer unterstützt. Die Verfügbarkeitsanforderungen werden in der Regel durch ein SLA definiert und durch effektives Änderungsmanagement und effektive Governance erfüllt. Software-, Anwendungs-, Konfigurations- oder Netzwerkänderungen sollten im Allgemeinen nicht in einem Produktivsystem vorgenommen werden, ohne in einer Staging-Umgebung getestet worden zu sein. In der Regel sind es Mitarbeiter in der Produktionsumgebung, die Apps anzeigen, um Entscheidungen zu treffen, intern oder extern Informationen sammeln und bearbeiten und die Durchführung von unternehmenskritischen Aufgaben koordinieren. In dieser Umgebung erfolgt häufig eine verstärkte Überwachung. Sie verfügt möglicherweise über dedizierte Hardware, um eine hohe Performance zu gewährleisten, und ihre Verwaltung erfordert den höchsten Grad an Unterstützung durch die IT.
2. Eine Staging-Umgebung ist in der Regel eine repräsentative Spiegelung der Produktionsumgebung, in der Sie Systemänderungen überprüfen können, bevor sie in der Produktionsumgebung bereitgestellt werden. Die Staging-Umgebung wird als repräsentativ bezeichnet, weil die Verwaltung einer gesamten Umgebung, die mit der Produktionsumgebung identisch ist, einen hohen Aufwand an Ressourcen und Mitarbeitern erfordert. Eine Staging-Umgebung spiegelt in der Regel die Produktionsumgebung im Hinblick auf die Ebenen, Server, Komponenten und Rollen wider. Jedoch ist möglicherweise nicht die gleiche Kapazität der einzelnen Server wie in der Produktionsumgebung erforderlich. Daher kann eine reduzierte Bereitstellung in Betracht gezogen werden, um Kosten zu sparen. Sie können Benutzerakzeptanztests, Performance-Tests, Auslastungstests und Schulungen in einer Staging-Umgebung durchführen, um Risiken für das Produktivsystem zu vermeiden. Bei Bedarf können Sie sogar mehrere Staging-Umgebungen für unterschiedliche Test- und Schulungsaktivitäten implementieren. In der Regel werden Auslastungstests, Performance-Tests, Integrationstests, QA/QK oder möglicherweise sogar Schulungen von den Mitarbeitern in einer Staging-Umgebung durchgeführt.
3. Ein Entwicklungssystem ist ein Arbeitsbereich, in dem Entwickler und Analysten Inhalte erstellen und verwalten oder Änderungen vornehmen können, ohne dass sich dies auf eine große Zielgruppe auswirkt. Diese dedizierte Umgebung wird in der Regel zum Erstellen neuer Funktionen wie Anwendungen, Services, Datenmodelle oder Geoverarbeitungsmodelle, für Komponententests sowie zum Entwerfen und Erstellen von Geschäftsworkflows verwendet. Die Größe und Komplexität der Umgebung hängt davon ab, wie hoch das Risiko durch die Änderungen ist, wie viele Ersteller es gibt und welche potenziellen Auswirkungen Systemausfälle und Ausfallzeiten haben. In der Regel haben nur Mitarbeiter, die aktiv mit Inhalten in der Entwicklungsumgebung arbeiten, Zugriff auf dieses System, oder in der Organisation kann generell nicht darauf zugegriffen werden.

Abhängig von der Risikotoleranz der Organisation und den IT-Richtlinien kann es erforderlich sein, bestimmte Arten von Aktivitäten außerhalb der Produktions-, Staging- und Entwicklungskonstrukte zu isolieren. Bei Bedarf können Sie mehrere Umgebungen für unterschiedliche Test- und Schulungsaktivitäten implementieren, z. B für die folgenden Aktivitäten:

• QA/QK
• Integrations- oder Akzeptanztests
• Performance-Tests
• Auslastungstests
• Training

Vorteile und Kosten der Umgebungsisolation

Die Umgebungsisolation schützt Ihre Produktionsumgebung vor bekannten Risiken und Änderungen, die sich negativ auf Ihr Unternehmen auswirken können, z. B. Upgrades, neue Software oder unerwartete Änderungen, und unterstützt Sie bei der Aufrechterhaltung der Funktionalität, Stabilität und Performance. Unbeabsichtigte Systemänderungen können dazu führen, dass Betriebssysteme nicht die von den Benutzern erwarteten Funktionen und Performance liefern. Die Implementierung isolierter Computing-Umgebungen hilft Ihnen, ein stabiles, erweiterbares und leistungsstarkes System bereitzustellen.

Die Umgebungsisolation ist auch mit Kosten verbunden, sowohl bei den IT-Ressourcen (Aufrechterhaltung des Betriebs mehrerer Systeme) und der Softwarelizenzierung als auch beim Personal, da eine zunehmende Anzahl von Umgebungen ein größeres Support-Netzwerk und mehr Mitarbeiter für die Änderungskontrolle und Bereitstellung erfordert. Im Allgemeinen sind die Ansätze der Umgebungsisolation umso komplexer, je größer und unternehmenskritischer die Systeme sind. Aber auch kleinere Organisationen können eine Version dieses Ansatzes wählen, um Änderungen zu isolieren und ihre Systeme zu schützen. Es ist wichtig, die Kosten dieser Entscheidungen zu untersuchen und sie den Stakeholdern mitzuteilen, damit eine fundierte Entscheidung getroffen und nicht der Standardansatz für mehrere Umgebungen lediglich aus dem Grund gewählt wird, weil “dies schon immer so gehandhabt wurde”.

Implementieren der Umgebungsisolation

Governance spielt bei der erfolgreichen Implementierung der Umgebungsisolation eine entscheidende Rolle. Durch diese Methode werden Risiken gemindert, Ressourcen optimiert und Geschäftsvorteile erzielt. Governance sollte definieren, welche Richtlinien, Verfahren und Techniken Teams nutzen, um die Umgebungen zu verwalten und Änderungen umgebungsübergreifend durchzuführen.

Es gibt keine allgemeingültigen Überlegungen oder Standardmethoden für die Verwaltung Ihrer vielfältigen Software, Anwendungen, Services und Daten in verschiedenen Umgebungen. Es gibt jedoch einige Ressourcen, die die konsistente Bereitstellung von Umgebungen unterstützen, z. B. Chef Cookbooks, Enterprise Cloud Builder, ArcGIS Enterprise Builder sowie Werkzeuge und Asset-Pakete für die Datenbankreplikation. Weitere Informationen finden Sie unter ArcGIS Enterprise-Bereitstellungswerkzeuge. Darüber hinaus wird empfohlen, eine manuelle Konfiguration zu vermeiden, um die Wahrscheinlichkeit menschlicher Fehler nach Möglichkeit zu verringern. Mit PowerShell DSC for ArcGIS, der ArcGIS REST API und der ArcGIS API for Python können Sie einige dieser Aufgaben automatisieren. Beachten Sie, dass die Erstellung dieser Skripte in einer Entwicklungsumgebung erfolgen sollte.

Jede Entscheidung, die in der Entwicklungsumgebung getroffen wird, führt zwangsläufig zu einem Ergebnis oder einer Aufgabe, das bzw. die jemand in der Staging- oder Produktionsumgebung kennen muss bzw. durchführen kann. Nutzen Sie effektive Bereitstellungsverfahren, indem Sie sicherstellen, dass die Mitarbeiter in der Produktionsumgebung über die entsprechenden Kenntnisse oder Fähigkeiten für die erforderlichen Maßnahmen verfügen.

Arbeiten mit mehreren ArcGIS Enterprise-Bereitstellungen

Einige Organisationen verwenden mehrere ArcGIS Enterprise-Umgebungen, um diese verschiedenen Ebenen zu trennen. Es kann eine Herausforderung sein, Inhalte konsistent und erfolgreich zwischen verschiedenen Umgebungen zu migrieren und zu verwalten. Es gibt jedoch Werkzeuge, mit denen Sie diese Aufgaben automatisieren können. Mit der ArcGIS REST API sind z. B. Vorgänge verfügbar, die das Migrieren von Layern, Karten und Apps zwischen Umgebungen erleichtern. Diese Vorgänge lauten Exportieren von Gruppeninhalten und Importieren von Gruppeninhalten.

Stellen Sie sich beispielsweise ein Szenario vor, in dem Sie eine angepasste Experience Builder-Anwendung entwickelt haben, die auf eine Webkarte und eine Reihe von Feature-Layern in einer Gruppe in Ihrer Entwicklungsumgebung verweist und jetzt für eine strukturierte Überprüfung zu einem Staging-System migriert werden kann. Zum Exportieren/Importieren von Gruppeninhalten führen Sie die folgenden Schritte aus:

1. Exportieren Sie den Gruppeninhalt aus der Entwicklungsumgebung in ein Paket.
2. Fügen Sie das Paket als Element zur Staging-Umgebung hinzu.
3. Importieren Sie den Inhalt des Pakets in eine Gruppe innerhalb der Staging-Umgebung.
4. Stellen Sie die benutzerdefinierte App in der Staging-Hostumgebung bereit, und verweisen Sie von der Konfiguration auf die URLs der Staging-Umgebung.

Jetzt können die Elemente im Paket in der Staging-Umgebung entsprechend den Einstellungen der Staging-Gruppe ermittelt, freigegeben, bearbeitet und verwendet werden. Derselbe Workflow kann verwendet werden, um die Elemente in die Produktionsumgebung zu überführen, wenn sie die Voraussetzungen erfüllen. Für diesen Workflow kann auch mit dem Modul GroupMigrationManager in der ArcGIS API for Python ein Skript erstellt werden.

Blau/Grün-Bereitstellungen

Das Bereitstellen bestimmter Typen von Änderungen, z. B. eines Systemupgrades oder einer wesentlichen Konfigurationsänderung, kann zu Unterbrechungen führen. Einige Organisationen verwenden eine als Blau/Grün-Bereitstellung bezeichnete Strategie, um Änderungen nahtlos für Benutzer bereitzustellen. Eine Blau/Grün-Bereitstellung ist eine Bereitstellungsstrategie, bei der Sie zwei gesonderte, aber identische Umgebungen erstellen. In einer Umgebung (Blau) wird die aktuelle Anwendungsversion ausgeführt, und in der anderen Umgebung (Grün) wird die neue Anwendungsversion oder ein Satz von Konfigurationen ausgeführt. Der Datenverkehr zu jeder Umgebung erfolgt mithilfe von Standardmechanismen wie Routern, Load Balancern, Reverse-Proxys oder Webservern.

Blau und Grün übernehmen abwechselnd die Rolle der Produktionsumgebung. Es ist immer nur eine der Umgebungen aktiv. Wenn z. B. ein Upgrade von ArcGIS Enterprise durchgeführt werden muss, wird das Upgrade zuerst im grünen System durchgeführt. Sobald das Testteam davon überzeugt ist, dass alles vollständig funktionsfähig ist und in der Produktionsumgebung verwendet werden kann, ändert sich lediglich die Richtung des Datenverkehrs vom Proxy oder Load Balancer – zu Grün statt Blau. Die Endbenutzer in der Produktionsumgebung nehmen keine Änderung wahr. Jetzt werden neue Inhalte und Funktionen in Blau entwickelt, bis eine ausreichende Menge von Tests erfolgreich war, um eine erneute Richtungsänderung des Datenverkehrs zu rechtfertigen.

Es kann hohe Kosten verursachen, zwei Umgebungen ständig in Betrieb zu halten.  Glücklicherweise werden Blau/Grün-Bereitstellungen durch die Cloud vereinfacht. Jeder große Anbieter von Cloud-Plattformen verfügt über Tools, mit denen die Infrastruktur bedarfsabhängig erstellt und beseitigt werden kann. So können beispielsweise Server mit Infrastructure-as-Code gestartet und gestoppt und die Verfügbarkeit und Konfiguration des Systems bis ins kleinste Detail automatisiert werden.

Abschließende Empfehlungen

Die Implementierung isolierter Computing-Umgebungen hilft Ihnen, ein stabiles, erweiterbares und leistungsstarkes System bereitzustellen. Durch die Nutzung dieser Umgebungen für ein effektives Änderungsmanagement können Sie Ihr System vor unerwarteten Ausfällen schützen und Unterbrechungen des Geschäftsbetriebs vermeiden. Die meisten Organisationen sollten mindestens über zwei Computing-Umgebungen verfügen: Produktion und Staging. Dies reicht aus, wenn sie keine benutzerdefinierte Entwicklung durchführen, die eine Entwicklungsumgebung erfordert, oder hauptsächlich Low-Code- und No-Code-Anwendungen verwenden. Möglicherweise verfügen Sie jedoch über mehr Umgebungen, abhängig von der Risikobereitschaft Ihrer Organisation.

Überlegen Sie zu einem möglichst frühen Zeitpunkt, wie Sie die Umgebungsisolation (und die in den einzelnen Umgebungen isolierten Aktivitäten) implementieren und steuern. Es gibt zwar keinen einheitlichen Ansatz für diese Entscheidungen, aber viele Werkzeuge und gängige Verfahren, an denen Sie sich orientieren können.

Ein zusätzliches Dokument, das kürzlich veröffentlicht wurde, befasst sich mit dem Konzept der Überführung von Inhalten zwischen Umgebungen, mit einem Beispiel für eine skriptbasierte Methode: Esri Community Post: ArcGIS Enterprise Content Promotion.