Überlegungen zum Aktualisieren einer mehrinstanzenfähigen Lösung

  • Artikel

Einer der Vorteile der Cloudtechnologie ist die kontinuierliche Verbesserung und Weiterentwicklung. Als Dienstanbieter müssen Sie Updates auf Ihre Lösung anwenden: Möglicherweise müssen Sie Änderungen an Ihrer Azure-Infrastruktur, Ihrem Code bzw. Ihren Anwendungen, Ihren Datenbankschemas oder einer anderen Komponente vornehmen. Es ist wichtig zu planen, wie Sie Ihre Umgebungen aktualisieren. In einer mehrinstanzenfähigen Lösung ist es besonders wichtig, dass Sie Ihre Aktualisierungsrichtlinien klar formulieren, da einige Ihrer Mandanten Änderungen an ihren Umgebungen möglicherweise nur ungern zulassen oder Anforderungen haben, die die Bedingungen einschränken, unter denen Sie ihren Dienst aktualisieren können.

Wichtige Punkte bei der Planung einer Aktualisierungsstrategie für Ihre Lösung:

  • Ermitteln Sie die Anforderungen Ihrer Mandanten.
  • Klären Sie Ihre eigenen Anforderungen für den Betrieb des Diensts.
  • Finden Sie ein ausgewogenes Verhältnis, das sowohl für Sie als auch für Ihre Mandanten akzeptabel ist.
  • Kommunizieren Sie Ihre Strategie klar gegenüber Ihren Mandanten und anderen Projektbeteiligten.

In diesem Artikel erhalten technische Entscheidungsträger Informationen zu den Ansätzen, die sie beim Aktualisieren der Software der Mandanten in Betracht ziehen können, sowie zu den damit verbundenen Vor- und Nachteilen.

Anforderungen Ihrer Kunden

Stellen Sie sich die folgenden Fragen:

  • Erwartungen und Anforderungen: Haben Ihre Kunden Erwartungen oder Anforderungen im Zusammenhang mit der Durchführung von Aktualisierungen? Diese werden Ihnen möglicherweise formell in Verträgen oder Vereinbarungen zum Servicelevel mitgeteilt, sie können aber auch informell sein.
  • Wartungsfenster: Erwarten Ihre Kunden dienstdefinierte oder sogar selbstdefinierte Wartungsfenster? Möglicherweise müssen sie ihren eigenen Kunden über mögliche Ausfälle informieren.
  • Bestimmungen: Haben Ihre Kunden rechtliche Bedenken, die eine zusätzliche Genehmigung erfordern, bevor Updates angewendet werden können? Wenn Sie beispielsweise eine Gesundheitslösung mit IoT-Komponenten bereitstellen, müssen Sie möglicherweise eine Genehmigung von der nordamerikanischen Food and Drug Administration (FDA) einholen, bevor Sie ein Update anwenden.
  • Sensibilität: Gibt es Kunden, die hinsichtlich der Anwendung von Updates besonders sensibel oder ablehnend sind? Versuchen Sie zu verstehen, warum. Wenn sie beispielsweise ein Ladengeschäft oder eine Einzelhandelswebsite betreiben, möchten sie möglicherweise Updates rund um den Black Friday vermeiden, da die Risiken höher sind als die möglichen Vorteile.
  • Bisherige Erfahrungen: Wie sieht Ihre Erfolgsbilanz aus, wenn es darum geht, Updates ohne Beeinträchtigung Ihrer Kunden durchzuführen? Befolgen Sie die bewährten Methoden für DevOps, Tests, Bereitstellung und Überwachung, um die Wahrscheinlichkeit von Ausfällen zu verringern und sicherzustellen, dass Sie Probleme, die durch Updates auftreten, schnell identifizieren. Wenn Ihre Kunden wissen, dass Sie in der Lage sind, ihre Umgebungen reibungslos zu aktualisieren, ist die Wahrscheinlichkeit geringer, dass sie Einwände erheben.
  • Rollback: Möchten Kunden im Falle eines Breaking Change ein Rollback für Updates ausführen?

