Freigeben über

Kompromisse beim optimalen Betrieb

  • Artikel

Operational Excellence bietet Arbeitsauslastungsqualität durch die Implementierung klarer Teamstandards, verstandener Verantwortung und Rechenschaftspflicht, Aufmerksamkeit auf Kundenergebnisse und Teamzusammenhalt. Die Implementierung dieser Ziele ist in DevOps verwurzelt, was die Minimierung der Prozessabweichung, die Verringerung des menschlichen Fehlers und letztendlich die Rückgabe des Werts für die Workload empfiehlt. Dieser Wert wird nicht nur anhand der funktionalen Anforderungen gemessen, die von den Komponenten der Workload bereitgestellt werden. Es wird auch durch den Wert gemessen, den das Team nach Verbesserungsbedarf liefert.

Während der Entwurfsphase einer Arbeitsauslastung und ihres Lebenszyklus ist es wichtig zu berücksichtigen, wie Entscheidungen, die auf den Designprinzipien der Operational Excellence basieren, und die Empfehlungen in der Prüfliste für die Designüberprüfung für Operational Excellence die Ziele und Optimierungen anderer Säulen beeinflussen können. Bestimmte Entscheidungen können einigen Säulen zugute kommen, stellen aber Gegensätze für andere dar. In diesem Artikel werden Beispiel-Kompromisse beschrieben, auf die ein Workloadteam beim Entwerfen der Workloadarchitektur und -vorgänge stoßen kann.

Operative Exzellenz-Kompromisse mit Zuverlässigkeit

Kompromiss: Erhöhte Komplexität. Zuverlässigkeit priorisiert Einfachheit, da einfaches Design fehlkonfiguriert und unerwartete Interaktionen reduziert.

  • Sichere Bereitstellungsstrategien erfordern häufig eine menge Vorwärts- und Abwärtskompatibilität zwischen Anwendungslogik und Daten in der Workload. Dadurch erhöht sich die Komplexität der Tests und kann zu Komplexitäts- oder Integritätsproblemen mit den Daten der Workload führen.

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

  • Clouddesignmuster, die von Vorgängen profitieren, erfordern manchmal die Einführung zusätzlicher Komponenten, z. B. die Verwendung eines externen Konfigurationsspeichers oder die Koordination von Sidecar-Bereitstellungen in einer containerisierten Anwendungsplattform. Die zusätzlichen Komponenten und hinzugefügten Ebenen der Dereferenzierung erhöhen die Interaktionspunkte im System, wodurch die Oberfläche für Fehlfunktionen oder Fehlkonfigurationen erhöht wird.

  • Workload-Komponenten, die sich unabhängig entwickeln sollen, um agile Entwicklung und Hosting zu unterstützen, führen Abhängigkeiten von der Dienstermittlung als Dereferenzierungsebene ein. Die Dienstermittlung fehlt möglicherweise an Reaktionsfähigkeit, und Fehlfunktionen können schwer zu diagnostizieren sein.

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

  • Die Bereitstellung kleiner, inkrementeller Änderungen ist eine Technik zur Risikominderung, aber diese kleinen Änderungen werden voraussichtlich häufiger an die Produktion übermittelt. Bereitstellungen können ein System destabilisieren, sodass sich die Bereitstellungsrate erhöht, sodass dieses Risiko besteht.

  • Eine Kultur, die sich mit Geschwindigkeitsmetriken wie Bereitstellungen pro Woche misst und Automatisierung verwendet, die die Einführung von Änderungen in einem schnelleren Tempo erleichtern kann, ist wahrscheinlich auch, dass mehr Bereitstellungen in einem kürzeren Zeitraum ausgeführt werden.

  • Eine zunehmende Dichte zur Vereinfachung des Betriebs durch Verringerung der Anzahl der Kontroll- und Observierbarkeitsflächen kann auch zu einem erhöhten Verfügbarkeitsrisiko führen, da Fehlfunktionen oder Fehlkonfigurationen den Auswirkungsradius eines destabilisierenden Ereignisses erhöhen.

Operative Exzellenz-Kompromisse mit Sicherheit

Kompromiss: Erhöhte Fläche. Die Säule "Sicherheit" empfiehlt eine reduzierte Arbeitslastfläche in Bezug auf Komponenten und Die Exposition gegenüber Vorgängen. Diese Reduzierung minimiert Angriffsvektoren und erzeugt einen kleineren Bereich für die Sicherheitskontrolle und -tests.

  • Komponenten, die die Workload umgeben und ihre Vorgänge unterstützen, z. B. Automatisierung oder eine benutzerdefinierte Steuerungsebene, müssen auch im Bereich der regelmäßigen Sicherheitshärtung und -tests stehen.

  • Routine-, Ad-hoc- und Notfalloperationen erhöhen die Kontaktpunkte mit der Arbeitsauslastung. 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 Observability-Plattform des Systems sammelt Protokolle und Metriken über die Workload, was 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.

  • Erstellen Von Agents, externen Konfigurations- und Feature-Umschaltern und parallelen Bereitstellungsansätzen erhöhen Sie den Anwendungsoberflächenbereich, der Sicherheit erfordert.

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

