In diesem Dokument werden Notfallwiederherstellung (Disaster Recovery, DR) und Notfallplanung zur Aufrechterhaltung des Geschäftsbetriebs (Business Continuity Planning, BCP) im Kontext von Continuous Integration und Continuous Delivery (CI/CD) beschrieben. Außerdem wird erläutert, wie Sie Abhängigkeiten erkennen und minimieren können, wenn Sie einen umfassenden Notfallplan zur Aufrechterhaltung des Geschäftsbetriebs (Business Continuity Plan, BCP) entwickeln. Das Dokument enthält Best Practices, die Sie unabhängig von den von Ihnen verwendeten Tools und Prozessen auf Ihren BCP anwenden können. In diesem Dokument wird davon ausgegangen, dass Sie mit den Grundlagen des Softwarebereitstellungs- und ‑betriebszyklus, CI/CD und DR vertraut sind.
CI/CD-Pipelines sind für das Erstellen und Bereitstellen Ihrer geschäftskritischen Anwendungen verantwortlich. Wie bei Ihrer Anwendungsinfrastruktur müssen Sie auch bei Ihrem CI/CD-Prozess für DR und Geschäftskontinuität planen. Wenn Sie über DR und Geschäftskontinuität für CI/CD nachdenken, ist es wichtig, jede Phase des Softwarebereitstellungs- und Betriebszyklus zu verstehen und zu wissen, wie sie als ganzheitlicher Prozess zusammenarbeiten.
Das folgende Diagramm ist eine vereinfachte Darstellung des Softwareentwicklungs- und ‑betriebszyklus, der die folgenden drei Phasen umfasst:
- Inner Loop der Entwicklung: Code schreiben, ausprobieren und committen
- Continuous Integration: Erstellen, Testen und Sicherheit
- Continuous Delivery: Hochstufen, Rollout, Rollback und Messwerte
Das Diagramm zeigt auch, dass Google Kubernetes Engine (GKE), Cloud Run und Google Distributed Cloud mögliche Bereitstellungsziele für den Softwareentwicklungs- und ‑betriebszyklus sind.
Während des gesamten Softwareentwicklungs- und ‑betriebszyklus müssen Sie die Auswirkungen einer Katastrophe auf die Fähigkeit von Teams berücksichtigen, geschäftskritische Anwendungen zu betreiben und zu warten. So können Sie das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO) für die Tools in Ihrer CI/CD-Toolchain ermitteln.
Außerdem haben die meisten Organisationen viele verschiedene CI/CD-Pipelines für verschiedene Anwendungen und Infrastrukturen. Jede Pipeline hat eigene Anforderungen an die Notfallwiederherstellung und die Planung der Geschäftskontinuität. Die Wiederherstellungsstrategie, die Sie für eine Pipeline auswählen, hängt von den RTO- und RPO-Werten Ihrer Tools ab. Einige Pipelines sind beispielsweise wichtiger als andere und haben niedrigere RTO- und RPO-Anforderungen. Es ist wichtig, die geschäftskritischen Pipelines in Ihrem BCP zu identifizieren. Sie sollten auch mehr Aufmerksamkeit erhalten, wenn Sie Best Practices für das Testen und Ausführen von Wiederherstellungsverfahren implementieren.
Da jeder CI/CD-Prozess und seine Toolchain anders sind, soll dieser Leitfaden Ihnen helfen, Single Points of Failure in Ihrem CI/CD-Prozess zu identifizieren und einen umfassenden BCP zu entwickeln. In den folgenden Abschnitten erfahren Sie, wie Sie Folgendes tun können:
- Hier erfahren Sie, was erforderlich ist, um sich von einem Notfall zu erholen, der sich auf Ihren CI/CD-Prozess auswirkt.
- Bestimmen Sie die RTO und RPO für die Tools in Ihrem CI/CD-Prozess.
- Verstehen Sie die Fehlermodi und Abhängigkeiten Ihres CI/CD-Prozesses.
- Wählen Sie eine geeignete Wiederherstellungsstrategie für die Tools in Ihrer Toolchain aus.
- Allgemeine Best Practices für die Implementierung eines DR-Wiederherstellungsplans für Ihren CI/CD-Prozess.
Geschäftskontinuitätsprozess verstehen
Die Entwicklung eines BCP ist entscheidend, um sicherzustellen, dass Ihre Organisation im Falle von Störungen und Notfällen ihre Abläufe fortsetzen kann. So kann Ihre Organisation schnell wieder zum normalen Betrieb für ihren CI/CD-Prozess zurückkehren.
In den folgenden Abschnitten werden die allgemeinen Phasen beschrieben, die die Schritte zum Erstellen eines effektiven BCP umfassen. Viele dieser Schritte gelten allgemein für die Programmverwaltung und die Notfallwiederherstellung. Bestimmte Schritte sind jedoch relevanter für die Planung der Geschäftskontinuität für Ihren CI/CD-Prozess. Die Schritte, die speziell für die Planung der Geschäftskontinuität für CI/CD relevant sind, werden in den folgenden Abschnitten hervorgehoben. Sie bilden auch die Grundlage für die Anleitung im Rest dieses Dokuments.
Initiierung und Planung
In dieser ersten Phase arbeiten sowohl technische als auch geschäftliche Teams zusammen, um die Grundlage für den Prozess zur Planung der Geschäftskontinuität und seine fortlaufende Wartung zu schaffen. Die wichtigsten Schritte in dieser Phase sind:
- Unterstützung durch die Führungsebene: Sorgen Sie dafür, dass das Topmanagement die Entwicklung des BCP unterstützt und fördert. Weisen Sie ein spezielles Team oder eine Person zu, die für die Überwachung des Plans verantwortlich ist.
- Ressourcenzuweisung: Weisen Sie das erforderliche Budget, Personal und die erforderlichen Ressourcen für die Entwicklung und Implementierung des BCP zu.
- Umfang und Ziele: Definieren Sie den Umfang Ihres BCP und seine Ziele. Legen Sie fest, welche Geschäftsprozesse kritisch sind und im Plan berücksichtigt werden müssen.
- Risikobewertung: Identifizieren Sie potenzielle Risiken und Bedrohungen, die Ihr Unternehmen beeinträchtigen könnten, z. B. Naturkatastrophen, Cyberangriffe oder Unterbrechungen der Lieferkette.
- Wirkungsanalyse: Bewerten Sie die potenziellen Folgen dieser Ergebnisse der Risikobewertung für Ihre Geschäftsabläufe, Finanzen, Ihren Ruf und die Kundenzufriedenheit.
Geschäftsauswirkungsanalyse
In dieser Phase analysieren die Geschäfts- und Technikteams die Auswirkungen von Störungen auf Ihre Kunden und Ihr Unternehmen und priorisieren die Wiederherstellung kritischer Geschäftsfunktionen. Diese Geschäftsfunktionen werden in den verschiedenen Phasen eines Build- und Bereitstellungsprozesses von unterschiedlichen Tools ausgeführt.
Die Geschäftsauswirkungsanalyse ist eine wichtige Phase im Prozess der Notfallplanung für CI/CD, insbesondere die Schritte zur Identifizierung kritischer Geschäftsfunktionen und Tool-Abhängigkeiten. Außerdem ist es wichtig, Ihre CI/CD-Toolchain zu verstehen, einschließlich ihrer Abhängigkeiten und ihrer Funktionsweise im DevOps-Lebenszyklus. Das ist ein grundlegender Baustein für die Entwicklung eines BCP für Ihren CI/CD-Prozess.
Die wichtigsten Schritte in der Phase der Geschäftsauswirkungsanalyse sind:
- Kritische Funktionen: Ermitteln Sie die wichtigsten Geschäftsfunktionen und ‑prozesse, die bei der Wiederherstellung priorisiert werden müssen. Wenn Sie beispielsweise feststellen, dass die Bereitstellung von Anwendungen wichtiger ist als die Ausführung von Unit-Tests, würden Sie die Wiederherstellung für Prozesse und Tools zur Anwendungsbereitstellung priorisieren.
- Abhängigkeiten: Ermitteln Sie interne und externe Abhängigkeiten, die sich auf die Wiederherstellung Ihrer kritischen Funktionen auswirken könnten. Abhängigkeiten sind besonders wichtig, um den kontinuierlichen Betrieb Ihres CI/CD-Prozesses über die Toolchain hinweg zu gewährleisten.
- RTO und RPO: Definieren Sie akzeptable Grenzwerte für Ausfallzeiten und Datenverlust für jede kritische Funktion. Diese RTO- und RPO-Ziele sind mit der Bedeutung einer Geschäftsfunktion für den laufenden Betrieb verknüpft und umfassen bestimmte Tools, die für einen reibungslosen Betrieb der Geschäftsfunktion erforderlich sind.
Strategieentwicklung
In dieser Phase entwickelt das technische Team Wiederherstellungsstrategien für kritische Geschäftsfunktionen, z. B. für die Wiederherstellung von Betrieb und Daten sowie für die Kommunikation mit Anbietern und Stakeholdern. Die Strategieentwicklung ist auch ein wichtiger Bestandteil der Planung der Geschäftskontinuität für Ihren CI/CD-Prozess, insbesondere bei der Auswahl von Wiederherstellungsstrategien auf hoher Ebene für kritische Funktionen.
Die wichtigsten Schritte in der Phase der Strategieentwicklung sind:
- Strategien zur Wiederherstellung: Entwickeln Sie Strategien zur Wiederherstellung wichtiger Funktionen. Dazu gehören möglicherweise alternative Standorte, Remote-Arbeit oder Back-up-Systeme. Diese Strategien sind an die RTO- und RPO-Ziele für jede kritische Funktion gebunden.
- Beziehungen zu Anbietern und Lieferanten: Erstellen Sie Kommunikations- und Koordinierungspläne mit wichtigen Anbietern und Lieferanten, um die Lieferkette bei Störungen aufrechtzuerhalten.
- Daten- und IT-Wiederherstellung: Erstellen Sie Pläne für die Datensicherung, die Wiederherstellung von IT-Systemen und Cybersicherheitsmaßnahmen.
- Kommunikationsplan: Entwickeln Sie einen klaren Kommunikationsplan für interne und externe Stakeholder während und nach einer Störung.
Planentwicklung
In dieser Phase besteht der Hauptschritt darin, den BCP zu dokumentieren. Das technische Team dokumentiert die Tools, Prozesse, Wiederherstellungsstrategien, Begründungen und Verfahren für jede kritische Funktion. Zur Entwicklung eines Plans gehört auch das Verfassen von detaillierten Anleitungen für Mitarbeiter, die sie im Falle einer Störung befolgen können. Während der Implementierung und der laufenden Wartung müssen möglicherweise Änderungen am Plan vorgenommen werden. Der Plan sollte als dynamisches Dokument betrachtet werden.
Implementierung
In dieser Phase setzen Sie den Plan für Ihre Organisation mithilfe des vom technischen Team erstellten BCP um. Die Implementierung umfasst Mitarbeiterschulungen und erste Tests des BCP. Die Implementierung umfasst auch die Verwendung des Plans, wenn es zu einer Störung kommt, um den normalen Betrieb wiederherzustellen. Die wichtigsten Implementierungsschritte sind:
- Erste Tests und Schulungen: Nachdem der BPC dokumentiert wurde, testen Sie ihn durch Simulationen und Übungen, um Lücken zu erkennen und die Effektivität zu verbessern. Schulen Sie Mitarbeiter in ihren Rollen und Verantwortlichkeiten während einer Unterbrechung.
- Aktivierung: Wenn eine Störung auftritt, wird der BCP gemäß den vordefinierten Triggern und Verfahren eingeleitet.
- Kommunikation: Stakeholder über die Situation und die Maßnahmen zur Wiederherstellung auf dem Laufenden halten.
Wartung und Überprüfung
Diese Phase ist kein definierter Prozess, der nur einmal stattfindet, sondern eine kontinuierliche, fortlaufende Aufgabe, die zu einem normalen Bestandteil Ihrer CI/CD-Vorgänge werden sollte. Es ist wichtig, den BCP in Ihrer Organisation regelmäßig zu überprüfen, zu testen und zu aktualisieren, damit er relevant und umsetzbar bleibt, falls es zu einer Störung kommt. Die wichtigsten Schritte bei der Wartung und Überprüfung sind:
- Regelmäßige Updates: Überprüfen und aktualisieren Sie den Notfallplan zur Aufrechterhaltung des Geschäftsbetriebs regelmäßig, damit er aktuell und effektiv bleibt. Aktualisieren Sie sie, wenn sich Änderungen bei Personal, Technologie oder Geschäftsprozessen ergeben.
- Gewonnene Erkenntnisse: Führen Sie nach jeder Störung oder jedem Test eine Nachbesprechung durch, um gewonnene Erkenntnisse und Verbesserungsmöglichkeiten zu ermitteln.
- Einhaltung regulatorischer Anforderungen: Richten Sie Ihren BCP an Branchenvorschriften und ‑standards aus.
- Sensibilisierung der Mitarbeiter: Mitarbeiter kontinuierlich über den BCP und ihre Rollen bei der Ausführung informieren.
Prozess zur Sicherstellung der Betriebskontinuität für CI/CD erstellen
In diesem Abschnitt finden Sie spezifische Richtlinien für die Erstellung eines BCP, das sich speziell auf die Wiederherstellung Ihrer CI/CD-Vorgänge konzentriert. Die Planung der Geschäftskontinuität für CI/CD beginnt mit einem gründlichen Verständnis Ihrer CI/CD-Toolchain und ihrer Verbindung zum Lebenszyklus der Softwarebereitstellung und des Betriebs. Auf dieser Grundlage können Sie dann planen, wie Ihre Organisation ihre CI/CD-Vorgänge nach einer Unterbrechung wiederherstellen wird.
Um einen robusten Prozess für Geschäftskontinuität für Ihren CI/CD-Prozess zu entwickeln, müssen Sie die folgenden wichtigen Schritte ausführen:
- Toolchain
- Daten und Abhängigkeiten identifizieren
- RTO- und RPO-Ziele festlegen
- Strategie für die Geschäftskontinuität auswählen
- BCP dokumentieren und Best Practices implementieren
- Szenarien für fehlgeschlagene Tests testen und den Plan pflegen
In den folgenden Abschnitten finden Sie weitere Informationen zu den einzelnen Schritten.
Toolchain
CI/CD-Toolchains bestehen aus vielen verschiedenen einzelnen Tools und die möglichen Kombinationen von Tools können endlos erscheinen. Um die Geschäftskontinuität für CI/CD zu planen, müssen Sie jedoch Ihre CI/CD-Toolchain und ihre Abhängigkeiten kennen. Die Hauptaufgabe Ihres CI/CD-Prozesses besteht darin, Code für die Produktionssysteme bereitzustellen, damit er von Endnutzern verwendet werden kann. Während dieses Prozesses werden viele verschiedene Systeme und Datenquellen verwendet. Es ist wichtig, diese Datenquellen und Abhängigkeiten zu kennen, um einen BCP zu entwickeln. Bevor Sie mit der Erstellung Ihrer DR-Strategie beginnen, müssen Sie sich mit den verschiedenen Tools vertraut machen, die in Ihrem CI/CD-Prozess verwendet werden.
Um Ihnen zu helfen, Ihre eigene Toolchain zu bewerten und Ihren BCP zu entwickeln, wird in diesem Dokument das Beispiel einer Java-Unternehmensanwendung verwendet, die in GKE ausgeführt wird. Das folgende Diagramm zeigt die erste Ebene von Daten und Systemen in der Toolchain. Diese erste Ebene unterliegt Ihrer direkten Kontrolle und umfasst Folgendes:
- Die Quelle für Ihre Anwendungen
- Tools in Ihrer CI/CD-Plattform, z. B. Cloud Build oder Cloud Deploy
- Grundlegende Verbindungen der verschiedenen Tools
Wie im Diagramm dargestellt, sieht der Hauptablauf für die Beispielanwendung so aus:
- Ereignisse bei der Codeentwicklung in der inneren Entwicklungsschleife lösen Cloud Build aus.
- Cloud Build ruft den Anwendungsquellcode aus dem Quellcode-Repository ab.
- Cloud Build ermittelt alle erforderlichen Abhängigkeiten, die in Build-Konfigurationsdateien angegeben sind, z. B. JAR-Dateien von Drittanbietern aus dem Java-Repository in Artifact Registry. Cloud Build ruft diese Abhängigkeiten dann von ihren Quellspeicherorten ab.
- Cloud Build führt den Build aus und nimmt die erforderlichen Validierungen vor, z. B. statische Analysen und Einheitentests.
- Wenn der Build erfolgreich ist, erstellt Cloud Build das Container-Image und überträgt es per Push in das Container-Repository in Artifact Registry.
- Eine Cloud Deploy-Pipeline wird ausgelöst. Die Pipeline ruft das Container-Image aus dem Repository ab und stellt es in einer GKE-Umgebung bereit.
Um die in Ihrem CI/CD-Prozess verwendeten Tools zu verstehen, empfehlen wir, ein Diagramm zu erstellen, das Ihren CI/CD-Prozess und die darin verwendeten Tools zeigt, ähnlich dem Beispiel in diesem Dokument. Anschließend können Sie anhand des Diagramms eine Tabelle erstellen, in der wichtige Informationen zu Ihrer CI/CD-Toolchain erfasst werden, z. B. die Phase des Prozesses, der Zweck des Tools, das Tool selbst und die Teams, die von einem Fehler des Tools betroffen sind. In dieser Tabelle finden Sie eine Zuordnung der Tools in Ihrer Toolchain und der Tools, die bestimmten Phasen des CI/CD-Prozesses zugeordnet sind. So können Sie sich einen Überblick über Ihre Toolchain und ihre Funktionsweise verschaffen.
In den folgenden Tabellen wird das oben erwähnte Beispiel einer Unternehmensanwendung den einzelnen Tools im Diagramm zugeordnet. Um ein vollständigeres Beispiel für eine Toolchain-Zuordnung zu geben, enthalten diese Tabellen auch andere Tools, die im Diagramm nicht erwähnt werden, z. B. Sicherheits- oder Testtools.
Die erste Tabelle bezieht sich auf Tools, die in der CI-Phase des CI/CD-Prozesses verwendet werden:
| Continuous Integration | Quelle | Verwendete Tools | Hauptnutzer | Nutzung |
|---|---|---|---|---|
| Phase: Versionsverwaltung |
|
|
|
|
| Phase: Build |
|
Entwickler |
|
|
| Phase: Test |
|
Entwickler |
Unit- und Integrationstests auf einer konsistenten On-Demand-Plattform ausführen |
|
| Phase: Sicherheit |
|
|
Code auf Sicherheitsprobleme scannen |
Die zweite Tabelle konzentriert sich auf Tools, die in der CD-Phase des CI/CD-Prozesses verwendet werden:
| Kontinuierliche Bereitstellung | Quelle | Verwendete Tools | Hauptnutzer | Nutzung |
|---|---|---|---|---|
| Phase: Bereitstellung | Konfigurationsdateien für das Deployment |
|
Automatisieren Sie Bereitstellungen, um Traffic auf einer sicheren und konsistenten Plattform zu fördern, zu genehmigen und zu verwalten. |
|
| Phase: Test |
|
|
Entwickler |
Testen Sie die Integration und Leistung auf Qualität und Nutzerfreundlichkeit. |
| Phase: Protokollierung |
|
|
Protokolle für die Beobachtbarkeit und Fehlerbehebung aufbewahren |
|
| Phase: Monitoring | Überwachung von Konfigurationsdateien, einschließlich der folgenden:
|
|
|
Wenn Sie weiter an Ihrem BCP arbeiten und Ihr Wissen über Ihre CI/CD-Toolchain wächst, können Sie Ihr Diagramm und Ihre Zuordnungstabelle aktualisieren.
Daten und Abhängigkeiten identifizieren
Nachdem Sie Ihr Basisinventar und Ihre Karte der CI/CD-Toolchain erstellt haben, müssen Sie alle Abhängigkeiten von Metadaten oder Konfigurationen erfassen. Bei der Implementierung Ihres BCP ist es entscheidend, dass Sie ein klares Verständnis der Abhängigkeiten in Ihrer CI/CD-Toolchain haben. Abhängigkeiten lassen sich in der Regel in zwei Kategorien einteilen: interne (erste Ordnung) und externe (zweite oder dritte Ordnung).
Interne Abhängigkeiten
Interne Abhängigkeiten sind Systeme, die von Ihrer Toolchain verwendet werden und über die Sie direkte Kontrolle haben. Interne Abhängigkeiten werden ebenfalls von Ihren Teams ausgewählt. Dazu gehören Ihr CI-Tool, der Schlüsselverwaltungsspeicher und das Quellcodeverwaltungssystem. Diese Systeme befinden sich in der nächsten Ebene unterhalb der Toolchain.
Das folgende Diagramm zeigt beispielsweise, wie interne Abhängigkeiten in eine Toolchain passen. Das Diagramm erweitert das vorherige Toolchain-Diagramm der ersten Ebene für die Beispiel-Java-Anwendung um die internen Abhängigkeiten der Toolchain: Anmeldedaten der Anwendung, die deploy.yaml-Datei und die cloudbuild.yaml-Datei.
Das Diagramm zeigt, dass für die erfolgreiche Ausführung der Beispiel-Java-Anwendung Tools wie Cloud Build, Cloud Deploy und GKE Zugriff auf Nicht-Toolchain-Abhängigkeiten wie cloudbuild.yaml, deploy.yaml und Anmeldedaten der Anwendung benötigen. Wenn Sie Ihre eigene CI/CD-Toolchain analysieren, prüfen Sie, ob ein Tool eigenständig ausgeführt werden kann oder ob es eine andere Ressource aufrufen muss.
Sehen Sie sich die dokumentierten internen Abhängigkeiten für die Beispiel-Java-Anwendung an.
Anmeldedaten werden in Secret Manager gespeichert, der nicht Teil der Toolchain ist. Die Anmeldedaten sind jedoch erforderlich, damit die Anwendung bei der Bereitstellung gestartet werden kann. Daher sind die Anwendungsanmeldedaten als Abhängigkeit für GKE enthalten. Es ist auch wichtig, die Dateien deploy.yaml und cloudbuild.yaml als Abhängigkeiten einzuschließen, auch wenn sie mit dem Anwendungscode in der Quellcodeverwaltung gespeichert sind, da sie die CI/CD-Pipeline für diese Anwendung definieren.
Das BCP für die Beispiel-Java-Anwendung sollte diese Abhängigkeiten von den Dateien deploy.yaml und cloudbuild.yaml berücksichtigen, da die CI/CD-Pipeline nach der Einrichtung der Tools während des Wiederherstellungsprozesses neu erstellt wird.
Wenn diese Abhängigkeiten manipuliert werden, wird die Gesamtfunktion der Pipeline beeinträchtigt, auch wenn die Tools selbst noch funktionieren.
Externe Abhängigkeiten
Externe Abhängigkeiten sind externe Systeme, auf die Ihre Toolchain angewiesen ist, und die nicht Ihrer direkten Kontrolle unterliegen. Externe Abhängigkeiten ergeben sich aus den von Ihnen ausgewählten Tools und Programmier-Frameworks. Externe Abhängigkeiten können als eine weitere Ebene unterhalb der internen Abhängigkeiten betrachtet werden. Beispiele für externe Abhängigkeiten sind npm- oder Maven-Repositories und Monitoring-Dienste.
Obwohl externe Abhängigkeiten außerhalb Ihrer Kontrolle liegen, können Sie sie in Ihren BCP aufnehmen. Im folgenden Diagramm wird die Beispiel-Java-Anwendung aktualisiert, indem zusätzlich zu den internen auch externe Abhängigkeiten einbezogen werden: Java-Bibliotheken in Maven Central und Docker-Images in Docker Hub. Die Java-Bibliotheken werden von Artifact Registry verwendet und die Docker-Images von Cloud Build.
Das Diagramm zeigt, dass externe Abhängigkeiten für Ihren CI/CD-Prozess wichtig sein können: Sowohl Cloud Build als auch GKE sind auf zwei externe Dienste (Maven und Docker) angewiesen, um erfolgreich zu funktionieren. Wenn Sie Ihre eigene Toolchain bewerten, dokumentieren Sie sowohl externe Abhängigkeiten, auf die Ihre Tools zugreifen müssen, als auch Verfahren für den Umgang mit Ausfällen von Abhängigkeiten.
In der Beispiel-Java-Anwendung können die Java-Bibliotheken und Docker-Images nicht direkt gesteuert werden. Sie können sie aber trotzdem in den BCP aufnehmen und auch die entsprechenden Wiederherstellungsverfahren. Sehen Sie sich beispielsweise die Java-Bibliotheken in Maven an. Obwohl die Bibliotheken in einer externen Quelle gespeichert sind, können Sie einen Prozess einrichten, um Java-Bibliotheken regelmäßig in ein lokales Maven-Repository oder in Artifact Registry herunterzuladen und zu aktualisieren. So ist Ihr Wiederherstellungsprozess nicht von der Verfügbarkeit der Drittanbieterquelle abhängig.
Außerdem ist es wichtig zu wissen, dass externe Abhängigkeiten mehrere Ebenen haben können. Die Systeme, die von Ihren internen Abhängigkeiten verwendet werden, können beispielsweise als Abhängigkeiten zweiter Ordnung betrachtet werden. Diese Abhängigkeiten zweiter Ordnung haben möglicherweise eigene Abhängigkeiten, die als Abhängigkeiten dritter Ordnung bezeichnet werden. Möglicherweise müssen Sie sowohl externe Abhängigkeiten zweiter als auch dritter Ordnung in Ihrem BCP dokumentieren und berücksichtigen, um den Betrieb bei einer Störung wiederherzustellen.
RTO- und RPO-Ziele festlegen
Nachdem Sie sich ein Bild von Ihrer Toolchain und den Abhängigkeiten gemacht haben, definieren Sie die RTO- und RPO-Ziele für Ihre Tools. Die Tools im CI/CD-Prozess führen jeweils eine andere Aktion aus, die sich unterschiedlich auf das Unternehmen auswirken kann. Daher ist es wichtig, die Priorität der RTO- und RPO-Ziele der Geschäftsfunktion an ihre Auswirkungen auf das Unternehmen anzupassen. Beispielsweise kann das Erstellen neuer Versionen von Anwendungen in der CI-Phase weniger Auswirkungen haben als das Bereitstellen von Anwendungen in der CD-Phase. Daher können für Bereitstellungstools längere RTO- und RPO-Ziele als für andere Funktionen gelten.
Das folgende Vier-Quadranten-Diagramm ist ein allgemeines Beispiel dafür, wie Sie Ihre RTO- und RPO-Ziele für jede Komponente der CI-/CD-Toolchain festlegen können. Die in diesem Diagramm dargestellte Toolchain umfasst Tools wie eine IaC-Pipeline und Testdatenquellen. Die Tools wurden in den vorherigen Diagrammen für die Java-Anwendung nicht erwähnt, sind aber hier enthalten, um ein vollständigeres Beispiel zu liefern.
Das Diagramm enthält Quadranten, die auf dem Grad der Auswirkungen auf Entwickler und Betrieb basieren. Im Diagramm sind die Komponenten so positioniert:
- Mäßige Auswirkungen auf Entwickler, geringe Auswirkungen auf den Betrieb: Testdatenquellen
- Mäßige Auswirkungen auf Entwickler, mäßige Auswirkungen auf den Betrieb: Cloud Key Management Service, Cloud KMS
- Moderate Auswirkungen auf Entwickler, hohe Auswirkungen auf den Betrieb: Bereitstellungspipeline
- Hohe Auswirkungen auf Entwickler, geringe Auswirkungen auf den Betrieb: Innere Entwicklungs-Schleife
- Hohe Auswirkungen auf Entwickler, moderate Auswirkungen auf den Betrieb: CI-Pipeline, Infrastructure as Code (IaC)-Pipeline
- Hohe Auswirkungen auf Entwickler, hohe Auswirkungen auf den Betrieb: Quellcodeverwaltung (Source Control Management, SCM), Artifact Registry
Komponenten wie die Quellcodeverwaltung und Artifact Registry, die sich stark auf Entwickler und den Betrieb auswirken, haben den größten Einfluss auf das Unternehmen. Für diese Komponenten sollten die niedrigsten RTO- und RPO-Ziele gelten. Die Komponenten in den anderen Quadranten haben eine niedrigere Priorität, was bedeutet, dass die RTO- und RPO-Zielsetzungen höher sind. Im Allgemeinen sollten die RTO- und RPO-Ziele für Ihre Toolchain-Komponenten entsprechend dem tolerierbaren Verlust an Daten oder Konfigurationen im Vergleich zur Zeit, die für die Wiederherstellung des Dienstes für diese Komponente benötigt wird, festgelegt werden.
Sehen Sie sich beispielsweise die verschiedenen Standorte von Artifact Registry und der IaC-Pipeline im Diagramm an. Ein Vergleich dieser beiden Tools zeigt, dass ein Artifact Registry-Ausfall größere Auswirkungen auf den Geschäftsbetrieb hat als ein Ausfall in der IaC-Pipeline. Da sich ein Ausfall von Artifact Registry erheblich auf die Bereitstellung oder automatische Skalierung Ihrer Anwendung auswirkt, hätte er im Vergleich zu anderen Tools niedrigere RTO- und RPO-Ziele. Im Gegensatz dazu zeigt das Diagramm, dass ein Ausfall der IaC-Pipeline weniger Auswirkungen auf den Geschäftsbetrieb hat als andere Tools. Die IaC-Pipeline hätte dann höhere RTO- und RPO-Ziele, da Sie während eines Ausfalls andere Methoden zum Bereitstellen oder Aktualisieren der Infrastruktur verwenden können.
Strategie zur Sicherstellung der Betriebskontinuität auswählen
Prozesse zur Aufrechterhaltung der Geschäftskontinuität für Produktionsanwendungen basieren häufig auf einer von drei gängigen DR-Strategien. Für CI/CD können Sie jedoch zwischen zwei übergeordneten Strategien für die Geschäftskontinuität wählen: aktiv/passiv oder Sicherung/Wiederherstellung. Welche Strategie Sie wählen, hängt von Ihren Anforderungen und Ihrem Budget ab. Jede Strategie hat Komplexitäts- und Kostenkompromisse und Sie haben unterschiedliche Überlegungen für Ihren CI/CD-Prozess. In den folgenden Abschnitten finden Sie weitere Informationen zu den einzelnen Strategien und ihren Kompromissen.
Außerdem können sich Vorfälle, die den Dienst unterbrechen, auf mehr als nur Ihre CI/CD-Implementierung auswirken. Sie sollten auch die gesamte benötigte Infrastruktur berücksichtigen, einschließlich Netzwerk, Computing und Speicher. Sie sollten einen DR-Plan für diese Bausteine haben und ihn regelmäßig testen, um sicherzustellen, dass er effektiv ist.
Aktiv/Passiv
Bei der Active/Passive-Strategie (oder Warm Standby) sind Ihre Anwendungen und die passive CI/CD-Pipeline Spiegelbilder. Die passive Pipeline verarbeitet jedoch keine Kundenarbeitslasten und führt keine Builds oder Bereitstellungen aus. Sie befindet sich also in einem reduzierten Zustand. Diese Strategie eignet sich am besten für geschäftskritische Anwendungen, bei denen eine kurze Ausfallzeit tolerierbar ist.
Das folgende Diagramm zeigt eine Aktiv/Passiv-Konfiguration für die Beispiel-Java-Anwendung, die in diesem Dokument verwendet wird. Die passive Pipeline dupliziert die Anwendungstoolchain vollständig in einer anderen Region.
In diesem Beispiel wird die aktive CI/CD-Pipeline in region1 gehostet und region2 enthält das passive Gegenstück. Der Code wird von einem externen Git-Dienstanbieter wie GitHub oder GitLab gehostet. Ein Repository-Ereignis (z. B. das Zusammenführen einer Pull-Anfrage) kann die CI/CD-Pipeline in Region 1 auslösen, um die multiregionale Produktionsumgebung zu erstellen, zu testen und bereitzustellen.
Wenn ein kritisches Problem für die Pipeline „region1“ auftritt, z. B. ein regionaler Ausfall eines Produkts, kann dies zu fehlgeschlagenen Bereitstellungen oder Builds führen. Um das Problem schnell zu beheben, können Sie den Trigger für das Git-Repository aktualisieren und zur Pipeline in Region 2 wechseln, die dann zur aktiven Pipeline wird. Nachdem das Problem in Region 1 behoben wurde, können Sie die Pipeline in Region 1 als passiv beibehalten.
Vorteile der Active/Passive-Strategie:
- Geringe Ausfallzeiten: Da die passive Pipeline bereitgestellt, aber herunterskaliert wurde, ist die Ausfallzeit auf die Zeit begrenzt, die zum Hochskalieren der Pipeline erforderlich ist.
- Konfigurierbare Toleranz für Datenverlust: Bei dieser Strategie müssen die Konfiguration und das Artefakt regelmäßig synchronisiert werden. Der Betrag kann jedoch entsprechend Ihren Anforderungen konfiguriert werden, was die Komplexität verringern kann.
Nachteile dieser Strategie:
- Kosten: Durch die duplizierte Infrastruktur steigen die Gesamtkosten Ihrer CI/CD-Infrastruktur.
Sicherung/Wiederherstellung
Bei der Sicherungs-/Wiederherstellungsstrategie erstellen Sie Ihre Failover-Pipeline nur bei Bedarf während der Vorfallwiederherstellung. Diese Strategie eignet sich am besten für Anwendungsfälle mit niedrigerer Priorität. Das folgende Diagramm zeigt eine Sicherungs-/Wiederherstellungskonfiguration für die Beispiel-Java-Anwendung. Die Sicherungskonfiguration dupliziert nur einen Teil der CI/CD-Pipeline der Anwendung in einer anderen Region.
Ähnlich wie im vorherigen Beispiel wird die aktive CI/CD-Pipeline in region1 gehostet. Anstelle einer passiven Pipeline in Region 2 sind dort nur Back-ups der erforderlichen regionalen Daten wie der Maven-Pakete und Container-Images vorhanden. Wenn Sie Ihre Quell-Repositories in Region 1 hosten, sollten Sie die Daten auch mit Ihren DR-Standorten synchronisieren.
Wenn beispielsweise ein schwerwiegendes Problem in der Pipeline für Region 1 auftritt, z. B. ein regionaler Produktausfall, können Sie Ihre CI/CD-Implementierung in Region 2 wiederherstellen. Wenn der Infrastrukturcode im Infrastrukturcode-Repository gespeichert ist, können Sie das Automatisierungsskript aus dem Repository ausführen und die CI/CD-Pipeline in region2 neu erstellen.
Wenn der Ausfall ein groß angelegtes Ereignis ist, konkurrieren Sie möglicherweise mit anderen Kunden um Cloud-Ressourcen. Eine Möglichkeit, diese Situation zu entschärfen, besteht darin, mehrere Optionen für den DR-Standort zu haben. Wenn sich Ihre Pipeline für Region 1 beispielsweise in us-east1 befindet, kann Ihre Failover-Region us-east4, us-central1 oder us-west1 sein.
Vorteile der Sicherungs-/Wiederherstellungsstrategie:
- Kosten: Diese Strategie verursacht die niedrigsten Kosten, da Sie die Backup-Pipeline nur in DR-Szenarien bereitstellen.
Nachteile dieser Strategie:
- Ausfallzeit: Die Implementierung dieser Strategie dauert länger, da Sie die Failover-Pipeline erst bei Bedarf erstellen. Anstelle einer vorgefertigten Pipeline müssen die Dienste während der Wiederherstellung nach einem Vorfall erstellt und konfiguriert werden. Auch die Build-Zeit für Artefakte und die Zeit zum Abrufen externer Abhängigkeiten können deutlich länger sein.
BCP dokumentieren und Best Practices implementieren
Nachdem Sie Ihre CI/CD-Toolchain zugeordnet, ihre Abhängigkeiten ermittelt und RTO- und RPO-Ziele für kritische Funktionen festgelegt haben, müssen Sie alle relevanten Informationen in einem schriftlichen BCP dokumentieren. Dokumentieren Sie beim Erstellen Ihres BCP die Strategien, Prozesse und Verfahren zum Wiederherstellen jeder kritischen Funktion. Dieser Dokumentationsprozess umfasst das Verfassen von Schritt-für-Schritt-Anleitungen für Mitarbeiter in bestimmten Rollen, die sie bei einer Störung befolgen müssen.
Nachdem Sie Ihren BCP definiert haben, stellen Sie Ihre CI/CD-Toolchain bereit oder aktualisieren sie. Dabei sollten Sie Best Practices anwenden, um Ihre RTO- und RPO-Ziele zu erreichen. Obwohl CI/CD-Toolchains sehr unterschiedlich sein können, sind zwei wichtige Muster für Best Practices unabhängig von der Toolchain üblich: ein umfassendes Verständnis von Abhängigkeiten und die Implementierung von Automatisierung.
In Bezug auf Abhängigkeiten beziehen sich die meisten BCPs direkt auf die Systeme, die Sie kontrollieren. Externe Abhängigkeiten zweiter oder dritter Ordnung können jedoch genauso wichtig sein. Daher ist es wichtig, auch für diese kritischen Abhängigkeiten Best Practices und Redundanzmaßnahmen zu implementieren. Die externen Java-Bibliotheken in der Beispielanwendung sind ein Beispiel für Abhängigkeiten dritter Ordnung. Wenn Sie kein lokales Repository oder Backup für diese Bibliotheken haben, können Sie Ihre Anwendung möglicherweise nicht erstellen, wenn die externe Quelle, aus der Sie die Bibliotheken abrufen, nicht verbunden ist.
In Bezug auf die Automatisierung sollte die Implementierung von Best Practices in Ihre allgemeine Cloud-IaC-Strategie einbezogen werden. Ihre IaC-Lösung sollte Tools wie Terraform verwenden, um die erforderlichen Ressourcen Ihrer CI/CD-Implementierung automatisch bereitzustellen und die Prozesse zu konfigurieren. IaC-Verfahren sind sehr effektive Wiederherstellungsverfahren, da sie in den täglichen Betrieb Ihrer CI/CD-Pipelines integriert sind. Außerdem wird durch IaC die Speicherung Ihrer Konfigurationsdateien in der Versionsverwaltung gefördert, was wiederum die Einführung der Best Practices für Back-ups fördert.
Nachdem Sie Ihre Toolchain gemäß Ihrem BCP und den Best Practices für Abhängigkeiten und Automatisierung implementiert haben, können sich Ihr CI/CD-Prozess und Ihre Wiederherstellungsstrategien ändern. Dokumentieren Sie alle Änderungen an Wiederherstellungsstrategien, ‑prozessen und ‑verfahren, die sich aus der Überprüfung des BCP und der Implementierung von Best Practices ergeben.
Fehlerszenarien testen und den Plan auf dem neuesten Stand halten
Es ist wichtig, dass Sie Ihren BCP regelmäßig überprüfen, testen und aktualisieren. Durch das Testen des Notfallplans zur Aufrechterhaltung des Geschäftsbetriebs und der Wiederherstellungsverfahren wird überprüft, ob der Plan noch gültig ist und ob die dokumentierten RPO- und RTO-Ziele akzeptabel sind. Am wichtigsten ist jedoch, dass durch regelmäßige Tests, Aktualisierungen und Wartung die Ausführung des Notfallplans zur Aufrechterhaltung des Geschäftsbetriebs Teil des normalen Betriebs wird. Mit Google Cloudkönnen Sie Wiederherstellungsszenarien sehr kostengünstig testen. Folgende empfohlene Maßnahmen unterstützen Sie beim Testen:
- Infrastrukturbereitstellung mit einem IaC-Tool automatisieren: Sie können Tools wie Terraform verwenden, um die Bereitstellung von CI/CD-Infrastruktur zu automatisieren.
- Tests mit Cloud Logging und Cloud Monitoring überwachen und debuggen: Google Cloud Observability bietet Logging- und Monitoringtools, auf die Sie per API-Aufruf zugreifen können. Damit können Sie die Bereitstellung bestimmter Wiederherstellungsszenarien auf Grundlage von Messwerten automatisieren. Achten Sie auch beim Entwurf der Tests darauf, dass Überwachungs- und Benachrichtigungsfunktionen verfügbar sind, die geeignete Wiederherstellungsaktionen auslösen können.
- Führen Sie die Tests in Ihrem BCP durch: Sie können beispielsweise testen, ob Berechtigungen und Nutzerzugriff in der DR-Umgebung wie in der Produktionsumgebung funktionieren. Sie können Integrations- und Funktionstests in der DR-Umgebung durchführen. Sie können auch testen, ob Ihr gewöhnlicher Zugriffspfad für Google Cloud funktioniert.
Bei Google testen wir unseren Notfallplan zur Aufrechterhaltung des Geschäftsbetriebs regelmäßig durch einen Prozess namens DiRT (Disaster Recovery Testing). Mit diesem Test kann Google Auswirkungen und Automatisierung überprüfen und nicht berücksichtigte Risiken aufdecken. Wichtige Ergebnisse von DiRT sind Änderungen an der Automatisierung und am BCP, die implementiert werden müssen.
Best Practices
In diesem Abschnitt erfahren Sie mehr über einige Best Practices, die Sie implementieren können, um Ihre RTO- und RPO-Ziele zu erreichen. Diese Best Practices gelten allgemein für DR für CI/CD und nicht für bestimmte Tools. Unabhängig von Ihrer Implementierung sollten Sie Ihren BCP regelmäßig testen, um sicherzustellen, dass Hochverfügbarkeit, RTO und RPO Ihren Anforderungen entsprechen. Wenn ein Vorfall oder eine Katastrophe eintritt, sollten Sie auch eine Retrospektive durchführen und Ihren Prozess analysieren, um ihn zu verbessern.
Hochverfügbarkeit
Für jedes Tool sollten Sie Best Practices für Hochverfügbarkeit implementieren. Wenn Sie Best Practices für Hochverfügbarkeit befolgen, wird Ihr CI/CD-Prozess proaktiver, da er dadurch widerstandsfähiger gegen Fehler wird. Diese proaktiven Strategien sollten mit reaktiveren Kontrollen und Verfahren für die Wiederherstellung und Sicherung kombiniert werden.
Im Folgenden finden Sie einige Best Practices, um eine hohe Verfügbarkeit zu erreichen. Weitere Best Practices finden Sie in der detaillierten Dokumentation für jedes Tool in Ihrem CI/CD:
- Verwaltete Dienste: Durch die Verwendung verwalteter Dienste wird die operative Verantwortung auf Google Cloudverlagert.
- Autoscaling: Verwenden Sie nach Möglichkeit Autoscaling. Ein wichtiger Aspekt des Autoscaling ist, dass Worker-Instanzen dynamisch erstellt werden. Daher erfolgt die Wiederherstellung von fehlgeschlagenen Knoten automatisch.
- Globale und multiregionale Bereitstellungen: Verwenden Sie nach Möglichkeit globale und multiregionale Bereitstellungen anstelle von regionalen Bereitstellungen. Sie können Artifact Registry beispielsweise für die multiregionale Speicherung konfigurieren.
- Abhängigkeiten: Machen Sie sich mit allen Abhängigkeiten Ihrer Tools vertraut und sorgen Sie dafür, dass diese hochverfügbar sind. Sie können beispielsweise alle Drittanbieterbibliotheken in Ihrer Artifact Registry-Instanz zwischenspeichern.
Sicherungsverfahren
Wenn Sie DR für CI/CD implementieren, eignen sich einige Tools und Prozesse besser für Backup-/Wiederherstellungsstrategien. Eine umfassende Sicherungsstrategie ist der erste Schritt zu effektiven reaktiven Kontrollen. Mit Sicherungen können Sie Ihre CI/CD-Pipeline im Falle von böswilligen Akteuren oder Notfallszenarien mit minimaler Unterbrechung wiederherstellen.
Als Ausgangspunkt sollten Sie die folgenden drei Best Practices implementieren. Detailliertere Best Practices für Back-ups finden Sie in der Dokumentation für die einzelnen Tools in Ihrem CI/CD-Prozess.
- Versionsverwaltung: Speichern Sie Konfigurationsdateien und alles, was Sie codieren, z. B. Automatisierungsskripts und Richtlinien, in der Versionsverwaltung. Beispiele sind
cloudbuild.yamlund Kubernetes-YAML-Dateien. - Redundanz: Achten Sie darauf, dass es keinen Single Point of Failure beim Zugriff auf Secrets wie Passwörter, Zertifikate und API-Schlüssel gibt. Beispiele für Praktiken, die Sie vermeiden sollten, sind, dass nur eine Person das Passwort kennt oder der API-Schlüssel nur auf einem einzigen Server in einer bestimmten Region gespeichert wird.
- Sicherungen: Prüfen Sie regelmäßig die Vollständigkeit und Richtigkeit Ihrer Sicherungen. Verwaltete Dienste wie Backup for GKE können den Bestätigungsprozess vereinfachen.
Wiederherstellungsverfahren
Für die Notfallwiederherstellung sind auch Wiederherstellungsverfahren erforderlich, die die Sicherungsprozesse ergänzen. Ihre Wiederherstellungsverfahren in Kombination mit vollständigen Sicherungen bestimmen, wie schnell Sie auf Notfallszenarien reagieren können.
Abhängigkeitsverwaltung
Ihre CI/CD-Pipeline kann viele Abhängigkeiten haben, die auch Fehlerquellen sein können. Eine vollständige Liste der Abhängigkeiten sollte wie oben in diesem Dokument unter Daten und Abhängigkeiten ermitteln beschrieben ermittelt werden. Die beiden häufigsten Quellen für Abhängigkeiten sind jedoch:
- Anwendungsartefakte, z. B. Pakete, Bibliotheken und Bilder
- Externe Systeme: z. B. Ticket- und Benachrichtigungssysteme
Eine Möglichkeit, die Risiken von Abhängigkeiten zu minimieren, besteht darin, Vendoring zu verwenden. Das Vendoring von Anwendungspaketen oder ‑images ist der Prozess, bei dem Kopien davon in einem privaten Repository erstellt und gespeichert werden. Durch Vendoring wird die Abhängigkeit von externen Quellen für diese Pakete oder Bilder entfernt. Außerdem kann so verhindert werden, dass Malware in die Softwarelieferkette eingeschleust wird.
Das Vendoring von Anwendungspaketen oder ‑images bietet unter anderem folgende Vorteile:
- Sicherheit: Durch das Vendoring wird die Abhängigkeit von externen Quellen für Anwendungspakete oder ‑images entfernt. So können Angriffe durch Einschleusen von Malware verhindert werden.
- Kontrolle: Durch die Bereitstellung eigener Pakete oder Images haben Organisationen mehr Kontrolle über die Quelle dieser Pakete und Images.
- Compliance: Die Nutzung von Drittanbietern kann Unternehmen dabei helfen, Branchenvorschriften wie die Cybersecurity Maturity Model Certification (CMMC) einzuhalten.
Wenn Ihr Team beschließt, Anwendungs- oder Bildpakete von einem Drittanbieter zu beziehen, gehen Sie so vor:
- Identifizieren Sie die Anwendungspakete oder Bilder, die als Anbieter gekennzeichnet werden müssen.
- Erstellen Sie ein privates Repository zum Speichern der Anbieterpakete oder ‑bilder.
- Laden Sie die Pakete oder Images von der ursprünglichen Quelle herunter und speichern Sie sie im privaten Repository.
- Prüfen Sie die Integrität der Pakete oder Images.
- Aktualisieren Sie die Vendored-Pakete oder ‑Bilder nach Bedarf.
CI/CD-Pipelines rufen häufig Systeme von Drittanbietern auf, um Aktionen wie das Ausführen von Scans, das Erfassen von Tickets oder das Senden von Benachrichtigungen auszuführen. In den meisten Fällen haben diese Systeme von Drittanbietern eigene DR-Strategien, die implementiert werden sollten. In einigen Fällen haben sie jedoch möglicherweise keinen geeigneten Plan für die Notfallwiederherstellung. Diese Fälle sollten im Plan für die Geschäftskontinuität klar dokumentiert werden. Sie müssen dann entscheiden, ob diese Phasen in der Pipeline aus Verfügbarkeitsgründen übersprungen werden können oder ob es akzeptabel ist, dass die CI/CD-Pipeline zu Ausfallzeiten führt.
Monitoring und Benachrichtigungen
Ihre CI/CD-Systeme sind wie Ihre Produktionssysteme für Anwendungen. Daher müssen Sie auch für Ihre CI/CD-Tools Überwachungs- und Benachrichtigungstechniken implementieren. Als Best Practice empfehlen wir, Dashboards und Benachrichtigungen einzurichten. Das GitHub-Beispielrepository für Cloud Monitoring enthält viele Beispiele für Dashboards und Benachrichtigungsrichtlinien.
Sie können auch zusätzliche Überwachungsebenen wie Service Level Indicators (SLIs) und Service Level Objectives (SLOs) implementieren. Mit diesen Überwachungsstufen können Sie den allgemeinen Zustand und die Leistung Ihrer CI/CD-Pipelines im Blick behalten. SLOs können beispielsweise implementiert werden, um die Latenz von Build- und Bereitstellungsphasen zu erfassen. Diese SLOs helfen Teams, Anwendungen in der gewünschten Geschwindigkeit und Häufigkeit zu entwickeln und zu veröffentlichen.
Notfallzugriffsverfahren
Bei einer Katastrophe müssen Betriebsteams möglicherweise Maßnahmen ergreifen, die über die Standardverfahren hinausgehen, und Notfallzugriff auf Systeme und Tools erhalten. Solche Notfallmaßnahmen werden manchmal als Breakglass-Verfahren bezeichnet. Als Ausgangspunkt sollten Sie diese drei Best Practices implementieren:
- Erstellen Sie einen klaren Eskalationsplan und ein klares Eskalationsverfahren. Ein klarer Plan hilft dem Betriebsteam zu wissen, wann es die Notfallzugriffsverfahren anwenden muss.
- Sorgen Sie dafür, dass mehrere Personen Zugriff auf wichtige Informationen wie Konfiguration und Secrets haben.
- Entwickeln Sie automatisierte Prüfmethoden, damit Sie nachvollziehen können, wann und von wem Notfallzugriffsverfahren verwendet wurden.
Nächste Schritte
- Weitere Informationen zu den in diesem Dokument verwendeten Google Cloud -Produkten:
- Leitfaden zur Planung der Notfallwiederherstellung
- Weitere Google Cloud Funktionen können Sie mit unseren Anleitungen ausprobieren.
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.
Beitragende
Autor*innen:
- Ben Good | Lösungsarchitekt
- Xiang Shen | Solutions Architect
Weitere Beitragende:
- Marco Ferrari | Cloud Solutions Architect
- Anuradha Bajpai | Solutions Architect
- Rodd Zurcher | Solutions Architect