DEEN
Projekt besprechen
Menü

So arbeiten wir bei Störungen, Changes und Patches

Bei Störungen, Changes, Problemen und Patches sollen Sie wissen, wer zuständig ist und was als Nächstes passiert. Deshalb arbeiten wir nach dem ITIL® Framework.

Störungen: Incident Management

Jede Störung hat einen Verantwortlichen, vom Alarm bis zum BerichtITIL® Praxis: Incident Management, vereinfachtJede Störung hat einen Verantwortlichen, vom Alarm bis zum BerichtITIL® Praxis: Incident Management, vereinfachtKundeMonitoringTechnikerTeamMeldungAlarmIncidenterfassenPriorisierenP1 bis P4Statusmeldungan den KundenP1/P2: laut SLADiagnose &Workaroundbehoben?Swarming:Team hinzuziehenneinLösungbestätigtjaWiederholt?→ Problem Mgmt.

Fahren Sie mit der Maus über einen Schritt oder tippen Sie ihn an. Hervorgehoben bleibt, was davor passiert und wie es danach weitergeht.

Jede Störung hat einen Verantwortlichen, von der Meldung oder dem Alarm bis zur bestätigten Behebung.
Jede Störung hat einen Verantwortlichen, von der Meldung oder dem Alarm bis zur bestätigten Behebung.
Eine Störung, von der Erfassung bis zum ReviewIncident Management
Erfasst
In ArbeitChange
BehobenPatch
ReviewProblem
P2Störung

Eine Störung melden Sie uns, oder unser Monitoring schlägt Alarm. Ein Techniker erfasst den Incident, setzt die Priorität und schickt Ihnen eine erste Statusmeldung. Dann stellt er die Diagnose. Wenn nötig richtet er einen Workaround ein, damit Ihr System wieder läuft.

Reicht das nicht, holen wir weitere Leute aus dem Team dazu. Den Incident schließen wir erst, wenn die Behebung bestätigt ist. Kommt dieselbe Störung wieder, übernimmt das Problem Management.

Prioritäten: Auswirkung und Dringlichkeit

Die Priorität von P1 bis P4 ergibt sich aus der Auswirkung einer Störung und ihrer Dringlichkeit. P1 heißt, die Produktion steht oder Daten oder Sicherheit sind gefährdet. Welche Reaktionszeit gilt, hängt von der Priorität und Ihrem Service Level ab. Was wir unter Reaktion verstehen und welche Zeiten je Service Level gelten, steht unter Service Levels.

Auswirkung × Dringlichkeit bestimmen die ReaktionszeitITIL® Praxis: Incident Management · Priorität · Reaktion heißt, ein Techniker arbeitet daranAuswirkung × Dringlichkeit bestimmen die ReaktionszeitITIL® Praxis: Incident Management · Priorität · Reaktion heißt, ein Techniker arbeitet daranDringlichkeitAuswirkunghochmittelniedrighochmittelniedrigP1P2P3P2P3P4P3P4P4Reaktionszeit je ServicestufeBasisBusiness24/7AbdeckungMo bis Fr8 bis 17Mo bis Fr7 bis 20P1: 24/7P14 Std.¹1 Std.¹auf AnfrageP2+1 Arbeitstag4 Std.¹4 Std.¹¹ innerhalb der Servicezeit; 24/7: P1 rund um die UhrP1 Produktion steht oder Sicherheit gefährdetP2 Wichtige Funktion gestörtP3 Einschränkung mit WorkaroundP4 Anfrage oder kleiner Fehler

Fahren Sie mit der Maus über ein Feld oder tippen Sie es an. Darunter steht, was die Priorität bedeutet und wie schnell wir reagieren.

Auswirkung und Dringlichkeit bestimmen die Priorität und damit die Reaktionszeit.
Auswirkung und Dringlichkeit bestimmen die Priorität und damit die Reaktionszeit.

Änderungen: Change Enablement