Kompromiss: Größerer Wunsch nach Transparenz. Eine sichere Workload basiert auf Designs, die die Vertraulichkeit von Daten schützen, die durch die Komponenten des Systems fließen.

Observability-Plattformen sammeln Daten aller Typen, um Einblicke in die Integrität und das Verhalten einer Workload zu erhalten. Da Teams versuchen, eine höhere Genauigkeit bei Observability-Daten zu erreichen, besteht ein erhöhtes Risiko, dass Die Datenklassifizierungssteuerelemente wie datenformatieren die Quellsysteme nicht auf die Protokolle und Protokollenken der Observability-Plattform erweitern.

Tradeoff: Reduzierte Segmentierung. Ein wichtiger Sicherheitsansatz zum Isolieren von Zugriff und Funktion besteht darin, eine starke Segmentierungsstrategie zu entwerfen. Dieser Entwurf wird durch Ressourcenisolation und Identitätssteuerelemente implementiert.

  • Die gemeinsame Suche nach unterschiedlichen Anwendungskomponenten in gemeinsam genutzten Compute-, Netzwerk- und Datenressourcen erleichtert die Verwaltung der Segmentierung oder macht die Rollenbasierte Segmentierung schwieriger zu erreichen. Gemeinsame Komponenten müssen möglicherweise auch eine Workloadidentität freigeben, was zu einer Überzuweisung von Berechtigungen oder zu einem Mangel an Rückverfolgbarkeit 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 jedoch auch schwieriger oder unmöglich machen, zeilenbasierte Sicherheit bereitzustellen, um vertrauliche Daten mit den erforderlichen Überwachungssteuerelementen zu behandeln.

  • Die Vereinfachung der Verwaltung attributbasierter oder rollenbasierter Sicherheit, indem die Granularität von Rollen und deren Zuweisungen reduziert werden, kann zu unangemessen breiten Berechtigungen führen.

Operative Exzellenz-Kompromisse mit Kostenoptimierung

Die Säule Operational Excellence empfiehlt niemals Aktivitäten, die die Produktivität reduzieren oder die Rendite einer Arbeitsauslastung gefährden. Empfehlungen, die den Fokus von den Übermittlungsaktivitäten verschieben, berücksichtigen langfristige beste Interessen für die Arbeitsauslastung und das Team. Wenn sich Ihre Workload dem Sonnenuntergangstermin nähert, ist es wahrscheinlich nicht sinnvoll, in Empfehlungen zu investieren, die diese Kompromisse auslösen.

Kompromiss: Erhöhte Ressourcenausgaben. Ein wichtiger Kostentreiber für eine Arbeitsauslastung ist die Kosten seiner Ressourcen. Durch die Bereitstellung von weniger Ressourcen, die richtige Größenanpassung von Ressourcen und die Verringerung des Verbrauchs wird im Allgemeinen die Kosten niedrig gehalten.

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

  • Das Team muss möglicherweise zusätzliche Workloadkomponenten einführen, um betriebsbereit ausgerichtete Clouddesignmuster oder Workloadautomatisierung zu implementieren. Um beispielsweise die Flexibilität der Bereitstellung zu unterstützen, können sie eine Gatewayroutingkomponente hinzufügen. Um eine bessere Konfigurationsverwaltung zu unterstützen, fügen sie möglicherweise einen externen Konfigurationsspeicher hinzu. Um Mandantenlebenszyklusereignisse zu unterstützen, erstellen sie möglicherweise eine Steuerungsebene. Diese Ressourcen beeinflussen auch die Kosten für Vorproduktionsumgebungen.

  • Die Erhöhung der Anzahl der Vorproduktionsumgebungen zur Verbesserung der Entwicklungs- und Testerfahrung durch Isolierung erhöht auch die Anzahl der Ressourcen. Diese Ressourcen, die nicht für die Lieferung von Angebot an produktionsbezogene Nachfrage verwendet werden, erhöhen die Kosten der Lösung.

  • Die Erhöhung der Parität von Vorproduktionsumgebungen mit der Produktionsumgebung im Hinblick auf die Ressourcenanzahl, SKUs und Datenvolumes verbessert den Qualitätssicherungsprozess. Die Kosten steigen, wenn die Parität steigt.

  • Obwohl Telemetriedaten nicht direkt eine Ressource sind, müssen diese Daten beibehalten werden, um die Effektivität von Observability-Plattformen zu ermöglichen. Die meisten betriebsbereiten Datenspeicher verfügen über Preise, die auf einer Kombination aus Aufnahmeraten und Volumen basieren. Im Allgemeinen erhöhen sich auch die Kosten, da die Anzahl der Telemetrie mit geringer Latenz steigt. Bei Bereitstellungen mit mehreren Regionen werden diese Betriebsdatensenken voraussichtlich pro Region bereitgestellt, sodass die Kosten pro Ressource zu einem Faktor werden.