Ihre Anforderungen

Sie müssen auch die folgenden Fragen aus Ihrer eigenen Perspektive berücksichtigen:

  • Steuerungsmöglichkeiten: Ist es für Ihre Kunden sinnvoll, steuern zu können, wann Updates angewendet werden? Wenn Sie eine Lösung erstellen, die von großen Unternehmenskunden verwendet wird, kann die Antwort „Ja“ lauten. Wenn Sie jedoch eine verbraucherorientierte Lösung entwickeln, ist es unwahrscheinlich, dass Sie die Kontrolle darüber abgeben, wie Sie Ihre Lösung aktualisieren oder betreiben.
  • Versionen: Wie viele Versionen Ihrer Lösung können Sie sinnvoll gleichzeitig verwalten? Denken Sie daran, dass Sie den Hotfix möglicherweise auf alle verwendeten Versionen anwenden müssen, wenn Sie einen Fehler finden und diesen mit einem Hotfix beheben müssen.
  • Folgen alter Versionen: Welche Folgen hat es, wenn die Kunden zu weit von der aktuellen Version entfernt sind? Sind alte Versionen schnell veraltet, wenn Sie regelmäßig neue Features veröffentlichen? Abhängig von Ihrer Upgradestrategie und den Arten von Änderungen müssen Sie außerdem möglicherweise separate Infrastrukturen für jede Version Ihrer Lösung verwalten. Es können also sowohl operative als auch finanzielle Kosten entstehen, wenn Sie Unterstützung für ältere Versionen anbieten.
  • Rollback: Unterstützt Ihre Bereitstellungsstrategie Rollbacks auf frühere Versionen? Möchten Sie eine solche Möglichkeit unterstützen?

Hinweis

Überlegen Sie, ob Sie Ihre Lösung für Updates oder Wartungen offline schalten müssen. Im Allgemeinen werden Ausfallfenster als veraltet angesehen, und moderne DevOps-Methoden und Cloudtechnologien ermöglichen es Ihnen, Ausfallzeiten während Updates und Wartungen zu vermeiden. Sie müssen Ihren Entwurf jedoch auf Bereitstellungen ohne Ausfallzeiten ausrichten. Daher ist es wichtig, den Aktualisierungsprozess bei der Planung Ihrer Lösungsarchitektur zu berücksichtigen.

Auch wenn während des Aktualisierungsprozesses keine Ausfälle geplant sind, empfiehlt es sich ggf. trotzdem, ein reguläres Wartungsfenster zu definieren. Ein Fenster macht Ihren Kunden gegenüber deutlich, dass Änderungen zu bestimmten Zeiten vorgenommen werden.

Weitere Informationen zu Bereitstellungen ohne Ausfallzeiten finden Sie unter Eliminate downtime through versioned service updates (Beseitigen von Ausfallzeiten durch Dienstupdates mit Versionsangabe).

Finden eines Gleichgewichts

Wenn Sie es Ihren Mandanten überlassen, wie oft sie ihre Dienste aktualisieren, kann es sein, dass sie sich dafür entscheiden, niemals Aktualisierungen vorzunehmen. Es ist wichtig, dass Sie die Möglichkeit haben, Ihre Lösung zu aktualisieren und dabei alle berechtigten Bedenken oder Einschränkungen Ihrer Kunden zu berücksichtigen. Wenn ein Kunde zum Beispiel besonders empfindlich auf Aktualisierungen an einem Freitag reagiert (weil das sein wichtigster Tag in der Woche ist), können Sie die Aktualisierungen dann einfach auf den Montag verschieben, ohne dass dies Auswirkungen auf Ihre Lösung hat?

Ein Ansatz, der gut funktionieren kann, ist das Rollout von Updates auf Basis einzelner Mandanten mithilfe eines der unten beschriebenen Ansätze. Informieren Sie Ihren Kunden über geplante Updates. Erlauben Sie Kunden, das Update vorübergehend abzulehnen, aber nicht für immer. Setzen Sie eine vernünftige Frist, bis zu der Sie die Anwendung der Aktualisierung verlangen.

