Frage Haben Sie Ideen, wie Sie die Wartung auf einer Website ausführen können, die immer verwendet wird?


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

Wir haben versucht, unseren Aufstellungsort so ähnlich wie möglich zum Produktionsstandort zu machen, aber wir können es nur so ähnlich machen.

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

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


18
2017-11-28 06:39


Ursprung


Warum dauert eine Bereitstellung so lange? - Michael Hampton♦
@MichaelHampton Unsere Bereitstellungen dauern nicht lange, es ist nur so, dass wir uns die Ausfallzeiten nicht leisten können, wenn etwas schief läuft. - cheese5505
Ich denke, die Frage ist also: Warum dauert ein Rollback so lange? - Michael Hampton♦
@MichaelHampton haben wir Rollbacks nicht richtig angeschaut, aber manchmal machen wir große Updates, die die Seite für zu lange dauern werden. - cheese5505
Was auch immer die großen Zeitblöcke nimmt, das ist es, was Sie sehen müssen. - Michael Hampton♦


Antworten:


Es gibt viele Dinge, die Sie tun könnten, um Ihren Bereitstellungsprozess zu verbessern. Einige von ihnen sind:

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

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

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

    Untersuchen Sie verhaltensorientierte Entwicklung.

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

  • Führen Sie eine kontinuierliche Integration durch.

    Wann immer jemand eine Änderung vornimmt, kann CI dann automatisch führe die Testsuite darauf aus. Wenn die Testsuite besteht, kann sie sofort bereitgestellt werden (oder eine Bereitstellung planen). Bei Änderungen, die keine wesentlichen Änderungen an Ihren Datenbanken erfordern, sparen Sie dadurch viel Zeit und Kopfzerbrechen.

    Im Falle eines Problems kann CI Ihnen auch einen Rollback mit einem Klick geben.

    CI ist viel weniger nützlich, wenn Ihre Testsuite nicht vollständig und korrekt ist, da die gesamte Prämisse auf der automatischen Validierung Ihres Codes beruht.

  • Machen Sie atomare Updates.

    Idealerweise sollten Sie nicht einfach neue Dateien über die alten auf dem Produktionsserver kopieren. Verwenden Sie stattdessen ein Tool wie capistrano, das jede Datei an einen neuen Speicherort kopiert und anschließend mithilfe einer symbolischen Verknüpfung auf die gewünschte Bereitstellung verweist. Das Zurücksetzen erfolgt sofort, da der Symlink einfach so geändert wird, dass er auf die vorherige Bereitstellung verweist. (Dies umfasst jedoch nicht unbedingt die Datenbankmigration.)

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

  • Machen Sie kleinere, häufigere Änderungen.

    Ob Sie Tests, CI oder nichts haben, allein dies kann Ihnen erheblich helfen. Jede Änderung sollte eine eigene Git-Verzweigung aufweisen und eine Bereitstellung sollte so wenig wie möglich geändert werden. Da Änderungen kleiner sind, ist bei einer Bereitstellung möglicherweise weniger Fehler möglich.

    In diesem Sinne sollten Sie die Änderungen möglichst isoliert durchführen. Wenn Sie eine Änderung am Omaha-Spiel vorgenommen haben und dies keinen Einfluss auf Texas Hold'em, 5 Card Stud oder etwas anderes hat, dann ist dies das einzige Spiel, das für eine Wartung gesperrt werden muss.

  • Analysiere alles, was lange läuft.

    Sie haben erwähnt, dass einige Teile Ihrer Bereitstellungen sehr lange dauern. Das ist wahrscheinlich Änderungen des Datenbankschemas Es lohnt sich, einen DBA mit jeder Schemaänderung in Ihrer Datenbank zu suchen, um zu sehen, was besser funktioniert.

    Lassen Sie einen Fachexperten jeden anderen Teil einer Bereitstellung betrachten, der große Zeitblöcke in Anspruch nimmt.

  • Arbeite ungerade Stunden.

    Vielleicht machst du das bereits, aber es erwähnt. Von Entwicklern (und Sysadmins!) Sollte nicht erwartet werden, dass sie "9 zu 5" mehr arbeiten, besonders für eine 24x7-Operation. Wenn von jemandem erwartet wird, dass er die nächtlichen Stunden damit verbringt, eine Bereitstellung zu babysitten, Probleme zu beheben und dann einen Tagesplan einzuhalten, sind Ihre Erwartungen unrealistisch, und Sie stellen diese Person für Burnout ein.


22
2017-11-28 07:55



