Nicht autorisierte Change-Anforderung

  • Freigeben Version: Washingtondc
  • Aktualisiert 1. Februar 2024
  • 4 Minuten Lesedauer

    • Hier erfahren Sie, wie Sie nicht autorisierte Change-Aktivitäten, die an Konfigurationselementen (CIs) vorgenommen werden, erfassen und verwalten können, um den Change zu prüfen und rechtzeitig Maßnahmen zu ergreifen.

    Im Rahmen der ServiceNow® Service-Mapping -Integration mit ServiceNow® ITSM erhält die Anwendung Change-Management eine Event-Benachrichtigung, wenn eine nicht autorisierte Change-Aktivität erkannt wird. Daher wird für das relevante CI eine nicht autorisierte Notfall-Change-Anforderung erstellt. Sie können den nicht autorisierten Change über die Change-Management-Anwendung überprüfen und genehmigen oder ablehnen.

    Hinweis:
    Nicht autorisierte Change-Anforderungen werden nur für die CIs erstellt, die Teil der Anwendungsservices sind. Außerdem gibt es einen Flapper-Algorithmus, der ein Lernmuster verwendet, um Falschmeldungen zu minimieren.

    Manchmal identifiziert der Discovery-Prozess (horizontale Erkennung oder Erkennung von oben nach unten) einen Change an einer CI-Eigenschaft, die gemäß Definition möglicherweise kein tatsächlicher Change ist. Diese Identifizierung ist auf einen Messfehler zurückzuführen, oder darauf, dass es sich um eine andere Darstellung desselben Werts handelt, z. B. bei Beachtung der Groß-/Kleinschreibung. Das Lernmuster identifiziert die falsch positive Meldungen (Flapper-Changes) und verhindert das Auslösen der Neuberechnung und Zeitachsen-Aktualisierungen, da Notfall-Change-Anforderungen kritische Aktionen sind. Es empfiehlt sich, falsch positive Meldungen zu vermeiden und nur echte Changes zu melden.

    Das Lernmuster identifiziert falsch positive Meldungen wie folgt:
    1. Wenn eine mit einem Service verknüpfte CI-Eigenschaft geändert wird, wird der neue Wert (CI-und-Feld-Paar) in der Datentabelle des Flapper protokolliert.
    2. Das System führt eine nächtliche Aufgabe aus und führt verschiedene Algorithmen für die erfassten Daten aus, um Muster zu identifizieren, die auf falsch positive Meldungen hinweisen.
    3. Das System führt alle relevanten Strategieprädikate für die geänderten CI-Felder mit einem Konfidenzniveau größer als 90 % aus. Dieser Schritt bestimmt, ob alle neuen Werte Falschmeldungen sind oder nicht. Wenn alle neuen Werte falsch positive Meldungen sind, wird der Change ignoriert, und das Modell wird nicht aktualisiert.
      Hinweis:
      Wenn das CI einer aktiven Change-Anforderung zugeordnet ist, wird dieser Schritt übersprungen.
    Eine nicht autorisierte Change-Anforderung wird erstellt, wenn eine ungeplante CI-Change-Aktivität auftritt. Das System löst dann die folgenden Prüfungen aus:
    • Das System prüft, ob das Konfigurationselement (CI) einer der zulässigen CI-Klassen angehört. Wenn dies der Fall ist, prüft das System, ob dieses konkrete CI zuvor schon einmal gekennzeichnet wurde. Wurde es schon einmal gekennzeichnet und lag der zuvor erstellte nicht autorisierte Change im Ignorierungszeitraum für Benachrichtigungen, wird keine weitere Aktion ausgeführt. Andernfalls wird weiter geprüft, ob dieses CI mit einer Change-Anforderung verknüpft ist, die den in den Eigenschaften angegebenen Bedingungen entspricht. Falls nicht, wird der erkannte CI-Change als nicht autorisiert gekennzeichnet, und ein ci.change.unplanned-Ereignis wird ausgelöst.
    • Bei Empfang des Ereignisses ci.change.unplanned prüft das Skript, ob das Feld Event-Verarbeitung aktivieren den Wert true aufweist. Wenn der Wert true ist, wird eine nicht autorisierte Change-Anforderung erstellt. Standardmäßig ist diese Eigenschaft false.

    Das Ereignis ci.change.unplanned, das generiert wird, löst automatisch die Erstellung einer Change-Anforderung vom Typ „Notfall“ aus.

    Mithilfe folgender, im Formular vorab ausgefüllter Angaben können Sie nicht autorisierte Changes identifizieren und prüfen:
    • Die Option Nicht autorisiert ist aktiviert. Diese Option gibt an, dass der Change nicht autorisiert ist.
    • In das Feld Zuweisungsgruppe wurde Change Management eingetragen.
    • Das Feld Konfigurationselement wurde mit dem Element gefüllt, an dem der nicht autorisierte Change vorgenommen wurde.
    • Im Feld Beschreibung werden Angaben zu den geänderten Feldern der Change-Anforderung eingetragen.
    Abbildung : 1. Change Request-Formular
    Kennzeichnung eines nicht autorisierten Change
    Eine E-Mail-Benachrichtigung zur Überprüfung und Genehmigung wird an die Mitglieder von „Zuweisungsgruppe“, „CI-Element verwaltet von“, „Eigentum von“ und „Zugewiesen an“ gesendet. Wenn jedoch viele CI-Changes vorliegen und keine offenen Change-Anforderungen erstellt wurden, welche die CIs einbeziehen, erstellt das System für diese CIs nicht autorisierte Change-Anforderungen. Wenn dieses Ereignis auftritt, erhalten die Mitglieder zahlreiche Benachrichtigungs-E-Mails über nicht autorisierte Changes. in so einem Fall können Sie diese Benachrichtigungen deaktivieren. Weitere Informationen finden Sie unter Benachrichtigung über nicht autorisierte Changes deaktivieren.
    Hinweis:
    E-Mail-Benachrichtigungen werden nur gesendet, wenn ein ungeplanter Change für ein CI vorliegt, das Teil eines Anwendungsservice ist (erkannter oder manueller Service).

    Sobald diese Change-Anforderung genehmigt wurde, ändert sich der Status in Prüfung und die Anforderung wird über den regulären Prozess geschlossen.

    Überprüfung nach der Implementierung zuweisen

    Wenn ein Change ohne Genehmigung implementiert wird, ist eine Überprüfung nach der Implementierung erforderlich, um das Risiko und die Auswirkungen des nicht autorisierten Change zu bewerten.

    Wenn der nicht autorisierte Change genehmigt wurde, wird eine Change-Aufgabe erstellt, bei der das Feld Status den Wert Prüfung enthält. Diese Change-Aufgabe wird mit dem Wert Überprüfung nach der Implementierung im Feld Kurzbeschreibung der Change Management-Gruppe zugewiesen. Die zugewiesenen Mitglieder, welche die Benachrichtigung erhalten, können die Change-Aufgabe überprüfen und schließen.

    Einstellungen für nicht autorisierte Changes ändern

    Als Change-Manager können Sie das Kontrollkästchen Nicht autorisiert deaktivieren, um eine nicht autorisierte Change-Anforderung in eine Notfall-Change-Anforderung umzuwandeln. Wenn Sie das Kontrollkästchen deaktivieren, geben Sie den Grund für diese Änderung im Feld Arbeitsnotizenein.

    Wenn Sie ITIL-Benutzer sind, können Sie das Kontrollkästchen Nicht autorisiert deaktivieren, indem Sie aus dem Aufgabendatensatz heraus einen Ausfall erstellen. Das Feld Typ muss den Wert Ausfall enthalten. Weitere Informationen finden Sie unter Ausfall von einer Aufgabe erstellen.

    Hinweis:
    Wenn ein nicht autorisierter Change ohne zugehörigen Ausfalldatensatz vorliegt, wechselt der Status von Autorisieren zu Prüfung. Die Status „Zeitplan“ und „Implementieren“ werden übersprungen. Der Status ändert sich, weil die Implementierung für diesen Change bereits erfolgt ist.