Die geschäftliche Verpflichtung in der Cloudverwaltung

Die Definition einer geschäftlichen Verpflichtung ist eine Übung des Ausbalancierens von Prioritäten. Das richtige Betriebsverwaltungsniveau muss zu akzeptablen Betriebskosten erzielt werden. Hier die Balance zu finden, erfordert einige Datenpunkte und Berechnungen, die wir in diesem Artikel beschrieben haben.

Verpflichtungen gegenüber der Geschäftsstabilität durch technische Resilienz oder andere Auswirkungen auf die Vereinbarung zum Servicelevel (SLA) basieren auf einer geschäftlichen Begründung. Für die meisten Workloads in einer Umgebung ist eine Basiscloudverwaltung ausreichend. Für andere lassen sich 2- bis 4-fache Kosten aufgrund der möglichen Auswirkungen in Form von Geschäftsunterbrechungen mühelos rechtfertigen.

Die vorherigen Artikel in dieser Serie können Ihnen helfen, die Klassifizierung und Auswirkung von Unterbrechungen bei verschiedenen Workloads zu verstehen. Dieser Artikel hilft Ihnen bei der Berechnung der Ergebnisse. Wie in der vorherigen Abbildung dargestellt, gibt es auf jeder Ebene der Cloudverwaltung Wendepunkte, bei denen die Kosten schneller ansteigen können als die Resilienz. Diese Wendepunkte fordern ausführliche Geschäftsentscheidungen und Geschäftsverpflichtungen.

Bestimmen einer angemessenen Verpflichtung gegenüber dem Unternehmen

Für jede Workload im Portfolio sollten sich das Cloudbetriebsteam und das Cloudstrategieteam an der Verwaltungsebene ausrichten, die direkt vom Cloudbetriebsteam bereitgestellt wird.

Im Folgenden sind die wichtigsten Aspekte aufgeführt, die beim Aufstellen einer Verpflichtung gegenüber dem Unternehmen zu berücksichtigen sind:

• IT-Betriebsvoraussetzungen
• Verwaltungsverantwortlichkeit
• Cloudmandant
• Weiche Kostenfaktoren
• ROI bei Verlustvermeidung
• Validierung der Verwaltungsebene

Als Unterstützung für Ihren Entscheidungsprozess werden diese Aspekte im weiteren Verlauf dieses Artikels eingehender beschrieben.

IT-Betriebsvoraussetzungen

Im Azure-Verwaltungsleitfaden werden die in Azure verfügbaren Verwaltungstools beschrieben. Bevor eine Verpflichtung gegenüber dem Unternehmen formuliert wird, sollte die IT-Abteilung eine akzeptable Verwaltungsbaseline auf Standardniveau festlegen, die auf alle verwalteten Workloads angewendet werden soll. Anschließend sollte die IT basierend auf der Anzahl von CPU-Kernen, dem Speicherplatz auf dem Datenträger und anderen ressourcenbezogenen Variablen für jede der verwalteten Workloads im IT-Portfolio die Standardverwaltungskosten berechnen. Außerdem sollte für jede Workload basierend auf der Architektur eine zusammengesetzte SLA geschätzt werden.

Die Betriebsverwaltungsbaseline dient als Ausgangspunkt, der in jedem der folgenden Abschnitte überprüft wird.

Verwaltungsverantwortlichkeit

In einer herkömmlichen lokalen Umgebung werden die Kosten für die Verwaltung der Umgebung häufig als versunkene Kosten des IT-Betriebs angesetzt. In der Cloud ist die Verwaltung eine gezielte Entscheidung mit direkten Auswirkungen auf das Budget. Die Kosten der einzelnen Verwaltungsfunktionen können den einzelnen in der Cloud ausgeführten Workloads direkter zugeordnet werden. Dieser Ansatz ermöglicht eine bessere Kontrolle, stellt jedoch an Cloudbetriebsteams und Cloudstrategieteams die Anforderung, zunächst eine Verpflichtung zu einer Vereinbarung über Zuständigkeiten einzugehen.

Organisationen können auch entscheiden, einige ihrer laufenden Verwaltungsfunktionen an einen Dienstanbieter auszulagern. Diese Dienstanbieter können Organisationen mit Azure Lighthouse ermöglichen, den Zugriff auf ihre Ressourcen genauer zu steuern sowie einen umfassenderen Einblick in die von den Dienstanbietern ausgeführten Aktionen zu erhalten.

