In diesem Dokument werden Notfallwiederherstellung und Geschäftskontinuitätsplanung im Kontext von Continuous Integration und Continuous Delivery (CI/CD) beschrieben. Außerdem wird beschrieben, wie Sie Abhängigkeiten erkennen und minimieren können, wenn Sie einen umfassenden Notfallplan zur Aufrechterhaltung des Geschäftsbetriebes (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 Ihre Anwendungsinfrastruktur erfordert auch Ihr CI/CD-Prozess eine Planung für Notfallwiederherstellung und Geschäftskontinuität. 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:
- Innere Entwicklungsschleife: Code schreiben, testen und committen
- Continuous Integration: Erstellen, Testen und Sicherheit
- Continuous Delivery: Hochstufen, Rollout, Rollback und Messwerte
In diesem Diagramm ist auch zu sehen, 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 der RTO und RPO 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:
- Sie erfahren, 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.
- Die Fehlermodi und Abhängigkeiten Ihres CI/CD-Prozesses verstehen.
- 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 den Betrieb fortsetzen kann. So kann Ihre Organisation schnell wieder zum normalen Betrieb ihres CI/CD-Prozesses 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 Anleitungen 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 Aufrechterhaltung des Geschäftsbetriebs und seine fortlaufende Wartung zu schaffen. Die wichtigsten Schritte in dieser Phase sind:
- Unterstützung durch die Führungsebene: Das Senior Management muss die Entwicklung des BCP unterstützen und fördern. 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. Ermitteln Sie, welche Geschäftsprozesse kritisch sind und im Plan berücksichtigt werden müssen.
- Risikobewertung: Ermitteln 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 Risikobewertungsergebnisse 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 Analyse der geschäftlichen Auswirkungen ist ein wichtiger Schritt im Prozess der Planung der Geschäftskontinuität 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 Analyse der geschäftlichen Auswirkungen 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 für jede kritische Funktion akzeptable Grenzwerte für Ausfallzeiten und Datenverlust. 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 übergeordneten Wiederherstellungsstrategien für kritische Funktionen.
Die wichtigsten Schritte in der Phase der Strategieentwicklung sind:
- Strategien zur Wiederherstellung: Entwickeln Sie Strategien zur Wiederherstellung wichtiger Funktionen. Diese Strategien können alternative Standorte, Remote-Arbeit oder Back-up-Systeme umfassen. Diese Strategien sind an die RTO- und RPO-Ziele für jede kritische Funktion gebunden.
- Beziehungen zu Anbietern und Lieferanten: Erstellen Sie Kommunikations- und Koordinationsplä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 wichtigste Schritt 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 BCP dokumentiert wurde, testen Sie ihn durch Simulationen und Übungen, um Lücken zu identifizieren und die Effektivität zu verbessern. Schulen Sie Ihre Mitarbeiter in Bezug auf ihre Rollen und Verantwortlichkeiten bei einer Störung.
- Aktivierung: Wenn eine Störung auftritt, initiieren Sie den BCP gemäß den vordefinierten Triggern und Verfahren.
- Kommunikation: Informieren Sie die Stakeholder über die Situation und die Maßnahmen zur Wiederherstellung.
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 BCP regelmäßig, damit er aktuell und effektiv bleibt. Aktualisieren Sie es, wenn sich Änderungen bei Personal, Technologie oder Geschäftsprozessen ergeben.
- Erkenntnisse: Führen Sie nach jeder Störung oder jedem Test eine Nachbesprechung durch, um Erkenntnisse und Verbesserungsmöglichkeiten zu ermitteln.
- Einhaltung von Vorschriften: Richten Sie Ihren BCP an Branchenvorschriften und ‑standards aus.
- Mitarbeiter sensibilisieren: 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 Ihr Unternehmen seine 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 verstehen
- Daten und Abhängigkeiten identifizieren
- RTO- und RPO-Ziele festlegen
- Strategie auf hoher Ebene für die Geschäftskontinuität auswählen
- BCP dokumentieren und Best Practices implementieren
- Fehlerszenarien testen und den Plan pflegen
In den folgenden Abschnitten finden Sie weitere Informationen zu den einzelnen Schritten.
Toolchain verstehen
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, ist es jedoch wichtig, die CI/CD-Toolchain und ihre Abhängigkeiten zu verstehen. 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 zeigen, wie Sie Ihre eigene Toolchain bewerten und einen BCP entwickeln können, 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 Anträge
- 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:
- Codeentwicklungsereignisse 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 wichtig, 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 die direkte Kontrolle haben. Interne Abhängigkeiten werden ebenfalls von Ihren Teams ausgewählt. Dazu gehören Ihr CI-Tool, Ihr Schlüsselspeicher und Ihr Quellcodeverwaltungssystem. Sie können sich diese Systeme als die nächste Ebene unterhalb der Toolchain vorstellen.
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 sie die CI/CD-Pipeline nach der Einrichtung der Tools während des Wiederherstellungsprozesses neu erstellen.
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 sind eine weitere Ebene unterhalb der internen Abhängigkeiten. 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 mehr als eine Ebene 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 während einer Unterbrechung 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 zeigt Quadranten, die auf der Grundlage 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, IaC-Pipeline (Infrastructure as Code)
- 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-Ziele höher sind. Im Allgemeinen sollten die RTO- und RPO-Ziele für Ihre Toolchain-Komponenten entsprechend dem zulässigen Daten- oder Konfigurationsverlust 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 Ausfall von Artifact Registry größere Auswirkungen auf den Geschäftsbetrieb hat als ein Ausfall 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 andere Methoden zum Bereitstellen oder Aktualisieren der Infrastruktur während eines Ausfalls 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 Aktiv/Passiv-Strategie (oder Warm-Standby-Strategie) 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 heruntergefahrenen 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 für Region 1 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 Aktiv/Passiv-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 an Ihre Anforderungen angepasst 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. Die Build-Zeit für Artefakte und die Zeit zum Abrufen externer Abhängigkeiten können ebenfalls 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, Ihren BCP regelmäßig zu überprüfen, zu testen und zu aktualisieren. Durch das Testen des BCP und der Wiederherstellungsverfahren wird überprüft, ob der Plan noch gültig ist und ob die dokumentierten RPO- und RTO-Ziele akzeptabel sind. Regelmäßige Tests, Aktualisierungen und Wartung sorgen dafür, dass die Ausführung des BCP zum normalen Betrieb gehört. 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 der 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 Ihrer DR-Umgebung durchführen. Sie können auch testen, ob Ihr gewöhnlicher Zugriffspfad für Google Cloud funktioniert.
Bei Google testen wir unseren BCP regelmäßig durch einen Prozess namens DiRT (Disaster Recovery Testing). Mit diesen Tests 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 Ihrer CI/CD-Pipeline:
- 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. Die Wiederherstellung fehlgeschlagener Knoten erfolgt also 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 jedoch 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 des Erstellens und Speicherns von Kopien in einem privaten Repository. 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 Einbinden 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 Einfügen von Malware verhindert werden.
- Kontrolle: Durch die Bereitstellung eigener Pakete oder Images können Organisationen mehr Kontrolle über die Quelle dieser Pakete und Images haben.
- Compliance: Die Zusammenarbeit mit Anbietern kann Organisationen helfen, Branchenvorschriften wie die Cybersecurity Maturity Model Certification einzuhalten.
Wenn Ihr Team beschließt, Anwendungspakete oder Bilder von Drittanbietern zu beziehen, gehen Sie so vor:
- Identifizieren Sie die Anwendungspakete oder ‑images, die als Vendor-Pakete bereitgestellt werden müssen.
- Erstellen Sie ein privates Repository zum Speichern der Pakete oder Bilder.
- Laden Sie die Pakete oder Bilder 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 Anbieterpakete oder ‑bilder nach Bedarf.
CI/CD-Pipelines rufen häufig Systeme von Drittanbietern auf, um Aktionen wie das Ausführen von Scans, das Protokollieren 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 DR-Plan. Diese Fälle sollten im BCP 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 Beispiel-Repository für Cloud Monitoring auf GitHub 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 Eskalierungsverfahren. 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 Konfigurationen 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
- Google Cloud Weitere Funktionen Google Cloud �
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.
Beitragende
Autoren:
- Ben Good | Lösungsarchitekt
- Xiang Shen | Solutions Architect
Weitere Beitragende:
- Marco Ferrari | Cloud Solutions Architect
- Anuradha Bajpai | Solutions Architect
- Rodd Zurcher | Solutions Architect