Der Blog

So vermeiden Sie planmäßige Wartungsarbeiten

von Julie Arsenault 19. November 2014 | 3 Minuten Lesezeit

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

Verzichten Sie vollständig auf planmäßige Wartungsarbeiten.

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

Geplante Wartung Die Wartung findet meist spät am Wochenende statt – eine Herausforderung für Betriebsingenieure und Administratoren. Kunden benötigen rund um die Uhr Zugriff, nicht nur tagsüber. Und planmäßige Wartungen bedeuten, dass Ihr System weniger zuverlässig ist als gedacht, weil Sie Angst haben, es während der Arbeitszeit 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 etwas abwegig. Aber die Verschiebung geplanter Wartungsarbeiten ist einfacher als Sie denken. Doug stellte in seinem Vortrag vier Möglichkeiten vor.

Stufenweise Bereitstellung

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

Sie müssen außerdem vorwärts- und rückwärtskompatibel zu einer Version sein. Ein Stillstand bei der Veröffentlichung einer neuen Version ist keine Option. Rot-Blau-Grün-Bereitstellungen sind hier entscheidend, da sie sicherstellen, dass immer nur ein Drittel Ihrer Infrastruktur Änderungen unterliegt.

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

Setzen Sie Canary Deployments mit Bedacht ein, 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 zu einer Katastrophe für Ihren gesamten Dienst führt.

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

  • Gate-Funktionen, sodass Sie Code im Dunkeln veröffentlichen und neue Funktionen langsam auf eine Teilmenge der 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 den Code für den kritischen Pfad nebenher 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. Integrieren Sie diese in alle Service-Layer-Hops und verwenden Sie exponentielle Backoffs, um eine Überlastung des nachgelagerten 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 die Antwort keine Rolle spielt, um den Client vom Server zu entkoppeln. Wenn Sie mit einem Anfrage-/Antwort-Flow nicht weiterkommen, verwenden Sie einen Circuit-Breaker-Ansatz. Dabei liefert Ihre Client-Bibliothek bei einem Dienstausfall nur minimale Ergebnisse zurück. Das reduziert die Latenz und Fehler im Front-End.

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 nutzt das Team Multi-Master-Cluster, die den Betrieb und die vertikale Skalierung unterstützen. Außerdem werden mehrere Datenbankserver wie Cassandra eingesetzt: Kein Server ist speziell, sodass die operative Arbeit tagsüber erledigt werden kann.

Zusammengenommen helfen diese Strategien Administratoren und Betriebsingenieuren, mehr zu schlafen, sich weniger Sorgen zu machen und die Wartung zu verbessern – und das alles vorzeitig.

Fragen? Teilen Sie Ihre Gedanken in den Kommentaren unten.