Wann sollte man Hochverfügbarkeit in Betracht ziehen?

“Hochverfügbarkeit ist nichts, was man kauft, sondern etwas, das man tut.” – John Nicholson

Wenige Dinge werden in der IT so allgemein gewünscht wie Hochverfügbarkeitslösungen (High Availability, HA). Wirklich, sprechen Sie diese Worte aus, und jeder IT-Profi wird sofort sagen, dass er das haben möchte. HA für seine Server, seine Anwendungen, seinen Speicher und natürlich sogar seine Desktops. Wenn es neben jedem System ein Kontrollkästchen gäbe, auf dem einfach “HA” stünde, warum sollten wir es nicht ankreuzen? Wir würden es natürlich tun. Niemand wünscht sich freiwillig ein System, das häufig ausfällt. Ausfall schlecht, Erfolg gut.

Zunächst müssen wir jedoch HA definieren. HA kann vieles bedeuten. Mindestens muss HA bedeuten, dass die Verfügbarkeit des betreffenden Systems höher als “normal” sein muss. Was ist normal? Das allein ist schwer genug zu definieren. HA ist bestenfalls ein lockerer Begriff. Im Kontext seiner gebräuchlichsten Verwendung jedoch, nämlich gängige Anwendungen, die auf normaler Unternehmenshardware laufen, würde ich diesen Ausgangspunkt für HA-Diskussionen vorschlagen:

Normale oder Standardverfügbarkeit (Standard Availability, SA) wäre zu definieren als die Verfügbarkeit eines gängigen Mainline-Servers, auf dem ein gängiges Unternehmensbetriebssystem läuft, auf dem eine gängige Unternehmensanwendung in einer Best-Practices-Umgebung mit Unternehmenssupport läuft. Gute Beispiele hierfür könnten Exchange sein, das auf Windows Server läuft, das auf dem HP Proliant DL380 läuft (dem gängigsten Mainline-Commodity-Server). Oder BIND (der DNS-Server), das auf Red Hat Enterprise Linux auf dem Dell PowerEdge R730 läuft. Dies sind lediglich Beispiele, die zur Festlegung einer groben Ausgangsbasis dienen. Es gibt keine gute Möglichkeit, dies zu messen, doch mit einem guten Supportvertrag sowie rascher Reparatur oder raschem Ersatz in der realen Welt wird angenommen, dass die Zuverlässigkeit eines Systems dieser Art zwischen vier und fünf Neunen der Zuverlässigkeit liegt (99,99 % Verfügbarkeit oder höher), wenn menschliches Versagen nicht einbezogen wird.

Hochverfügbarkeit (High Availability, HA) sollte gemeinhin definiert werden als eine Verfügbarkeit, die deutlich höher ist als die der Standardverfügbarkeit. Deutlich höher sollte mindestens eine Steigerung um eine Größenordnung bedeuten. Also mindestens fünf Neunen der Zuverlässigkeit und eher sechs Neunen. (99,9999 % Verfügbarkeit.)

Niedrige Verfügbarkeit (Low Availability, LA) wäre gemeinhin zu definieren als eine Verfügbarkeit, die deutlich niedriger ist als die der Standardverfügbarkeit, wobei deutlich wiederum mindestens eine Größenordnung bedeutet. LA würde also typischerweise mit etwa 99 % bis 99,9 % oder niedrigerer Verfügbarkeit angenommen.

Die Messung ist hier sehr schwierig, da menschliche, umweltbedingte und andere Faktoren eine gewaltige Rolle bei der Bestimmung der Verfügbarkeit unterschiedlicher Konfigurationen spielen. Dieselbe Ausrüstung, die in einer Rolle eingesetzt wird, könnte fünf Neunen erreichen, während sie in einer anderen nicht einmal eine erreicht. Die Qualität des Rechenzentrums, das Können des Support-Personals, die Schnelligkeit des Teileaustauschs, die Granularität der Überwachung und eine Vielzahl weiterer Faktoren werden die Gesamtzuverlässigkeit erheblich beeinflussen. Dies ist für uns jedoch nicht zwangsläufig ein Problem. In den meisten Fällen können wir die Teile eines Systemdesigns, die wir kontrollieren, so bewerten, dass die relative Zuverlässigkeit bestimmt werden kann, sodass wir zumindest zeigen können, dass ein Ansatz einem anderen überlegen sein wird, damit wir dann eine gut informierte Entscheidungsfindung nutzen können, selbst wenn sich keine genauen Ausfallratenmodelle leicht erstellen lassen.

