Operational Excellence-Kompromisse

  • Artikel

Operational Excellence bietet Workloadqualität durch die Implementierung klarer Teamstandards, das Verständnis von Verantwortung und Verantwortlichkeit, die Aufmerksamkeit auf die Kundenergebnisse und den Teamzusammenhalt. Die Implementierung dieser Ziele basiert auf DevOps, was empfohlen wird, 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 an den funktionalen Anforderungen gemessen, die von den Komponenten der Workload bereitgestellt werden. Es wird auch am Wert gemessen, den das Team im Streben nach Verbesserung liefert.

Während der Entwurfsphase einer Workload und während des Gesamten Lebenszyklus ist es wichtig, zu berücksichtigen, wie Entscheidungen, die auf den Entwurfsprinzipien der Operational Excellence und den Empfehlungen in der Prüfliste für die Entwurfsüberprüfung für operationale Exzellenz basieren, die Ziele und Optimierungen anderer Säulen beeinflussen können. Bestimmte Entscheidungen können einigen Säulen zugute kommen, aber sie stellen kompromisse für andere dar. In diesem Artikel werden Beispiele für Kompromisse beschrieben, die einem Workloadteam beim Entwerfen von Workloadarchitekturen und -vorgängen begegnen können.

Operational Excellence-Kompromisse mit Zuverlässigkeit

Kompromiss: Erhöhte Komplexität. Zuverlässigkeit priorisiert die Einfachheit, da der einfache Entwurf Fehlkonfigurationen minimiert und unerwartete Interaktionen reduziert.

  • Strategien für sichere Bereitstellungen 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.

  • Eine hochschichtige, modularisierte oder parametrisierte Infrastruktur als Code kann aufgrund der Komplexität der Interaktion zwischen den Codekomponenten die Wahrscheinlichkeit einer versehentlichen Fehlkonfiguration erhöhen.

  • Cloudentwurfsmuster, die Vorgängen zugute kommen, erfordern manchmal die Einführung zusätzlicher Komponenten, z. B. die Verwendung eines externen Konfigurationsspeichers oder die Koordination von Sidecar-Bereitstellungen in einer Containeranwendungsplattform. Die zusätzlichen Komponenten erhöhen die Interaktionspunkte im System, wodurch die Oberfläche für Fehlfunktionen oder Fehlkonfigurationen erhöht wird.

  • Workloadkomponenten, die für die unabhängige Weiterentwicklung entwickelt wurden, um agile Entwicklung und Hosting zu unterstützen, führen Abhängigkeiten von der Dienstermittlung oder sogar von DNS als Dereferenzierungsebene ein. Bei der Dienstermittlung fehlt möglicherweise die Reaktionsfähigkeit auf Änderungen, und Fehlfunktionen können schwer zu diagnostizieren sein.

Kompromiss: Erhöhte potenziell destabilisierende Aktivitäten. Die Säule Zuverlässigkeit fördert die Vermeidung von Aktivitäten oder Entwurfsentscheidungen, die ein System destabilisieren und zu Störungen, Ausfällen oder Fehlfunktionen führen können.

  • Das Bereitstellen kleiner, inkrementeller Änderungen ist eine Technik zur Risikominderung, aber diese kleinen Änderungen werden auch häufiger in die Produktion übermittelt. Bereitstellungen können ein System destabilisieren, sodass die Bereitstellungsrate zunimmt, auch dieses Risiko.

  • Eine Kultur, die sich selbst mit 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.

  • Die Erhöhung der Dichte zur Vereinfachung von Vorgängen durch Verringerung der Anzahl von Kontroll- und Beobachtbarkeitsflächen kann auch zu einem erhöhten Verfügbarkeitsrisiko führen, da Fehlfunktionen oder Fehlkonfigurationen den Auswirkungsradius eines destabilisierenden Ereignisses erhöhen.

Operational Excellence-Kompromisse mit Sicherheit

