In diesem Dokument werden Notfallwiederherstellung (Disaster Recovery, DR) und Notfallplanung (Business Continuity Planning, BCP) im Kontext von Continuous Integration und Continuous Delivery (CI/CD) beschrieben. Außerdem erhalten Sie eine Anleitung dazu, wie Sie Abhängigkeiten bei der Entwicklung eines umfassenden Notfallplans zur Aufrechterhaltung des Geschäftsbetriebes (Business Continuity Plan, BCP) identifizieren und beheben. Das Dokument enthält Best Practices, die Sie unabhängig von den verwendeten Tools und Prozessen auf Ihr Notfallwiederherstellungskonzept 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. Daher müssen Sie für Ihren CI/CD-Prozess wie für Ihre Anwendungsinfrastruktur die Notfallwiederherstellung und die Geschäftskontinuität planen. Wenn Sie über Notfallwiederherstellung und Geschäftskontinuität für CI/CD nachdenken, ist es wichtig, jede Phase des Softwarebereitstellungs- und Betriebszyklus zu verstehen und zu verstehen, wie sie als ganzheitlicher Prozess zusammenwirken.
Das folgende Diagramm ist eine vereinfachte Darstellung des Softwareentwicklungs- und ‑betriebszyklus, der die folgenden drei Phasen umfasst:
- Innerer Entwicklungs-Loop: Code schreiben, testen und committen
- Continuous Integration: Build, Test und Sicherheit
- Continuous Delivery: Freigabe, Roll-out, Rollback und Messwerte
Aus diesem Diagramm geht auch hervor, dass die Google Kubernetes Engine (GKE), Cloud Run und die Google Distributed Cloud mögliche Bereitstellungsziele des Softwareentwicklungs- und ‑betriebszyklus sind.
Während des gesamten Softwareentwicklungs- und ‑betriebszyklus müssen Sie die Auswirkungen einer Katastrophe auf die Fähigkeit der Teams berücksichtigen, geschäftskritische Anwendungen zu betreiben und zu verwalten. 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 Unternehmen viele verschiedene CI/CD-Pipelines für unterschiedliche Anwendungen und Infrastrukturen. Jede Pipeline hat spezifische 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 kritischer als andere und haben niedrigere RTO- und RPO-Anforderungen. Es ist wichtig, die geschäftskritischen Pipelines in Ihrem Notfallwiederherstellungsplan zu identifizieren. Außerdem sollten sie mehr Aufmerksamkeit erhalten, wenn Sie Best Practices für das Testen und Ausführen von Wiederherstellungsverfahren implementieren.
Da sich jeder CI/CD-Prozess und seine Toolchain unterscheiden, soll Ihnen dieser Leitfaden dabei helfen, Single Points of Failure in Ihrem CI/CD-Prozess zu identifizieren und eine umfassende Notfallwiederherstellungsstrategie zu entwickeln. In den folgenden Abschnitten erfahren Sie, wie Sie
- Informationen dazu, wie Sie sich von einem Notfall erholen, der sich auf Ihren CI/CD-Prozess auswirkt.
- Legen Sie die RTO und RPO für die Tools in Ihrem CI/CD-Prozess fest.
- Machen Sie sich mit den Fehlermodi und Abhängigkeiten Ihres CI/CD-Prozesses vertraut.
- Wählen Sie eine geeignete Wiederherstellungsstrategie für die Tools in Ihrer Toolchain aus.
- Allgemeine Best Practices für die Implementierung eines Notfallwiederherstellungsplans für Ihren CI/CD-Prozess
Geschäftskontinuität
Ein Notfallplan zur Aufrechterhaltung des Geschäftsbetriebs ist entscheidend, damit Ihr Unternehmen bei Störungen und Notfällen den Betrieb fortsetzen kann. So kann Ihr Unternehmen schnell wieder zum Normalbetrieb für seinen CI/CD-Prozess zurückkehren.
In den folgenden Abschnitten werden die allgemeinen Phasen beschrieben, einschließlich der Schritte, die zum Erstellen eines effektiven Notfallwiederherstellungsplans erforderlich sind. Viele dieser Schritte gelten zwar 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 für die Planung der Geschäftskontinuität für CI/CD besonders 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äftsteams zusammen, um die Grundlage für die Planung der Geschäftskontinuität und deren kontinuierliche Wartung zu schaffen. Zu den wichtigsten Schritten dieser Phase gehören:
- Unterstützung durch die Führungsebene: Sorgen Sie dafür, dass die Geschäftsleitung die Entwicklung des Notfallplans unterstützt und vorantreibt. Weisen Sie ein Team oder eine Person zu, die für die Überwachung des Plans verantwortlich ist.
- Ressourcenzuweisung: Zuweisung des erforderlichen Budgets, des Personals und der Ressourcen für die Entwicklung und Implementierung des Notfallplans.
- Umfang und Ziele: Definieren Sie den Umfang und die Ziele Ihres Notfallwiederherstellungsplans. 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, Cybersicherheitsverstöße oder Unterbrechungen der Lieferkette.
- Auswirkungsanalyse: Bewerten Sie die potenziellen Folgen dieser Ergebnisse der Risikobewertung auf Ihr Unternehmen, Ihre Finanzen, Ihren Ruf und die Kundenzufriedenheit.
Analyse der Auswirkungen auf das Unternehmen
In dieser Phase analysieren die Geschäfts- und Technikteams die Geschäftsauswirkungen 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 verschiedenen Tools ausgeführt.
Die Analyse der Geschäftsauswirkungen ist eine wichtige Phase im Prozess der Planung der Geschäftskontinuität für CI/CD, insbesondere die Schritte zur Identifizierung kritischer Geschäftsfunktionen und Toolabhängigkeiten. Außerdem ist das Verständnis Ihrer CI/CD-Toolchain – einschließlich ihrer Abhängigkeiten und ihrer Funktionsweise im DevOps-Lebenszyklus – ein wichtiger Baustein für die Entwicklung eines Notfallplans für Ihren CI/CD-Prozess.
Zu den wichtigsten Schritten in der Phase der Analyse der Geschäftsauswirkungen gehören:
- Kritische Funktionen: Bestimmen 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, priorisieren Sie die Wiederherstellung für Prozesse und Tools zur Anwendungsbereitstellung.
- Abhängigkeiten: Identifizieren Sie interne und externe Abhängigkeiten, die sich auf die Wiederherstellung Ihrer kritischen Funktionen auswirken könnten. Abhängigkeiten sind besonders wichtig, um den reibungslosen Betrieb Ihres CI/CD-Prozesses über die Toolchain hinweg zu gewährleisten.
- RTO und RPO: Definieren Sie für jede kritische Funktion zulässige Grenzwerte für Ausfallzeiten und Datenverluste. Diese RTO- und RPO-Ziele hängen mit der Bedeutung einer Geschäftsfunktion für den fortlaufenden Betrieb zusammen und beinhalten bestimmte Tools, die für einen reibungslosen Ablauf der Geschäftsfunktion erforderlich sind.
Strategieentwicklung
In dieser Phase entwickelt das technische Team Wiederherstellungsstrategien für kritische Geschäftsfunktionen, z. B. die Wiederherstellung von Betrieb und Daten sowie die Kommunikation mit Anbietern und Stakeholdern. Die Strategieentwicklung ist auch ein wichtiger Teil der Planung der Geschäftskontinuität für Ihren CI/CD-Prozess, insbesondere die Auswahl von allgemeinen Wiederherstellungsstrategien für kritische Funktionen.
Zu den wichtigsten Schritten in der Phase der Strategieentwicklung gehören:
- Wiederherstellungsstrategien: Entwickeln Sie Strategien zur Wiederherstellung kritischer Funktionen. Dazu gehören alternative Standorte, Remote-Arbeit oder Sicherungssysteme. Diese Strategien sind mit den RTO- und RPO-Zielen für jede kritische Funktion verknüpft.
- Beziehungen zu Anbietern und Lieferanten: Erstellen Sie Kommunikations- und Koordinierungspläne mit wichtigen Anbietern und Lieferanten, um die Lieferkette bei Störungen am Laufen zu halten.
- Daten- und IT-Wiederherstellung: Erstellen Sie Pläne für die Datensicherung, die Wiederherstellung von IT-Systemen und Maßnahmen zur Cybersicherheit.
- 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, das Notfallwiederherstellungskonzept zu dokumentieren. Das technische Team dokumentiert die Tools, Prozesse, Wiederherstellungsstrategien, Begründungen und Verfahren für jede kritische Funktion. Die Planentwicklung umfasst auch die Erstellung einer detaillierten Anleitung für Mitarbeiter, die sie bei 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 lebendiges Dokument betrachtet werden.
Implementierung
In dieser Phase implementieren Sie den Plan für Ihre Organisation mithilfe des Notfallwiederherstellungsplans, den das technische Team erstellt hat. Die Implementierung umfasst die Schulung der Mitarbeiter und die ersten Tests des Notfallplans. Die Implementierung umfasst auch die Verwendung des Plans, um bei einer Störung den normalen Betrieb wiederherzustellen. Zu den wichtigsten Implementierungsschritten gehören:
- Erste Tests und Schulungen: Nachdem die BPC dokumentiert wurde, testen Sie sie anhand von Simulationen und Übungen, um Lücken zu identifizieren und die Effektivität zu verbessern. Schulungen für Mitarbeiter zu ihren Rollen und Verantwortlichkeiten bei Störungen
- Aktivierung: Wenn eine Störung auftritt, wird das Notfallkonzept gemäß den vordefinierten Triggern und Verfahren eingeleitet.
- Kommunikation: Halten Sie die Stakeholder über die Situation und die Wiederherstellungsmaßnahmen auf dem Laufenden.
Wartung und Überprüfung
Diese Phase ist kein definierter Prozess, der nur einmal auftritt. Stattdessen handelt es sich um eine kontinuierliche, fortlaufende Aufgabe, die zu einem normalen Bestandteil Ihrer CI/CD-Vorgänge werden sollte. Es ist wichtig, den Notfallplan in Ihrem Unternehmen regelmäßig zu überprüfen, zu testen und zu aktualisieren, damit er bei einer Störung relevant und umsetzbar bleibt. Zu den wichtigsten Schritten der Wartung und Überprüfung gehören:
- Regelmäßige Aktualisierungen: Überprüfen und aktualisieren Sie den Notfallplan regelmäßig, damit er auf dem neuesten Stand und effektiv bleibt. Aktualisieren Sie sie bei Änderungen an Personal, Technologie oder Geschäftsprozessen.
- Erkenntnisse: Führen Sie nach jeder Störung oder jedem Test eine Nachbesprechung durch, um Erkenntnisse und Verbesserungsmöglichkeiten zu identifizieren.
- Regulatory Compliance: Richten Sie Ihr Notfallwiederherstellungskonzept an den Branchenvorschriften und ‑standards aus.
- Bewusstsein der Mitarbeiter: Mitarbeiter kontinuierlich über das Notfallwiederherstellungskonzept und ihre Rolle bei der Umsetzung informieren.
Einen Prozess für die Geschäftskontinuität für CI/CD entwickeln
Dieser Abschnitt enthält spezifische Richtlinien für die Erstellung eines Notfallplans, der sich speziell auf die Wiederherstellung Ihrer CI/CD-Vorgänge konzentriert. Die Planung der Geschäftskontinuität für CI/CD beginnt mit einem umfassenden Verständnis Ihrer CI/CD-Toolchain und ihrer Einbindung in den Lebenszyklus der Softwarebereitstellung und -nutzung. Auf dieser Grundlage können Sie dann planen, wie Ihre Organisation ihre CI/CD-Vorgänge nach einer Störung wiederherstellen kann.
Um einen robusten Prozess für die Geschäftskontinuität für Ihren CI/CD-Prozess zu erstellen, müssen Sie die folgenden wichtigen Schritte ausführen:
- Toolchain
- Daten und Abhängigkeiten identifizieren
- RTO- und RPO-Ziele festlegen
- Allgemeine Strategie für die Geschäftskontinuität auswählen
- BCP dokumentieren und Best Practices implementieren
- Fehlerszenarien testen und den Plan pflegen
In den folgenden Abschnitten werden die einzelnen Schritte genauer beschrieben.
Toolchain
CI/CD-Toolchains bestehen aus vielen verschiedenen einzelnen Tools und die möglichen Kombinationen von Tools können endlos erscheinen. Für die Planung der Geschäftskontinuität für CI/CD ist es jedoch wichtig, die CI/CD-Toolchain und ihre Abhängigkeiten zu kennen. Der Hauptzweck Ihres CI/CD-Prozesses besteht darin, Code für die Nutzung durch Endnutzer in Produktionssystemen bereitzustellen. Bei diesem Prozess werden viele verschiedene Systeme und Datenquellen verwendet. Das Wissen um diese Datenquellen und Abhängigkeiten ist für die Entwicklung eines Notfallwiederherstellungsplans entscheidend. Bevor Sie mit der Erstellung Ihrer Notfallwiederherstellungsstrategie beginnen, müssen Sie sich mit den verschiedenen Tools vertraut machen, die in Ihrem CI/CD-Prozess verwendet werden.
Um Ihnen zu veranschaulichen, wie Sie Ihre eigene Toolchain bewerten und Ihr Notfallwiederherstellungskonzept entwickeln, wird in diesem Dokument das Beispiel einer Java-Unternehmensanwendung verwendet, die auf GKE ausgeführt wird. Das folgende Diagramm zeigt die erste Schicht von Daten und Systemen in der Toolchain. Diese erste Schicht steht unter Ihrer direkten Kontrolle und umfasst Folgendes:
- Quelle für Ihre Anwendungen
- Tools auf Ihrer CI/CD-Plattform, z. B. Cloud Build oder Cloud Deploy
- Grundlegende Verknüpfungen 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 Quellcode der Anwendung aus dem Repository für die Versionskontrolle ab.
- Cloud Build erkennt alle erforderlichen Abhängigkeiten, die in Build-Konfigurationsdateien angegeben sind, z. B. JAR-Dateien von Drittanbietern aus dem Java-Repository in der Artifact Registry. Cloud Build ruft diese Abhängigkeiten dann von ihren Quellspeicherorten ab.
- Cloud Build führt den Build aus und führt die erforderlichen Validierungen durch, z. B. statische Analysen und Unit-Tests.
- 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 und 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 Ihnen, ein Diagramm zu erstellen, das Ihren CI/CD-Prozess und die darin verwendeten Tools zeigt, ähnlich wie im Beispiel in diesem Dokument. Anhand Ihres Diagramms können Sie dann eine Tabelle erstellen, die wichtige Informationen zu Ihrer CI/CD-Toolchain enthält, z. B. die Phase des Prozesses, den Zweck des Tools, das Tool selbst und die Teams, die von einem Ausfall des Tools betroffen sind. Diese Tabelle enthält eine Zuordnung der Tools in Ihrer Toolchain und identifiziert die Tools mit bestimmten Phasen des CI/CD-Prozesses. So erhalten Sie einen Überblick über Ihre Toolchain und ihre Funktionsweise.
In den folgenden Tabellen wird das zuvor erwähnte Beispiel für eine Unternehmensanwendung den einzelnen Tools im Diagramm zugeordnet. Um ein vollständigeres Beispiel dafür zu geben, wie eine Toolchain-Zuordnung aussehen könnte, enthalten diese Tabellen auch andere Tools, die im Diagramm nicht erwähnt werden, z. B. Sicherheits- oder Testtools.
Die erste Tabelle enthält 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 einheitlichen On-Demand-Plattform ausführen |
|
| Phase: Sicherheit |
|
|
Code auf Sicherheitsprobleme prüfen |
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 die Bereitstellung |
|
Implementierungen automatisieren, um Zugriffe auf einer sicheren und einheitlichen Plattform zu fördern, zu genehmigen und zu verwalten. |
|
| Phase: Test |
|
|
Entwickler |
Testen Sie die Integration und Leistung auf Qualität und Nutzerfreundlichkeit. |
| Phase: Logging |
|
|
Protokolle für die Observabilität und Fehlerbehebung aufbewahren |
|
| Phase: Monitoring | Monitoring von Konfigurationsdateien, einschließlich der folgenden:
|
|
|
Wenn Sie weiter an Ihrem Notfallplan arbeiten und Ihr Verständnis Ihrer CI/CD-Toolchain wächst, können Sie Ihr Diagramm und Ihre Zuordnungstabelle aktualisieren.
Daten und Abhängigkeiten identifizieren
Nachdem Sie Ihr Basisinventar und die Zuordnung Ihrer CI/CD-Toolchain erstellt haben, besteht der nächste Schritt darin, alle Abhängigkeiten von Metadaten oder Konfigurationen zu erfassen. Wenn Sie Ihr Notfallwiederherstellungskonzept implementieren, ist es wichtig, dass Sie die Abhängigkeiten in Ihrer CI/CD-Toolchain genau kennen. Abhängigkeiten fallen in der Regel in eine von zwei Kategorien: interne (erster Ordnung) und externe (zweiter oder dritter Ordnung).
Interne Abhängigkeiten
Interne Abhängigkeiten sind Systeme, die von Ihrer Toolchain verwendet werden und über die Sie direkt die Kontrolle haben. Interne Abhängigkeiten werden ebenfalls von Ihren Teams ausgewählt. Dazu gehören Ihr CI-Tool, Ihr Schlüsselverwaltungsspeicher und Ihr Quellkontrollsystem. Sie können sich diese Systeme als die nächste Ebene unter 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: Anwendungsanmeldedaten, die deploy.yaml-Datei und die cloudbuild.yaml-Datei.
Das Diagramm zeigt, dass Tools wie Cloud Build, Cloud Deploy und GKE für die erfolgreiche Ausführung der Beispiel-Java-Anwendung Zugriff auf nicht toolchainabhängige Abhängigkeiten wie cloudbuild.yaml, deploy.yaml und Anwendungsanmeldedaten benötigen. Wenn Sie Ihre eigene CI/CD-Toolchain analysieren, prüfen Sie, ob ein Tool eigenständig ausgeführt werden kann oder ob eine andere Ressource aufgerufen werden muss.
Sehen wir uns die dokumentierten internen Abhängigkeiten der Beispiel-Java-Anwendung an.
Anmeldedaten werden im Secret Manager gespeichert, der nicht Teil der Toolchain ist. Die Anmeldedaten sind jedoch erforderlich, damit die Anwendung bei der Bereitstellung gestartet werden kann. Daher werden die Anmeldedaten der Anwendung als Abhängigkeit für GKE aufgeführt. Es ist auch wichtig, die Dateien deploy.yaml und cloudbuild.yaml als Abhängigkeiten anzugeben, auch wenn sie mit dem Anwendungscode in der Versionskontrolle gespeichert sind, da sie die CI/CD-Pipeline für diese Anwendung definieren.
Der Notfallwiederherstellungsplan 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 Wiederherstellung der Tools neu erstellt wird.
Wenn diese Abhängigkeiten manipuliert werden, wird auch die Gesamtfunktion der Pipeline beeinträchtigt, selbst wenn die Tools selbst noch funktionieren.
Externe Abhängigkeiten
Externe Abhängigkeiten sind externe Systeme, die für die Funktion Ihrer Toolchain erforderlich sind und nicht direkt von Ihnen verwaltet werden. Externe Abhängigkeiten ergeben sich aus den von Ihnen ausgewählten Tools und Programmier-Frameworks. Sie können sich externe Abhängigkeiten als eine weitere Ebene unter den internen Abhängigkeiten vorstellen. Beispiele für externe Abhängigkeiten sind npm- oder Maven-Repositories und Monitoring-Dienste.
Externe Abhängigkeiten liegen zwar außerhalb Ihrer Kontrolle, Sie können sie aber in Ihr Notfallwiederherstellungskonzept einbeziehen. Im folgenden Diagramm wird die Beispiel-Java-Anwendung aktualisiert, indem neben den internen auch externe Abhängigkeiten berücksichtigt werden: Java-Bibliotheken in Maven Central und Docker-Images in Docker Hub. Die Java-Bibliotheken werden von Artifact Registry und die Docker-Images von Cloud Build verwendet.
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 ordnungsgemäß zu funktionieren. Dokumentieren Sie bei der Bewertung Ihrer eigenen Toolchain sowohl die externen Abhängigkeiten, auf die Ihre Tools zugreifen müssen, als auch die Verfahren zum 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 und ihre Wiederherstellungsverfahren aber trotzdem in den Notfallwiederherstellungsplan aufnehmen. Denken Sie beispielsweise an die Java-Bibliotheken in Maven. Auch wenn die Bibliotheken in einer externen Quelle gespeichert sind, können Sie einen Prozess einrichten, mit dem Java-Bibliotheken regelmäßig in ein lokales Maven-Repository oder in die Artifact Registry heruntergeladen und aktualisiert werden. So ist der 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 Sie beispielsweise als Abhängigkeiten zweiter Ordnung betrachten. Diese Abhängigkeiten zweiter Ordnung können eigene Abhängigkeiten haben, die Sie als Abhängigkeiten dritter Ordnung betrachten können. Möglicherweise müssen Sie sowohl externe Abhängigkeiten zweiter als auch dritter Ordnung in Ihrem Notfallplan 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 ihrer Auswirkung auf das Unternehmen auszurichten. So kann es beispielsweise weniger effizient sein, neue Versionen von Anwendungen über die CI-Phase zu erstellen, als Anwendungen über die CD-Phase bereitzustellen. Daher können Bereitstellungstools längere RTO- und RPO-Ziele haben als andere Funktionen.
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 ermitteln 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 hier aber enthalten, um ein vollständigeres Beispiel zu bieten.
Das Diagramm zeigt Quadranten, die auf dem Ausmaß der Auswirkungen auf Entwickler und die Betriebsabläufe basieren. Im Diagramm sind die Komponenten so positioniert:
- Moderate Auswirkungen auf Entwickler, geringe Auswirkungen auf die Betriebsabläufe: Testdatenquellen
- Moderate Auswirkungen auf Entwickler, moderate Auswirkungen auf die Betriebsabläufe: Cloud Key Management Service, Cloud KMS
- Moderate Auswirkungen auf Entwickler, hohe Auswirkungen auf die Betriebsabläufe: Bereitstellungspipeline
- Hohe Auswirkungen auf die Entwickler, geringe Auswirkungen auf die Betriebsabläufe: Innerer Entwicklungs-Loop
- Hohe Auswirkungen auf Entwickler, moderate Auswirkungen auf die Betriebsabläufe: CI-Pipeline, IaC-Pipeline (Infrastruktur als Code)
- Hohe Auswirkungen auf Entwickler und auf die Betriebsabläufe: SCM (Source Control Management), Artifact Registry
Komponenten wie die Verwaltung der Quellcodekontrolle und Artifact Registry, die einen hohen Einfluss auf Entwickler und die Betriebsabläufe haben, haben den größten Einfluss auf das Unternehmen. Diese Komponenten sollten die niedrigsten RTO- und RPO-Ziele haben. 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 so festgelegt werden, dass der Daten- oder Konfigurationsverlust im Vergleich zur Zeit, die für die Wiederherstellung des Dienstes für diese Komponente erforderlich ist, toleriert werden kann.
Sehen Sie sich beispielsweise die verschiedenen Speicherorte der Artifact Registry und der IaC-Pipeline in der Abbildung an. Ein Vergleich dieser beiden Tools zeigt, dass eine Störung der Artifact Registry größere Auswirkungen auf den Geschäftsbetrieb hat als eine Störung in der IaC-Pipeline. Da eine Auszeit der Artifact Registry sich erheblich auf die Möglichkeit auswirkt, Ihre Anwendung bereitzustellen oder automatisch zu skalieren, sind die RTO- und RPO-Ziele niedriger als bei anderen Tools. Im Gegensatz dazu zeigt das Diagramm, dass ein Ausfall der IaC-Pipeline weniger Auswirkungen auf den Geschäftsbetrieb hat als bei anderen Tools. Die IaC-Pipeline hätte dann höhere RTO- und RPO-Ziele, da Sie während eines Ausfalls andere Methoden zur Bereitstellung oder Aktualisierung der Infrastruktur verwenden können.
Eine allgemeine Strategie für die Betriebskontinuität auswählen
Prozesse zur Aufrechterhaltung der Geschäftskontinuität für Produktionsanwendungen basieren häufig auf einer der drei gängigen Notfallwiederherstellungsstrategien. Bei CI/CD können Sie jedoch zwischen zwei allgemeinen 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 Vor- und Nachteile in Bezug auf Komplexität und Kosten. Außerdem haben Sie unterschiedliche Anforderungen an Ihren CI/CD-Prozess. In den folgenden Abschnitten finden Sie weitere Informationen zu den einzelnen Strategien und ihren Vor- und Nachteilen.
Außerdem können sich Vorfälle, die den Dienst unterbrechen, nicht nur auf Ihre CI/CD-Implementierung auswirken. Sie sollten auch die gesamte erforderliche 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) sind Ihre Anwendungen und die passive CI/CD-Pipeline Spiegel. Die passive Pipeline verarbeitet jedoch keine Kundenarbeitslast und keinen Build oder keine Bereitstellung. Sie befindet sich daher in einem reduzierten Zustand. Diese Strategie eignet sich am besten für geschäftskritische Anwendungen, bei denen eine kurze Ausfallzeit toleriert werden kann.
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 Anwendungs-Toolchain vollständig in einer anderen Region.
In diesem Beispiel wird in Region 1 die aktive CI/CD-Pipeline gehostet und in Region 2 die passive. Der Code wird bei einem externen Git-Anbieter wie GitHub oder GitLab gehostet. Ein Repository-Ereignis (z. B. ein Zusammenführen aus einer Pull-Anfrage) kann die CI/CD-Pipeline in region1 auslösen, um die Anwendung in der mehrregionalen 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 „region2“ wechseln, die dann aktiv wird. Nachdem das Problem in Region 1 behoben wurde, können Sie die Pipeline in Region 1 passiv lassen.
Zu den Vorteilen der aktiven/passiven Strategie gehören:
- Geringe Ausfallzeit: Da die passive Pipeline bereitgestellt, aber herunterskaliert wurde, ist die Ausfallzeit auf die Zeit beschränkt, die zum Hochskalieren der Pipeline erforderlich ist.
- Konfigurationstoleranz für Datenverlust konfigurieren: Bei dieser Strategie müssen Konfiguration und Artefakt regelmäßig synchronisiert werden. Die Anzahl lässt sich jedoch an Ihre Anforderungen anpassen, was die Komplexität reduzieren kann.
Zu den Nachteilen dieser Strategie gehören:
- Kosten: Durch die duplizierte Infrastruktur steigen mit dieser Strategie die Gesamtkosten Ihrer CI/CD-Infrastruktur.
Sicherung/Wiederherstellung
Bei der Sicherungs-/Wiederherstellungsstrategie erstellen Sie die Failover-Pipeline nur bei Bedarf während der Notfallwiederherstellung. 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. Bei der Sicherungskonfiguration wird nur ein Teil der CI/CD-Pipeline der Anwendung in einer anderen Region dupliziert.
Ähnlich wie im vorherigen Beispiel wird die aktive CI/CD-Pipeline in region1 gehostet. Anstatt einer passiven Pipeline in region2 gibt es dort nur Back-ups der erforderlichen regionalen Daten, z. B. der Maven-Pakete und Container-Images. Wenn Sie Ihre Quellrepositories in Region 1 hosten, sollten Sie die Daten auch mit Ihren DR-Standorten synchronisieren.
Wenn in der Pipeline von Region 1 ein kritisches Problem 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 Ihr Automatisierungsskript aus dem Repository ausführen und die CI/CD-Pipeline in region2 neu erstellen.
Bei einem groß angelegten Ausfall müssen Sie möglicherweise mit anderen Kunden um Cloud-Ressourcen konkurrieren. Eine Möglichkeit, diese Situation zu vermeiden, besteht darin, mehrere Optionen für den Notfallwiederherstellungsort zu haben. Wenn sich die Pipeline „region1“ beispielsweise in us-east1 befindet, kann die Failover-Region us-east4, us-central1 oder us-west1 sein.
Vorteile der Sicherungs-/Wiederherstellungsstrategie:
- Kosten: Diese Strategie ist am kostengünstigsten, da Sie die Sicherungspipeline nur bei Notfallwiederherstellungsszenarien bereitstellen.
Zu den Nachteilen dieser Strategie gehören:
- Ausfallzeit: Die Implementierung dieser Strategie dauert länger, da Sie die Failover-Pipeline bei Bedarf erstellen. Anstatt eine vorkonfigurierte Pipeline zu haben, müssen die Dienste während der Wiederherstellung nach einem Vorfall erstellt und konfiguriert werden. Auch die Erstellungszeit von Artefakten und die Zeit zum Abrufen externer Abhängigkeiten kann deutlich länger sein.
Notfallwiederherstellungsplan dokumentieren und Best Practices implementieren
Nachdem Sie Ihre CI/CD-Toolchain kartiert, ihre Abhängigkeiten ermittelt und die RTO- und RPO-Ziele für kritische Funktionen festgelegt haben, besteht der nächste Schritt darin, alle relevanten Informationen in einem schriftlichen Notfallwiederherstellungsplan zu dokumentieren. Dokumentieren Sie beim Erstellen Ihres Notfallwiederherstellungsplans die Strategien, Prozesse und Verfahren zur Wiederherstellung jeder kritischen Funktion. Dieser Dokumentationsprozess umfasst die Erstellung von detaillierten Anleitungen für Mitarbeiter in bestimmten Rollen, die bei einer Störung befolgt werden müssen.
Nachdem Sie Ihr Notfallwiederherstellungskonzept definiert haben, stellen Sie Ihre CI/CD-Toolchain bereit oder aktualisieren sie anhand der Best Practices, um Ihre RTO- und RPO-Ziele zu erreichen. CI/CD-Toolchains können sehr unterschiedlich sein, aber unabhängig von der Toolchain sind zwei wichtige Muster für Best Practices üblich: ein umfassendes Verständnis von Abhängigkeiten und die Implementierung von Automatisierung.
In Bezug auf Abhängigkeiten beziehen sich die meisten Notfallpläne auf die Systeme, die sich direkt in Ihrer Kontrolle befinden. Denken Sie jedoch daran, dass externe Abhängigkeiten zweiter oder dritter Ordnung genauso schädlich sein können. 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 Back-up für diese Bibliotheken haben, können Sie Ihre Anwendung möglicherweise nicht erstellen, wenn die Verbindung zur externen Quelle, von der Sie die Bibliotheken abrufen, getrennt ist.
Bei der Automatisierung sollten Best Practices in Ihre IaC-Strategie für die Cloud einfließen. 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-Praktiken sind äußerst effektive Wiederherstellungsverfahren, da sie in die tägliche Funktionsweise Ihrer CI/CD-Pipelines eingebunden sind. Darüber hinaus fördert IaC das Speichern Ihrer Konfigurationsdateien in der Versionsverwaltung, was wiederum die Umsetzung der Best Practices für Sicherungen fördert.
Nachdem Sie Ihre Toolchain gemäß Ihrem Notfallwiederherstellungsplan und den Best Practices für Abhängigkeiten und Automatisierung implementiert haben, ändern sich möglicherweise Ihr CI/CD-Prozess und Ihre Wiederherstellungsstrategien. Dokumentieren Sie alle Änderungen an Wiederherstellungsstrategien, -prozessen und -verfahren, die sich aus der Überprüfung des Notfallwiederherstellungsplans und der Implementierung von Best Practices ergeben.
Fehlerszenarien testen und den Plan pflegen
Es ist wichtig, Ihr Notfallwiederherstellungskonzept regelmäßig zu überprüfen, zu testen und zu aktualisieren. Durch das Testen des Notfallwiederherstellungsplans 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 Wartungen die Durchführung des Notfallwiederherstellungsplans zum normalen Betrieb wird. Mit Google Cloud können Sie Wiederherstellungsszenarien besonders 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 der 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 Notfallwiederherstellungsplan durch: Sie können beispielsweise testen, ob Berechtigungen und Nutzerzugriff in der Notfallwiederherstellungsumgebung wie in der Produktionsumgebung funktionieren. Sie können Integrations- und Funktionstests in Ihrer DR-Umgebung durchführen. Sie können auch einen Test durchführen, bei dem Ihr üblicher Zugriffspfad auf Google Cloud nicht funktioniert.
Bei Google testen wir unsere Notfallpläne regelmäßig mit einem Verfahren namens DiRT (Disaster Recovery Testing). Mit diesen Tests kann Google die Auswirkungen und Automatisierung prüfen und nicht berücksichtigte Risiken aufdecken. Änderungen an der Automatisierung und dem Notfallwiederherstellungsplan, die implementiert werden müssen, sind ein wichtiger Ausgangspunkt für DiRT.
Best Practices
In diesem Abschnitt erfahren Sie, welche Best Practices Sie implementieren können, um Ihre RTO- und RPO-Ziele zu erreichen. Diese Best Practices gelten allgemein für die Wiederherstellung bei CI/CD und nicht für bestimmte Tools. Unabhängig von Ihrer Implementierung sollten Sie Ihr Notfallwiederherstellungskonzept regelmäßig testen, um sicherzustellen, dass Hochverfügbarkeit, RTO und RPO Ihren Anforderungen entsprechen. Wenn ein Vorfall oder Notfall eintritt, sollten Sie auch eine Retrospektive durchführen und Ihren Prozess analysieren, damit Sie ihn verbessern können.
Hochverfügbarkeit
Für jedes Tool sollten Sie Best Practices für die Hochverfügbarkeit implementieren. Wenn Sie Best Practices für Hochverfügbarkeit einhalten, können Sie proaktiver auf Fehler reagieren, da diese Praktiken den CI/CD-Prozess widerstandsfähiger gegen Fehler machen. Diese proaktiven Strategien sollten mit reaktiveren Kontrollen und Verfahren sowohl für die Wiederherstellung als auch für die Sicherung verwendet werden.
Im Folgenden finden Sie einige Best Practices für eine hohe Verfügbarkeit. Weitere Best Practices finden Sie jedoch in der detaillierten Dokumentation zu jedem Tool in Ihrer CI/CD:
- Verwaltete Dienste: Bei der Verwendung verwalteter Dienste wird die operative Verantwortung auf Google Cloud übertragen.
- Autoscaling: Verwenden Sie nach Möglichkeit Autoscaling. Ein wichtiger Aspekt des Autoscalings ist, dass Worker-Instanzen dynamisch erstellt werden, sodass ausgefallene Knoten automatisch wiederhergestellt werden.
- Globale und multiregionale Bereitstellungen: Verwenden Sie nach Möglichkeit globale und multiregionale Bereitstellungen anstelle einer regionalen Bereitstellung. Sie können Artifact Registry beispielsweise für den multiregionalen Speicher konfigurieren.
- Abhängigkeiten: Sie müssen alle Abhängigkeiten Ihrer Tools kennen und dafür sorgen, dass diese hoch verfügbar sind. Sie können beispielsweise alle Drittanbieterbibliotheken in Ihrer Artifact Registry im Cache speichern.
Sicherungsverfahren
Wenn Sie DR für CI/CD implementieren, eignen sich einige Tools und Prozesse besser für Sicherungs-/Wiederherstellungsstrategien. Eine umfassende Sicherungsstrategie ist der erste Schritt zu effektiven reaktiven Kontrollen. Mithilfe von Sicherungen können Sie Ihre CI/CD-Pipeline im Falle von böswilligen Handlungen oder Notfallszenarien mit minimaler Unterbrechung wiederherstellen.
Als Ausgangspunkt sollten Sie die folgenden drei Best Practices implementieren. Ausführlichere Best Practices für die Sicherung finden Sie jedoch in der Dokumentation zu jedem Tool in Ihrem CI/CD-Prozess.
- Versionsverwaltung: Speichern Sie Konfigurationsdateien und alles, was Sie codieren, z. B. Automatisierungsscripts und Richtlinien, in der Versionsverwaltung. Beispiele sind
cloudbuild.yaml- und Kubernetes-YAML-Dateien. - Redundanz: Es darf keinen Single Point of Failure beim Zugriff auf Secrets wie Passwörter, Zertifikate und API-Schlüssel geben. Beispiele für Praktiken, die vermieden werden 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, ob Ihre Sicherungen vollständig und korrekt sind. Mit verwalteten Diensten wie Backup for GKE lässt sich der Überprüfungsprozess 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 zu Fehlern führen können. Eine vollständige Liste der Abhängigkeiten sollte wie oben in diesem Dokument unter Daten und Abhängigkeiten ermitteln beschrieben angegeben 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, Auftragsentwicklung zu nutzen. Beim Anbietern von Anwendungspaketen oder -images werden Kopien davon in einem privaten Repository erstellt und gespeichert. Durch die Bereitstellung durch einen Anbieter entfällt die Abhängigkeit von externen Quellen für diese Pakete oder Images. Außerdem kann so verhindert werden, dass Malware in die Softwarelieferkette eingefügt wird.
Die Vorteile von Anbieter-Anwendungspaketen oder -Images:
- Sicherheit: Durch das Vendoring entfällt die Abhängigkeit von externen Quellen für Anwendungspakete oder -images, was dazu beitragen kann, Angriffe durch Einschleusung von Malware zu verhindern.
- Kontrolle: Wenn Organisationen ihre eigenen Pakete oder Images bereitstellen, haben sie mehr Kontrolle über die Quelle dieser Pakete und Images.
- Compliance: Die Auslagerung an einen Anbieter kann Unternehmen dabei helfen, Branchenvorschriften wie die Zertifizierung für das Cybersecurity Maturity Model einzuhalten.
Wenn Ihr Team sich für Anbieter-Anwendungspakete oder -Images entscheidet, gehen Sie so vor:
- Identifizieren Sie die Anwendungspakete oder -images, die bereitgestellt werden müssen.
- Erstellen Sie ein privates Repository zum Speichern der von Anbietern bereitgestellten Pakete oder Images.
- 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 vom Anbieter bereitgestellten Pakete oder Images nach Bedarf.
CI/CD-Pipelines rufen häufig Systeme von Drittanbietern auf, um Aktionen wie Scans auszuführen, Tickets zu erfassen oder Benachrichtigungen zu senden. In den meisten Fällen haben diese Systeme eigene Notfallwiederherstellungsstrategien, die implementiert werden sollten. In einigen Fällen haben sie jedoch möglicherweise keinen geeigneten Notfallwiederherstellungsplan. Diese Fälle sollten im Notfallwiederherstellungsplan klar dokumentiert werden. Sie müssen dann entscheiden, ob diese Phasen in der Pipeline aus Gründen der Verfügbarkeit übersprungen werden können oder ob es akzeptabel ist, eine Ausfallzeit für die CI/CD-Pipeline zu verursachen.
Monitoring und Benachrichtigungen
Ihre CI/CD-Systeme sind genau wie Ihre Produktionssysteme für Anwendungen. Daher müssen Sie auch Überwachungs- und Benachrichtigungstechniken für Ihre CI/CD-Tools implementieren. Als Best Practice empfehlen wir, Dashboards und Benachrichtigungen zu implementieren. Das Beispiel-Repository für das Cloud Monitoring auf GitHub enthält viele Beispiele für Dashboards und Benachrichtigungsrichtlinien.
Sie können auch zusätzliche Überwachungsebenen implementieren, z. B. Service Level Indicators (SLIs) und Service Level Objectives (SLOs). Diese Überwachungsebenen helfen Ihnen, den allgemeinen Zustand und die Leistung Ihrer CI/CD-Pipelines im Blick zu behalten. SLOs können beispielsweise implementiert werden, um die Latenz der Build- und Bereitstellungsphasen zu erfassen. Diese SLOs helfen Teams, Anwendungen in der gewünschten Geschwindigkeit und Häufigkeit zu entwickeln und zu veröffentlichen.
Verfahren für den Notfallzugriff
Bei einer Katastrophe müssen die Einsatzteams möglicherweise Maßnahmen außerhalb der Standardverfahren ergreifen und Notfallzugriff auf Systeme und Tools erhalten. Solche Notfallmaßnahmen werden manchmal als Breakglass-Verfahren bezeichnet. Als Ausgangspunkt sollten Sie die folgenden drei Best Practices implementieren:
- Sie haben einen klaren Eskalationsplan und -vorgehensweise. Ein klarer Plan hilft dem Einsatzteam zu wissen, wann es die Verfahren für den Notfallzugriff anwenden muss.
- Sorgen Sie dafür, dass mehrere Personen Zugriff auf wichtige Informationen wie Konfigurations- und Geheimdaten haben.
- Entwickeln Sie automatisierte Prüfmethoden, damit Sie nachvollziehen können, wann und von wem Verfahren für den Notfallzugriff verwendet wurden.
Nächste Schritte
- Weitere Informationen zu den in diesem Dokument verwendeten Google Cloud-Produkten:
- Leitfaden zur Planung der Notfallwiederherstellung
- Weitere Google Cloud-Features können Sie in unseren Anleitungen ausprobieren.
- 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