Es ist wichtig anzumerken, dass es in den Definitionen von Hochverfügbarkeit oder niedriger Verfügbarkeit, abgesehen von der Bereitstellung einer beispielhaften Ausgangsbasis, von der aus gearbeitet werden kann, nichts gibt, das davon spricht, wie diese Niveaus erreicht werden sollten – das ist nicht das, was die Begriffe bedeuten. Die Begriffe sind resultierende Zuverlässigkeitsmengen in Relation zur Ausgangsbasis und nichts weiter. Es gibt viele Wege, Hochverfügbarkeit zu erreichen, ohne gemeinhin angenommene Ansätze zu verwenden, und praktisch unbegrenzte Wege, niedrige Verfügbarkeit zu erreichen.

Natürlich kann HA auf jeder Schicht definiert werden. Wir können hochverfügbare Plattformen oder Betriebssysteme haben, aber darauf fragile Anwendungen. Daher ist es sehr wichtig zu verstehen, auf welcher Ebene wir zu einem gegebenen Zeitpunkt sprechen. Letztlich wird sich ein Unternehmen nur um die hochverfügbare Bereitstellung von Diensten kümmern, unabhängig davon, wie sie erreicht wird oder wo. Das Endergebnis ist das, worauf es ankommt, nicht die “Details unter der Haube”, wie es bewerkstelligt wurde, oder, wie immer, der Zweck heiligt die Mittel.

Es ist heute äußerst verbreitet, dass IT-Abteilungen sich von neuen und auffälligen HA-Werkzeugen auf der Plattformschicht ablenken lassen und vergessen, höher und tiefer im Stack nach HA zu suchen, um sicherzustellen, dass wir dem Unternehmen hochverfügbare Dienste bereitstellen; statt nur die eine Schicht zu betrachten und das Unternehmen dabei genauso verwundbar zu lassen wie eh und je, oder noch mehr.

In der realen Welt ist HA jedoch nicht immer eine Option, und wenn sie es ist, hat sie ihren Preis. Dieser Preis ist fast immer monetär und geht im Allgemeinen ebenso mit zusätzlicher Komplexität einher. Und wie wir nur zu gut wissen, birgt jede Komplexität auch ein zusätzliches Risiko, und dieses Risiko könnte, wenn wir nicht vorsichtig sind, dazu führen, dass ein Versuch, HA zu erreichen, tatsächlich scheitert und uns sogar mit LA oder niedriger Verfügbarkeit zurücklassen könnte.

Sobald wir diese notwendige Sprache zur Beschreibung dessen, was wir meinen, verstehen, können wir beginnen, darüber zu sprechen, wann Hochverfügbarkeit, Standardverfügbarkeit und sogar niedrige Verfügbarkeit für uns richtig sein könnten. Wir verwenden dieses hohe Maß an Granularität, weil es so schwierig ist, die Systemzuverlässigkeit zu messen, dass zu viel Detailtreue wertlos wird.

Konzeptionell bringen alle Systeme ein Ausfallrisiko mit sich, und nichts kann immer verfügbar sein, das ist unmöglich. Zuverlässigkeit kostet im Allgemeinen Geld, wenn alle anderen Dinge gleich sind. Um also zu bestimmen, welches Verfügbarkeitsniveau für einen Workload am angemessensten ist, müssen wir die Kosten der Risikominderung ermitteln (den Geldbetrag, der erforderlich ist, um das durchschnittliche Ausmaß der Ausfallzeit zu verändern) und diese mit den Kosten der Ausfallzeit selbst vergleichen.

Dies wird heikel und kompliziert, denn die Kosten der Ausfallzeit zu bestimmen ist schon schwierig genug, und dann das Risiko der Ausfallzeit zu bestimmen ist noch schwieriger. In vielen Fällen ist die Ausfallzeit keine feste Zahl, aber sie könnte es sein. Diese Kosten könnten als 5 $/Minute oder 20.000 $/Tag oder Ähnliches ausgedrückt werden. Ein noch besseres Werkzeug wäre jedoch die Erstellung einer “Verlustwirkungskurve”, die zeigt, wie über die Zeit (innerhalb eines angemessenen Intervalls) Geld verloren geht.