• Delegierte Verantwortung: Da es nicht erforderlich ist, zu zentralisieren und einen Mehraufwand für die Betriebsverwaltung vorauszusetzen, erwägen die IT-Abteilungen vieler Organisationen neue Ansätze. Ein gängiger Ansatz wird als Delegierte Verantwortung bezeichnet. In einem Modell mit Cloudkompetenzzentrum bieten Plattformvorgänge und Plattformautomatisierung Self-Service-Verwaltungstools, die unabhängig von einem zentralen IT-Betriebsteam von geschäftsorientierten Betriebsteams genutzt werden können. Dieser Ansatz ermöglicht den Beteiligten im Unternehmen eine umfassende Kontrolle verwaltungsrelevanter Budgets. Außerdem kann das Cloudkompetenzzentrum (CCoE) so sicherstellen, dass ein minimaler Satz von Schutzmaßnahmen ordnungsgemäß implementiert wird. In diesem Modell fungiert die IT als Broker und Führer, um dem Unternehmen zu helfen, vernünftige Entscheidungen zu treffen. Geschäftsvorgänge überwachen tägliche Vorgänge abhängiger Workloads.

• Zentralisierte Verantwortung: Complianceanforderungen, technische Komplexität und einige freigegebene Dienstmodelle erfordern möglicherweise ein Modell mit einem zentralen IT-Team. In diesem Modell nimmt die IT-Abteilung weiterhin ihre Verantwortlichkeiten für die Betriebsverwaltung wahr. Umgebungsentwurf, Verwaltungskontrollen und Governancetools können zentral verwaltet und gesteuert werden, was die Rolle der Beteiligten im Unternehmen einschränkt, wenn Verpflichtungen zur Verwaltung eingegangen werden. Die Transparenz hinsichtlich Kosten und Architektur von Cloudansätzen erleichtern es der zentralisierten IT stark, die Kosten und Verwaltungsebene für die einzelnen Workloads zu kommunizieren.

• Gemischtes Modell: Die Klassifizierung ist der Kern eines gemischten Modells für Verantwortlichkeiten für die Betriebsverwaltung. Unternehmen, die sich mitten im Wandel von „lokal“ zur Cloud befinden, benötigen möglicherweise für eine Weile ein „Zuerst lokal“-Betriebsmodell. Unternehmen mit strengen Complianceanforderungen oder die von langfristigen Verträgen mit IT-Outsourcinganbietern abhängen, benötigen möglicherweise ein zentralisiertes Betriebsmodell.

  Unabhängig von ihren Einschränkungen müssen Unternehmen heute innovativ sein. Wenn eine schnelle Innovation mitten in einem Modell einer zentralen IT mit zentralisierter Verantwortung gedeihen muss, könnte ein gemischter Ansatz für ein Gleichgewicht sorgen. Bei diesem Ansatz stellt ein zentrales IT-Team ein zentralisiertes Betriebsmodell für alle Workloads bereit, die unternehmenskritisch sind oder vertrauliche Informationen enthalten. Gleichzeitig können alle anderen Klassifizierungen der Workload in einer Cloudumgebung platziert werden, die für delegierte Verantwortlichkeiten entworfen wurde. Der Ansatz der zentralisierten Verantwortlichkeit dient als allgemeines Betriebsmodell. Das Unternehmen besitzt dann die Flexibilität, ein spezialisiertes Betriebsmodell basierend auf dem erforderlichen Niveau von Unterstützung und Vertraulichkeit anzunehmen.

Der erste Schritt besteht in der Verpflichtung zu einem Verantwortlichkeitsansatz, der dann die folgenden Verpflichtungen prägt.

Welche Organisation ist für diese Workload für die tägliche Betriebsverwaltung verantwortlich?

Cloudmandant

Bei den meisten Unternehmen ist die Verwaltung einfacher, wenn sich alle Ressourcen in einem einzigen Mandanten befinden. Allerdings müssen einige Organisationen möglicherweise mehrere Mandanten verwalten. Informationen dazu, warum ein Unternehmen eine mehrinstanzenfähige Azure-Umgebung benötigt, finden Sie unter Zentralisieren von Verwaltungsvorgängen mit Azure Lighthouse.