Jede Änderung an Ihrem System ist ein Change, und wie schnell wir ihn ausrollen, hängt vom Risiko ab. Dafür gibt es drei Wege:

  • Standard Changes kommen immer wieder vor und haben ein geringes Risiko. Sie folgen einer vorab genehmigten Vorlage und brauchen keine Einzelfreigabe.
  • Bei einem Normal Change bewerten wir das Risiko, planen den Rollback und holen die Freigabe der Change Authority ein.
  • Muss jemand sofort eingreifen, holen wir für den Emergency Change eine Eilfreigabe ein und machen Review und Dokumentation danach.

Standard und Normal Changes spielen wir im vereinbarten Wartungsfenster ein. Danach prüfen wir das Ergebnis und tragen die neue Konfiguration in unsere Dokumentation ein.

Drei Wege für eine Änderung: Das Tempo folgt dem RisikoITIL® Praxis: Change EnablementDrei Wege für eine Änderung: Das Tempo folgt dem RisikoITIL® Praxis: Change EnablementBedarfChangebeantragenStandardNormalNotfallVorlage,vorab genehmigtkeine EinzelfreigabeIm FensterumsetzenRisiko bewerten,Rollback planenFreigabe durchChange AuthorityIm FensterumsetzenEilfreigabe,sofort umsetzenReview folgtNachträglichdokumentierenPrüfen &Konfigurationaktualisieren

Fahren Sie mit der Maus über einen Schritt oder tippen Sie ihn an. Hervorgehoben bleibt, was davor passiert und wie es danach weitergeht.

Drei Wege für eine Änderung, je nach Risiko unterschiedlich schnell.
Drei Wege für eine Änderung, je nach Risiko unterschiedlich schnell.

Ursachen: Problem Management

Hinter einem Symptom steckt eine Ursache, und die sucht das Problem Management. Anlass sind wiederkehrende Incidents, Trends aus dem Monitoring oder Hinweise von Herstellern.

Zuerst suchen wir in Incidents und Trends nach Mustern, bei ITIL heißt das Problemerkennung. In der Problemkontrolle analysieren wir dann die Ursache und halten einen Workaround fest. In der Fehlerkontrolle bewerten und planen wir zuletzt die dauerhafte Behebung.

Bekannte Fehler tragen wir mit ihrem Workaround in unsere Wissensdatenbank ein. Bei der nächsten Störung geht es dann schneller. Die dauerhafte Behebung planen wir als Change.

Einmal die Ursache beheben statt jedes Mal das SymptomITIL® Praxis: Problem ManagementEinmal die Ursache beheben statt jedes Mal das SymptomITIL® Praxis: Problem ManagementWiederkehrendeIncidentsTrends aus demMonitoringHinweise vonHerstellernProblemerkennungMuster in Incidentsund Trends findenProblemkontrolleUrsache analysieren,Workaround festhaltenFehlerkontrolledauerhafte Lösungbewerten und planenKnown Error+ WorkaroundChange beantragenfür die Dauerlösung→ Incident Managementund Wissensdatenbank→ Change Enablement

Fahren Sie mit der Maus über einen Schritt oder tippen Sie ihn an. Hervorgehoben bleibt, was davor passiert und wie es danach weitergeht.

Vom wiederkehrenden Incident zur dauerhaften Behebung der Ursache.
Vom wiederkehrenden Incident zur dauerhaften Behebung der Ursache.

Patches und Supportende

Grundlage ist unser Inventar, was wo in welcher Version läuft. Daran gleichen wir Supportenden und Sicherheitslücken ab. Steht etwas an, bewerten wir das Risiko, planen den Change und spielen ihn ein, danach prüfen wir, ob alles funktioniert. Das wiederholt sich in festem Takt. Jede Runde endet mit einem Nachweis im Bericht.

Kritische Patches spielen wir außer der Reihe ein. Welche Versionen wann aus dem Support fallen, sehen Sie in unserem EOL Kalender, den Takt der Patchfenster je Service Level auf der Seite Service Levels.