Beispielsweise könnte ein Unternehmen für die ersten fünf Minuten leicht überhaupt keinen Verlust erleiden, mit langsam steigenden, aber geringen Verlusten bis etwa zur vierten Stunde, wenn die Arbeit zum Erliegen kommt, weil die Leute nicht mehr auf Papier oder was auch immer ausweichen können, und dann steigen die Verluste von nahezu null auf recht groß. Oder manche Unternehmen erleiden in dem Moment, in dem die Systeme ausfallen, einen riesigen Verlust, doch die Verluste lösen sich mit der Zeit langsam auf. Verluste könnten nur zu bestimmten Tageszeiten ins Gewicht fallen. Vielleicht sind Ausfälle nachts oder während der Mittagspause unbedeutend, mitten am Vormittag oder mitten am Nachmittag jedoch gravierend. Die Wirkung, das Risiko und die Fähigkeit, dieses Risiko zu mindern, sind bei jedem Unternehmen unterschiedlich, oft dramatisch.

Manchmal kommt es auf die Menschen an, die im Unternehmen arbeiten. Werden sie alle bereitwillig die nötigen Toiletten-, Kaffee-, Snack- oder sogar Mittagspausen zu dem Zeitpunkt einlegen, an dem ein System ausfällt, damit sie zur Arbeit zurückkehren können, wenn es repariert ist? Werden die Leute früher nach Hause gehen und morgen früher kommen, um einen größeren Ausfall auszugleichen? Gibt es Maschinen, die stillstehen werden? Wird die Fähigkeit, auf Kunden zu reagieren, beeinträchtigt? Werden lebenserhaltende Systeme ausfallen? Es gibt unzählige potenzielle Auswirkungen und unzählige potenzielle Wege, verschiedene Arten von Ausfällen zu mindern. All dies muss berücksichtigt werden. Die Kosten der Ausfallzeit könnten auf Minutenbasis einen Bruchteil der Unternehmenseinnahmen ausmachen, oder die Ausfallzeit könnte einen Verlust an Kunden oder Vertrauen verursachen, der gravierender ist als der von Minute zu Minute erwirtschaftete Umsatz.

Sobald wir einige grobe Verlustzahlen haben, mit denen wir arbeiten können, haben wir zumindest einen Ausgangspunkt. Selbst wenn wir nur wissen, dass der Umsatz ~10 $/Minute beträgt und Verluste in Höhe von ~5 $/Minute zu erwarten sind, haben wir einen gewissen Ausgangspunkt. Wenn wir eine vollständige Kurve oder eine Studie mit einigen detaillierteren Zahlen haben, umso besser. Nun müssen wir grob herausfinden, wie unsere Ausgangsbasis aussehen wird. Ein gut gewarteter Server, der vor Ort betrieben wird, mit einem guten Supportvertrag sowie guten Sicherungs- und Wiederherstellungsverfahren, kann recht leicht vier Neunen der Zuverlässigkeit erreichen. Das bedeutet, dass wir alle fünf Jahre etwa fünf Stunden Ausfallzeit erleben würden. Das ist tatsächlich weniger als die allgemein erwartete Ausfallzeit von SA in den meisten Umgebungen und potenziell weitaus weniger als die erwarteten Niveaus in exzellenten Umgebungen wie hochwertigen Rechenzentren mit Teilen und Service in der Nähe.

Basierend auf unserem Ausgangsbeispiel von etwa fünf Stunden alle fünf Jahre können wir also unser potenzielles Risiko ermitteln. Wenn wir etwa ~5 $/Minute verlieren und wir alle fünf Jahre grob 300 Minuten Ausfallzeit erwarten, blicken wir auf einen potenziellen Verlust von 1.500 $ pro halbes Jahrzehnt.

Das bedeutet, dass wir im äußersten Fall niemals 1.500 $ ausgeben könnten, um dieses Risiko zu mindern, das wäre finanziell absurd. Dies hat mehrere Gründe. Einer der größten ist, dass dies nur ein Risiko ist; 1.500 $ auszugeben, um sich gegen den Verlust von 1.500 $ zu schützen, ergibt wenig Sinn, aber es ist ein sehr verbreiteter Fehler, der gemacht wird, wenn Menschen diese Zahlen nicht sorgfältig analysieren.

