Irgendwelche Ideen, wie man eine Wartung auf einer Site durchführt, die immer in Gebrauch ist?

Ich helfe mit einer großen Spieleseite in Australien. Wir veranstalten Wettbewerbe von 7 Uhr Ortszeit bis 1 Uhr am nächsten Tag, jeden Tag der Woche. Wir haben keinen Tag übersprungen, seit die Website veröffentlicht wurde. Dies macht die Wartung natürlich extrem schwierig, und wir stellen fest, dass unser Staging-Server bis zu 50 Commits vor unserer Produktionsbranche liegt. Normalerweise muss der Hauptentwickler sehr früh aufstehen, um die Zweige zusammenzuführen und sicherzustellen, dass alles ordnungsgemäß funktioniert.

Wir haben versucht, unseren Staging-Standort so ähnlich wie möglich zum Produktionsstandort zu machen, aber wir können ihn nur so ähnlich gestalten.

Unsere Site basiert auf Laravel mit einem Node.JS-Server für Echtzeit. Wir benutzen Laravel Forge.

Hat jemand Vorschläge, wie wir Updates häufiger pushen könnten? Wir sind offen für alles.

Es gibt eine Menge Dinge, die Sie tun können, um Ihren Bereitstellungsprozess zu verbessern. Einige davon sind:

• Stellen Sie sicher, dass Ihr Code gut getestet ist.

  Idealerweise sollten Sie für jedes denkbare Szenario eine 100% ige Einheitentestabdeckung sowie Integrationstests haben.

  Wenn Sie das nicht haben, sollten Sie wahrscheinlich alles fallen lassen und sich darum kümmern.

  Betrachten Sie die verhaltensorientierte Entwicklung.

  Mit einer vollständigen Testsuite können Sie ...

• Führen Sie eine kontinuierliche Integration durch.

  Immer wenn jemand eine Änderung festschreibt, kann CI die Testsuite automatisch darauf ausführen. Wenn die Testsuite erfolgreich ist, kann sie sofort bereitgestellt werden (oder eine Bereitstellung planen). Bei Änderungen, die keine wesentlichen Änderungen an Ihren Datenbanken erfordern, sparen Sie allein dadurch viel Zeit und Kopfschmerzen.

  Im Falle eines Problems kann CI Ihnen auch ein Rollback mit einem Klick ermöglichen.

  CI ist viel weniger nützlich , wenn Ihre Testsuite nicht vollständig und richtig ist , da die gesamte Prämisse ruht auf in der Lage, Ihren Code in einer automatisierten Art und Weise zu validieren.

• Machen Sie atomare Updates.

  Im Idealfall sollten Sie nicht nur neue Dateien über die alten auf dem Produktionsserver kopieren. Verwenden Sie stattdessen ein Tool wie capistrano, mit dem jede Datei an einen neuen Speicherort kopiert und anschließend über einen symbolischen Link auf die gewünschte Bereitstellung verwiesen wird. Das Zurücksetzen erfolgt sofort, da der Symlink einfach so geändert wird, dass er auf die vorherige Bereitstellung verweist. (Dies gilt jedoch nicht unbedingt für Ihre Datenbankmigration.)

  Prüfen Sie auch, ob Container wie Docker Ihnen helfen können.

• Nehmen Sie kleinere und häufigere Änderungen vor.

  Ganz gleich, ob Sie Tests, CI oder nichts haben, dies allein kann Ihnen erheblich helfen. Jede Änderung sollte einen eigenen Git-Zweig haben, und eine Bereitstellung sollte so wenig Änderungen wie möglich enthalten. Da die Änderungen kleiner sind, kann bei einer Bereitstellung möglicherweise weniger schief gehen.

  In diesem Sinne sollten Sie Änderungen nach Möglichkeit stärker isolieren. Wenn Sie das Omaha-Spiel geändert haben und es keine Auswirkungen auf Texas Hold'em, 5 Card Stud oder etwas anderes hat, ist dies das einzige Spiel, das für eine Wartung gesperrt werden muss.