Patchen ist ein Kreislauf, kein ProjektPatch Management über den ganzen Lebenszyklus, mit ITIL® PraktikenPatchen ist ein Kreislauf, kein ProjektPatch Management über den ganzen Lebenszyklus, mit ITIL® Praktiken1 InventarWas läuft wo, welche VersionService Configuration Mgmt.2 BeobachtenEOL Kalender und CVEsIT Asset Management3 BewertenRisiko und DringlichkeitInformation Security Mgmt.4 PlanenChange und WartungsfensterChange Enablement5 Ausrollen & prüfenDeployment, FunktionstestDeployment Management6 NachweisenBericht, NISG § 32Service Level ManagementFester Taktjede Runde endet mit einem Nachweiskritisch: außer der Reihe

Fahren Sie mit der Maus über einen Schritt oder tippen Sie ihn an. Hervorgehoben bleiben der Schritt davor und der danach.

Wir führen das Inventar, beobachten Supportenden, bewerten das Risiko, planen den Change, rollen ihn aus und halten alles im Bericht fest. Dann beginnt die nächste Runde.
Wir führen das Inventar, beobachten Supportenden, bewerten das Risiko, planen den Change, rollen ihn aus und halten alles im Bericht fest. Dann beginnt die nächste Runde.

Bei ITIL gehört das Inventar zu Service Configuration Management und IT Asset Management, die Bewertung zu Information Security Management, das Ausrollen zu Change Enablement und Deployment Management und der Bericht zu Service Level Management.

Monitoring und Event Management

Unser Monitoring sammelt Ereignisse aus Uptime Checks, Logs und Metriken sowie aus Cron Jobs und Importen. Jedes Ereignis ordnen wir einem von drei Typen zu:

  • Informationen protokollieren wir, ohne etwas zu tun.
  • Warnungen beheben wir automatisch, wo das möglich ist. Häufen sie sich, legen wir ein Ticket an.
  • Aus einer Ausnahme machen wir einen Incident mit Priorität.

Meldet sich ein Job nicht mehr, behandeln wir das ausbleibende Signal als Ausnahme. So fallen Jobs auf, die seit Monaten unbemerkt nicht mehr laufen.

Auch Stille ist ein EreignisITIL® Praxis: Monitoring und Event Management · drei EreignistypenAuch Stille ist ein EreignisITIL® Praxis: Monitoring und Event Management · drei EreignistypenUptime ChecksLogs & MetrikenCron Jobs & ImporteHeartbeat bleibt ausEreignis erkennenund filternTyp?InformationWarnungAusnahmeProtokollieren,keine AktionAutomatisch beheben,bei Häufung TicketIncident anlegen,Priorität setzenTechnikeralarmiertfehlendes Signal = AusnahmeEin ausbleibendes Signal wird wie ein Fehler behandelt. So fallen Jobs auf, die seit Monaten unbemerkt nicht mehr laufen.

Fahren Sie mit der Maus über einen Schritt oder tippen Sie ihn an. Hervorgehoben bleibt, was davor passiert und wie es danach weitergeht.

Drei Typen von Ereignissen. Ein ausbleibendes Signal zählt als Ausnahme.
Drei Typen von Ereignissen. Ein ausbleibendes Signal zählt als Ausnahme.

Wer dafür zuständig ist

Wartung und Betrieb verantwortet bei uns der Solutions Architect. Er hält das ITIL Expert Certificate in IT Service Management und den ITIL 4 Managing Professional, beides persönliche Zertifizierungen und keine des Unternehmens. Sie können sie im Register von PeopleCert prüfen. Mehr zum Team steht auf der Seite Über uns.

Warum wir mit ITIL Praktiken arbeiten

Incident, Change und Problem haben im ITIL Framework feste Namen und Grenzen. Sagen wir Change, meinen Ihr Team und Ihre Auditoren dasselbe. Eine Notation für Diagramme schreibt ITIL nicht vor, unsere tragen die Namen der ITIL Praktiken. Seit Anfang 2026 ist Version 5 des ITIL Frameworks aktuell. Wir verwenden nur Namen von Praktiken, die in Version 4 und 5 gleich lauten.

ITIL® ist eine eingetragene Marke von PeopleCert.