Der größte Faktor ist, dass keine Minderungstechnik vollständig wirksam ist. Wenn es uns gelingt, unser Vier-Neunen-System auf ein Fünf-Neunen-System zu heben, würden wir nur 90 % der durchschnittlichen Ausfallzeit reduzieren, was uns von 1.500 $ Verlust auf 150 $ Verlust bringt. Wenn wir 1.500 $ für diese Reduzierung ausgeben würden, läge der Gesamt-“Verlust” immer noch bei 1.650 $ (die Kosten des Schutzes sind eine Form des finanziellen Verlusts). Die Kosten der Risikominderung in Kombination mit der erwarteten verbleibenden Wirkung müssen zusammengenommen immer noch niedriger sein als die erwarteten Kosten des Risikos ohne Minderung, andernfalls ist die Minderung selbst sinnlos oder aktiv schädlich.

Viele mögen sich fragen, warum die Gesamtkosten der Risikominderung niedriger und nicht einfach gleich sein müssen, denn das müsste doch sicherlich bedeuten, dass wir an einem “Risiko-Break-even”-Punkt sind? Das scheint an der Oberfläche zuzutreffen, aber da wir es mit Risiko zu tun haben, ist dies nicht der Fall. Risikominderung ist eine sichere Kosten – ein finanzieller Schaden, den wir im Voraus auf uns nehmen, in der Hoffnung, die Verluste von morgen zu reduzieren. Aber das Risiko für morgen ist eine Schätzung, hoffentlich eine fundierte, aber nur eine Schätzung. Die Kosten von heute sind sicher. Heute einen sicheren Schaden auf sich zu nehmen, in der Hoffnung, einen möglichen Schaden von morgen zu reduzieren, ergibt nur dann Sinn, wenn der Schaden von heute gering ist und der erwartete oder mögliche Schaden von morgen sehr groß ist und die Wirksamkeit der Minderung erheblich ist.

In der Idee der “sicheren Kosten im Voraus”, um “mögliche Kosten von morgen” zu reduzieren, ist die Idee des Zeitwerts des Geldes enthalten. Selbst wenn ein Ausfall von bekanntem Ausmaß und bekannter Dauer wäre, würden wir heute nicht dasselbe Geld ausgeben, um ihn morgen zu mindern, weil unser Geld heute wertvoller ist.

In den dramatischsten Fällen sehen wir mitunter, dass IT-Abteilungen verlangen, dass Zehn- oder Hunderttausende von Dollar im Voraus ausgegeben werden, um vielleicht einige Tausend Dollar zu vermeiden, irgendwann, vielleicht in vielen Jahren in der Zukunft. Eine Strategie, die wir als “sich heute ins Gesicht schießen, um morgen vielleicht keine Kopfschmerzen zu bekommen” bezeichnen können.

Es ist im Konzept der Bewertung der Risikominderung enthalten, sollte aber ausdrücklich erwähnt werden, dass es im Fall von IT-Ausrüstung viele Beispiele für versuchte Risikominderung gibt, die möglicherweise nicht so wirksam ist, wie angenommen wird. Beispielsweise wird das Vorhalten zweier Server, die im selben Rack stehen, potenziell sehr wirksam für die Minderung des Risikos eines Host-Hardwareausfalls sein, aber nicht gegen Naturkatastrophen, Standortverlust, Brand, die meisten Fälle von elektrischem Schlag, die Auslösung der Brandunterdrückung, Netzwerkunterbrechungen, die meisten Anwendungsausfälle, Ransomware-Angriffe oder andere im Rahmen des Möglichen liegende Katastrophen mindern.