Erwägen Sie außerdem, sich selbst die Möglichkeit zu geben, Sicherheitspatches oder andere kritische Hotfixes mit sehr kurzfristiger oder ohne vorherige Ankündigung bereitzustellen.

Ein anderer Ansatz kann darin bestehen, Mandanten zu ermöglichen, ihre eigenen Updates zu einem Zeitpunkt ihrer Wahl zu initiieren. Auch hier sollten Sie einen Stichtag angeben, an dem Sie das Update in ihrem Namen anwenden.

Warnung

Seien Sie vorsichtig, wenn Sie den Mandanten erlauben, ihre eigenen Updates zu initiieren. Die Implementierung ist komplex und erfordert einen erheblichen Entwicklungs- und Testaufwand für Bereitstellung und Wartung.

Wie auch immer Sie vorgehen, stellen Sie sicher, dass Sie ein Verfahren zur Überwachung der Integrität Ihrer Mandanten haben, insbesondere vor und nach der Durchführung von Updates. Häufig treten kritische Produktionsincidents (auch Live-Site Incidents genannt) nach Aktualisierungen des Codes oder der Konfiguration auf. Daher ist es wichtig, dass Sie Probleme proaktiv überwachen und darauf reagieren, um das Vertrauen der Kunden zu erhalten. Weitere Informationen zur Überwachung finden Sie unter Überwachen von Workloads.

Kommunizieren Sie mit Ihren Kunden

Klare Kommunikation ist der Schlüssel zur Vertrauensbildung bei Ihren Kunden. Es ist wichtig, die Vorteile regelmäßiger Updates zu erläutern, einschließlich neuer Funktionen, Fehlerbehebungen, Behebung von Sicherheitslücken und Leistungsverbesserungen. Einer der Vorteile einer modernen, in der Cloud gehosteten Lösung ist die kontinuierliche Bereitstellung von Funktionen und Updates.

Stellen Sie sich die folgenden Fragen:

  • Werden Sie Ihre Kunden über bevorstehende Updates informieren?
  • Falls ja: Fordern Sie implizit eine Genehmigung an, indem Sie eine Abwahlmöglichkeit bereitstellen, und mit welchen Einschränkungen ist diese Abwahl verbunden?
  • Haben Sie ein geplantes Wartungsfenster, das Sie für die Anwendung von Updates nutzen?
  • Was geschieht, wenn ein Notfallupdate wie ein kritischer Sicherheitspatch erforderlich wird? Können Sie Updates unter solchen Umständen erzwingen?
  • Können Sie nachträgliche Benachrichtigungen bereitstellen, wenn Sie Kunden nicht proaktiv über anstehende Updates benachrichtigen können? Können Sie beispielsweise eine Seite auf Ihrer Website mit der Liste der Updates aktualisieren, die Sie angewendet haben?
  • Wie viele separate Versionen Ihres Systems verwalten Sie in der Produktion?

Kommunizieren Sie mit Ihrem Kundensupportteam

Es ist wichtig, dass Ihr eigenes Supportteam über vollständige Einblicke in Updates verfügt, die auf jeden Mandanten angewendet wurden. Kundensupportmitarbeiter sollten in der Lage sein, die folgenden Fragen problemlos zu beantworten:

  • Wurden kürzlich Updates auf die Infrastruktur eines Mandanten angewendet?
  • Welcher Art waren diese Updates?
  • Was war die vorherige Version?
  • Wie häufig werden Updates auf diesen Mandanten angewendet?

Wenn einer Ihrer Kunden aufgrund eines Updates ein Problem hat, müssen Sie sicherstellen, dass Ihr Kundensupportteam über die erforderlichen Informationen verfügt, um zu verstehen, was sich geändert hat.

Bereitstellungsstrategien zur Unterstützung von Updates