Befindet sich diese Workload neben allen anderen Workloads in einem einzelnen Azure-Mandanten?

Weiche Kostenfaktoren

Im nächsten Abschnitt wird ein Ansatz für Vergleichsrenditen erläutert, die Ebenen von Verwaltungsprozessen und Tools zugeordnet sind. Am Ende dieses Abschnitts werden für jede analysierte Workload die Kosten der Verwaltung im Vergleich zu den vorhergesagten Auswirkungen von Geschäftsunterbrechungen gemessen. Dieser Ansatz ist eine relativ einfache Methode, um zu verstehen, ob eine Investition in aufwändigere Verwaltungsansätze gerechtfertigt ist.

Vor dem Ausführen der Zahlen ist es wichtig, die weichen Kostenfaktoren zu betrachten. Weiche Kostenfaktoren erzeugen eine Rendite, aber diese Rendite ist schwierig in direkten Kosteneinsparungen zu messen, die in einer Gewinn-und-Verlust-Rechnung sichtbar wären. Weiche Kostenfaktoren sind wichtig, da sie darauf hindeuten können, dass in eine höhere Verwaltungsebene investiert werden muss, als fiskalisch klug ist.

Einige Beispiele für diese weichen Kostenfaktoren sind:

• Tägliche Verwendung einer Workload durch den Vorstand oder den CEO.
• Nutzung einer Workload durch die größten x % von Kunden, was an anderer Stelle größere Auswirkungen auf den Umsatz nach sich zieht.
• Auswirkung auf die Zufriedenheit der Mitarbeiter.

Der nächste Datenpunkt, der erforderlich ist, um eine Verpflichtung einzugehen, ist eine Liste der weichen Kostenfaktoren. Diese Faktoren müssen in dieser Phase nicht dokumentiert werden, aber der Geschäftsbeteiligte sollte die Wichtigkeit dieser Faktoren und deren Ausschluss aus den folgenden Berechnungen beachten.

Berechnen des ROI bei Verlustvermeidung

Beim Berechnen der relativen Rendite der Betriebsverwaltungskosten sollte das für die Cloud verantwortliche IT-Team dafür sorgen, dass die zuvor genannten Voraussetzungen erfüllt sind, und für alle Workloads von einer minimalen Verwaltungsebene ausgehen.

Die nächste Verpflichtung ist die Akzeptanz der Kosten, die mit dem Baselineverwaltungsangebot verbunden sind, durch das Unternehmen.

Ist das Unternehmen damit einverstanden, in das Baselineangebot zu investieren, um die Mindestanforderungen der Cloudvorgänge zu erfüllen?

Wenn das Unternehmen dieser Verwaltungsebene nicht zustimmt, muss eine Lösung entwickelt werden, mit der das Unternehmen fortfahren kann, ohne dass die Cloudvorgänge anderer Workloads wesentlich beeinträchtigt werden.

Wenn das Unternehmen mehr als die Standardverwaltungsebene wünscht, hilft der Rest dieses Abschnitts bei der Überprüfung dieser Investition und der damit verbundenen Rendite (in Form der Verlustvermeidung).

Höhere Verwaltungsebenen: Entwurfsprinzipien und Dienstkatalog

Für verwaltete Lösungen gibt es mehrere Entwurfsprinzipien und Vorlagenlösungen, die zusätzlich zur Verwaltungsbaseline angewendet werden können. Jedes dieser Entwurfsprinzipien für Zuverlässigkeit und Resilienz erhöht die Betriebskosten für die Workload. Damit IT und Unternehmen diesen zusätzlichen Verpflichtungen zustimmen, ist es wichtig, potenzielle Verluste zu verstehen, die mit dieser höheren Investition vermieden werden können.

In den folgenden Berechnungen werden Formeln erläutert, die Ihnen dabei helfen, die Unterschiede zwischen Verlusten und Investitionen für eine intensivere Verwaltung zu verstehen. Anleitungen zum Berechnen der Kosten für eine intensivere Verwaltung finden Sie unter Workloadautomatisierung und Plattformautomatisierung.

Geschätzter Ausfall (Stunden pro Jahr)

