Suche
GRIDSZ
Kontakt
Demo anfordern
GRIDSZ

Einführung in Service & Vorfälle

Das Modul Service & Vorfälle ermöglicht die Verwaltung verschiedener Arten von Aufgaben. Welche Arten einem Benutzer zur Verfügung stehen, hängt von seinen Rolleneinstellungen ab. Die wichtigsten Arten werden auf dieser Seite beschrieben, aber zum Beispiel der Schadensbericht hat eine eigene Seite.

Ein Vorfall oder ein (potenzielles) Problem kann jemandem in Ihrer eigenen Organisation oder einer anderen Organisation zugewiesen werden. Wenn Sie eine Aufgabe einer anderen Organisation zuweisen, können Sie den Benutzer nicht angeben - das muss die zugewiesene Organisation tun (falls gewünscht). Sobald ein Empfänger eingegeben und die Aufgabe gespeichert wurde, erhält der Empfänger eine E-Mail, in der er über die Erstellung der Aufgabe informiert wird und darauf hingewiesen wird, dass die Bearbeitung dieser Aufgabe erforderlich ist.

Vorfall

Ein Vorfall ist ein einzelnes Problem im passiven Netz, das mehr als eine Verbindung betrifft. Das bedeutet, dass ein Vorfall Auswirkungen auf eine Anzahl von N Verbindungen hat. Dabei kann es sich entweder um einen Netzvorfall (Kabel, Verteilerpunkt) oder um einen PoP-Vorfall handeln. Ein PoP-Ereignis, das sich direkt auf das passive Netz auswirkt und somit (direkt) Auswirkungen auf den Dienst hat, ist ein telco-orientiertes PoP-Ereignis. Ein nicht telco-orientierter PoP-Zwischenfall betrifft keine der Netzkomponenten im PoP, sondern alles um, auf oder im PoP, was für den Betrieb des PoP erforderlich ist, z. B. eine Notstromversorgung (Batterie), eine Klimaanlage oder ein Feuerlöschgerät. Ein Nicht-Telekommunikationsproblem hat nicht unbedingt direkte Auswirkungen auf die Netzdienste, kann aber im Laufe der Zeit zu einer Beeinträchtigung führen.

Subtypen von Vorfällen und Ursachencodes

Bei der Erstellung von Vorfällen in Gridsz kann der Benutzer einen Untertyp und einen Grundcode zuweisen, um die notwendigen Details zu liefern. Die derzeit verfügbaren Untertypen sind:

  • Netzwerk
    Der Vorfall bezieht sich auf das passive Netzwerk außerhalb eines PoP. Dies kann entweder ein Kabel oder ein Verteilerpunkt sein.
  • PoP
    Vorfall im oder am PoP, zu dem weitere Details hinzugefügt werden können, indem ein Grundcode (falls bekannt) zugewiesen wird, um anzugeben, ob es sich um einen Telekommunikations- oder Nicht-Telekommunikationsvorfall handelt.

Grundcodes werden vom PO konfiguriert und können entweder zum Öffnen, Halten oder Schließen eines Vorfalls verwendet werden. Um die Codes zu konfigurieren, muss der PO angeben, wo der Code verwendet werden soll (öffnen/halten/schließen), den eigentlichen alphanumerischen Code (eindeutig), eine Beschreibung, Aufgabentyp(en) zuweisen und ob der Code aktiv oder inaktiv ist. Die konfigurierten Codes werden über die AO- und Auftragnehmer-APIs übermittelt.

Beziehungen zu Zwischenfällen

Gridsz kann Serviceaufgaben miteinander verknüpfen, die in einem kausalen Zusammenhang stehen oder miteinander verknüpft werden müssen, um diese Aufgaben effizient zu bearbeiten. Verbindungs-Incidents (1 Verbindung), Incidents (N>1 Verbindungen) und Probleme sind die Aufgaben, die Gridsz verknüpfen kann. Wenn Verbindungsvorfälle die Ursache für einen Vorfall sind, können diese Verbindungsvorfälle mit dem Vorfall verknüpft werden. Sobald der Vorfall gelöst ist, können alle verknüpften Verbindungsvorfälle bei Bedarf geschlossen werden. Beim Schließen des Vorfalls wird der Benutzer gefragt, ob alle verknüpften Verbindungsvorfälle ebenfalls geschlossen werden sollen, oder der Benutzer kann alle oder eine Teilmenge der Verbindungsvorfälle, die geschlossen werden müssen, abwählen. Vorfälle, die sich wiederholen und ähnliche Merkmale aufweisen, können in einem Problem erfasst werden, um die Ursachen zu untersuchen und Aufgaben zur Lösung eines Problems und seiner Ursache(n) bereitzustellen.

Routing von Vorfällen

Gridsz kann Vorfälle und Probleme an Auftragnehmerorganisationen innerhalb eines PO-Clusters weiterleiten. Damit kann der PO oder sein NOC Aufgaben an eine bestimmte Lösungspartei weiterleiten. Das NOC kann das Routing des Auftragnehmers für einen einzelnen Vorfall oder ein Problem bei der Erstellung des Vorfalls oder nach der Erstellung des Vorfalls auswählen. Bei der Erstellung des Vorfalls ist der Wert für den Lösungspartner leer. Falls ein Auftragnehmer außerhalb Ihres Clusters in Gridsz sitzt, lässt die PO/NOC das Feld für die Lösungspartei leer und es wird keine Auftragnehmeraufgabe erstellt. Dadurch wird verhindert, dass unnötige Aufgaben in Gridsz erstellt werden, die nicht von der Lösungspartei empfangen und bearbeitet werden können. Das NOC muss mit dem Problemlöser kommunizieren und von diesem per Telefon und/oder E-Mail Updates erhalten und diese in den Vorfall eingeben. Sicherstellung der ordnungsgemäßen Weiterverfolgung und des Abschlusses des Vorfalls/der Vorfälle.

Problem

Eine Problemaufgabe ergibt sich aus zwei oder mehr Vorfällen, die bewertet wurden, einen kausalen Zusammenhang aufweisen und eine weitere Untersuchung der Grundursache erfordern, um einen ähnlichen Vorfall in Zukunft zu verhindern. Das NOC ist in der Lage, Problemtickets mit offenen oder abgeschlossenen Vorfällen zusammenzustellen. Da sich Probleme auf die Vermeidung von Vorfällen und die Verringerung ihrer Auswirkungen konzentrieren und Vorfälle in Echtzeit behandelt werden, ist zu erwarten, dass Problemtickets hauptsächlich mit geschlossenen Vorfällen verknüpft sind. Die Möglichkeit, Vorfälle zu verknüpfen, ermöglicht es, das Problem mit Informationen zu versorgen, die für die Bestimmung der Auswirkungen und der Grundursachen entscheidend sind.

Problem, Status Potenzial

Gridsz kann feststellen, ob es ein potenzielles Problem gibt. Das NOC ist in der Lage, mögliche Probleme aus Incidents (oder v.v.) zusammenzustellen und zu beurteilen, ob es sich tatsächlich um ein Problem oder einen einzelnen/unverbundenen Incident handelt. Potenzielle Probleme können akzeptiert werden, und sobald sie akzeptiert sind, erhalten sie den Status, der gemäß dem Statusübergangsfluss zugewiesen wird.

Meldung der Auswirkungen (Information des aktiven Betreibers über die Auswirkungen auf den Kunden)

Wenn ein Vorfall erstellt wird, wird Gridsz (abhängig von den eingegebenen Netzwerkinformationen) eine Liste von Suchcodes und DHid's für jede betroffene AO bereitstellen. Um diese potenziellen Auswirkungen an jede AO zu kommunizieren, erstellt Gridsz impact_notification Aufgaben, die über die AO API oder per E-Mail kommuniziert werden können. Die Impact-Benachrichtigung informiert die AO über grundlegende Details des Vorfalls, wie z.B.:

  • ID
  • Typ
  • Untertyp
  • Priorität
  • Code für den Grund
  • Erwartete Lösungszeit
  • Netz-Infos
  • Mögliche Auswirkungen
    • Suchcodes
    • DHids
  • Kommentare
  • Anhänge

Die potenziellen Auswirkungen werden über die AO-API mitgeteilt und können auch abgerufen werden, indem der Anhang (.csv) über die AO-API abgerufen wird oder die Datei per E-Mail-Benachrichtigung empfangen wird.

Falls sich die Netzwerkinformationen ändern oder aktualisiert werden, wird Gridsz eine neue Einschätzung der potenziell betroffenen Suchcodes und DHid's liefern, die dann den AO's über ihre bevorzugte Kommunikationsmethode mitgeteilt werden.

Impact_notifications sind für die AOs nur lesbar, daher können keine Änderungen an den Informationselementen wie Untertyp, Priorität, Status, Netzinformationen, Daten usw. vorgenommen werden. Die AO kann Kommentare und/oder Anhänge in die impact_notification einfügen, um dem PO NOC Informationen oder Mitteilungen zukommen zu lassen.

Die impact_notification folgt dem Status und den Informationen ihrer übergeordneten Aufgabe - dem Vorfall. Wenn sich der Status des Vorfalls ändert (z. B.: der Vorfall wird geschlossen), werden die impact_notification Aufgaben ebenfalls geschlossen. Wenn sich Informationen ändern, z. B. die Priorität, werden diese auch in den impact_notification-Aufgaben aktualisiert.

FTU Veränderung

Eine FTU-Änderung ist ein HAS-bezogener Auftrag, der Änderungen an FTUs und deren Standort (Verbindungsstatus) erlaubt. Dies ermöglicht es aktiven Betreibern, Änderungen zu beantragen, die der passive Betreiber zulassen kann, indem er die FTU-Änderungsaufgabe erstellt. Je nach der gewünschten Änderung kann der entsprechende Untertyp gewählt werden, der im Folgenden erläutert wird. Bei der FTU-Änderung geht es nur um HAS-Informationen, d. h. es ist kein Patching erforderlich.

FTU Subtypen ändern

Bei der Erstellung einer FTU-Änderung in Gridsz kann der Benutzer einen Subtyp zuweisen, damit die richtigen Änderungen vorgenommen werden können. Die verfügbaren Untertypen werden im Folgenden erläutert:

  • Konstruieren Sie
    Die FTU ändern - Konstruieren kann eine FTU_CONSTRUCT-Aufgabe für den Auftragnehmer erstellt werden. Da kein PATCH_INSTALL ausgegeben wird, kann dieser Aufgabentyp typischerweise verwendet werden, wenn ein PO aktiv Adressen mit Glasfaser verbindet, diese Verbindung aber nicht patchen möchte.
    • Der geplante FTU-Wert wird verwendet, um zu bestimmen, welchen FTU-Typ der Auftragnehmer platzieren soll.
  • Verschieben
    Die FTU ändern - verschieben kann eine FTU_MOVE-Aufgabe für den Auftragnehmer erstellt werden. Wenn eine Adresse eine aktive Verbindung hat, aber z. B. der Standort der FTU nicht den (technischen) Anforderungen des PO entspricht, kann der PO mit FTU_MOVE einen neuen Standort für die FTU festlegen.
    • Der aktuelle FTU-Standort wird von Gridsz AC abgefragt (falls verfügbar)
    • Beim Erstellen 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, wenn aus irgendeinem (technischen) Grund der ursprünglich geplante Verbindungsstatus nicht möglich ist, den tatsächlichen Verbindungsstatus der FTU vor der Übergabe der Aufgabe auszuwählen und einzustellen. Diese Information wird in der übergeordneten Aufgabe aktualisiert. (diese Information wird derzeit nicht von AC aktualisiert)
  • Ersetzen Sie
    Die FTU Ändern - Ersetzen ermöglicht die Erstellung einer Aufgabe FTU_RECONSTRUCT für den Auftragnehmer. Z.B. für den Fall, dass der Besteller die FTU auf ein neueres Modell umrüsten möchte.
    • Der aktuelle FTU-Typ wird von Gridsz AC abgefragt.
    • Der geplante FTU-Typ wird aus Gridsz AC geholt (erforderlich für FTU_RECONSTRUCT)
  • Entfernen
    Mit der FTU-Änderung - Entfernen kann eine FTU_REMOVE-Aufgabe für den Auftragnehmer erstellt werden. Wenn z. B. Gebäude abgerissen oder renoviert werden und die FTU entfernt und das Glasfaserkabel zurück an die Grundstücksgrenze verlegt werden muss, kann der PO diese Aufgabe verwenden.