Zum Hauptinhalt wechseln

Der NTx Blog

Geschichten über Technik, und was sonst noch in der IT passieren kann ...

Blogspace
  

Was ist System Center Operations Manager (SCOM) …

… dieses Thema habe ich unlängst wieder ausgiebig mit einem Kunden diskutiert. Also eigentlich drehte sich die Diskussion hauptsächlich darum, was SCOM nicht ist.

Nachdem ich mit diesen Fragen – nicht zuletzt in meinen Trainings – häufig konfrontiert werde, wage ich jetzt den Versuch, dies aus meiner – natürlich gänzlich objektiven :-) - Sicht zu klären. Und weil SCOM in der allgemeinen Wahrnehmung – nicht zuletzt auf Grund des Produktnamens – was mit IT Betrieb zu tun hat, werde ich das unter dem Aspekt der 3 „Produktionsfaktoren“ dieser Disziplin, nämlich

image_itops

tun. Dabei werde ich „People“ einfach so stehen lassen, Sie können das nach Bedarf selbst „in memory“ übersetzen mit „Menschen“ oder „Personal“ oder „Leute“, oder was Ihnen sonst gerade zum Thema „Humankaptial“ einfällt.

Was SCOM ist

ist schnell zusammengefasst:

  • Technologie:
    • eine Statusmaschine für die End-to-End Überwachung von (Server-) Systemen, die Informationen über Statusänderungen mit Hilfe jeder vorstellbaren Benachrichtigungsmethode transportieren kann;
    • eine Datensammelmaschine, hauptsächlich für die Sammlung von Performancedaten zur Gewinnung von Trends über die kapazitative Entwicklung der Umgebung, und die mit dem Audit Collection Service (ACS) zum fast schon manischen Sammelmonster ausartet;
  • People:
    • ein niemals endendes Betätigungsfeld für Administratoren, weil das System – wie jedes andere Monitoringtool auch – an die spezifischen Gegebenheiten der Umgebung angepasst werden muss. Und kaum ist man damit fertig, ändert sie sich schon wieder, die Umgebung.

Ich werde hier nicht näher in die Details vordringen. Aber ich komme nicht umhin zu bemerken, dass mit SCOM hinsichtlich des Monitorings von Windows Systemen technisch nichts unmöglich ist. Die Frage ist immer nur, welcher Nutzen dem Aufwand der Implementierung einer spezifischen Monitoringfunktion gegenübersteht, und das ist eine reine – organisationsspezifische – Bewertungsfrage. Hier wiederstehe ich der Versuchung, in die unendlichen Weiten des Portfoliomanagements abzubiegen, sondern wende mich wieder dem Thema, und hier dem Kern desselben zu:

Was SCOM nicht ist

ist auch rasch gesagt, nämlich

  • Technologie:
    • ein Netzwerk Managementtool.
  • People:
    • ein mit der umfassenden Weisheit aller Microsoft Produktgruppen vollgepacktes, sich autonom optimierendes Wunderwuzzi-Managementtool, mit dem 2/3 der Administrationsmannschaft überflüssig und alle Probleme von vornherein im Keim erstickt werden.
  • Prozess:
    • ein Tool für Incident-/Problem-/Changemanagement, oder anders gesagt: SCOM liefert Ihnen jede Menge Stati, nicht aber die Prozesse, die die Stati auslösen sollten.

Jetzt ist Ihnen als aufmerksamer LeserIn natürlich schon aufgefallen, dass der „Prozess“-Sektor schon im „Was SCOM ist“ Absatz gar nicht vorkommt. Abhilfe kommt hier entweder von Drittherstellern, oder neuerdings mit dem System Center Service Manager (SCSM) aus der System Center Familie. Das klingt ganz super, ist es auch, wenn erst einmal die Prozesse in der Organisation verankert sind. Solange ITIL (oder MOF) unentdeckte Welten sind, helfen die besten Werkzeuge nicht.

Der zweite Punkt ist leider etwas komplexer. Das Faktum der eben nicht in den Management Packs enthaltenen allumfassenden Weisheit der Produktgruppen stößt regelmäßig auf Unverständnis. Der Hauptgrund für diesen “Mangel” liegt in der Komplexität und Individualität der implementierten Betriebsumgebungen und der sich daraus ergebenden Konsequenz, dass „best practices“ für die Organisation „A“ nicht zwangsläufig auch für das Unternehmen „B“ gelten. Jedenfalls ergibt sich daraus die Notwendigkeit, SCOM in einer spezifischen Betriebsumgebung derart zu integrieren, dass dabei die individuellen Organisations-„best practices“ abgeleitet werden, und das ist selbst wieder ein Prozess, der implementiert werden will.

Was SCOM verspricht

Darin liegt aber m.E. das Potential von SCOM: Das Produkt macht Stati einer technischen Infrastruktur gnadenlos sichtbar. Wenn man sich nicht damit begnügt, die entweder kommentarlos zur Kenntnis zu nehmen, oder die lästigen Alarme einfach wegzuklicken, sondern sie konsequent und vor allem konsistent mit SCOM Mitteln bearbeitet, erreicht man zwangsläufig einen Punkt, an dem der “Operations Manager” zur operativen Basis des Betriebs wird.

Und das ist der Sinn der Übung: Probleme nicht suchen oder durch Zufall darüber stolpern (z.B. wenn die User anrufen), sondern – im Idealfall - von vornherein verhindern oder strukturiert bearbeiten, wenn sie auftreten. Spätestens hier braucht es dann Prozesse, die die Betriebsorganisationen genau dazu in die Lage versetzen, sichtbar gewordene Herausforderungen strukturiert und dokumentiert zu meistern.

Diese Prozesse muss man nicht selbst erfinden, und für deren Umsetzung braucht es keine großartigen technologischen Werkzeuge, man muss sie nur implementieren.