Es ist üblich, dass Speichergeräte mit “dualen Controllern” ausgestattet sind, was einen starken Eindruck hoher Zuverlässigkeit erweckt, doch im Allgemeinen befinden sich diese Controller in einem einzigen Gehäuse mit gemeinsam genutzten Komponenten, und selbst wenn die Komponenten nicht gemeinsam genutzt werden, ist häufig die Firmware gemeinsam genutzt und die Kommunikation zwischen den Komponenten ist komplex; was oft zu Ausfällen führt, bei denen der Ausfall einer Komponente den Ausfall einer anderen auslöst – wodurch sie recht häufig LA-Geräte sind statt SA oder der HA, die die Leute beim Kauf erwartet hatten. Daher ist es sehr entscheidend zu bedenken, ob die Risikominderungsstrategie welche Risiken mindern wird und ob die Minderungstechnik wahrscheinlich wirksam ist. Keine Technik ist vollständig wirksam, es besteht immer die Möglichkeit eines Ausfalls, aber manche Strategien und Techniken sind breiter wirksam als andere, und manche sind schlicht irreführend oder tatsächlich kontraproduktiv. Wenn wir nicht vorsichtig sind, implementieren wir womöglich kostspielige Produkte oder Techniken, die unsere Ziele aktiv untergraben.

Manche Techniken und Produkte, die im Streben nach Hochverfügbarkeit eingesetzt werden, sind recht teuer, wozu der Kauf redundanter Hardware, die Anmietung eines weiteren Gebäudes, die Installation teurer Generatoren oder die Lizenzierung spezieller Software gehören könnten. Es gibt ebenso kostengünstige Techniken und Software, aber in den meisten Fällen wird jede Bewegung hin zur Hochverfügbarkeit eine entsprechend große Ausgabe an Investitionskapital nach sich ziehen, um sie zu erreichen. Es ist absolut entscheidend, im Hinterkopf zu behalten, dass Hochverfügbarkeit ein Prozess ist; es gibt keinen Weg, Hochverfügbarkeit einfach zu kaufen. Das Erreichen von HA erfordert gute Dokumentation, Verfahren, Planung, Support, Ausrüstung, Engineering und mehr. In der Systemwelt wird HA normalerweise zuerst aus einer Umgebungsperspektive angegangen, mit Notstromgeneratoren, redundanten HVAC-Systemen, Stromaufbereitung, Luftfilterung, Brandunterdrückungssystemen und mehr, um sicherzustellen, dass die Umgebung für die Verfügbarkeit vorhanden ist. Dies allein kann oft weitere Investitionen unnötig machen, da es unglaubliche Ergebnisse liefern kann. Dann kommt das HA-Systemdesign, das sicherstellt, dass nicht nur eine Schicht eines Technologie-Stacks hochverfügbar ist, sondern der gesamte Stack es den kritischen Anwendungen, Daten oder Diensten ermöglicht, während so viel Zeit wie möglich funktionsfähig zu bleiben. Dann betrachtet man die Standort-zu-Standort-Redundanz, um Überschwemmungen, Hurrikanen, Schneestürmen usw. standhalten zu können. Natürlich gibt es völlig andere Techniken, etwa die Nutzung von Cloud-Computing-Diensten, die remote in unserem Auftrag gehostet werden. Worauf es ankommt, ist, dass Hochverfügbarkeit breites Denken und Planen erfordert, nicht einfach als Posten gekauft werden kann und danach beurteilt wird, ob sie einen Risikofaktor zurückgeben kann, der eine resultierende Verfügbarkeit oder Wahrscheinlichkeit der Verfügbarkeit liefert, die weitaus höher ist als das, was ein “Standard”-Systemdesign liefern würde.

Was viele Unternehmen und insbesondere IT-Fachleute, die selten eine finanzielle Risikoanalyse durchführen und denen ständig gesagt wird, dass HA für jedes Unternehmen eine Notwendigkeit sei und dass der Kauf der neuesten HA-Produkte zweifellos der Weg sei, wie ihre Budgets ausgegeben werden sollten, oft überrascht, beinahe schockiert, ist, dass Hochverfügbarkeit, wenn die Zahlen durchgerechnet und die Realität der Kosten und der Wirksamkeit von Risikominderungsstrategien berücksichtigt werden, in jeder Organisation sehr wenig Platz hat, insbesondere in solchen, die klein sind oder sehr heterogene Workloads haben. Im Markt der kleinen und mittleren Unternehmen ist es nahezu durchgängig festzustellen, dass die Kosten und Komplexität (die wiederum Risiko mit sich bringt, meist in Form mangelnder Erfahrung rund um Techniken und Risikobewertung) von Hochverfügbarkeitsansätzen viel zu kostspielig sind, um den potenziellen Schaden des Ausfalls, vor dem die Minderung schützen soll, jemals auszugleichen. Es gibt natürlich Ausnahmen, und es gibt viele Unternehmen, für die Hochverfügbarkeitslösungen absolut sinnvoll sind, aber dies sind die Ausnahmen und weit davon entfernt, die Norm zu sein.