Die einfachste Lösung besteht darin, das Deployment-Scripting in einem Tool wie Capistrano zu verwenden und vielleicht sogar Lastenausgleich durchzuführen. - JakeGould
Danke für den Hinweis. Wir werden das untersuchen. Im Moment haben wir überhaupt keine Testsuite, und ich würde wirklich gerne darüber nachdenken, aber die Seite ist seit über 8 Monaten in Entwicklung und so groß, dass es mehr als eine Woche dauern würde, um eine zu erstellen. Wir betreiben Laravel Forge, das nur die neue Version mit dem Ordner verlinkt, für den nginx eingerichtet ist. Ich kann aufgrund der Schule keine ungeraden Stunden arbeiten, und das gleiche gilt für den anderen Entwickler. - cheese5505
@ cheese5505 Ich weiß, das ist frustrierend und das löst dein Problem nicht, aber wenn du das sagst, "... ist so groß, dass es mehr als eine Woche dauern würde, um eins zu machen." Das erscheint offensichtlich lächerlich. Jeder vernünftige Entwicklungs- und Bereitstellungsprozess würde es ermöglichen, einen Server in weniger als einem Tag oder vielleicht einigen Stunden bis zu einer Stunde aufzubauen. Sie sollten wirklich überprüfen, was Sie getan haben, um diesen Stapel unkontrollierbaren Materials aufzubauen, um dies zu vermeiden. Das Problem ist nicht Komplexität, sondern grundsätzliche Voraussicht in der Planung. - JakeGould
"Im Moment haben wir überhaupt keine Testsuite" - beheben Sie das jetzt, bevor Sie neue Funktionen entwickeln. Dies ist Ihr größter Schwachpunkt und wird ein Verfügbarkeitsrisiko darstellen. Automatisierte Tests werden dazu beitragen, Ausfälle zu verhindern und Operationsschmerzen signifikant zu reduzieren. - Josh


Es scheint von dem, was Sie sagen, dass Sie ein Wartungsfenster von 1 Uhr morgens bis 7 Uhr morgens haben, das Problem ist nicht Zeit, sondern Bequemlichkeit. Das ist normal und viele Leute beschäftigen sich nur damit im Geschäft.

Sie könnten ein 2 (oder mehr Backend) -Systeme mit einem Frontend haben, das den Verkehr auf den aktuellen Stand leitet. Sobald Sie froh sind, dass ein Release funktioniert, sagen Sie dem Frontend, dass Sie zum neuen System wechseln sollen. Dies sollte leicht zu schreiben und eine kurze Zeit dauern.

Jetzt haben Sie die Wahl, das alte System entweder so zu belassen, dass es wieder verfügbar ist, 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.


6
2017-11-28 07:24



Wenn Sie Backend vom Frontend unterscheiden, meinen Sie eine vollständig modulare Softwarearchitektur? Oder Server-Architektur wie ein Load Balancer? - JakeGould
nur etwas, das Verbindungen akzeptiert und sie an das aktuelle primäre Back-End liefert. - Iain


Die anderen Antworten ändern: Sie sollten dem folgen blau-grünes Bereitstellungsmodell. Wenn Sie eine neue Version veröffentlichen möchten, stellen Sie sie auf einer internen Staging-Website bereit. Anschließend können Sie automatisierte Tests auf der nächsten Version der Produktionsumgebung ausführen. Wenn die Tests durchgeführt werden, weisen Sie den Load Balancer auf die neue Website.

Dies hilft auf folgende Weise:

  1. Schwere Probleme werden immer ohne Ausfallzeiten gefunden.
  2. Der Wechsel zu einer neuen Version hat genau null Ausfallzeiten, da die neue Version bereits gestartet und aufgewärmt ist.
  3. Sie können jederzeit zur alten Version wechseln, da sie noch physisch läuft.

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


5
2017-11-28 13:06



Wir haben bereits einen Staging-Server, den wir testen, aber im Moment befinden sich Produktion und Staging auf verschiedenen Servern an verschiedenen Standorten. Wir versuchen, die Produktion dorthin zu verlagern, wo sie ist, da sie für uns eine bessere Leistung bietet. - cheese5505
Der Schlüssel ist, den Load Balancer einfach auf eine bewährte Arbeitsversion umstellen zu müssen. Mit diesem aktuellen Modell hast du das nicht. - usr
Wie gut ein Modell ist, hängt stark davon ab, was die Site macht. Wenn die Seite zustandslos ist, dann ist sie großartig, aber wenn sie nicht staatenlos ist, müssen Sie herausfinden, wie Sie diesen Zustand beim Umschalten übertragen. - Peter Green
@PeterGreen es ist sehr schwierig für Websites, statusbehaftet zu sein, da das Clustering nicht möglich ist und der Zustand jederzeit durch erneute Bereitstellung / Neustart / Absturz / Bluescreen usw. verloren gehen kann. Daher ist dies sehr ungewöhnlich. - usr
@ usr die meisten Websites haben Staat. Dieser Zustand kann entweder in Dateien oder in einer Datenbank gespeichert werden. Im letzteren Fall kann die Datenbank entweder lokal oder entfernt sein. Einige Upgrades haben wahrscheinlich Auswirkungen auf diesen Zustand, was bedeutet, dass Upgrades und Rollback nicht so einfach sind, wie nur den Code umzuschalten. - Peter Green


