Zu Service-Level-Management migrieren
Migrieren Sie die SLA-Verarbeitung von der Eskalations-Engine, um die Service-Level-Management-Funktionalität zu verwenden.
Die beiden Hauptunterschiede zwischen der alten SLA-Engine und dem neuen Service-Level-Management-Plugin bestehen darin, dass Aufgaben jetzt mehrere SLAs gleichzeitig ausführen können und das Eskalations-Konzept durch den robusteren Workflow-Editor ersetzt wurde. Dadurch können Administratoren besser steuern, welche Aktionen, Benachrichtigungen und Ereignisse von Aufgaben ausgelöst werden, um ausgereiftere Servicelevel-Prozesse zu berücksichtigen.
Wenn eine Instanz die ursprüngliche SLA-Engine verwendet und das SLA-Plugin (Service Level Agreement) aktiviert hat, funktionieren die alten SLAs nicht mehr. Damit die alten SLAs funktionieren, müssen sie in die neuen SLA-Definitionsdatensätze konvertiert werden, die die entsprechenden Aufgaben-SLA-Datensätze an die entsprechenden Aufgaben-Datensätze anhängen. Dies geschieht manuell, indem neue SLA-Definitionsdatensätze erstellt werden, die die Definition des alten SLA widerspiegeln. Alte SLAs funktionieren weiterhin, aber jedes Mal, wenn eine Aufgabe aktualisiert wird, werden die entsprechenden neuen Aufgaben-SLAs angehängt.
Sobald neue Aufgaben-SLAs implementiert sind, werden sie sich an jeden neuen oder aktualisierten Incident anhängen, einschließlich solcher, an die bereits alte SLAs angehängt sind. Wenn das neue Aufgaben-SLA so eingestellt ist, dass er rückwirkend startet, berechnet es automatisch die Dauer ab diesem Punkt in der Vergangenheit. Daher ist die Dauer weiterhin genau.
Ist die Eigenschaft Vorherige SLA-Pausenzeit für neue, retroaktive SLAs berechnen (nur SLA-Engine 2011) aktiviert, wird die Pausenzeit berechnet, wenn ein retroaktiver SLA angehängt.
Beispiel: Wenn ein rückwirkendes SLA sich eine Stunde nach seiner Erstellung an einen Incident anhängt und die Pausierungsbedingungen eine halbe Stunde lang erfüllt sind, beträgt die verstrichene Zeit eine halbe Stunde statt der vollen Stunde.