test

Sun Java Enterprise System 2005Q4 Handbuch zur Bereitstellungsplanung

Kapitel 3 Technische Anforderungen

Während der Phase der technischen Anforderungen im Lösungslebenszyklus führen Sie eine Anwendungsanalyse durch, erstellen Anwendungsfälle und bestimmen die Dienstqualitätsanforderungen für die vorgeschlagene Bereitstellungslösung.

Dieses Kapitel enthält folgende Abschnitte:

Informationen zu technischen Anforderungen

Die Analyse der technischen Anforderungen basiert auf den Dokumenten zu den Geschäftsanforderungen, die während der Phase der Geschäftsanalyse des Lösungslebenszyklus erstellt wurden. Verwenden Sie die Geschäftsanalyse als Grundlage für die Durchführung folgender Aufgaben:

Anwendungsanalyse

In der Anwendungsanalyse werden die verschiedenen Benutzer der zu entwickelnden Lösung und die Anwendungsmuster für diese Benutzer ermittelt. Die zusammengetragenen Informationen bilden eine Grundlage für eine Schätzung der Lastbedingungen des Systems. Die Informationen aus der Anwendungsanalyse sind außerdem bei der Gewichtung der Anwendungsfälle, wie unter Anwendungsfälle beschrieben, hilfreich.

Bei der Anwendungsanalyse sollten Sie Benutzer wann immer möglich mit einbeziehen und befragen, vorhandene Daten zu Anwendungsmustern analysieren und die Entwickler und Admininistratoren vorheriger Systeme befragen. In der folgenden Tabelle werden die Faktoren aufgelistet, die bei der Durchführung einer Anwendungsanalyse zu berücksichtigen sind.

Tabelle 3–1 Faktoren der Anwendungsanalyse

Thema 

Beschreibung 

Benutzeranzahl und Benutzertyp 

Ermitteln Sie, wie viele Benutzer Ihre Lösung unterstützen muss und kategorisieren Sie die Benutzer gegebenenfalls. 

Beispiel: 

  • Eine Business-to-Customer (B2C)-Lösung muss möglicherweise für eine große Besucherzahl ausgelegt sein, jedoch nur für eine geringe Anzahl an Benutzern, die sich registrieren und Geschäftstransaktionen vornehmen.

  • Eine Business-to-Employee (B2E)-Lösung muss üblicherweise für alle Mitarbeiter ausgelegt sein, selbst wenn einige Mitarbeiter möglicherweise Zugriff von außerhalb des gemeinsamen Netzwerks benötigen. In einer B2E-Lösung benötigen Manager möglicherweise Berechtigungen für Bereiche, auf die ein normaler Mitarbeiter keinen Zugriff hat.

Aktive und inaktive Benutzer 

Ermitteln Sie die Anwendungsmuster und das Anwendungsverhältnis von aktiven zu inaktiven Benutzern. 

Aktive Benutzer sind am System angemeldete Benutzer und interagieren mit den Systemdiensten. Inaktive Benutzer können Benutzer sein, die nicht angemeldet sind, Benutzer, die angemeldet sind, aber nicht mit den Systemkomponenten interagieren oder Benutzer, die sich in der Datenbank befinden, sich jedoch nie anmelden. 

Verwaltungsbenutzer 

Ermitteln Sie die Benutzer, die auf das bereitgestellte System zugreifen können, um die Bereitstellung zu überwachen, zu aktualisieren und zu unterstützen. 

Ermitteln Sie sämtliche verwaltungsspezifische Anwendungsmuster, die die technischen Anforderungen beeinflussen könnten (z. B. die Verwaltung der Bereitstellung von außerhalb der Firewall aus).  

Anwendungsmuster 

Ermitteln Sie, auf welche Weise die verschiedenen Benutzertypen auf das System zugreifen und formulieren Sie Ziele für die erwartete Auslastung. 

Beispiel: 

  • Gibt es Spitzenzeiten, zu denen die Auslastung besonders hoch ist?

  • Wie sind die normalen Geschäftszeiten?

  • Sind die Benutzer weltweit verteilt?

  • Wie hoch ist die erwartete Dauer der Benutzerverbindungen?

