Stellen Sie die ASP.NET-Website bereit und aktualisieren Sie die MSSQL-Datenbank ohne Ausfallzeiten

Ich habe in den letzten fünf Jahren eine große Website mit monatlichen Versionen verwaltet und es ist mir gelungen, mehr als 95% der Zeit keine Ausfallzeit zu haben. Der Schlüssel ist leider, dass die Datenbank immer abwärtskompatibel ist, aber nur mit der vorherigen Version, so dass Sie die Möglichkeit haben, ein Rollback durchzuführen.

Wenn Sie beispielsweise eine Spalte löschen möchten, hängt Ihre Anwendung von folgenden Faktoren ab:

1. Ändern Sie Ihren Anwendungscode so, dass er nicht von der Spalte abhängt, und geben Sie diesen frei (ohne die Spalte in der Datenbank zu entfernen).
2. In der nächsten Version löschen Sie die Spalte (da die Anwendung nicht mehr darauf angewiesen ist).

Es braucht etwas Disziplin von Ihrem Entwickler-Team, ist aber überraschend einfach zu erreichen, wenn Sie die richtigen Umgebungen eingerichtet haben (Entwicklung / Test / Bereitstellung / Produktion).

Wenn Sie loslassen:

1. Stellen Sie Datenbankänderungen in einer Staging -Umgebung bereit, die der Produktion so nahe wie möglich kommt. Tun Sie dies vorzugsweise auf automatisierte Weise, indem Sie etwas wie SQL Compare und SQL Data Compare verwenden, damit Sie wissen, dass die Datenbank mit Ihrer Testumgebung vollständig auf dem neuesten Stand ist.
2. Führen Sie "Rauchtests" mit der Anwendung alt durch, aber mit dem neuen -Datenbankschema, um sicherzustellen, dass die Datenbank keine größeren Änderungen aufweist.
3. Geben Sie Ihren Anwendungscode frei.
4. Smoke teste deine Staging-Anwendung.
5. Freigabe zur Produktion.

Eine andere Sache, die wir tun, um sicherzustellen, dass keine Ausfallzeiten auf der Website auftreten, ist die Bereitstellung von Blue-Green. Dazu müssen Sie für jede Website 2 Ordner haben, einen aktualisieren und das IIS-Home-Verzeichnis wechseln, sobald es aktuell ist. Ich habe hier darüber gebloggt: Ссылка

Nicht, es zu tun. Punkt.

ZERO-Downtime-Installationen sind sehr schwierig zu machen und umfassen mehrere Kopien der Datenbank, Vorabprüfung in einer Staging-Umgebung, sorgfältige Programmierung und Resynchronisierung der Datenbank.

Es ist eigentlich immer besser, eine kleine Auszeit zu nehmen. Schlafe lange in der Nacht, entfalte um 2 Uhr morgens. Oder wache früher auf. Identifizieren Sie, wann es für Ihre Benutzer unpraktisch ist.

100% Uptime ist sehr teuer zu implementieren, in Bezug auf die Menge an Zeit dafür. Wenn es sich hier nicht um einen strikten Geschäftsfall handelt, ist eine gelegentliche Ausfallzeit eine viel gesündere Entscheidung.

Selbst große Websites wie salesforce.com und ebay.com haben Wartungsfenster geplant, in denen zumindest Teile dieser Websites aufgrund von Änderungen an den Back-Ends für einen bestimmten Zeitraum nicht verfügbar sind.

Für Ebay ist es jede Donnerstagsnig ht und dauert für 4 Stunden, in denen "bestimmte Funktionen sein können langsam oder nicht verfügbar während dieser Zeit ". Für Salesforce planen und benachrichtigen Sie die Benutzer nach Bedarf .

Abhängig von Ihrer Website empfiehlt es sich möglicherweise, ein einstündiges Fenster zu einer späten Stunde einzuplanen, in der sich Ihre Website auf dem niedrigsten Traffic-Level befindet. Benachrichtigen Sie die Benutzer im Voraus 1 Woche vor, 1 Tag vor und 1 Stunde vorher.

Bevor Sie es offline nehmen, stellen Sie sicher, dass Sie Ihre Bereitstellung von einer Kopie Ihrer aktuellen Produktionsdatenbank auf einem anderen Server testen. Dies gibt Ihnen eine Vorstellung von allen möglichen Problemen und lässt Sie genau wissen, wie lange es dauern sollte. Verdoppeln Sie diese Nummer, wenn Sie Benutzer benachrichtigen. Führen Sie die Tests mehrmals durch, um sicherzustellen, dass nicht nur die Zeit, sondern auch die Datenkonsistenz überprüft wird.

Duffman hat eine gute Antwort, wenn es darum geht, parallele Versionen für ein sehr kurzes Fenster auszuführen, um die Updates zu erhalten. Dies ist jedoch in der Regel ein Grund für Änderungen des Datenmodells, und es ist normalerweise besser, alle vorhandenen Daten zum Zeitpunkt der Bereitstellung zu konvertieren. Wenn diese Umwandlung ausgeführt wird, könnte bestimmte Transaktionen während des Vorgangs ungültig machen und zu beschädigten Daten führen.

Nachdem ich viele "heiße" Produktionsschritte gemacht habe, kann ich mit hundertprozentiger Sicherheit sagen, dass weder ich noch meine Kunden jemals wieder mit diesen arbeiten wollen. Es gibt absolut keinen Platz für Fehler.