Kompromiss: Vergrößerte Oberfläche. Die Säule Sicherheit empfiehlt eine reduzierte Arbeitsauslastungsoberfläche in Bezug auf Komponenten und Die Exposition gegenüber Vorgängen. Diese Reduzierung minimiert Angriffsvektoren und führt zu einem geringeren Umfang für Sicherheitskontrollen und -tests.

  • 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 die regelmäßige Sicherheitshärtung und -tests fallen.

  • Routine-, Ad-hoc- und Notfallvorgänge erhöhen die Berührungspunkte mit der Workload. Ein Zero Trust-Ansatz erfordert, dass diese Prozesse als Angriffsvektoren betrachtet werden und in die Sicherheitskontrollen und die Validierung für die Workload einbezogen werden müssen.

  • Die Beobachtbarkeitsplattform des Systems sammelt Protokolle und Metriken zur Workload, die eine wertvolle Quelle für die Offenlegung von Informationen sein kann. 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 sowie parallele Bereitstellungsansätze erhöhen die Anwendungsoberfläche, die Sicherheit erfordert.

  • Eine höhere Bereitstellungshäufigkeit, die durch kleine, inkrementelle Änderungen oder durch "Aktuelles abrufen, auf dem neuesten Stand bleiben" verursacht wird, führt zu mehr Sicherheitstests im Softwareentwicklungslebenszyklus.

Kompromiss: Erhöhter Wunsch nach Transparenz. Eine sichere Workload basiert auf Entwürfen, die die Vertraulichkeit von Daten schützen, die durch die Komponenten des Systems fließen.

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.

Kompromiss: Reduzierte Segmentierung. Ein wichtiger Sicherheitsansatz zum Isolieren von Zugriff und Funktion ist die Entwicklung einer starken Segmentierungsstrategie. Dieser Entwurf wird durch Ressourcenisolation und Identitätskontrollen implementiert.

  • Die gemeinsame Lokalisierung unterschiedlicher Anwendungskomponenten in freigegebenen Compute-, Netzwerk- 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 freigeben, 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. Dies kann es jedoch auch erschweren oder unmöglich machen, zeilenbasierte Sicherheit bereitzustellen, um vertrauliche Daten mit den erforderlichen Überwachungskontrollen 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.

Operational Excellence-Kompromisse bei der Kostenoptimierung

Die Säule Operational Excellence empfiehlt niemals Aktivitäten, die die Produktivität verringern oder die Rendite einer Workload gefährden. Empfehlungen, die den Fokus von Bereitstellungsaktivitäten zu verlagern scheinen, berücksichtigen langfristig die besten Interessen für die Workload und das Team. Wenn sich Ihr Workload dem Ablaufdatum nähert, ist es wahrscheinlich nicht sinnvoll, in Empfehlungen zu investieren, die diese Kompromisse auslösen.

Kompromiss: Erhöhte Ressourcenausgaben. Ein wichtiger Kostenfaktor für eine Workload sind die Kosten ihrer Ressourcen. Die Bereitstellung von weniger Ressourcen, die richtige Größenanpassung von Ressourcen und die Verringerung des Verbrauchs tragen im Allgemeinen dazu bei, die Kosten niedrig zu halten.

  • Die Implementierung sicherer Bereitstellungsmethoden, auch wenn die Änderungen relativ klein sind, kann zu einer Erhöhung der Anzahl von Ressourcen führen, die gleichzeitig bereitgestellt werden. Diese Muster erfordern die Bereitstellung mehrerer gleichzeitiger Instanzen der Anwendungs- oder Infrastrukturkomponente, damit der Datenverkehr kontrolliert verschoben werden kann. Dieser Anstieg ist in einer Workload deutlicher, die einen unveränderlichen Infrastrukturansatz verwendet.

  • Das Team muss möglicherweise zusätzliche Workloadkomponenten einführen, um betriebsorientierte Cloudentwurfsmuster oder Workloadautomatisierung zu implementieren. Um die Flexibilität der Bereitstellung zu unterstützen, können sie beispielsweise eine Gatewayroutingkomponente hinzufügen. Zur Unterstützung einer besseren Konfigurationsverwaltung wird möglicherweise ein externer Konfigurationsspeicher hinzugefügt. Zur Unterstützung von Mandantenlebenszyklusereignissen können sie eine Steuerungsebene erstellen. Diese Ressourcen beeinflussen auch die Kosten von Präproduktionsumgebungen.

  • Wenn Sie die Anzahl von Präproduktionsumgebungen erhöhen, um die Entwicklungs- und Testerfahrung durch Isolation zu verbessern, erhöht sich auch die Anzahl der Ressourcen. Diese Ressourcen, die nicht verwendet werden, um das Angebot gegenüber der Produktionsnachfrage zu liefern, erhöhen die Kosten der Lösung.

  • Die Erhöhung der Parität von Präproduktionsumgebungen mit der Produktionsumgebung in Bezug auf Ressourcenanzahl, SKUs und Datenvolumen verbessert den Qualitätssicherungsprozess. Die Kosten steigen, wenn die Parität zunimmt.

  • Obwohl Telemetriedaten keine direkte Ressource sind, müssen diese Daten beibehalten werden, um die Effektivität von Beobachtbarkeitsplattformen zu ermöglichen. Für die meisten operativen Datenspeicher gelten Preise, die auf einer Kombination aus Erfassungsraten und Volumen basieren. Mit zunehmender Anzahl von Telemetriedaten mit geringer Latenz und hoher Vielfalt steigen im Allgemeinen auch die Kosten. Bei Bereitstellungen in mehreren Regionen wird erwartet, dass diese Operativen Datensenken pro Region bereitgestellt werden, sodass alle Ressourcenkosten zu einem Faktor werden.

Kompromiss: Verringerter Fokus auf Übermittlungsaktivitäten. Workloadteammitglieder bieten einen höheren Workloadwert, indem sie Aufgaben effizient ausführen, die auf ihre Funktionen abgestimmt sind.

  • Workloadteams, die Zeit damit verbringen, eine fehlerfreie und verantwortungsvolle Supportstruktur und Reaktion auf Vorfälle zu erstellen und zu verfeinern, stellen den Benutzern der Workload einen wertvollen Dienst zur Verfügung. Wenn der Supportaufwand zunimmt (z. B. formelle Bereitschaftsrotationen), in der Regel aufgrund einer Änderung der Unternehmenskritikalität, steigen die Kosten dieser Aktivitäten. Diese Kostensteigerung kann das Ergebnis einer Personalaufstockung sein oder indirekt in Form von Aufmerksamkeit entstehen, die von den Bereitstellungsaktivitäten zu unterstützenden Funktionen verlagert wird.

  • Schulungen sind ein wichtiger Bestandteil des persönlichen kontinuierlichen Verbesserungsprozesses eines Workloadteams. Dieses Training kann während der persönlichen Anreicherungszeit formal oder selbstgesteuert sein. Wenn die Trainingszeit zunimmt, verringert sich die Zeit, die für die direkte Entwicklung der Workload zur Verfügung steht. Die Investitionen in Schulungen werden verringert, wenn die Schulung nicht rollenbasiert oder speziell für die Workload oder ihre Zukunft relevant ist.

  • Standardisierte routinebetriebsbezogene Aufgaben zum Schutz der Zuverlässigkeit, Sicherheit und Leistungseffizienz einer Workload benötigen Zeit, um zu definieren, zu verfeinern und auszuführen. Diese Zeit wird nicht direkt für die Lieferung aufgewendet. Beispiele für diese Aufgaben sind eine umfassende Analyse der Auswirkungen auf Änderungen, Prozesse zur Änderungssteuerung, gründliche Tests und eine erweiterte Patchverwaltung. Mit zunehmender Häufigkeit, Vollständigkeit oder betrieblicher Belastung dieser Aufgaben nimmt auch die investierte Zeit zu.