Anstieg der Benutzerzahl 

Ermitteln Sie, ob die Größe des Benutzerstamms feststehend ist oder ob für die Bereitstellung ein Anstieg der Benutzerzahl erwartet wird. 

Wird ein Anstieg des Benutzerstamms erwartet, versuchen Sie, realistische Prognosen des Anstiegs zu erstellen. 

Benutzertransaktionen 

Ermitteln Sie den Typ der Benutzertransaktionen, die unterstützt werden müssen. Diese Benutzertransaktionen können in Anwendungsfälle umgesetzt werden. 

Beispiel: 

  • Welche Aufgaben führen die Benutzer durch?

  • Bleiben Benutzer nach Ihrer Anmeldung angemeldet? Führen die Benutzer üblicherweise einige Aufgaben durch und melden sich dann wieder ab?

  • Macht eine weitgehende Zusammenarbeit der Benutzer möglicherweise die Bereitstellung von gemeinsamen Kalendern, Webkonferenzen und internen Webseiten erforderlich?

Benutzerstudien und Statistiken 

Verwenden Sie bereits vorhandene Benutzerstudien und andere Quellen, um die verschiedenen Verhaltensmuster der Benutzer zu ermitteln. 

Oft liegen in Firmen oder Industrieunternehmen Benutzerstudien vor, denen Sie nützliche Informationen über die Benutzer entnehmen können. Die Protokolldateien vorhandener Anwendungen enthalten möglicherweise statistische Daten, die für die Erstellung von Prognosen für das System hilfreich sein können. 

Anwendungsfälle

Anwendungsfälle stellen ein Modell für die typische Benutzerinteraktion mit der zu entwickelnden Lösung dar und beschreiben den vollständigen Verlauf eines Vorgangs aus der Perspektive eines Endbenutzers. Indem das Konzept vorranging auf der Grundlage vollständiger Anwendungsfälle entwickelt wird, wird sichergestellt, dass der Fokus kontinuierlich auf der Entwicklung einer Lösung mit der erwarteten Funktionalität liegt. Anwendungsfälle stellen die wichtigste Grundlage eines logischen Konzepts dar.

Weisen Sie den Anwendungsfällen eine relative Gewichtung zu, wobei die höchste Gewichtung die Fälle erhalten, die für die häufigsten Benutzeraufgaben stehen. Die Gewichtung von Anwendungsfällen ermöglicht Ihnen die Fokusierung Ihrer Konzeptentscheidungen auf die Systemdienste, die am häufigsten verwendet werden.

Anwendungsfälle können auf zwei Ebenen beschrieben werden.

Dienstqualitätsanforderungen

Dienstqualitätsanforderungen (QoS-Anforderungen) sind technische Spezifikationen, mit der die Systemqualität von Funktionen wie Leistung, Verfügbarkeit, Skalierbarkeit und Wartungseignung bestimmt wird. Die QoS-Anforderungen werden durch die in den Geschäftsanforderungen festgelegten Geschäftsbedürfnisse bestimmt. Wenn Dienste beispielsweise ganzjährig 24 Stunden pro Tag verfügbar sein müssen, muss diese Geschäftsanforderung von der Verfügbarkeitsanforderung erfüllt werden.

Die folgende Tabelle listet die Systemqualitäten auf, die üblicherweise die Grundlage für QoS-Anforderungen bilden.

Tabelle 3–2 Systemqualitäten mit Auswirkung auf QoS-Anforderungen

Systemqualität 

Beschreibung 

Leistung 

Die Messung der Antwortzeit und des Datendurchsatzes relativ zu den Benutzerauslastungsbedingungen.  

Verfügbarkeit 

Eine Maßangabe, mit der angegeben wird, wie oft Systemressourcen und -dienste für Endbenutzer verfügbar sind. Diese wird häufig als Uptime (verfügbare Betriebszeit) eines Systems bezeichnet.

Skalierbarkeit 

