In diesem Dokument des Google Cloud-Architektur-Frameworks finden Sie Best Practices zum zuverlässigen Ausführen Ihres Dienstes, z. B. zum Bereitstellen von Aktualisierungen, zum Ausführen von Diensten in Produktionsumgebungen und zu Problemtests. Eine Architektur, die auf Zuverlässigkeit achtet, sollte den gesamten Lebenszyklus des Dienstes abdecken und nicht nur das Softwaredesign.
Geeignete Namen für Anwendungen und Dienste auswählen
Vermeiden Sie die Verwendung interner Codenamen in Produktionskonfigurationsdateien, da sie verwirrend sein können, insbesondere für neuere Mitarbeiter, wodurch die Zeit zur Problemminderung (TTM) bei Ausfällen möglicherweise länger wird. Wählen Sie nach Möglichkeit gute Namen für alle Ihre Anwendungen, Dienste und wichtigen Systemressourcen wie VMs, Cluster und Datenbankinstanzen, wobei die jeweiligen Längenbeschränkungen gelten. Ein guter Name beschreibt den Zweck der Entität. Er ist präzise, spezifisch und unverwechselbar; und ist für jeden verständlich, der ihn sieht. Ein guter Name hat keine Akronyme, Codenamen, Abkürzungen und potenziell anstößige Terminologie. Außerdem verursacht er keine negative öffentliche Reaktion, wenn er extern veröffentlicht wird.
Schrittweise Rollouts mit Canary-Tests implementieren
Sofortige globale Änderungen an Dienstbinärdateien oder -konfigurationen sind mit Risiken verbunden. Führen Sie neue Versionen ausführbarer Dateien und Konfigurationsänderungen schrittweise ein. Beginnen Sie mit einem kleinen Bereich, z. B. einigen VM-Instanzen in einer Zone, und erweitern Sie dann den Bereich schrittweise. Es kann schnell ein Rollback durchgeführt werden, wenn die Änderung nicht Ihren Erwartungen entspricht oder die Nutzer in jeder Phase der Einführung negativ beeinflusst. Ihr Ziel ist es, Programmfehler zu erkennen und zu beheben, wenn sie nur einen kleinen Teil des Nutzertraffics betreffen, bevor Sie die Änderung global einführen.
Richten Sie ein Canary-Testsystem ein, das Dienständerungen erkennt und einen A/B-Vergleich der Messwerte der geänderten Server mit den verbleibenden Servern durchführt. Das System sollte unerwartetes oder ungewöhnliches Verhalten melden. Wenn die Änderung nicht wie erwartet funktioniert, sollte das Canary-Testsystem Rollouts automatisch anhalten. Probleme können offensichtlich sein, z. B. Nutzerfehler, oder geringfügig, wie die Erhöhung der CPU-Auslastung oder ein überhöhtes Speichervolumen.
Es ist besser, beim ersten Hinweis auf ein Problem zu stoppen, ein Rollback durchzuführen und die Probleme ohne die bei einem Ausfall unvermeidliche Eile zu diagnostizieren. Nachdem die Änderung den Canary-Test bestanden hat, geben Sie sie nach und nach an größere Bereiche weiter, z. B. erst an eine gesamte Zone und dann an eine weitere Zone. Warten Sie, während das geänderte System immer größere Mengen an Nutzertraffic verarbeitet, um eventuell latente Probleme zu erkennen.
Weitere Informationen finden Sie unter Strategien für Bereitstellung und Tests von Anwendungen.
Traffic für zeitlich begrenzte Werbeaktionen und Markteinführungen verteilen
Möglicherweise gibt es Werbeaktionen, z. B. Rabatte, die zu einem bestimmten Zeitpunkt beginnen und viele Nutzer gleichzeitig dazu anregen, sich mit dem Dienst zu verbinden. Falls ja, entwerfen Sie Clientcode, um den Traffic über einige Sekunden zu verteilen. Verwenden Sie zufällige Verzögerungen, bevor sie Anfragen initiieren.
Sie können das System auch vorwärmen. Wenn Sie das System vorwärmen, senden Sie das voraussichtlich erwartete Volumen an Nutzertraffic im Voraus, um zu prüfen, ob die Leistung Ihren Erwartungen entspricht. Durch ein solches Design werden plötzlich auftretende Trafficspitzen verhindert, die Ihre Server zum geplanten Beginn zum Absturz bringen könnten.
Erstellung, Test und Bereitstellung automatisieren
Verringern Sie den manuellen Aufwand Ihres Releaseprozesses durch die Verwendung von Continuous Integration- und Continuous Delivery-Pipelines (CI/CD). Führen Sie automatisierte Integrationstests und Bereitstellungen durch. Erstellen Sie beispielsweise einen modernen CI-/CD-Prozess mit GKE.
Weitere Informationen finden Sie unter Continuous Integration, Continuous Delivery, Testautomatisierung und Bereitstellungsautomatisierung.
Schutz vor Operatorfehlern implementieren
Entwickeln Sie Ihre Betriebstools, um potenziell ungültige Konfigurationen abzulehnen. Erkennen und benachrichtigen, wenn eine Konfigurationsversion leer, teilweise oder gekürzt, beschädigt, logisch falsch oder unerwartet ist oder nicht innerhalb der erwarteten Zeit empfangen wird. Tools sollten auch Konfigurationsversionen ablehnen, die sich zu stark von der vorherigen Version unterscheiden.
Vermeide Änderungen oder Befehle mit einem zu umfassenden Bereich, die potenziell destruktiv sein können. Diese allgemeinen Befehle können "Berechtigungen für alle Nutzer widerrufen", "Alle VMs in dieser Region neu starten" oder "Alle Laufwerke in dieser Zone neu formatieren" sein. Änderungen sollten nur angewendet werden, wenn der Operator beim Bereitstellen der Konfiguration Befehlszeilen-Flags oder Optionseinstellungen zur Notfall-Überschreibung hinzugefügt hat.
Die Tools müssen die mögliche Wirkungen riskanter Befehle darstellen, z. B. die Anzahl der VMs, auf die sich die Änderungen auswirken. Weiter muss eine explizite Bestätigung des Operators nötig sein, bevor das Tool fortgesetzt wird. Um wichtige Ressourcen zu sperren und deren versehentliches oder nicht autorisiertes Löschen zu verhindern können Sie Funktionen wie das Sperren von Cloud Storage-Aufbewahrungsrichtlinien nutzen.
Test auf Wiederherstellung nach Fehlern
Testen Sie Ihre betrieblichen Abläufe zur Wiederherstellung nach Dienstausfällen regelmäßig. Ohne regelmäßige Tests greifen Ihre Abläufe möglicherweise nicht, sollten Sie sie benötigen, wenn ein echter Fehler auftritt. Zu den Elementen, die regelmäßig getestet werden sollten, gehören der regionale Failover, das Rollback eines Releases und die Wiederherstellung von Daten aus Back-ups.
Notfallwiederherstellungstests anwenden
Wie bei Tests zur Wiederherstellung nach Fehlern sollten Sie hier nicht darauf warten, bis eine Katastrophe passiert. Testen und prüfen Sie Ihre Abläufe und Prozesse zur Notfallwiederherstellung regelmäßig.
Vielleicht erstellen Sie eine Systemarchitektur, um Hochverfügbarkeit bereitzustellen. Eine solche Architektur überschneidet sich nicht vollständig mit der Notfallwiederherstellung (DR, Disaster Recovery), muss aber häufig in Überlegungen zu RTO- (Recovery Time Objective) und RPO-Werten (Recovery Point Objective) einbezogen werden.
HA hilft Ihnen dabei, eine vereinbarte Betriebsleistung zu erreichen oder zu übertreffen, z. B. die Betriebszeit. Wenn Sie Produktionsarbeitslasten in Google Cloud ausführen, können Sie eine passive oder aktive Standby-Instanz in einer zweiten Region bereitstellen. Bei dieser Architektur stellt die Anwendung weiterhin Dienste aus der nicht betroffenen Region bereit, wenn es in der primären Region eine Katastrophe gibt. Weitere Informationen finden Sie unter Architektur der Notfallwiederherstellung bei Cloudausfällen.
Chaos Engineering üben
Erwägen Sie den Einsatz von Chaos Engineering in Testpraktiken. Führen Sie in einer sicheren Umgebung tatsächliche Fehler in verschiedene Komponenten von Produktionssystemen unter Last ein. Dieser Ansatz hilft, allgemeinen Systemauswirkungen vorzubeugen, da Ihr Dienst Fehler auf jeder Ebene ordnungsgemäß verarbeitet.
In das System eingeschleuste Probleme können Absturzaufgaben, Fehler und Zeitüberschreitungen bei RPCs und eine Reduzierung der Ressourcenverfügbarkeit umfassen. Verwenden Sie zufällige Fehlerinjektionen, um zeitweise Probleme (flapping) in Dienstabhängigkeiten zu testen. Solches Verhalten ist in der Produktion schwer zu erkennen und zu minimieren.
Chaos Engineering sorgt dafür, dass die Auswirkungen solcher Experimente minimiert und beschränkte bleiben. Behandeln Sie solche Tests als Praxis für tatsächliche Ausfälle und nutzen Sie alle erfassten Informationen, um Ihre Ausfallreaktion zu verbessern.
Nächste Schritte
- Effiziente Benachrichtigungen erstellen (nächstes Dokument in dieser Reihe)
Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Systemdesign, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance