Im letzten Beitrag „Systemautomaion – Definition und Messageflut“ habe ich über die Flut an Messages im z/OS geschrieben. Heute beschreibe ich, wie wir diese in den Griff bekommen:
Untersuchung der Messages
Die Systemautomation verankert sich im System und untersucht mit verschiedenen Mitteln die auf dem z/OS-System auflaufenden Messages.
Anhand vordefinierter Kriterien wird dann entschieden, ob:
1. auf eine Message reagiert werden muss.
2. selbständig korrektiv eingegriffen werden soll.
3. bestimmte Betriebseinheiten über den aufgetretenen Zustand informiert werden sollen.
Wie wichtig diese Filter- und Voranalyse-Möglichkeiten sind, zeigen die von uns ermittelten Zahlen:
Gesamt – und automatisierte Messages bei der Systemadministration
Bei einem Verhhältnis von einer automatisierten zu 384 Gesamt-Messages, wird dem Operator also die Arbeit erspart, aus 384 Messages die eine herauszufinden, auf die eine Reaktion erfolgen muss.
Zielorientierung bei Automatischen Reaktionen
Generell ist wichtig, dass die Automation zielorientiert arbeitet. Erfolgt eine automatische Reaktion, so sollte evaluiert werden, ob sich der gemeldete Zustand verändert hat, und – wichtig! – wenn ja, ob der neue Zustand dem entspricht, der erwartet wird. Zielorientierung heißt aber nicht unbedingt, dass alle auf einem System startbaren Anwendungen (Ressourcen im Automations-Sprachgebrauch) auch gestartet werden müssen. Um sich an einem Systemverbund anmelden zu können, genügt es zum Beispiel wenn eines der Systeme im Verbund diese Möglichkeit bietet. Fällt dieses System aus oder wird es bewusst beendet, sorgt die Systemautomation dafür, dass der Zugang von einem anderen System im Verbund bereitgestellt wird.
Bei FI-TS verwaltet die Systemautomation insgesamt ca. 10.100 Ressourcen. Diese werden anhand vorgegebener Kriterien verfügbar gehalten.
Diese Kriterien setzen sich so zusammen:
Die unterschiedlichen Abhängigkeiten in der Systemautomation
Es gibt „harte“ Abhängigkeiten. Das sind Voraussetzungen, wie beispielsweise die Verfügbarkeit von IP-Services. Daneben gibt es „zeitliche“ Abhängigkeiten, die besagen können, dass die Ressource zum Beispiel nur an Wochentagen zwischen 8:00 Uhr und 20:00 Uhr verfügbar sein soll.
Auch „zustandsspezifische“ Abhängigkeiten sind möglich. Die werden beispielsweise beim Auftreten einer bestimmten Message während des Startens definiert. So kann der Befehl lauten: Wird Ressource A gestartet, wird die abhängige Ressourcen AB nicht gestartet.
Von „dynamischen“ Abhängigkeiten sprechen wir, wenn beipielsweise Datenbanksystem 1 gestartet wird und dann Aktionenkatalog 1 gewählt werden soll. Das gleiche gilt für Datenbanksystem 2. Wird es gestartet, dann soll Aktionenkatalog 2 gewählt werden.
Reaktionen auf den Health State, also den „Gesundheitszustand“ können sein, dass bei Überschreitung einer bestimmten Anzahl an Messages sofort weitere Ressourcen zum Auffangen der Messages gestartet werden. Der Health State ist also ein Kriterium, dass bei Überschreitung eines Schwellwertes, weitere Ressourcen ebenfalls Messages von der Queue lesen und umgekehrt bei Unterschreitung des Schwellwertes die zuvor gestarteten Ressourcen wieder gestoppt werden.
Daneben gibt es auch noch die Abhängigkeit vom Systemstatus, beispielsweise der Zustand „in Wartung“, „voll produktionsfähig“, und so weiter.
Ergänzung der Kriterien um Kundensicht
Viele dieser Kriterien können auch um eine logische Kundensicht ergänzt werden. Das heißt, dass beim Auftreten einer bestimmten Message für den Kunden 1 der Befehl A, für den Kunden 2 aber der Befehl B ausgeführt wird. So können wir einen gemeinsamen, starken Standard fahren und unseren Kunden trotzdem höchste Flexibilität gewähren, wenn es notwendig sein sollte.
So viel zu den Basis-Diensten der Systemautomation.
Im nächsten Beitrag werde ich mich intensiv mit den erweiterten Möglichkeiten zur Ermittlung des Health State („Gesundheitszustand“) auseinander setzen.