Die Möglichkeit, zu einem späteren Zeitpunkt Kapazitäten (und Benutzer) zu einem bereitgestellten System hinzuzufügen. Skalierbarkeit beinhaltet üblicherweise das Hinzufügen von Ressourcen zum System, ohne dass Änderungen an der Bereitstellungsarchitektur vorgenommen werden müssen. 

Sicherheit 

Eine komplexe Kombination von Faktoren, die die Integrität eines Systems und seiner Benutzer beschreiben. Zur Sicherheit gehört die Authentifizierung und die Zuweisung von Berechtigungen zu Benutzern sowie Sicherheitsdaten und der sichere Zugriff auf ein bereitgestelltes System. 

Latente Kapazität 

Die Fähigkeit eines Systems, ungewöhnlich hohe Lasten ohne zusätzliche Ressourcen bedienen zu können. Die latente Kapazität spielt eine Rolle in den Verfügbarkeits-, Leistungs- und Skalierbarkeitsanforderungen.  

Wartungseignung 

Die Leichtigkeit, mit der ein bereitgestelltes System gewartet werden kann, einschließlich der Systemüberwachung, Problembehebung und Aktualisierung von Soft- und Hardwarekomponenten.  

Systemqualitäten sind eng miteinander verknüpft. Die Anforderungen für eine Systemqualität können die Anforderungen und das Konzept für andere Systemqualitäten beeinflussen. So kann beispielsweise ein höheres Sicherheitsniveau die Leistung beeinträchtigen, was wiederum die Verfügbarkeit beeinflusst. Das Hinzufügen zusätzlicher Server, um Verfügbarkeitsprobleme zu beheben, wirkt sich auf die Zweckmäßigkeit (Wartungskosten) aus.

Das Verständnis, wie die einzelnen Systemqualitäten miteinander in Beziehung stehen und wie diese abgestimmt werden müssen, ist der Schlüssel für die Entwicklung eines Systems, dass sowohl den Geschäftsanforderungen als auch den Geschäftsteinschränkungen erfolgreich gerecht wird.

In den folgenden Abschnitten werden die Systemqualitäten, die sich auf das Bereitstellungskonzept auswirken, näher beschrieben. Es wird außerdem erläutert, welche Faktoren bei der Gestaltung der QoS-Anforderungen berücksichtigt werden müssen. Ein Abschnitt zu den Anforderungen an die Dienstebenen, die die Grundlage für die Vereinbarungen auf Dienstebene (Service Level Agreement, SLA) bilden, ist ebenfalls enthalten.

Leistung

Geschäftsanforderungen messen die Leistung normalerweise in nicht technischen Begriffen, die sich auf die Antwortzeit beziehen. Eine Geschäftsanforderung für den internetbasierten Zugriff könnte beispielsweise wie folgt lauten:

Die Benutzer erwarten eine angemesse Antwortzeit bei der Anmeldung von üblicherweise maximal vier Sekunden.

Untersuchen Sie, beginnend mit dieser Geschäftsanforderung, sämtliche Anwendungsfälle, um zu bestimmen, wie diese Anforderung auf einer Systemebene ausgedrückt werden könnte. In einigen Fällen möchten Sie möglicherweise die Bedingungen der Benutzerauslastung miteinschließen, die während der Anwendungsanalyse ermittelt wurden. Formulieren Sie die Leistungsanforderung für jeden Anwendungsfall in Bezug auf die Antwortzeit unter bestimmten Auslastungsbedingungen oder in Bezug auf die Antwortzeit zuzüglich Datendurchsatz. Sie können auch die zulässige Anzahl an Fehlern angeben.

Im Folgenden wird anhand von zwei Beispielen verdeutlicht, wie die Systemanforderungen für die Leistung angegeben werden können:

Leistungsanforderungen sind eng mit Verfügbarkeitsanforderungen (Failover-Auswirkung auf die Leistung) und der latenten Kapazität (Menge der verfügbaren Kapazität für die Bewältigung außergewöhnlicher Spitzenauslastung) verknüpft.

Verfügbarkeit

Über die Verfügbarkeit kann man die Betriebszeit eines Systems bestimmt werden. Sie bemisst sich normalerweise aus dem Prozentsatz der Zeit, während der Benutzer auf das System zugreifen können. Die Zeit, in der das System nicht verfügbar ist (Ausfallzeit) kann durch Ausfälle der Hardware, der Software, des Netzwerks oder durch einen beliebigen anderen Faktor (z. B. Unterbrechung der Stromversorgung) verursacht werden, durch den das System zum Stillstand kommt. Geplante Zeiten, in denen das System zu Servicezwecken (Wartung und Aufrüstung) heruntergefahren wird, werden nicht als Ausfallzeit bezeichnet. Eine grundlegende Gleichung zur Berechnung der Systemverfügbarkeit als Prozentsatz der Betriebszeit lautet wie folgt:

Verfügbarkeit = Uptime / (Uptime + Downtime) * 100%

Üblicherweise messen Sie die Verfügbarkeit anhand der Anzahl der "Neunen“, die Sie erreichen können. Bei einer 99%-igen Verfügbarkeit erhalten Sie zwei Neunen. Die Angabe zusätzlicher Neuen wirkt sich erheblich auf das Bereitstellungskonzept aus. In der folgenden Tabelle wird die unvorhergesehene Ausfallszeit bei zusätzlichen "Verfügbarkeits-Neunen“ auf einem System berechnet, das 24 Stunden an 7 Tagen die Woche ganzjährig (insgesamt 8.760 Stunden) verfügbar ist.

Tabelle 3–3 Unvorhergesehene Ausfallzeit für ein System, das ganzjährig (8.760 Stunden) verfügbar ist

Anzahl der Neunen 

Verfügbarkeit (Prozent) 

Unvorhergesehene Ausfallzeit 

2 

99 % 

88 Stunden 

3 

99,9 % 

9 Stunden 

4 

99,99 % 

45 Minuten 

5 

99,999 % 

5 Minuten 

Fehlertolerante Systeme

Verfügbarkeitsanforderungen von vier oder fünf Neunen erfordern im Normalfall ein fehlertolerantes System. Ein fehlertolerantes System muss in der Lage sein, seinen Dienst auch während eines Hardware- oder Softwareausfalls fortzusetzen. Normalerweise wird die Fehlertoleranz durch Redundanz in der Hardware (CPUs, Speicher- und Netzwerkgeräte) als auch in der Software, die die wichtigsten Dienste zur Verfügung stellt, erreicht.

Bei einem Single-Point-of-Failure handelt es sich um eine Hardware- oder Softwarekomponente, die Teil eines wichtigen Pfads ist, aber nicht von redundanten Komponenten gesichert wird. Der Ausfall dieser Komponente führt zum Dienstausfall des Systems. Wenn Sie ein fehlertolerantes System konzipieren, müssen Sie potenzielle Single-Point-of-Failure ermitteln und vermeiden.

Fehlertolerante Systeme können in der Implementierung und Wartung teuer sein. Stellen Sie sicher, dass Sie verstanden haben, worin die Geschäftsanforderungen für die Verfügbarkeit liegen, und berücksichtigen Sie die Strategien und Kosten der Verfügbarkeitslösungen, die diese Anforderungen erfüllen.

Priorisieren der Dienstverfügbarkeit

Aus Sicht des Benutzers bezieht sich die Verfügbarkeit oft eher auf einzelne Dienste als auf die Verfügbarkeit des gesamten Systems. So hat es beispielsweise im Normalfall keine oder nur geringe Auswirkungen auf andere Dienste, wenn keine Instant Messaging-Dienste verfügbar sind. Wenn jedoch Dienste nicht verfügbar sind, von denen viele andere Dienste abhängig sind (z. B. Directory Server), sind die Auswirkungen weitreichender. Genauere Verfügbarkeitsspezifikationen sollten deutlich auf bestimmte Anwendungsfälle und Anwendungsanalysen verweisen, für die eine höhere Verfügbarkeit erforderlich ist.

Es ist hilfreich, Verfügbarkeitsbedürfnisse entsprechend den verschiedenen aufgestellten Prioritäten aufzulisten. In der folgenden Tabelle wird die Verfügbarkeit verschiedener Diensttypen nach Priorität geordnet aufgeführt.

Tabelle 3–4 Verfügbarkeit von Diensten nach Priorität

Priorität 

Diensttyp 

Beschreibung 

1 

Unerlässlich 

Dienste, die immer verfügbar sein müssen. Beispielsweise Datenbankdienste (z. B. LDAP-Verzeichnisse) für Anwendungen. 

2 

Muss verfügbar sein 

Dienste, die verfügbar sein müssen, aber mit reduzierter Leistung verfügbar sein können. Die Verfügbarkeit von Messaging-Diensten ist möglicherweise in einigen Unternehmensumgebungen nicht zwingend erforderlich. 

3 

Kann verschoben werden 

Dienste, die innerhalb eines angegebenen Zeitraums verfügbar sein müssen. Die Verfügbarkeit von Kalenderdiensten ist möglicherweise in einigen Unternehmensumgebungen nicht erforderlich. 

4 

Optional 

Dienste, die auf unbegrenzte Zeit verschoben werden können. In einigen Umgebungen können Instant Messaging-Dienste zwar als nützlich aber nicht unbedingt als erforderlich bewertet werden. 

Dienstausfall

Im Rahmen des Verfügbarkeitskonzepts werden auch die Auswirkungen berücksichtigt, die entstehen, wenn die Verfügbarkeit beeinträchtigt wird oder eine Komponente ausfällt. Hierbei muss auch berücksichtigt werden, ob die angemeldeten Benutzer Sitzungen neu starten müssen und inwiefern ein Fehler in einem Bereich sich auf andere Bereiche eines Systems auswirkt. QoS-Anforderungen sollten diese Szenarien beachten und angeben, wie die Bereitstellung auf derartige Situationen reagiert.

Skalierbarkeit

Unter Skalierbarkeit wird die Fähigkeit verstanden, einem System Kapazitäten hinzuzufügen, sodass das System eine zusätzliche Auslastung durch bestehende Benutzer oder durch einen erweiterten Benutzerstamm unterstützen kann. Die Skalierbarkeit setzt normalerweise eine Erweiterung der Ressourcen voraus; es sollten jedoch keine Änderungen am Konzept der Bereitstellungsarchitektur oder Dienstausfälle erforderlich sein, die sich aufgrund der für das Hinzufügen zusätzlicher Ressourcen benötigten Zeit ergeben.

Wie auch die Verfügbarkeit bezieht sich die Skalierbarkeit eher auf einzelne von einem System bereitgestellte Dienste als auf das gesamte System. Im Fall von Diensten, von denen andere Dienste abhängig sind (z. B. Directory Server), kann sich die Skalierbarkeit auf das gesamte System auswirken.

Die Skalierbarkeitsanforderungen werden nicht notwendigerweise mit den QoS-Anforderungen angegeben, es sei denn, das geplante Wachstum der Bereitstellung wird eindeutig in den Geschäftsanforderungen festgehalten. Während der Bereitstellungskonzeptphase des Lösungslebenszyklus sollte die Bereitstellungsarchitektur grundsätzlich einen gewissen Spielraum für die Skalierung des Systems einschließen, auch wenn keine QoS-Anforderungen für die Skalierbarkeit angegeben wurden.

Wachstumseinschätzung

Bei der Einschätzung des Wachstums eines Systems zur Ermittlung der Skalierbarkeitsanforderungen muss mit Hochrechnungen, Schätzungen und Vermutungen gearbeitet werden, die möglicherweise nicht eintreten. Es gibt folgende drei Schlüssel für die Entwicklung von Anforderungen für ein skalierbares System:

In der folgenden Tabelle werden die Faktoren aufgeführt, die bei der Ermittlung der Skalierbarkeitsanforderungen berücksichtigt werden sollten.

Tabelle 3–5 Skalierbarkeitsfaktoren

Thema 

Beschreibung 

