Sie schlafen gern und haben gern Wochenenden. Kunden hassen es, wegen Wartungsarbeiten den Zugriff auf Ihr System zu verlieren. PagerDuty -Betriebsingenieur Doug Barth hat die Lösung:

Verzichten Sie gänzlich auf planmäßige Wartungsarbeiten.

Das klingt nach einem mutigen Vorschlag. Aber Doug erklärte bei den DevOps Days Chicago , es macht tatsächlich viel Sinn.

Geplante Wartung findet meist spät am Wochenende statt – eine schwierige Aufgabe für Betriebsingenieure und Administratoren. Kunden benötigen rund um die Uhr Zugriff, nicht nur tagsüber. Und geplante Wartung bedeutet, dass Ihr System weniger zuverlässig ist als Sie denken, weil Sie Angst haben, es während des Arbeitstags zu ändern.

Die Lösung? Vermeiden Sie es vollständig und ersetzen Sie es durch schnelle, iterative Wartungsstrategien, die Ihr gesamtes System nicht gefährden.

Das klingt vielleicht ein bisschen abwegig. Aber die Verschiebung geplanter Wartungsarbeiten ist einfacher als Sie denken. In seinem Vortrag präsentierte Doug vier Möglichkeiten, dies zu tun.

Stufenweise Bereitstellung

Das Wichtigste zuerst: Wenn Sie die geplante Wartung verwerfen, müssen Ihre Bereitstellungen absolut zuverlässig sein. Sie sollten skriptbasiert, schnell und schnell rückgängig gemacht werden und regelmäßig getestet werden, um sicherzustellen, dass Rollbacks nicht verzögert werden.

Sie müssen außerdem mit einer Version vorwärts- und rückwärtskompatibel sein. Es ist keine Option, die Druckmaschinen anzuhalten, wenn Sie eine neue Version herausbringen. Rot-Blau-Grün-Bereitstellungen sind hier von entscheidender Bedeutung, da sie sicherstellen, dass zu einem bestimmten Zeitpunkt nur ein Drittel Ihrer Infrastruktur geändert wird.

Und schließlich müssen zustandslose Apps die Norm sein. Sie sollten in der Lage sein, eine App neu zu starten, ohne dass dies Auswirkungen auf den Kunden hat (wie erzwungene Abmeldungen oder verlorene Einkaufswagen).

Schicken Sie Kanarienvögel in die Kohlenmine

Verwenden Sie Canary Deployments mit Bedacht, um Rollouts zu testen, ihre Integrität zu beurteilen und Ergebnisse zu vergleichen. Diese Testbereitstellungen betreffen nur einen kleinen Teil Ihres Systems, sodass fehlerhafter Code oder ein unerwarteter Fehler nicht das Ende für Ihren gesamten Dienst bedeuten.

Doug schlug einige praktische Möglichkeiten vor, um dies zu erreichen:

• Gate-Funktionen, sodass Sie Code im Dunkeln veröffentlichen und neue Funktionen langsam auf eine Teilmenge von Kunden anwenden können.

• Suchen Sie nach Möglichkeiten, den Datenverkehr langsam von einem System auf ein anderes zu übertragen, um das Risiko einer Fehlkonfiguration oder einer kalten Infrastruktur zu verringern.

• Führen Sie nebenbei kritischen Pfadcode aus. Führen Sie ihn aus und protokollieren Sie Fehler, aber verlassen Sie sich nicht sofort darauf.

Doug brachte es für das Publikum der DevOps Days auf den Punkt: „Vermeiden Sie messerscharfe Änderungen wie die Pest.“

Machen Sie Wiederholungsversuche zu Ihrem neuen besten Freund

Ihr System sollte mit Wiederholungsversuchen belastet sein. Bauen Sie sie in alle Service-Layer-Hops ein und verwenden Sie exponentielle Backoffs, um eine Überlastung des Downstream-Systems zu vermeiden. Die Anfragen zwischen den Service-Layern müssen idempotent sein, betonte Doug. Wenn dies der Fall ist, können Sie Anfragen an neue Server erneut senden, ohne Änderungen doppelt anzuwenden.

Verwenden Sie Warteschlangen, bei denen Sie sich nicht um die Antwort kümmern, um den Client vom Server zu entkoppeln. Wenn Sie bei einem Anfrage-/Antwortfluss nicht weiterkommen, verwenden Sie einen Circuit-Breaker-Ansatz, bei dem Ihre Client-Bibliothek minimale Ergebnisse zurückgibt, wenn ein Dienst ausfällt. Dadurch werden Latenz und Fehler am Front-End reduziert.

Legen Sie nicht alle Eier in einen Korb

Verteilen Sie Ihre Daten auf viele Server, sodass kein Server so wichtig ist, dass Sie nicht sicher darauf arbeiten können.

Bei PagerDuty verwendet das Team Multi-Master-Cluster, die bei Betrieb und vertikaler Skalierung helfen. Außerdem werden mehrere Datenbankserver wie Cassandra verwendet: Kein Server ist so speziell, dass die operative Arbeit tagsüber erfolgen kann.

Zusammengenommen verhelfen diese Strategien Administratoren und Betriebsingenieuren zu mehr Schlaf, weniger Sorgen und einer besseren Wartung – und das alles vorzeitig.

Fragen? Teilen Sie Ihre Gedanken in den Kommentaren unten.