Den Kontext Am selben CI lesen und den Rückblick einstellen

Eine Störung entsteht selten im luftleeren Raum. Bevor Sie telefonieren oder in anderen Listen suchen, zeigt Ihnen der Abschnitt Am selben CI, was am betroffenen Objekt los ist. Den Zusammenhang erklärt der Überblick. Wie Sie einen gefundenen Change als Ursache festhalten, steht in Einen Change als Ursache verknüpfen.

Beispiel im Artikel: Bei der Beispiel GmbH meldet Sara Beispiel die Störung „Bestellungen lassen sich nicht absenden“ am Auftragsportal. Am Datenbankserver srv-db01 wurden kurz vorher zwei Changes umgesetzt.

Schritt 1: Die Störung in der Vollansicht öffnen

Wählen Sie in der Seitenleiste Servicedesk, Störungen und klicken Sie in der Liste auf die Zeile der Störung. Rechts erscheint die Vorschau. Klicken Sie dort oben auf In Vollansicht öffnen und bleiben Sie auf dem Reiter Übersicht.

Warum? Der Kontext gehört zur Erfassung: Nach ITIL fragt man bei jeder Störung zuerst, was sich am betroffenen System zuletzt geändert hat. Steht die Antwort am Vorgang, spart der Servicedesk die Rundrufe.

Schritt 2: Den Abschnitt Am selben CI lesen

Blättern Sie im Reiter Übersicht nach unten bis zum Abschnitt Am selben CI. Unter der Überschrift steht, wie weit er zurückblickt, zum Beispiel Rückblick: 72 Stunden. Darunter stehen die Gruppen. Leere Gruppen blenden sich aus.

12345

Die Gruppen im Einzelnen:

1. Gelbe Hinweise (vermutete Ursachen). Bei einer Störung zeigt knooing bis zu drei Changes, die zeitlich zur Störung passen. Beispiel: CHG-2026-000002 wurde 1 Minute vor dieser Störung am selben System umgesetzt. Lief der Change noch, als die Störung entstand, heißt es lief am selben System, als diese Störung entstand. Darunter stehen die Schaltflächen Als Ursache verknüpfen und Passt nicht. Noch ist nichts verknüpft, es ist ein Vorschlag. Was Sie damit tun, steht in Einen Change als Ursache verknüpfen.
2. Laufende und kürzliche Änderungen. Jede Zeile nennt Nummer, Titel, die Phase (Geplant, Läuft oder Umgesetzt), das Ergebnis, sobald es erfasst ist, das Fenster beziehungsweise den Umsetzungszeitpunkt und das Objekt, an dem der Change hängt (Am Objekt srv-db01 (Server)). Laufende Changes stehen oben, dann geplante, dann umgesetzte, jeweils die neuesten zuerst. Geplante Changes zeigt der Abschnitt bis sieben Tage voraus, abgebrochene nie.
3. Weitere offene Störungen. Andere Störungen am selben Objekt, die noch nicht geschlossen oder abgebrochen sind, also auch gelöste, bis sie geschlossen werden. Der Vorgang selbst steht nicht in der Liste.
4. Offene Probleme. Probleme am selben Objekt, die noch nicht geschlossen oder abgebrochen sind, mit ihrem Status.
5. Aktive Known Errors am Service. Bekannte Fehler mit Workaround zum Service des Vorgangs. Hier zählt nur der Service selbst, nicht die Objekte, von denen er abhängt.

Über der Liste steht bei Bedarf Betroffene Objekte: mit den Objekten, nach denen gesucht wurde. Das sind die Geräte (CIs), Anwendungen und der Service des Vorgangs. Jede Gruppe zeigt höchstens zehn Einträge und nennt den Rest mit und n weitere. Ist nichts los, steht dort Keine laufenden Änderungen oder offenen Vorgänge an den betroffenen Objekten.

Hängt ein betroffenes Objekt von einem anderen ab (die Datenbank läuft auf einem Server), schaut knooing eine Ebene tiefer mit. Treffer darüber stehen getrennt unter Über Abhängigkeiten (Objekte, von denen die betroffenen Objekte abhängen) und tragen den Vermerk Über Abhängigkeit: mit dem Objekt. Sie stehen in der Reihenfolge der vermuteten Ursachen nach den direkten Treffern.

Warum zeigt der Abschnitt auch die Abhängigkeiten? Eine Änderung am Server kann die Datenbank darauf lahmlegen. Ohne den Blick eine Ebene tiefer dächte niemand an den Server. Nur die Richtung „hängt ab von“ zählt: Sonst zöge ein zentraler Server hunderte fremde Vorgänge an.

Wer sieht was? Der Abschnitt zeigt nur Vorgänge, die Sie auch in der Vorgangsliste sähen. Ohne Zugriff auf die Konfigurationsverwaltung stehen die Objektnamen ohne Klasse und ohne Sprung auf die Objektseite.

Schritt 3: Den Rückblick einstellen

Wie weit der Abschnitt zurückschaut, ist eine fachliche Entscheidung. Wählen Sie in der Seitenleiste unten Einstellungen, dann Servicedesk und SLA-Regeln. Suchen Sie den Block CI-Kontext am Vorgang, tragen Sie bei Stunden Rückblick (1 bis 336) einen Wert ein, zum Beispiel 24, und klicken Sie auf Speichern.

12

1. 1Stunden eintragen
2. 2Speichern

Nach dem Speichern erscheint die Meldung Die Einstellung wurde gespeichert., der Knopf Speichern wird wieder grau und der Wert bleibt stehen. Öffnen Sie danach eine Störung: Die Zeile unter Am selben CI nennt den neuen Wert, zum Beispiel Rückblick: 24 Stunden. Der Wert gilt für alle Vorgänge des Mandanten und wirkt sofort. Der Standard sind 72 Stunden.

Warum einstellbar? Ein Mandant mit wöchentlichen Wartungen braucht ein kurzes Fenster, sonst wirkt jede Störung „verdächtig“. Ein Mandant mit seltenen, großen Änderungen schaut länger zurück.

Beispiel: Die Beispiel GmbH spielt täglich Updates ein. Mit 72 Stunden hätte fast jede Störung drei Verdächtige, mit 24 Stunden nur noch die Changes des letzten Tages.

Wenn etwas nicht klappt

• Der Abschnitt fehlt. Er erscheint nur bei Störungen und Problemen, nicht bei Serviceanfragen oder Changes.
• Weitere Störungen, Probleme oder Known Errors fehlen, obwohl es sie gibt. Sie erscheinen, wenn sie am selben Objekt hängen. Prüfen Sie im Kasten Angaben die Zeile Auslösendes Gerät (CI) der beiden Vorgänge und tragen Sie bei Bedarf dasselbe Gerät ein.
• Der Abschnitt zeigt einen erwarteten Change nicht. Ein Change erscheint, wenn er im Rückblick umgesetzt wurde oder sein geplantes Fenster in den Zeitraum vom Rückblick bis sieben Tage voraus fällt. Ein Change ohne Termin und ohne Umsetzung erscheint nicht.
• Der Kontext ließ sich nicht laden. Die Meldung Der Kontext ließ sich nicht laden. erscheint, wenn die Abfrage scheitert. Laden Sie die Seite neu.
• Der Rückblick lässt sich nicht speichern. Die App meldet Der Rückblick muss zwischen 1 und 336 Stunden liegen. oder Der Rückblick ließ sich nicht speichern. Tragen Sie eine ganze Zahl zwischen 1 und 336 ein. Ohne das Recht für die Servicedesk-Einstellungen ist das Feld gesperrt, und der Knopf Speichern fehlt.