Kompromisse bei der operativen Exzellenz für Power Platform Workloads
Operational Excellence unterstützt die Arbeitsqualität durch die Implementierung klarer Teamstandards, verstandener Verantwortung und Rechenschaftspflicht, Aufmerksamkeit für Kundenergebnisse und Teamzusammenhalt. Die Implementierung dieser Ziele basiert auf DevOps, das empfiehlt, die Prozessvarianz zu minimieren, menschliche Fehler zu reduzieren und letztendlich die Wertrückgabe für die Workload zu erhöhen. Dieser Wert wird nicht nur anhand der funktionalen Anforderungen gemessen, die von den Komponenten der Arbeitslast erfüllt werden. Er wird auch daran gemessen, was das Team im Streben nach Verbesserung liefert.
Während der Entwurfsphase einer Workload und im Laufe ihres Lebenszyklus, während kontinuierliche Verbesserungsschritte unternommen werden, ist es wichtig zu berücksichtigen, wie Entscheidungen, die auf den Entwurfsprinzipien der operativen Exzellenz und den Empfehlungen in der Entwurfsüberprüfungs-Checkliste für operative Exzellenz basieren, die Ziele und Optimierungen anderer Säulen beeinflussen könnten. Bestimmte Entscheidungen können einigen Säulen zugute kommen, stellen aber einen Konflikt mit anderen dar. In diesem Artikel werden beispielhafte Konflikte beschrieben, die einem Workloadteam beim Entwerfen von Workloadarchitektur und -vorgängen begegnen können.
Die Zuverlässigkeit betreffende Konflikte bei der betrieblichen Effizienz
Kompromiss: Erhöhte Komplexität. Zuverlässigkeit priorisiert die Einfachheit, da der einfache Entwurf Fehlkonfigurationen minimiert und unerwartete Interaktionen reduziert.
Strategien für eine sichere Bereitstellung erfordern häufig eine gewisse Vorwärts- und Abwärtskompatibilität zwischen Anwendungslogik und Daten in der Workload. Diese zusätzliche Komplexität erhöht den Testaufwand und kann zu Komplexitäten oder Integritätsproblemen mit den Daten der Workload führen.
Hochschichtige, modularisierte oder parametrisierte Strukturen können aufgrund der Komplexität der Interaktion zwischen den Komponenten der Workload die Wahrscheinlichkeit einer versehentlichen Fehlkonfiguration erhöhen.
Für betriebswirtschaftlich vorteilhafte Cloud-Entwurfsmuster ist manchmal die Einführung weiterer Komponenten erforderlich, z. B. die Verwendung eines geheimen Speichers oder die Übernahme einer Abhängigkeit von Application Insights. Durch die zusätzlichen Komponenten erhöht sich die Anzahl der Interaktionspunkte im System, wodurch das Risiko von Fehlfunktionen oder Fehlkonfigurationen steigt.
Das Implementieren kleiner, inkrementeller Änderungen ist eine Methode zur Risikominimierung, die Benutzer erwarten jedoch, dass diese kleinen Änderungen häufiger in die Produktion überführt werden. Bereitstellungen können ein System destabilisieren, sodass mit der Bereitstellungsrate auch das Risiko zunimmt.
Eine Kultur, die sich anhand von Geschwindigkeitsmetriken wie Bereitstellungen pro Woche misst und Automatisierungen verwendet, die die Einführung von Änderungen in einem schnelleren Tempo erleichtern kann, wird wahrscheinlich auch mehr Bereitstellungen in einem kürzeren Zeitraum durchführen.
Eine Erhöhung der Dichte zur Vereinfachung des Betriebs durch Reduzierung der Anzahl von Kontroll- und Beobachtungspunkten kann auch zu einem erhöhten Verfügbarkeitsrisiko führen, da Fehlfunktionen oder Fehlkonfigurationen die Wirkung eines destabilisierenden Ereignisses verstärken.
Die Sicherheit betreffende Konflikte bei der betrieblichen Effizienz
Komponenten, die die Workload umschließen und deren Vorgänge unterstützen, z. B. Automatisierung oder eine benutzerdefinierte Steuerungsebene, müssen ebenfalls in den Bereich für regelmäßige Sicherheitshärtung und -tests einbezogen werden.
Routinemäßige, ungeplante und Notfalleinsätze erhöhen die Berührungspunkte mit der Arbeitsbelastung. Ein Zero-Trust-Ansatz erfordert, dass diese Prozesse als Schwachstellen betrachtet werden und in die Sicherheitskontrollen und -validierung für die Arbeitslast einbezogen werden.
Die Beobachtbarkeitsplattform des Systems sammelt Protokolle und Metriken zur Workload, die eine wertvolle Quelle für die Offenlegung von Informationen sein können. Daher muss die Sicherheit der Workload erweitert werden, um Datensenken vor internen und externen Bedrohungen zu schützen.
Build-Agents, externe Konfigurations- und Feature-Umschaltspeicher erhöhen die Anwendungsoberfläche, die Sicherheit erfordert.
Eine höhere Bereitstellungshäufigkeit aufgrund kleiner, inkrementeller Änderungen oder durch Bemühungen, auf dem neuesten Stand zu bleiben, führt zu mehr Sicherheitstests im Softwareentwicklungslebenszyklus (SDLC).
Beobachtbarkeitsplattformen erfassen Daten aller Typen, um Einblicke in die Integrität und das Verhalten einer Workload zu erhalten. Da Teams versuchen, eine höhere Genauigkeit der Beobachtbarkeitsdaten zu erreichen, besteht ein erhöhtes Risiko, dass Datenklassifizierungssteuerelemente wie die Datenmaskierung der Quellsysteme nicht auf die Protokolle und Protokollsenken der Beobachtbarkeitsplattform ausgedehnt werden.
Die gemeinsame Lokalisierung unterschiedlicher Anwendungskomponenten in freigegebenen Umgebungen und Datenressourcen, um die Verwaltung zu vereinfachen, kehrt die Segmentierung um oder erschwert die Durchführung einer rollenbasierten Segmentierung. Gemeinsame Komponenten müssen möglicherweise auch eine Workloadidentität teilen, was zu einer übermäßigen Zuweisung von Berechtigungen oder mangelnder Nachverfolgbarkeit führen kann.
Das Sammeln aller Protokolle aus dem gesamten System in einer einheitlichen Protokollsenke kann das Abfragen und Erstellen von Warnungen vereinfachen. Allerdings kann es dadurch auch schwieriger oder unmöglich werden, zeilenbasierte Sicherheit zu gewährleisten, um vertrauliche Daten mit den erforderlichen Prüfkontrollen zu behandeln.
Die Vereinfachung der Verwaltung der attributbasierten oder rollenbasierten Sicherheit durch Verringerung der Granularität von Rollen und deren Zuweisungen kann zu unangemessen breiten Berechtigungen führen.
Die Umgebungsoptimierung betreffende Konflikte bei der betrieblichen Effizienz
Die Entwicklung der Benutzererfahrung, die erhebliche Ressourcen erfordert, wird möglicherweise zurückgestellt, was dazu führen kann, dass der Erfahrung die Benutzerfreundlichkeit, Interaktionen und das visuelle Design fehlen, die Workload-Benutzer benötigen.
Die Entwicklung der Benutzeroberfläche erfolgt häufig in schnelleren Iterationen und Auslieferungszyklen, was die SDLC-Prozesse des Teams belasten kann.
Kompromisse zwischen operativer Exzellenz und Leistungseffizienz
- Das Überwachungsframework einer Workload erfordert, dass die Komponenten in der Architektur Zeit und Ressourcen für das Erstellen, Sammeln und Streamen von Protokollen und Metriken bereitstellen. Diese Datenpunkte tragen dazu bei, dass eine effektive Warnmeldung und Überwachung hinsichtlich Zuverlässigkeit, Sicherheit und Leistung möglich ist. Mit zunehmender Instrumentierung steigt möglicherweise auch die Belastung der Systemressourcen.
- Einige Cloud-Entwurfsmuster, die Ansätze der „unabhängigen Änderung im Laufe der Zeit“ unterstützen, um die Ideale der inkrementellen Verbesserung zu unterstützen, können aufgrund der Durchquerung zusätzlicher Komponenten zu Latenzen führen.