Es ist außerdem sinnvoll, den Bedarf an Hochverfügbarkeit auf Basis eines einzelnen Workloads zu betrachten und nicht abteilungs-, unternehmens- oder technologieweit. In einem kleinen Unternehmen ist es üblich, dass sich alle Workloads eine gemeinsame Plattform teilen, und der Bedarf eines einzelnen Workloads an Hochverfügbarkeit kann andere, weniger kritische Workloads mit sich ziehen. Das ist vollkommen in Ordnung und ein großartiger Weg, die Kosten der Risikominderung des kritischen Workloads durch einen zusätzlichen Nutzen für die weniger kritischen Workloads auszugleichen. In einer größeren Organisation, in der es eine Fülle von Plattformansätzen für unterschiedliche Workloads gibt, ist es üblich, dass nur bestimmte Workloads, die sowohl hochkritisch sind (im Hinblick auf das Risiko aus der Wirkung der Ausfallzeit) als auch praktisch von Risiko gemindert werden können (die Fähigkeit, Risiken zu mindern, kann zwischen verschiedenen Arten von Workloads dramatisch variieren), mit Hochverfügbarkeit ausgestattet werden und andere Workloads Standardtechniken überlassen bleiben.

Beispiele für Workloads, die kritisch sein können und mit Hochverfügbarkeit wirksam adressiert werden können, könnten ein Online-Bestellsystem sein, bei dem die durch multiregionale Replikation entstehende Latenz wenig Einfluss auf das Gesamtsystem hat, aber der Verlust von Bestellungen bei einem Systemausfall sehr stark finanziell ins Gewicht fallen könnte. Ein Beispiel für einen Workload, bei dem Hochverfügbarkeit leicht zu implementieren, aber wirkungslos sein könnte, wäre eine interne Intranet-Site, die häufig gestellte Personalfragen bedient; es wäre schlicht nicht kosteneffektiv, geringe Mengen gelegentlicher Ausfallzeit für ein System wie dieses zu vermeiden. Ein Beispiel für ein System, bei dem das Risiko hoch ist, aber die Kosten oder Wirksamkeit der Risikominderung sie unpraktisch oder sogar unmöglich machen, könnte eine finanzielle “Tick”-Datenbank sein, die das Einlesen riesiger Mengen latenzarmer Daten erfordert, und die Fähigkeit, ein Replikat vorzuhalten, wäre nicht nur unglaublich kostspielig, sondern könnte eine Latenz einführen, die die Fähigkeit des Systems untergraben würde, angemessen zu funktionieren. Jedes Unternehmen und jeder Workload ist einzigartig und sollte sorgfältig bewertet werden.

Natürlich können Hochverfügbarkeitstechniken in Stufen umgesetzt werden; es ist kein Alles-oder-nichts-Unterfangen. Es könnte praktisch sein, das Risiko eines Ausfalls auf Systemebene zu mindern, indem man Fehlertoleranz auf der Anwendungsschicht hat, um sich gegen den Ausfall von Systemhardware, Virtualisierungsplattform oder Speicher zu schützen. Aber für denselben Workload könnte es nicht wertvoll sein, sich gegen den Verlust eines einzelnen Standorts zu schützen. Wenn ein Workload nur einen bestimmten Standort bedient oder schlicht nicht wertvoll genug für die große Investition ist, die nötig wäre, um ihn zwischen Standorten ausfallsicher zu machen, könnte er leicht “in der Mitte” landen. Es ist sehr üblich, dass Workloads nur teilweise hochverfügbare Lösungen implementieren, oft weil eine IT-Abteilung möglicherweise nur für einen Teil davon verantwortlich ist und kein Mitspracherecht bei Dingen wie Stromversorgung und HVAC hat, aber wahrscheinlich am häufigsten, weil einige Hochverfügbarkeitstechniken als gut sichtbar und leicht an das Management zu verkaufen angesehen werden, während andere, wie hochwertige Stromversorgung und Klimatisierung, es oft nicht sind, obwohl sie leicht ein besseres Preis-Leistungs-Verhältnis bieten könnten. Es gibt gute Gründe, warum bestimmte Techniken gewählt werden und andere nicht, da sie unterschiedliche Risikokomponenten betreffen und manche Risiken eine unterschiedliche Wirkung auf ein einzelnes Unternehmen oder einen einzelnen Workload haben können.