Was tun Sie, wenn Ihr Hauptdatencenter einen Ausfall erleidet, der von Zeit zu Zeit in allen Rechenzentren auftritt? Sie könnten die Ausfallzeit akzeptieren, Sie könnten in ein anderes Datenzentrum failen, Sie könnten ständig im Aktiv-Aktiv-Modus in mehreren Rechenzentren arbeiten oder Sie haben einen anderen Plan. Was auch immer das ist, tun Sie es, wenn Sie Releases machen, und dann können Sie während einer Veröffentlichung Ihr Hauptdatenzentrum herunterfahren. Wenn Sie bereit sind, Ausfallzeiten zu haben, wenn Ihr Rechenzentrum ausfällt, sind Sie auf Ausfallzeiten vorbereitet, sodass es während einer Veröffentlichung kein Problem geben sollte.


3
2017-11-28 08:24





Um zu den vorherigen Antworten hinzuzufügen:

  • Verwenden Sie eine Bereitstellungsstrategie, die Rollbacks und sofortigen Wechsel ermöglicht. Capistrano oder so ziemlich jedes andere Bereitstellungssystem wird dabei helfen. Sie könnten Dinge wie Datenbank-Snapshots und Code-Symlinks verwenden, um schnell zu einem früheren Zustand zurückkehren zu können.

  • Nutzen Sie das komplette Konfigurationsmanagement, lassen Sie nichts manuell verwaltet. Systeme wie SaltStack, Ansible und Puppet sind Beispiele. Sie können auch auf Docker Container Konfigurationen und Vagrant Boxen angewendet werden.

  • Verwenden Sie HA, um sicherzustellen, dass Anforderungen beim Aktualisieren eines Knotens übergeben werden können. Wenn das Upgrade fehlschlägt, fahren Sie einfach den Knoten herunter, und wenn es zurückgerollt ist, bringen Sie es zurück und Ihre HA-Lösung wird Anfragen an diesen Knoten erneut bemerken und weiterleiten. HAProxy ist ein Beispiel, aber nginx funktioniert auch gut.

  • Stellen Sie sicher, dass die Anwendung gleichzeitige Instanzen verarbeiten kann, verwendete zentrale versionierte Datenrepositorys für Nicht-Codedaten, die auf der Festplatte gespeichert werden müssen, z. B. Cache. Auf diese Weise können Sie nie eine aktualisierte Anwendung ausführen, um Dateien von einer anderen Version zu cachen. Dies würde zusätzlich zu Cache-Bereinigungen und Cache-Warmups erledigt werden. (Die Caching-Sache ist nur ein Beispiel)

Normalerweise richte ich Workflows ein, bei denen Teammanager Zusammenführungsanforderungen an einen speziellen Zweig genehmigen können, der alle normalen CI-Aufgaben erledigt, aber als zusätzlichen letzten Schritt beginnt er auch, zu Produktionsknoten zu wechseln. Im Wesentlichen führen Sie eine manuelle CI-Bereitstellung für eine Produktionsinstanz aus. Wenn diese Instanz keine ungültigen Antworten erzeugt, bricht oder merkwürdige Dinge an Ihren Daten verursacht, dann massen Sie alle Knoten massenweise mit Ihrer CI-Lösung Ihrer Wahl. Wenn eine Implementierung funktioniert, wissen Sie, dass alle Bereitstellungen für ein bestimmtes Tag / Commit funktionieren.

Im Moment klingt es so, als ob Sie eine Produktionsanwendung auf einem einzelnen Knoten mit einem Bereitstellungsprozess, einer Quelle und einem Ziel ausführen. Dies bedeutet praktisch, dass jeder einzelne Schritt in diesem Workflow ein Fehlerpunkt ist, der die Website selbst zerstören kann. Sicherzustellen, dass so etwas nicht passieren kann, ist die Grundlage aller CI-, HA- und Failover-Prozesse. 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 ein CDN aus. Es hört sich vielleicht teuer an, aber ein Duplikat von dem, was Sie bereits haben in einem Rack auf einem Server mit einer eigenen Verbindung kostet in der Regel weniger als eine Stunde Ausfallzeit auf einer Business-Website.


2
2017-11-29 04:12





Ich stimme Michael in allen Punkten zu (https://serverfault.com/a/739449/309477).

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

Es ermöglicht Ihnen, friedlich zu implementieren und dann sofort zur neueren Version zu wechseln. Wenn etwas schief geht, können Sie sofort zur Arbeitsversion zurückkehren, indem Sie einfach den aktuellen Symlink in eine funktionierende Version ändern.

Und Capistrano ist ziemlich schnell zu handhaben (im Vergleich zu Beginn mit Tests und CI, die eine größere Zeitinvestition sein wird).

Zweitens, wenn das Geld nicht dein ist Main Problem: Sie sollten einen iso-prod-Entwicklungsserver haben, um Ihre App zu testen, bevor Sie sie in der Produktion bereitstellen. Benutze ein industriell Lösung (Ansible, Chef, Puppet) zum Verwalten von VPS-Instanzen.


0
2017-12-04 10:31