• Analysieren Sie alles, was auf lange Sicht läuft.

  Sie haben erwähnt, dass einige Teile Ihrer Bereitstellungen sehr lange dauern. Dies ist wahrscheinlich eine Änderung des Datenbankschemas. Es lohnt sich, zusammen mit jeder Schemaänderung einen DBA-Blick auf Ihre Datenbank zu werfen, um festzustellen, welche Leistung besser sein kann.

  Lassen Sie einen Fachexperten einen Blick auf jeden anderen Teil einer Bereitstellung werfen, der viel Zeit in Anspruch nimmt.

• Arbeite ungerade Stunden.

  Möglicherweise tun Sie dies bereits, aber es muss erwähnt werden. Von Entwicklern (und Sysadmins!) Sollte nicht mehr erwartet werden, dass sie "9 bis 5" arbeiten, insbesondere für einen 24x7-Betrieb. Wenn erwartet wird, dass jemand die Nachtstunden damit verbringt, einen Einsatz zu babysitten, Probleme zu beheben und dann einen Tagesplan einzuhalten, sind Ihre Erwartungen unrealistisch und Sie bereiten diese Person auf Burnout vor.

Anscheinend haben Sie jeden Tag von 01:00 bis 07:00 Uhr ein Wartungsfenster, bei dem es nicht um Zeit, sondern um Bequemlichkeit geht. Dies ist normal und viele Leute beschäftigen sich nur als Teil des Geschäfts.

Sie könnten zwei (oder mehr) Back-End-Systeme mit einem Front-End haben, das den Datenverkehr zu demjenigen leitet, der gerade aktiv ist. Wenn Sie mit dem Release zufrieden sind, weisen Sie das Front-End an, auf das neue System umzusteigen. Dies sollte einfach zu skripten sein und eine kurze Zeit in Anspruch nehmen.

Jetzt haben Sie die Wahl, entweder das alte System so zu belassen, wie es ist, damit Sie es zurücksetzen können, oder es auf den neuesten Stand zu bringen, damit es als Ersatz für das Live-System verwendet werden kann, bis es Zeit ist, die nächsten Updates zu erstellen / zu testen.

Ändern der anderen Antworten: Sie sollten dem blau-grünen Bereitstellungsmodell folgen . Wenn Sie eine neue Version veröffentlichen möchten, stellen Sie diese auf einer internen Staging-Website bereit. Anschließend können Sie automatisierte Tests auf der Produktionssite der nächsten Version ausführen. Wenn die Tests abgeschlossen sind, weisen Sie den Load Balancer an, die neue Website zu verwenden.

Dies hilft auf folgende Weise:

1. Schwerwiegende Probleme treten immer ohne Ausfallzeiten auf.
2. Das Wechseln zu einer neuen Version hat keine Ausfallzeit, da die neue Version bereits gestartet und aufgewärmt ist.
3. Sie können jederzeit zur alten Version zurückkehren, da diese noch physisch ausgeführt wird.

Alle anderen Probleme, die Sie und andere angesprochen haben, werden weniger schwerwiegend, wenn Sie jederzeit stressfrei bereitstellen können. Das blau-grüne Bereitstellungsmodell ist eine vollständige Lösung für Bereitstellungsprobleme.

Was tun Sie, wenn Ihr Hauptrechenzentrum ausfällt, was von Zeit zu Zeit in allen Rechenzentren der Fall ist? Möglicherweise akzeptieren Sie die Ausfallzeit, führen ein Failover zu einem anderen Rechenzentrum durch, führen einen Aktiv / Aktiv-Modus in mehreren Rechenzentren durch oder haben einen anderen Plan. Was auch immer es ist, tun Sie es, wenn Sie Releases durchführen, und dann können Sie Ihr Haupt-Rechenzentrum während eines Releases herunterfahren. Wenn Sie Ausfallzeiten haben, wenn Ihr Rechenzentrum ausfällt, sind Sie auf Ausfallzeiten vorbereitet, sodass dies während einer Veröffentlichung kein Problem darstellen sollte.

So ergänzen Sie die vorherigen Antworten:

• Verwenden Sie eine Bereitstellungsstrategie, die Rollbacks und sofortiges Umschalten ermöglicht. Capistrano oder so ziemlich jedes andere Bereitstellungssystem hilft dabei. Sie können beispielsweise Datenbank-Snapshots und Code-Symlinks verwenden, um schnell zu einem früheren Status zurückzukehren.