Überlegen Sie, wie Sie Updates für Ihre Infrastruktur bereitstellen. Dies wird stark durch das von Ihnen genutzte Mandantenmodell beeinflusst. Drei gängige Ansätze für die Bereitstellung von Updates sind Bereitstellungsstempel, Featureflags und Bereitstellungsringe. Sie können diese Ansätze unabhängig voneinander verwenden oder miteinander kombinieren, um komplexere Anforderungen zu erfüllen.

Stellen Sie in jedem Fall sicher, dass Sie über eine angemessene Berichterstellung und über genügend Transparenz verfügen, um zu wissen, welche Version der Infrastruktur, der Software oder eines Features die einzelnen Mandanten nutzen, zu welcher Version sie migrieren können und welche Zeitdaten mit diesen Zuständen verbunden sind.

Muster mit Bereitstellungsstempeln

Viele mehrinstanzenfähige Anwendungen eignen sich gut für das Muster mit Bereitstellungsstempeln, in dem Sie mehrere Kopien Ihrer Anwendung und anderer Komponenten bereitstellen. Abhängig von Ihren Isolationsanforderungen können Sie einen Stempel für jeden Mandanten oder freigegebene Stempel bereitstellen, die Workloads mehrerer Mandanten ausführen.

Stempel sind eine hervorragende Möglichkeit, Isolation zwischen Mandanten zu erzielen. Sie bieten Ihnen auch Flexibilität für Ihren Updateprozess, da Sie die Aktualisierungen schrittweise über die Stempel verteilen können, ohne andere zu beeinträchtigen.

Featureflags

Featureflags ermöglichen es Ihnen, Ihrer Lösung Funktionen hinzuzufügen und diese nur für eine Teilmenge Ihrer Kunden oder Mandanten verfügbar zu machen.

Erwägen Sie die Verwendung von Featureflags, wenn einer der folgenden Punkte für Sie zutrifft:

  • Sie stellen regelmäßig Updates bereit, möchten aber neue Funktionen erst verfügbar machen, wenn sie vollständig implementiert sind.
  • Sie möchten Änderungen am Verhalten vermeiden, bis sich ein Kunde für sie entscheidet.

Sie können die Unterstützung von Featureflags in Ihre Anwendung einbetten, indem Sie selbst Code schreiben oder einen Dienst wie Azure App Configuration verwenden.

Bereitstellungsringe

Mit Bereitstellungsringen können Sie Updates progressiv für eine Gruppe von Mandanten oder Bereitstellungsstempeln bereitstellen. Sie können jedem Ring eine Teilmenge von Mandanten zuweisen.

Sie können bestimmen, wie viele Ringe erstellt werden sollen und was jeder Ring für Ihre eigene Lösung bedeutet. In der Regel verwenden Organisationen die folgenden Ringe:

  • Canary: Ein Canary-Ring umfasst Ihre eigenen Testmandanten und Kunden, die Updates erhalten möchten, sobald sie verfügbar sind. Dabei ist den Kunden bewusst, dass sie ggf. häufiger Updates erhalten und Updates möglicherweise nicht so umfassend überprüft wurden wie in anderen Bereichen.
  • Early Adopter: Ein Early Adopter-Ring enthält Mandanten, die etwas risikoscheuer sind, aber dennoch regelmäßige Updates erhalten möchten.
  • Benutzer: Die meisten Ihrer Mandanten gehören zum Ring Benutzer. In diesem Ring werden Updates seltener bereitgestellt und intensiver getestet.

API-Versionen

Wenn Ihr Dienst eine externe API bereitstellt, sollten Sie berücksichtigen, dass alle Updates, die Sie anwenden, sich auf die Art und Weise auswirken können, wie Kunden oder Partner in Ihre Plattform integriert werden. Insbesondere müssen Sie sich über Breaking Changes Ihrer APIs bewusst sein. Erwägen Sie die Verwendung einer API-Versionsverwaltungsstrategie, um das Risiko von Aktualisierungen Ihrer API zu verringern.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

  • John Downs | Principal Customer Engineer, FastTrack for Azure

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte