Suche
gridsz
GRIDSZ
Kontaktieren Sie uns
Demo anfordern
GRIDSZ

Einführung in Service & Incidents

Das Modul „Service & Incidents“ ermöglicht die Verwaltung verschiedener Aufgabentypen. Welche Typen einem Benutzer zur Verfügung stehen, hängt von seinen Rolleneinstellungen ab. Die wichtigsten Typen werden auf dieser Seite beschrieben, aber beispielsweise der Schadensbericht hat eine eigene Seite.

Ein Incident oder ein (potenzielles) Problem kann jemandem in Ihrer eigenen Organisation oder einer anderen Organisation zugewiesen werden. Wenn Sie einer anderen Organisation zuweisen, können Sie den Benutzer nicht festlegen – dies muss von der zugewiesenen Organisation (falls gewünscht) vorgenommen werden. Sobald ein Bearbeiter eingetragen und die Aufgabe gespeichert wurde, erhält der Bearbeiter eine E-Mail, die die Erstellung der Aufgabe und die Notwendigkeit der Bearbeitung dieser Aufgabe bestätigt.

Incident

Ein Incident ist ein einzelnes Problem im passiven Netzwerk, das mehr als eine Verbindung betrifft. Das bedeutet, ein Incident hat Auswirkungen auf N Verbindungen. Dies kann entweder ein Netzwerk-Incident (Kabel, Verteilerpunkt) oder ein PoP-Incident sein. Ein PoP-Incident, der das passive Netzwerk direkt beeinflusst und somit (direkt) servicebeeinträchtigend ist, ist ein telco-orientierter PoP-Incident. Ein Nicht-Telco-PoP-Incident ist kein Problem mit Netzwerkkomponenten im PoP, sondern umfasst alles um, auf oder im PoP, das für den Betrieb des PoP erforderlich ist, wie z.B. Notstromversorgung (Batteriepack), Klimaanlage oder ein Feuerlöscher. Nicht-Telco-Incidents wirken sich nicht unbedingt direkt auf die Netzwerkdienste aus, können aber im Laufe der Zeit zu Auswirkungen führen.

Incident-Subtypen und Ursachencodes

Beim Erstellen von Incidents in Gridsz kann der Benutzer einen Subtyp und einen Ursachencode zuweisen, um die notwendigen Details bereitzustellen. Die derzeit verfügbaren Subtypen sind:

  • Netzwerk
    Der Incident bezieht sich auf das passive Netzwerk außerhalb eines PoP. Dies kann entweder ein Kabel oder ein Verteilerpunkt sein.
  • PoP
    Incident im oder am PoP, bei dem weitere Details durch Zuweisung eines Ursachencodes (falls bekannt) hinzugefügt werden können, um zu spezifizieren, ob es sich um einen Telco- oder Nicht-Telco-Incident handelt.

Ursachencodes werden vom PO konfiguriert und können verwendet werden, um einen Incident zu öffnen, zu halten oder zu schließen. Um die Codes zu konfigurieren, muss der PO angeben, wo der Code verwendet werden soll (öffnen/halten/schließen), den tatsächlichen alphanumerischen Code (eindeutig), eine Beschreibung, Aufgabentypen zuweisen und ob der Code aktiv oder inaktiv ist. Konfigurierte Codes werden über die AO- und Contractor-APIs kommuniziert.

Incident-Beziehungen

Gridsz kann Serviceaufgaben verknüpfen, die kausale Beziehungen aufweisen oder verknüpft werden müssen, um diese Aufgaben effizient in großen Mengen zu verarbeiten. Verbindungs-Incidents (1 Verbindung), Incidents (N>1 Verbindungen) und Probleme sind die Aufgaben, die Gridsz verknüpfen kann. Wenn Verbindungs-Incidents die Ursache eines Incidents sind, können diese Verbindungs-Incidents mit dem Incident verknüpft werden. Sobald der Incident behoben ist, können alle verknüpften Verbindungs-Incidents bei Bedarf in großen Mengen geschlossen werden. Beim Schließen des Incidents wird der Benutzer gefragt, ob alle verknüpften Verbindungs-Incidents ebenfalls geschlossen werden sollen, oder der Benutzer kann alle oder eine Untermenge der Verbindungs-Incidents, die geschlossen werden müssen, abwählen. Wiederkehrende Incidents mit ähnlichen Merkmalen können in einem Problem erfasst werden, um die Ursachen zu untersuchen und Aufgaben zur Behebung eines Problems und seiner Ursache(n) bereitzustellen.

Incident-Routing

Gridsz kann Incidents und Probleme an Auftragnehmerorganisationen innerhalb eines PO-Clusters routen. Dies ermöglicht dem PO oder seinem NOC, Aufgaben an eine bestimmte Lösungspartei zu leiten. Das NOC kann das Auftragnehmer-Routing für einen einzelnen Incident oder ein Problem bei der Erstellung des Incidents oder nach dessen Erstellung auswählen. Beim Erstellen des Incidents ist der Wert für die Lösungspartei leer. Falls ein Auftragnehmer außerhalb Ihres Clusters in Gridsz angesiedelt ist, lässt der PO/NOC das Feld für die Lösungspartei leer, und es wird keine Auftragnehmeraufgabe erstellt. Dies verhindert die Erstellung unnötiger Aufgaben in Gridsz, die von der Lösungspartei nicht empfangen und bearbeitet werden können. Das NOC muss mit der Lösungspartei telefonisch und/oder per E-Mail kommunizieren, Updates erhalten und diese in den Incident eingeben. Dies gewährleistet eine ordnungsgemäße Nachverfolgung und Schließung der Incidents.

Problem

Eine Problemaufgabe entsteht aus zwei oder mehr Incidents, die bewertet wurden, eine kausale Beziehung teilen und eine weitere Untersuchung der Ursache erfordern, um einen ähnlichen Incident in Zukunft zu verhindern. Das NOC kann Problemtickets mit offenen oder geschlossenen Incidents zusammenstellen. Da Probleme darauf abzielen, Incidents zu verhindern und deren Auswirkungen zu reduzieren, und Incidents in Echtzeit bearbeitet werden, ist zu erwarten, dass Problemtickets hauptsächlich verknüpfte Incidents enthalten, die geschlossen sind. Die Verknüpfung von Incidents ermöglicht es, das Problem mit Informationen zu versorgen, die entscheidend für die Bestimmung von Auswirkungen und Ursachen sind.

Problem, Status: Potenziell

Gridsz kann feststellen, ob ein potenzielles Problem vorliegt. Das NOC kann mögliche Probleme aus Incidents (oder umgekehrt) zusammenstellen und beurteilen, ob es sich tatsächlich um ein Problem oder einen einzelnen/unabhängigen Incident handelt. Potenzielle Probleme können akzeptiert werden; nach der Akzeptanz erhalten sie den Status, der gemäß dem Statusübergangsfluss zugewiesen wird.

Auswirkungsbenachrichtigung (Information des aktiven Betreibers über Kundenbeeinträchtigungen)

Wird ein Incident erstellt, stellt Gridsz (abhängig von den eingegebenen Netzwerkinformationen) eine Liste von Suchcodes und DHids für jeden betroffenen AO bereit. Um diese potenziellen Auswirkungen jedem AO mitzuteilen, erstellt Gridsz Impact_Notification-Aufgaben, die über die AO-API oder per E-Mail kommuniziert werden können. Die Auswirkungsbenachrichtigung informiert den AO über grundlegende Incident-Details, wie zum Beispiel:

  • ID
  • Typ
  • Untertyp
  • Priorität
  • Ursachencode
  • Erwartete Lösungszeit
  • Netzwerkinformationen
  • Potenzielle Auswirkungen
    • Suchcodes
    • DHids
  • Kommentare
  • Anhänge

Die potenziellen Auswirkungen werden über die AO-API kommuniziert und sind auch durch Abrufen des Anhangs (.csv) über die AO-API abrufbar oder die Datei kann per E-Mail-Benachrichtigung empfangen werden.

Falls sich die Netzwerkinformationen ändern oder aktualisiert werden, wird Gridsz eine neue Bewertung der potenziell betroffenen Suchcodes und DHids bereitstellen, die anschließend den AOs über deren bevorzugte Kommunikationsmethode mitgeteilt werden.

Impact_Notifications sind für AOs schreibgeschützt, daher können keine Änderungen an ihren Informationselementen wie Untertyp, Priorität, Status, Netzwerkinformationen, Daten usw. vorgenommen werden. Der AO darf Kommentare und/oder Anhänge in der Impact_Notification hinterlegen, um dem PO NOC Informationen oder Mitteilungen zukommen zu lassen.

Die Impact_Notification folgt den Status und Informationen ihrer übergeordneten Aufgabe – dem Incident. Ändert sich der Incident-Status (z.B. wird der Incident geschlossen), werden auch die Impact_Notification-Aufgaben geschlossen. Ändern sich Informationen, z.B. die Priorität, wird dies ebenfalls in den Impact_Notification-Aufgaben aktualisiert.

FTU-Änderung

Eine FTU-Änderung ist ein HAS-bezogener Auftrag, der Änderungen an FTUs und deren Standort (Verbindungsstatus) ermöglicht. Dies erlaubt aktiven Betreibern, Änderungen anzufordern, die der passive Betreiber durch Erstellung der FTU-Änderungsaufgabe zulassen kann. Je nach erforderlicher Änderung kann der entsprechende Untertyp gewählt werden, die nachfolgend erläutert werden. Die FTU-Änderung konzentriert sich ausschließlich auf HAS-Informationen, was bedeutet, dass kein Patching involviert ist.

FTU-Änderungsuntertypen

Beim Erstellen einer FTU-Änderung in Gridsz kann der Benutzer einen Untertyp zuweisen, der die korrekten Änderungen ermöglicht. Die verfügbaren Untertypen werden nachfolgend erläutert:

  • Konstrukt
    Die FTU-Änderung – Konstrukt ermöglicht die Erstellung einer FTU_CONSTRUCT-Aufgabe für den Auftragnehmer. Da kein PATCH_INSTALL ausgegeben wird, kann dieser Aufgabentyp typischerweise verwendet werden, wenn ein PO Adressen aktiv mit Glasfaser verbindet, aber diese Verbindung nicht patchen möchte.
    • Der geplante FTU-Wert dient zur Bestimmung, welchen FTU-Typ der Auftragnehmer platzieren soll.
  • Verschieben
    Die FTU-Änderung – Verschieben ermöglicht die Erstellung einer FTU_MOVE-Aufgabe für den Auftragnehmer. Wenn eine Adresse über eine aktive Verbindung verfügt, aber z.B. der FTU-Standort die (technischen) Anforderungen des PO nicht erfüllt, ermöglicht die FTU_MOVE dem PO, einen neuen Standort für die FTU festzulegen.
    • Der aktuelle FTU-Standort wird aus Gridsz AC abgerufen (falls verfügbar).
    • Bei der Erstellung der Aufgabe kann ein neuer Verbindungsstatus (Standort) für die FTU ausgewählt werden.
    • Wenn der Auftragnehmer die FTU_MOVE liefert, kann er optional aufgefordert werden, den neuen (geplanten) Verbindungsstatus zu bestätigen. Oder, falls aus einem (technischen) Grund der ursprünglich geplante Verbindungsstatus nicht möglich ist, den tatsächlichen Verbindungsstatus der FTU auszuwählen und festzulegen, bevor die Aufgabe geliefert wird. Diese Informationen werden in der übergeordneten Aufgabe aktualisiert. (Diese Informationen aktualisieren derzeit nicht AC.)
  • Ersetzen
    Die FTU-Änderung – Ersetzen ermöglicht die Erstellung einer FTU_RECONSTRUCT-Aufgabe für den Auftragnehmer. Z.B. falls der PO die FTU auf ein neueres Modell aufrüsten möchte.
    • Der aktuelle FTU-Typ wird aus Gridsz AC abgerufen.
    • Der geplante FTU-Typ wird aus Gridsz AC abgerufen (erforderlich für FTU_RECONSTRUCT).
  • Entfernen
    Die FTU-Änderung – Entfernen ermöglicht die Erstellung einer FTU_REMOVE-Aufgabe für den Auftragnehmer. Zum Beispiel, wenn Gebäude abgerissen oder renoviert werden und die FTU entfernt und das Glasfaserkabel zur Grundstücksgrenze zurückgeführt werden muss, kann der PO diese Aufgabe nutzen.