• Verwenden Sie die vollständige Konfigurationsverwaltung, und lassen Sie nichts manuell verwaltet. Systeme wie SaltStack, Ansible und Puppet sind Beispiele. Sie können auch auf Docker-Containerkonfigurationen und Vagabundkisten angewendet werden.

• Verwenden Sie HA, um sicherzustellen, dass Sie beim Upgrade eines Knotens Anforderungen übergeben können. Wenn das Upgrade fehlschlägt, fahren Sie den Knoten einfach herunter. Wenn das Rollback durchgeführt wird, rufen Sie ihn erneut auf, und Ihre HA-Lösung stellt fest, dass Anforderungen erneut an den Knoten gesendet werden. HAProxy ist ein Beispiel, aber Nginx funktioniert genauso gut.

• Stellen Sie sicher, dass die Anwendung gleichzeitige Instanzen verarbeiten kann und zentrale versionierte Datenrepositorys für Nicht-Code-Daten verwendet, die auf der Festplatte gespeichert werden müssen, z. B. Cache. Auf diese Weise haben Sie nie eine aktualisierte Anwendung, in der Dateien einer anderen Version zwischengespeichert werden. Dies würde natürlich zusätzlich zum Löschen der Caches und zum Aufwärmen der Caches erfolgen. (Das Caching-Ding ist nur ein Beispiel)

Normalerweise richte ich Workflows ein, in denen Teammanager Zusammenführungsanforderungen für einen speziellen Zweig genehmigen können, der alle normalen CI-Aufgaben erledigt, aber als zusätzlicher letzter Schritt auch die Übertragung auf Produktionsknoten beginnt. Grundsätzlich führen Sie eine manuelle CI-Bereitstellung für eine Produktionsinstanz aus. Wenn diese Instanz keine ungültigen Antworten generiert, Ihre Daten beschädigt oder verrückte Dinge ausführt, führen Sie ein Massen-Upgrade aller Knoten mit der CI-Lösung Ihrer Wahl durch. Auf diese Weise wissen Sie, wenn eine Bereitstellung funktioniert, dass alle Bereitstellungen für ein bestimmtes Tag / Commit funktionieren.

Momentan klingt es so, als würden Sie eine Produktionsanwendung auf einem einzelnen Knoten mit einem Bereitstellungsprozess, einer Quelle und einem Ziel ausführen. Praktisch bedeutet dies, dass jeder einzelne Schritt in diesem Workflow eine Fehlerquelle darstellt, die die Website von sich aus beschädigen kann. Es ist die Basis aller CI-, HA- und Failover-Prozesse, sicherzustellen, dass so etwas nicht passieren kann. Führen Sie nicht nur einen Knoten aus, führen Sie nicht nur einen HA-Prozess aus, führen Sie nicht nur eine IP-Adresse aus, führen Sie nicht nur eine CDN aus usw. Es mag teuer klingen, aber Sie müssen ein Duplikat dessen erstellen, was Sie bereits haben Ein Rack auf einem Server mit eigener Verbindung kostet normalerweise weniger als eine Stunde Ausfallzeit auf einer Unternehmens-Site.

In allen seinen Punkten stimme ich Michael zu ( /server//a/739449/309477 ).

Meiner Meinung nach ist die erste Verbesserung, die Sie vornehmen sollten, die Verwendung eines Bereitstellungstools (Capistrano).

Sie können es problemlos bereitstellen und dann sofort auf die neuere Version wechseln. Wenn etwas schief geht, können Sie sofort zur Arbeitsversion zurückkehren, indem Sie einfach den aktuellen Symlink in eine Arbeitsversion ändern.

Und Capistrano ist ziemlich schnell im Umgang (im Vergleich zu Tests und CI, die eine größere Zeitinvestition bedeuten).

Zweitens, wenn Geld nicht Ihr Hauptproblem ist, sollten Sie einen ISO-Produktentwicklungsserver haben, um Ihre App zu testen, bevor Sie sie in der Produktion bereitstellen. Verwenden Sie eine industrielle Lösung (Ansible, Chef, Puppet), um VPS-Instanzen zu verwalten.