Kompromiss: Erhöhte Anforderungen an Tools und Vielfalt. Die Säule "Kostenoptimierung" empfiehlt die Verringerung der Zersiedelung von Tools, die Konsolidierung der Anbieter und einen richtigen Ansatz für alle Werkzeugkäufe.

Ein Workloadteam kauft Tools und Hardware zur Unterstützung von Aktivitäten, die während des gesamten Softwareentwicklungslebenszyklus (SDLC) ausgeführt werden, einschließlich Planung und Entwurf, Entwicklung und Tests sowie Überwachung. Der Marketplace für Tools in diesem Bereich wächst. Tools werden zu verschiedenen Preisen angeboten, die in der Regel den Funktionen und Funktionen der Tools entsprechen. Mit Ausnahme von kostenlosen Angeboten fallen für diese Tools Anfängliche Lizenzierungskosten an, die pro Arbeitsplatz oder websiteweit sein können. Häufig sind auch laufende Wartungsverträge erforderlich. Möglicherweise müssen neue Lieferantenbeziehungen eingerichtet werden. Im Folgenden finden Sie einige Beispiele für erwartete Tool- oder Hardwareausgaben, die mit den Prinzipien der operativen Exzellenz verbunden sind:

  • Anforderungs- und Backlogverwaltung
  • Architekturentwurfstools
  • Ui/UX-Designtools
  • Hosten von Code und Medienobjekten
  • Code- und Low-Code-Entwicklungsumgebungen
  • Automatisierungstools
  • Entwicklungs- und Qualitätssicherungsarbeitsplätze
  • Entwicklungs- und Bereitstellungspipelines
  • Testausführung und -nachverfolgung
  • Observability-Tools

Operational Excellence-Kompromisse mit Leistungseffizienz

Kompromiss: Erhöhter Ressourcenverbrauch. Die Säule "Leistungseffizienz" empfiehlt, den Anforderungen der Workload so viel wie möglich des verfügbaren Computes und Netzwerks zuzuweisen.

  • Das Beobachtbarkeitsframework einer Workload erfordert, dass die Komponenten in der Architektur Zeit und Ressourcen zum Erstellen, Sammeln und Streamen von Protokollen und Metriken zuordnen. Diese Datenpunkte tragen dazu bei, dass eine effektive Warnung und Überwachung in Bezug auf Zuverlässigkeit, Sicherheit und Leistung möglich ist. Wenn die Instrumentierungsstufe zunimmt, kann auch die Belastung der Systemressourcen zunehmen.

  • Einige Bereitstellungsmodelle, z. B. blau/grün, die eine Workload für eine sichere Bereitstellung verwenden kann, können parallele Bereitstellungen auf der Produktionsanwendungsplattform einführen. Diese Bereitstellungen erfordern eine präemptive Skalierung, um genügend Angebot für die zukünftige Nachfrage bereitzustellen, oder eine größtenteils ruhende Bereitstellung für einen bestimmten Zeitraum zur Unterstützung des Rollbacks zu belassen.

Kompromiss: Erhöhte Latenz. Um leistungsfähige Workloads zu erstellen, suchen Teams nach Möglichkeiten, die Zeit und die Ressourcen zu reduzieren, die Workloads für die Ausführung ihrer Aufgaben benötigen.

  • Viele Bereitstellungsmodelle erfordern die Verwendung von Zugriffsmustern für das Gatewayrouting, was zu Latenz führen kann. Diese Latenz bezieht sich auf das Leistungszielbudget für die zugehörigen Flows.

  • Einige Cloudentwurfsmuster, die Ansätze für "unabhängige Änderungen im Zeitverlauf" unterstützen, um die Ideale der inkrementellen Verbesserung zu unterstützen, können aufgrund des Durchlaufens zusätzlicher Komponenten latenzen. Diese Latenz kann durch Gateways, Messagingbroker oder Antikorruptionsebenen eingeführt werden.

Erkunden Sie die Kompromisse für die anderen Säulen: