Sun Java logo     Zurück      Inhalt      Index      Weiter     

Sun logo
Sun Java Enterprise System 2005Q1 Handbuch zur Bereitstellungsplanung 

Kapitel 3
Technische Anforderungen

Während der Phase der technischen Anforderungen des Lebenszyklus einer Lösung führen Sie eine Anwendungsanalyse durch, bestimmen Anwendungsfälle und ermitteln die Dienstqualitätsanforderungen für die geplante Bereitstellungslösung.

Dieses Kapitel enthält die folgenden Abschnitte:


Informationen über technische Anforderungen

Die Analyse der technischen Anforderungen beginnt mit Geschäftsanforderungsdokumenten, die während der Geschäftsanalysephase des Lebenszyklus einer Lösung erstellt werden. Verwenden Sie die Geschäftsanalyse als Grundlage und gehen Sie wie folgt vor:

Die Dienstqualitätsanforderungen werden von der Anwendungsanalyse abgeleitet, wobei die Anwendungsfälle, unter Berücksichtigung der Geschäftsanforderungen und -einschränkungen zuvor ermittelt werden.

Die Geschäftsanforderungen werden später mit logischen Architekturen in der Phase des logischen Konzepts gepaart, um ein Bereitstellungsszenario zu entwerfen. Das Bereitstellungsszenario ist die wichtigste Eingabe für die Bereitstellungskonzeptphase des Lebenszyklus der Lösung.

Wie im Fall der Geschäftsanalyse gibt es keine einfache Formel für die Analyse der technischen Anforderungen, mit der die Anwendungsanalyse, Anwendungsfälle und Systemanforderungen generiert werden. Für die Analyse der technischen Anforderungen müssen die Geschäftsdomäne, die geschäftlichen Ziele und die zugrunde liegende Systemtechnologie begriffen werden.


Anwendungsanalyse

Bei der Anwendungsanalyse werden die verschiedenen Benutzer der zu entwerfenden Lösung sowie die Anwendungsmuster für jene Benutzer ermittelt. Die zusammengetragenen Informationen bieten eine Grundlage für die Einschätzung der Ladebedingungen auf dem System. Die Anwendungsanalyseinformationen sind auch bei der Gewichtung der Anwendungsfälle, wie unter Anwendungsfälle beschrieben, von Nutzen.

Während der Anwendungsanalyse sollten Sie Benutzer wannimmer möglich befragen, vorhandene Daten zu Anwendungsmustern untersuchen und Befragungen bei Herstellern und Administratoren von früheren Systemen durchführen. In der folgenden Tabelle werden die Faktoren aufgeführt, die bei der Durchführung einer Anwendungsanalyse berücksichtigt werden sollten.

Tabelle 3-1  Faktoren für die Anwendungsanalyse  

Thema

Beschreibung

Anzahl und Art der Benutzer

Stellen Sie fest, wie viele Benutzer Ihre Lösung unterstützen muss, und kategorisieren Sie diese Benutzer gegebenenfalls.

Beispielsweise:

  • Eine Business to Customer-(B2C-)Lösung weist möglicherweise eine große Anzahl an Besuchern auf, von denen jedoch nur eine kleine Anzahl bei geschäftlichen Transaktionen registriert und damit befasst ist.
  • Eine Business to Employee-(B2E-)Lösung enthält normalerweise jeden Mitarbeiter, auch wenn einige Mitarbeiter möglicherweise einen Zugriff von außerhalb des Unternehmensnetzwerks benötigen.

    In einer B2E-Lösung benötigen Führungskräfte möglicherweise die Berechtigung für Bereiche, auf die der normale Mitarbeiter nicht zugreifen darf.

Aktive und inaktive Benutzer

Ermitteln Sie die Anwendungsmuster und -verhältnisse der aktiven und inaktiven Benutzer.

Bei aktiven Benutzern handelt es sich um die Benutzer, die beim System angemeldet sind und mit den Systemdiensten interagieren. Inaktive Benutzer können Benutzer sein, die nicht angemeldet sind; die angemeldet sind, aber nicht mit den Systemkomponenten interagieren, oder Benutzer, die in einer Datenbank gespeichert sind, sich aber nie anmelden.

Administrative Benutzer

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

Legen Sie sämtliche speziellen administrativen Anwendungsmuster fest, die sich auf die technischen Anforderungen auswirken können (z. B. Verwaltung der Bereitstellung von außerhalb der Firewall aus).

Anwendungsmuster

Bestimmen Sie, in welcher Weise verschiedene Typen von Benutzern auf das System zugreifen und legen Sie Ziele für die erwartete Anwendung fest.

Beispielsweise:

  • Gibt es Zeiten, zu denen die Auslastung besonders hoch ist?
  • Wie sind die normalen Geschäftszeiten?
  • Sind die Benutzer weltweit verstreut?
  • Wie lange dauern Benutzerverbindungen erwartungsgemäß?

Benutzerwachstum

Stellen Sie fest, ob die Größe des Benutzerstamms festgelegt ist, oder ob die Bereitstellung einen Anstieg der Anzahl der Benutzer zu erwarten hat.

Wenn der Benutzerstamm wahrscheinlich wächst, versuchen Sie vernünftige Prognosen hinsichtlich des Wachstums zu machen.

Benutzertransaktionen

Bestimmen Sie die Typen der Benutzertransaktionen, die unterstützt werden müssen. Diese Benutzertransaktionen können in Anwendungsfälle übertragen werden.

Beispielsweise:

  • Welche Aufgaben führen die Benutzer durch?
  • Bleiben Benutzer nach ihrer Anmeldung angemeldet? Führen sie normalerweise einige Aufgaben durch und melden sich wieder ab?
  • Sind für eine sinnvolle Zusammenarbeit zwischen den Benutzern gemeinsame Kalender, Internetkonferenzen und interne Webseiten erforderlich?

Benutzerstudien und statistische Daten

Verwenden Sie bereits vorhandene Benutzerstudien und andere Quellen, um Muster für das Benutzerverhalten zu ermitteln.

Oft liegen in Firmen oder Industrieunternehmen Benutzerstudien vor, denen Sie nützliche Informationen über die Benutzer entnehmen können. Protokolldateien für vorhandene Anwendungen können statistische Daten enthalten, die bei der Einschätzung für ein System nützlich sind.


Anwendungsfälle

Anwendungsfälle stellen die typische Benutzerinteraktion mit der zu entwerfenden Lösung beispielhaft dar und beschreiben den vollständigen Verlauf eines Vorgangs aus der Perspektive eines Endbenutzers. Wenn für das Konzept eine komplette Gruppe von Anwendungsfällen zugrunde gelegt wird, wird das Augenmerk dauerhaft darauf gelegt, dass die gewünschte Funktionalität erbracht wird. Anwendungsfälle sind die wichtigste Grundlage für ein logisches Konzept.

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 durch zwei Ebenen näher beschrieben werden.


Dienstqualitätsanforderungen

Dienstqualitätsanforderungen (QoS-Anforderungen) sind technische Spezifikationen, die die Dienstqualität von Merkmalen, wie beispielsweise der Leistung, Verfügbarkeit, Skalierbarkeit und Zweckmäßigkeit, bestimmen. QoS-Anforderungen werden durch die geschäftlichen Bedürfnisse bestimmt, die durch die Anforderungen für das Unternehmen angegeben werden. Wenn beispielsweise ein Dienst 24 Stunden jeden Tag im gesamten Jahr verfügbar sein muss, muss die Verfügbarkeitsanforderung auf diese Anforderung im Unternehmen abzielen.

In der folgenden Tabelle werden die Systemqualitäten aufgeführt, die normalerweise die Grundlage für die QoS-Anforderungen bilden.

Tabelle 3-2  Systemqualitäten mit Auswirkung auf dieQoS-Anforderungen 

Systemqualität

Beschreibung

Leistung

Die Messung der Antwortzeit und des Datendurchsatzes in Bezug auf die Benutzerladebedingungen.

Verfügbarkeit

Ein Maß für die Häufigkeit, mit der die Ressourcen und Dienste eines Systems für Endbenutzer verfügbar sind, wird oft als Betriebszeit eines Systems bezeichnet.

Skalierbarkeit

Die Fähigkeit, einem bereitgestellten System im Laufe der Zeit Kapazität (und Benutzer) hinzuzufügen. Die Skalierbarkeit umfasst in der Regel das Hinzufügen von Ressourcen zum System, sollte jedoch keine Änderungen an der Bereitstellungsarchitektur erfordern.

Sicherheit

Eine komplexe Kombination von Faktoren, die die Integrität eines Systems und seiner Benutzer beschreibt. Zur Sicherheit zählt auch die Authentifizierung und Autorisierung von Benutzern, die Datensicherheit und der sichere Zugriff auf ein bereitgestelltes System.

Latente Kapazität

Die Fähigkeit eines Systems, eine außergewöhnliche Spitzenauslastung ohne zusätzliche Ressourcen zu bewältigen. Die latente Kapazität ist ein Faktor bei den Qualitäten Verfügbarkeit, Leistung und Skalierbarkeit.

Zweckmäßigkeit

Die Einfachheit der Wartung eines bereitgestellten Systems, einschließlich der Überwachung des Systems, der Behebung von auftretenden Problemen und der Aufrüstung der Hardware- und Softwarekomponenten.

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 weiterer Server, um Verfügbarkeitsprobleme zu beheben, wirkt sich auf die Wartungskosten (Zweckmäßigkeit) aus.

Für die Entwicklung eines Systems, das sowohl die geschäftlichen Anforderungen als auch Einschränkungen befriedigt, muss klar sein, wie die Systemqualitäten verknüpft sind und wie diese abgestimmt werden.

In den folgenden Abschnitten werden die Systemqualitäten, die sich auf das Bereitstellungskonzept auswirken, näher beschrieben. Es wird außerdem erklärt, welche Faktoren bei der Gestaltung der QoS-Anforderungen berücksichtigt werden müssen. Ein Abschnitt zu den Anforderungen für 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:

Untersuchen Sie, beginnend mit dieser Geschäftsanforderung sämtliche Anwendungsfälle, um zu bestimmen, wie Sie diese Anforderung auf einer Systemebene ausdrücken können. In einigen Fällen möchten Sie möglicherweise Benutzerladebedingungen miteinschließen, die während der Anwendungsanaylse ermittelt wurden. Drücken Sie die Leistungsanforderung für jeden Anwendungsfall in Bezug auf die Antwortzeit unter bestimmten Ladebedingungen oder in Bezug auf die Antwortzeit zuzüglich Datendurchsatz aus. Geben Sie auch die zulässige Anzahl an Fehlern an.

Im Folgenden sehen Sie zwei Beispiele für die Angabe der Systemanforderungen für die Leistung:

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öhnlichen Spitzenauslastung) verknüpft.

Verfügbarkeit

Über die Verfügbarkeit kann man die Betriebszeit eines Systems bestimmen. Sie bemisst sich normalerweise aus dem Prozentsatz der Zeit, während der Benutzer auf das System zugreifen kann. 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üstungen) heruntergefahren wird, werden nicht als Ausfallzeit bezeichnet. Ein grundlegende Gleichung zur Berechnung der Systemverfügbarkeit als Prozentsatz der Betriebszeit ist:

Verfügbarkeit = Betriebszeit / (Betriebszeit + Ausfallzeit) * 100%

Normalerweise messen Sie die Verfügbarkeit anhand der Anzahl der „Neunen“, die Sie erreichen können. Beispielsweise erhalten Sie bei 99%-iger Verfügbarkeit zwei Neunen. Die Angabe zusätzlicher Neunen wirkt sich erheblich auf das Bereitstellungskonzept aus. In der folgenden Tabelle wird die unvorhergesehene Ausfallzeit bei zusätzlichen „Verfügbarkeits-Neunen“ auf einem System berechnet, das 24 Stunden an 7 Tagen die Woche im gesamten Jahr (insgesamt 8760 Stunden) verfügbar ist.

Tabelle 3-3  Unvorhergesehene Ausfallzeiten für ein System, das das ganze Jahr (8760 Stunden) läuft 

Anzahl der Neunen

Verfügbarkeit (Prozent)

Unvorhergesehene Ausfallzeiten

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 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 Einzelpunkt-Versagen 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 Einzelpunkt-Versagen ermitteln und vermeiden.

Fehlertolerante Systeme können in der Implementierung und Wartung teuer sein. Stellen Sie sicher, dass Sie die 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 Anwendungsfälle und Anwendungsanalysen verweisen, für die eine höhere Verfügbarkeit erforderlich ist.

Es ist hilfreich, Verfügbarkeitsbedürfnisse anhand von verschiedenen sortierten 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 erforderlich erachtet werden.

Dienstausfall

Im Rahmen des Verfügbarkeitskonzepts wird auch berücksichtigt, was geschieht, 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.

Sie geben die Skalierbarkeitsanforderungen nicht notwendigerweise mit den QoS-Anforderungen an, es sei denn, das geplante Wachstum der Bereitstellung wird eindeutig in den Geschäftsanforderungen festgehalten. Während der Bereitstellungskonzeptphase des Lösungszyklus 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 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.

Häufig kann es sich hierbei um eine Schätzung über 24 Monate handeln, der die Leistungseinschätzung der vorhandenen Benutzerauslastung und angemessene Einschä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.

Beispielsweise:

  • 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 die Entwicklung und Implementierung der Sicherheitsmaßnahmen leiten soll.

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 

Aspekt

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 geographisch 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 vonnöten ist. 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.



Zurück      Inhalt      Index      Weiter     


Teilenr.: 819-1916.   Copyright 2005 Sun Microsystems, Inc. Alle Rechte vorbehalten.