Analyse der Anwendungsmuster 

Machen Sie sich mithilfe der vorhandenen Daten mit den Anwendungsmustern des aktuellen (oder geplanten) Benutzerstamms vertraut. Falls keine aktuellen Daten vorliegen, analysieren Sie die Branchendaten oder Markteinschätzungen.  

Konzept in Bezug auf maximal sinnvollen Umfang 

Konzepterstellung mit Hinblick auf den maximal erforderlichen Umfang sowohl für den bekannten als auch für den möglichen Bedarf. 

Hierbei handelt es sich häufig um eine Schätzung über 24 Monate, der die Leistungseinschätzung der vorhandenen Benutzerauslastung und angemessene Eischätzungen für die zukünftige Auslastung zugrunde liegen. Der Zeitraum für die Schätzung hängt in hohem Maße von der Zuverlässigkeit der Prognosen ab. 

Festlegen angemessener Meilensteine 

Schrittweise Implementierung des Bereitstellungskonzepts, um kurzfristige Anforderungen zu erfüllen, wobei ein Puffer für unerwartete Wachstumsschübe eingebaut wird. Legen Sie Meilensteine für das Hinzufügen von Systemressourcen fest.  

Beispiel: 

  • Kapitalbeschaffung (z. B. vierteljährlich oder jährlich)

  • Vorlaufzeit für den Erwerb von Hardware oder Software (z. B. eine bis sechs Wochen)

  • Puffer (10 % bis 100 %, je nach Wachstumserwartungen)

Aufnahme neuer Technologien 

Machen Sie sich mit neuen Technologien, wie beispielsweise schnelleren Prozessoren und Webservern, vertraut und darüber, wie die jeweilige Technologie sich auf die Leistung der zugrunde liegenden Architektur auswirkt. 

Sicherheitsanforderungen

Sicherheit ist ein komplexes Thema, das alle Stufen eines bereitgestellten Systems betrifft. Die Entwicklung von Sicherheitsanforderungen schließt die Identifizierung der Sicherheitsbedrohungen und die Entwicklung einer Strategie zur Bekämpfung dieser Gefahren ein. Diese Sicherheitsanalyse beinhaltet folgende Schritte:

  1. Identifizierung unerlässlicher Aspekte

  2. Identifizierung der Bedrohungen dieser Aspekte

  3. Identifizierung von Anfälligkeiten, aufgrund derer die Bedrohungen das Unternehmen gefährden können

  4. Entwicklung eines Sicherheitsplans, mit dessen Hilfe die Gefahr für das Unternehmen eingeschränkt wird

Bei der Analyse der Sicherheitsanforderungen sollte ein Querschnitt durch die Interessengruppen in Ihrem Unternehmen, wie beispielsweise leitende Angestellte, Unternehmensanalysten und Mitarbeiter aus dem IT-Bereich, einbezogen werden. Häufig wird in einem Unternehmen ein Sicherheitsarchitekt ernannt, der für die Entwicklung und Implementierung der Sicherheitsmaßnahmen verantwortlich ist.

Im folgenden Abschnitt werden einige der Bereiche beschrieben, die bei der Sicherheitsplanung abgedeckt werden.

Elemente eines Sicherheitsplans

Die Planung der Sicherheit eines Systems ist Bestandteil des Bereitstellungskonzepts, das für die erfolgreiche Implementierung unabdingbar ist. Ziehen Sie bei der Sicherheitsplanung folgende Aspekte in Betracht:

Latente Kapazität

Die latente Kapazität ist die Fähigkeit einer Bereitstellung, eine außergewöhnliche Spitzenauslastung zu bewältigen, ohne zusätzliche Ressourcen hinzuzufügen. Normalerweise geben Sie QoS-Anforderungen nicht direkt über die latente Kapazität an, aber diese Systemqualität ist ein Faktor für die Verfügbarkeit, Leistung und Skalierbarkeit des Systems.

Wartungseignungsanforderungen

Die Wartungseignung ist die Einfachheit, mit der ein bereitgestelltes System gewartet werden kann. Dazu zählen Aufgaben wie Überwachung des Systems, Behebung von auftretenden Problemen, Hinzufügen zum und Entfernen von Benutzern vom System und Aufrüsten der Hardware- und Softwarekomponenten.

Beim Planen der Wartungseignungsanforderungen sollten Sie die in der folgenden Tabelle aufgeführten Aspekte berücksichtigen.

Tabelle 3–6 Aspekte für die Wartungseignungsanforderungen

Thema 

Beschreibung 

Planung von Ausfallzeiten 

Identifizierung der Wartungsaufgaben, für die bestimmte Dienste nicht verfügbar oder teilweise nicht verfügbar sein dürfen. 

Einige Wartungs- und Aufrüstungsaufgaben können nahtlos für den Benutzer erfolgen, während für andere der Dienst unterbrochen werden muss. Planen Sie, wenn möglich, die Wartungsaufgaben, die eine Ausfallzeit mit sich bringen, zusammen mit den Benutzern, sodass die Benutzer sich auf die Ausfallzeiten einstellen können. 

Anwendungsmuster 

Identifizierung der Anwendungsmuster, um den besten Zeitpunkt für die Wartung zu bestimmen.  

Beispielsweise sollten Sie die Wartung von Systemen, deren Spitzenauslastung zu den normalen Geschäftszeiten ist, für die Abende oder Wochenenden planen. Bei geografisch verteilten Systemen kann die Ermittlung dieser Zeitpunkte schwieriger sein. 

Verfügbarkeit 

Die Wartungseignung reflektiert oft Ihr Verfügbarkeitskonzept. Die Strategien zur Minimierung der Ausfallzeiten für Wartungs- und Aufrüstungsaufgaben hängen von der Verfügbarkeitsstrategie ab. Bei Systemen, die häufig verfügbar sein müssen, gibt es weniger Gelegenheiten für Wartung, Aufrüstung und Reparaturen. 

Strategien für die Handhabung der Verfügbarkeitsanforderungen bestimmen, wie Wartungs- und Aufrüstungsaufgaben gehandhabt werden. Bei Systemen, die geografisch verteilt sind, hängt die Serviceplanung etwa davon ab, ob die Arbeitslast während der Wartungszeiträume an remote Server weitergeleitet werden kann. 

Außerdem sind für Systeme, die in hohem Maße verfügbar sein müssen, kompliziertere Lösungen erforderlich, bei denen die Systeme automatisch neu gestartet werden und der Benutzer nur geringfügig eingreifen muss. 

Diagnose und Überwachung 

Sie können die Stabilität eines Systems verbessern, indem Sie regelmäßig Diagnose- und Überwachungstools ausführen, um Problembereiche zu identifizieren. 

Die regelmäßige Überwachung eines Systems kann Probleme noch vor ihrem Auftreten vermeiden, die Arbeitsauslastung an den Verfügbarkeitsstrategien ausrichten und die Planung für Wartung und Ausfallzeiten verbessern. 

Anforderungen an die Dienstebene

In einer Vereinbarung auf Dienstebene (Service Level Agreement, SLA) werden die leistungsbezogenen Mindestanforderungen angegeben. Wenn diese Anforderungen nicht erfüllt werden, geht hieraus ebenfalls hervor, auf welcher Ebene und in welchem Umfang Kundenunterstützung bereitgestellt werden muss. Anforderungen an die Dienstebene sind Systemanforderungen, die die Bedingungen angeben, auf denen die SLA basiert.

Wie auch QoS-Anforderungen werden Anforderungen an die Dienstebene von den Geschäftsanforderungen abgeleitet und garantieren die allgemeine Systemqualität, die das bereitgestellte System aufweisen muss. Da die Vereinbarung auf Dienstebene als Vertrag angesehen wird, sollten die Anforderungen an die Dienstebene eindeutig festgelegt sein. Die Anforderungen an die Dienstebene definieren genau, unter welchen Bedingungen die Anforderungen getestet werden und welche Folgen es nach sich zieht, wenn die Anforderungen nicht erfüllt werden.