Tradeoff: Verringerter Fokus auf Lieferaktivitäten. Workload-Teammitglieder bieten einen erhöhten Workload-Wert, indem aufgaben effizient ausgeführt werden, die an ihre Funktionen ausgerichtet sind.

  • Arbeitsauslastungsteams, die Zeit für das Erstellen und Verfeinern einer fehlerfreien und verantwortungsvollen Supportstruktur und Reaktion auf Vorfälle verbringen, bieten den Benutzern der Workload einen wertvollen Dienst. Da sich der Supportaufwand erhöht (z. B. formale On-Call-Drehungen), in der Regel aufgrund einer Änderung der GeschäftskritischenItät, erhöhen sich die Kosten dieser Aktivitäten. Diese Kostenerhöhung kann das Ergebnis einer Erhöhung des Personals sein oder indirekt in Form von Aufmerksamkeit entstehen, die sich von Denlieferungsaktivitäten auf unterstützende Funktionen verlagert.

  • Die Schulung ist ein wichtiger Bestandteil des persönlichen kontinuierlichen Verbesserungsprozesses eines Arbeitsauslastungsteams. Diese Schulung kann während der persönlichen Anreicherungszeit formal oder selbstgesteuert sein. Da sich die Schulungszeit erhöht, verringert sich die für die direkte Entwicklung der Arbeitsauslastung verfügbare Zeit. Die Investitionen in die Ausbildung werden verringert, wenn die Schulung nicht rollenbasiert oder speziell für die Arbeitsauslastung oder ihre Zukunft relevant ist.

  • Standardisierte Routinevorgänge zum Schutz der Zuverlässigkeit, Sicherheit und Leistungseffizienz einer Arbeitsauslastung erfordern zeitaufwendigt, verfeinern und ausführen. Diese Zeit wird nicht direkt für die Lieferung ausgegeben. Einige Beispiele für diese Aufgaben sind umfassende Änderungsauswirkungsanalyse, Änderungskontrollesprozesse, gründliche Tests und erhöhte Patchverwaltung. Da sich die Häufigkeit, Vollständigkeit oder operative Belastung dieser Aufgaben erhöht, steigt auch die zeitaufwendigte Zeit.

Kompromiss: Erhöhte Werkzeuganforderungen und Vielfalt. Die Säule "Kostenoptimierung" empfiehlt die Reduzierung der Werkzeugverwüstung, die Konsolidierung von Lieferanten und einen richtigen Ansatz für alle Werkzeugkäufe.

Ein Workload-Team kauft Tools und Hardware, um Aktivitäten zu unterstützen, die während des gesamten Softwareentwicklungslebenszyklus (SDLC) durchgeführt werden, einschließlich Planung und Entwurf, Entwicklung und Tests und Überwachung. Der Markt für Werkzeugbau in diesem Raum wächst. Tools werden zu verschiedenen Preisen angeboten, die in der Regel den Funktionen und Funktionen der Tools entsprechen. Mit Ausnahme von kostenlosen Angeboten entstehen diese Tools anfängliche Lizenzierungskosten, die pro Benutzer, pro Gerät oder standortweit sein können. Sie erfordern häufig auch laufende Wartungsverträge. Möglicherweise müssen neue Lieferantenbeziehungen eingerichtet werden. Hier sind einige Beispiele für erwartete Werkzeug- oder Hardwareausgaben, die den Prinzipien der operativen Exzellenz zugeordnet sind:

  • Anforderungen und Backlogverwaltung
  • Architekturentwurfstools
  • Benutzeroberflächen-/UX-Designtools
  • Code- und Objekthosting
  • Code- und Low-Code-Entwicklungsumgebungen
  • Automatisierungstools
  • Arbeitsstationen für Entwicklung und Qualitätssicherung
  • Entwicklungs- und Bereitstellungspipelinen
  • Testen der Ausführung und Nachverfolgung
  • Observability Tools

Operative Exzellenz-Tradeoffs mit Leistungseffizienz

Kompromiss: Erhöhte Ressourcenauslastung. Die Säule "Leistungseffizienz" empfiehlt die Zuweisung eines möglichst viel verfügbaren Computes und Netzwerks für die Anforderungen der Workload.

  • Das Observability Framework 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 effektive Warnungen und Überwachungen für Zuverlässigkeit, Sicherheit und Leistung möglich sind. Da sich das Instrumentierungsniveau erhöht, kann sich auch die Belastung der Systemressourcen erhöhen.

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

Kompromiss: Erhöhte Latenz. Um leistungsfähige Arbeitslasten zu erstellen, suchen Teams nach Möglichkeiten, um die Zeit und Ressourcen zu reduzieren, die Workloads zum Ausführen ihrer Aufgaben verbrauchen.

  • 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 Flüsse.

  • Einige Clouddesignmuster, die "unabhängige Änderung im Laufe der Zeit" unterstützen, um die Idealen der inkrementellen Verbesserung zu unterstützen, können aufgrund der Durchquerung zusätzlicher Komponenten Latenzen auslösen. Diese Latenz kann durch Gateways, Messagingbroker oder Antischadsoftwareebenen eingeführt werden.

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