Zuverlässigkeitskompromisse für Power Platform Workloads
Eine zuverlässige Workload erfüllt konsequent ihre definierten Zuverlässigkeitsziele. Sie sollte etablierte Resilienzziele erreichen, idealerweise durch Umgehung von Ereignissen, die sich auf die Zuverlässigkeit auswirken. Realistischerweise muss eine Workload jedoch die Auswirkungen solcher Ereignisse tolerieren und steuern und den Betrieb während einer aktiven Fehlfunktion auf einer vorgegebenen Ebene aufrechterhalten. Auch während eines Notfalls muss eine zuverlässige Workload innerhalb eines bestimmten Zeitraums in einen bestimmten Zustand zurückgewonnen werden. Beides wird zwischen den Beteiligten vereinbart. Ein Plan zur Reaktion auf Vorfälle, mit dem Sie eine schnelle Erkennung und Wiederherstellung erreichen können, ist von entscheidender Bedeutung.
Während der Entwurfsphase einer Workload müssen Sie berücksichtigen, wie Entscheidungen, die auf den Prinzipien des Zuverlässigkeitsentwurfs und den Empfehlungen in der Prüfliste der Entwurfsprüfung für Zuverlässigkeit basieren, die Ziele und Optimierungen anderer Säulen beeinflussen können. Bestimmte Entscheidungen können einigen Säulen zugute kommen, stellen aber einen Kompromiss für andere dar. In diesem Artikel werden beispielhafte Zuverlässigkeitskonflikte beschrieben, die einem Workloadteam beim Entwerfen von Workloadarchitektur und -vorgängen begegnen können.
Die Sicherheit betreffende Zuverlässigkeitskonflikte
Kompromiss: Größere Arbeitsfläche. Die Säule Sicherheit priorisiert eine reduzierte und geschlossene Oberfläche, um Angriffsvektoren zu minimieren und die Verwaltung von Sicherheitskontrollen zu reduzieren.
Zuverlässigkeit wird häufig durch Replikation erreicht. Die Replikation kann auf Komponentenebene, auf Datenebene oder sogar auf geografischer Ebene erfolgen. Replikate erhöhen standardmäßig die Oberfläche einer Workload. Aus Sicherheitssicht wird eine reduzierte und geschlossene Oberfläche bevorzugt, um potenzielle Angriffsvektoren zu minimieren und die Verwaltung von Sicherheitskontrollen zu optimieren.
Ebenso vergrößern Notfallwiederherstellungslösungen wie Sicherungen die Oberfläche einer Workload. Sie sind jedoch häufig von der Runtime der Workload isoliert. Dies erfordert die Implementierung zusätzlicher Sicherheitskontrollen, die für die Notfallwiederherstellungslösung spezifisch sein können.
Zur Erreichung der Zuverlässigkeitsziele werden möglicherweise zusätzliche Komponenten für die Architektur benötigt, was die Oberfläche erhöht. Diese erhöhte Komplexität erhöht die Oberfläche der Workload, indem neue Komponenten hinzugefügt werden, die gesichert werden müssen, möglicherweise auf eine Weise, die noch nicht im System angewandt wird. In der Regel gehen diese Komponenten mit zusätzlichem Code einher, um ihre Verwendung oder allgemeine Zuverlässigkeitsmuster zu unterstützen, was ebenfalls die Oberfläche der Anwendung erhöht.
Wenn bei einer Workload ein Zuverlässigkeitsereignis auftritt, das im Rahmen der aktiven Reaktion auf den Vorfall behandelt wird, kann das Workloadteam durch die Dringlichkeit unter Druck geraten, Sicherheitskontrollen zu umgehen, die für den routinebasierten Zugriff optimiert sind.
Problembehandlungsaktivitäten können dazu führen, dass das Team Sicherheitsprotokolle vorübergehend deaktiviert, sodass ein bereits beanspruchtes System möglicherweise zusätzlichen Sicherheitsrisiken ausgesetzt ist. Zudem besteht das Risiko, dass die Sicherheitsprotokolle nicht unverzüglich wieder eingesetzt werden.
Präzise Implementierungen von Sicherheitskontrollen, z. B. rollenbasierte Zugriffssteuerungszuweisungen oder Firewallregeln, führen zur Komplexität und Vertraulichkeit der Konfiguration und erhöhen die Wahrscheinlichkeit von Fehlkonfigurationen. Die Abmilderung dieser potenziellen Auswirkungen auf die Zuverlässigkeit durch die Verwendung allgemeinerer Regeln untergräbt alle drei Zero Trust-Architekturprinzipien.
Das Anwenden von Aktualisierungen im Rahmen von Veröffentlichungszyklenn oder für Bibliotheken von Anbietern, wie Komponenten und Lösungen von Drittanbietern, kann die Zielkomponente möglicherweise stören und zur Nichtverfügbarkeit während der Änderung führen. Durch das Verzögern oder Vermeiden von Patches können potenzielle Zuverlässigkeitsrisiken vermieden werden, aber das System ist nicht vor neuen Bedrohungen geschützt.
Die vorstehende Überlegung gilt auch für den Code der Workload. Sie gilt beispielsweise für Anwendungscode, der alte Bibliotheken und Komponenten verwendet. Wenn das Aktualisieren und Bereitstellen von Anwendungscode als ein uneingeschränktes Zuverlässigkeitsrisiko angesehen wird, ist die Anwendung im Laufe der Zeit zusätzlichen Sicherheitsrisiken ausgesetzt.
Die betriebliche Effizienz betreffende Zuverlässsigkeitskonflikte
Eine umfassende Überwachungsstrategie für eine Workload ist ein wichtiger Bestandteil der betrieblichen Effizienz. Die Einführung zusätzlicher Komponenten in eine Architektur zum Implementieren von Zuverlässigkeitsentwurfsmustern führt zu mehr zu verwaltenden Datenquellen und erhöht die Komplexität der Implementierung verteilter Ablaufverfolgung und Beobachtbarkeit.
Wenn Sie mehrere Regionen verwenden, um Kapazitätseinschränkungen für Ressourcen in einer einzelnen Region zu überwinden und/oder eine Aktiv/Aktiv-Architektur zu implementieren, erhöht sich die Komplexität der Betriebsverwaltung der Workload. Diese Komplexität entsteht durch die Notwendigkeit, mehrere Regionen und die Datenreplikation zwischen ihnen zu verwalten.
Wenn eine Workload durch das Hinzufügen von Zuverlässigkeitskomponenten und -mustern robuster wird, braucht es mehr Zeit, um Betriebsverfahren und Artefaktdokumentation zu verwalten.
Das Training wird komplexer, wenn die Anzahl der Komponenten in der Workload zunimmt. Diese Komplexität wirkt sich auf den Zeitaufwand für das Onboarding aus und erhöht das Wissen, das zum Nachverfolgen von Produktroadmaps und Anleitungen zum Servicelevel benötigt wird.
Die Umgebungsoptimierung betreffende Zuverlässsigkeitskonflikte
Ein strikter Testplan kann die Freigabe von Funktionen für die Umgebung, die für die Einführung wesentlich sind, verzögern.
Bei der Optimierung auf Zuverlässigkeit kann es passieren, dass der Schwerpunkt zu sehr auf der Minimierung der Komplexität liegt, wodurch Funktionen für ein ansprechenderes Benutzererlebnis, wie benutzerdefinierte Komponenten und Integrationen, in den Hintergrund geraten.
Kompromisse zwischen Zuverlässigkeit und Leistungseffizienz
Zuverlässigkeitsmuster beinhalten häufig eine Datenreplikation, um Replikationsfehler zu überstehen. Durch die Replikation kommt es zu zusätzlichen Latenzen bei zuverlässigen Datenschreibvorgängen, was einen Teil des Leistungsbudgets für einen bestimmten Benutzer oder Datenfluss verbraucht.
Zur Gewährleistung der Zuverlässigkeit werden manchmal verschiedene Formen des Ressourcenausgleichs eingesetzt, um die Last auf fehlerfreie Replikate zu verteilen oder umzuverteilen. Eine dedizierte Komponente, die zum Ausgleichen verwendet wird, beeinträchtigt normalerweise die Leistung der Anforderung oder des Prozesses, der ausgeglichen wird.
Die Verteilung von Komponenten über geografische Grenzen oder Verfügbarkeitszonen hinweg, um eine begrenzte Auswirkung zu überstehen, führt zu Netzwerklatenzen bei der Kommunikation zwischen Komponenten, die diese Verfügbarkeitsgrenzen überschreiten.
Um den Zustand einer Arbeitslast zu überwachen, werden umfangreiche Prozesse eingesetzt. Obwohl die Überwachung für die Zuverlässigkeit von entscheidender Bedeutung ist, kann die Instrumentierung die Systemleistung beeinträchtigen. Mit zunehmender Beobachtbarkeit kann die Leistung abnehmen.
Automatische Skalierungsvorgänge erfolgen nicht augenblicklich und können daher einen plötzlichen und dramatischen Nachfrageanstieg, der nicht geformt oder geglättet werden kann, nicht zuverlässig bewältigen. Daher ist die Überbereitstellung über entweder größere oder mehr Instanzen eine wichtige Zuverlässigkeitstaktik, um die Verzögerung zwischen Nachfragesignal und Angebotserstellung auszugleichen. Ungenutzte Kapazitäten stehen den Zielen der Leistungseffizienz entgegen.
Manchmal kann eine Komponente nicht entsprechend der Nachfrage skaliert werden und diese Nachfrage ist nicht vollständig vorhersehbar. Die Verwendung großer Instanzen zur Abdeckung des schlimmsten Falls führt zu einer Überbereitstellung und Verschwendung in Situationen, die außerhalb dieses Anwendungsfalls liegen.