„Composite SLA“ (zusammengesetzte SLA) ist die Vereinbarung zum Service Level, die auf der Bereitstellung der einzelnen Ressourcen in der Workload basiert. Dieses Feld steuert den geschätzten Ausfall (in der Arbeitsmappe mit Est.Outage bezeichnet). Um den geschätzten Ausfall in Stunden pro Jahr zu berechnen, ohne die Arbeitsmappe zu verwenden, wenden Sie die folgende Formel an:

Geschätzter Ausfall = (1 – Prozentsatz der zusammengesetzten SLA) × Anzahl von Stunden pro Jahr

In der Arbeitsmappe wird der Standardwert von 8.760 Stunden pro Jahr verwendet.

Standardmäßige Auswirkungen von Datenverlust

Die standardmäßigen Auswirkungen von Datenverlust (in der Arbeitsmappe mit Standard Impact bezeichnet) prognostizieren die finanziellen Auswirkungen eines Ausfalls, vorausgesetzt, dass die Vorhersage des geschätzten Ausfalls korrekt ist. Um diese Vorhersage ohne Verwendung der Arbeitsmappe zu berechnen, wenden Sie die folgende Formel an:

Standardauswirkung = geschätzter Ausfall bei einer Betriebszeit der Verfügbarkeitsklasse 3 (drei Neunen) × zeitliche Auswirkung

Dies dient als Grundlage für die Kosten, wenn die Geschäftsbeteiligten entscheiden, in eine höhere Verwaltungsebene zu investieren.

Auswirkung der zusammengesetzten SLA

Die Auswirkung der zusammengesetzten SLA (in der Arbeitsmappe mit Commitment level impact bezeichnet) stellt die aktualisierten fiskalischen Auswirkungen dar, basierend auf den Änderungen der Betriebszeit-SLA. Anhand dieser Berechnung können Sie die projizierten finanziellen Auswirkungen beider Optionen vergleichen. Um diese vorhergesagte Auswirkung ohne die Arbeitsmappe zu berechnen, wenden Sie die folgende Formel an:

Auswirkung der zusammengesetzten SLA = geschätzter Ausfall × zeitliche Auswirkung

Der Wert stellt die potenziellen Verluste dar, die durch die geänderte Verpflichtungsebene und die neue zusammengesetzte SLA vermieden werden sollen.

Vergleichsbasis

Comparison basis (Vergleichsbasis) wertet „Standard Impact“ und „Composite SLA Impact“ aus, um zu bestimmen, was in der Renditespalte am besten geeignet ist.

Rendite bei Verlustvermeidung

Wenn die Kosten für die Verwaltung einer Workload die potenziellen Verluste überschreiten, ist die in der Cloudverwaltung vorgeschlagene Investition möglicherweise nicht rentabel. Beachten Sie zum Vergleichen der Rendite bei Verlustvermeidung die Spalte mit der Bezeichnung Annual ROI(jährlicher ROI)****. Um diese Spalte selbst zu berechnen, verwenden Sie die folgende Formel:

Rendite bei Verlustvermeidung = (Vergleichsbasis – (monatliche Kosten × 12)) ÷ (monatliche Kosten × 12))

Wenn keine weiteren weichen Kostenfaktoren berücksichtigt werden müssen, kann dieser Vergleich schnell zeigen, ob eine höhere Investition in Cloudbetrieb, Resilienz, Zuverlässigkeit oder andere Bereiche erfolgen sollte.

Überprüfen der Verpflichtung

An diesem Punkt des Prozesses wurden Verpflichtungen eingegangen: zentralisierte oder delegierte Verantwortlichkeit, Azure-Mandant und Verpflichtungsgrad. Jede Verpflichtung sollte überprüft und dokumentiert werden, um sicherzustellen, dass das Cloudbetriebsteam, das Cloudstrategieteam und die Geschäftsbeteiligten sich an diese Verpflichtung zur Verwaltung der Workload halten.

Nächste Schritte

Sobald Verpflichtungen eingegangen wurden, können die zuständigen Betriebsteams mit der Konfiguration für die betreffende Workload beginnen. Evaluieren Sie zunächst verschiedene Ansätze zu Bestand und Transparenz bei der Cloudverwaltung.