Hochverfügbarkeit erfordert sorgfältige Überlegung, ob es sich überhaupt lohnt, sie in Betracht zu ziehen, und noch sorgfältigere Überlegung hinsichtlich der Umsetzung. Der Aufbau echter HA-Systeme erfordert ein erhebliches Maß an Aufwand und Fachwissen und im Allgemeinen beträchtliche Kosten. Zu verstehen, welche Komponenten von HA wertvoll sind und welche nicht, erfordert nicht nur umfangreiches technisches Fachwissen, sondern ebenso finanzielle und betriebswirtschaftliche Fähigkeiten. Abteilungen müssen umfassend zusammenarbeiten, um wirklich zu verstehen, wie sich HA auf eine Organisation auswirken wird und wann sie die Investition wert sein wird. Es ist entscheidend, sich daran zu erinnern, dass der Bedarf an Hochverfügbarkeit in einer Organisation oder für einen Workload alles andere als eine ausgemachte Sache ist, und es sollte nicht im Geringsten überraschen, festzustellen, dass umfangreiche Hochverfügbarkeit oder selbst beiläufige Hochverfügbarkeitspraktiken sich als wirtschaftlich unpraktisch erweisen.

In vielerlei Hinsicht liegt dies daran, dass die Standardverfügbarkeit einen solchen Stand erreicht hat, dass es kontinuierlich immer weniger Risiko zu mindern gibt. Technologiekomponenten, die in einer Unternehmensinfrastruktur eingesetzt werden, vor allem Server, Netzwerkausrüstung und Speicher, sind so zuverlässig geworden, dass das Ausmaß an Ausfallzeit, vor dem wir uns schützen müssen, recht gering ist. Der Großteil des Glaubens an die Notwendigkeit reflexartiger Hochverfügbarkeit stammt aus einer anderen Ära, als zuverlässige Hardware unerschwinglich war und selbst die teuerste Ausrüstung nach modernen Maßstäben ziemlich unzuverlässig war. Dieses Gefühl des drohenden Unheils, dass jedes Gerät jederzeit ausfallen könnte, stammt aus einer älteren Ära, nicht aus der gegenwärtigen. Moderne Ausrüstung ist, obwohl sie offensichtlich noch immer Risiken birgt, erstaunlich zuverlässig.

Zusätzlich zu anderen Risiken birgt eine Überinvestition in Hochverfügbarkeitslösungen finanzielle und geschäftliche Risiken, die erheblich sein können. Sie erhöht die technischen Schulden angesichts geschäftlicher Unsicherheit. Was, wenn das Unternehmen plötzlich wächst, oder schlimmer, was, wenn es sich plötzlich verkleinert, die Richtung ändert, aufgekauft wird oder vollständig den Betrieb einstellt? Die Investition in die Hochverfügbarkeit ist bereits ausgegeben, selbst wenn der Bedarf an ihrem Schutz verschwindet. Was, wenn sich Technologie oder Standort ändern? Ein Teil oder die gesamte Hochverfügbarkeitsinvestition könnte verloren gehen, bevor sie an ihrem erwarteten Lebensende angelangt wäre.

Als IT-Praktiker steht die Bewertung des Nutzens, der Risiken und der Kosten von Technologielösungen im Kern dessen, was wir tun. Wie alles andere in der Unternehmensinfrastruktur ist die Bestimmung der Art der Risikominderung, des Werts des Schutzes und dessen, was finanziell angemessen ist, unsere zentrale Verantwortung und kann nicht beschönigt oder ignoriert werden. Wir können niemals einfach annehmen, dass Hochverfügbarkeit benötigt wird, noch dass sie einfach übersprungen werden kann. Es ist in Analysen dieser Art, dass die IT einen ihrer größten Werte für Organisationen einbringt. Es ist hier, dass wir das Potenzial haben, am meisten zu glänzen.