Wie nutze ich das Potenzial meines Monitoring-Systems in vollem Maße aus? Wie kreiere ich ein optimales Setup? Wie gehe ich mit Alarmfluten um? Auf diese Fragen gehen wir in unserer Session ein und zeigen dir, welche Erfahrungen wir im Bereich Application Performance und Incident Management gesammelt haben. Wir besprechen, welche Daten die Grundlage einer modernen Observability-Plattform sind und wie man mit Hilfe von Incident Management einen ganzheitlichen und nachhaltigen Prozess gestaltet.
6. ...so ist es Software ohne
Monitoring zu betreiben!
7. Observability ist die Antwort!
7
▪ Ist meine Applikation erreichbar?
▪ Sind alle Komponenten verfügbar?
▪ Wie sind meine Benutzer oder Geschäftstransaktionen von Fehlern betroffen?
▪ Wie schnell können wir auf Fehler reagieren?
▪ Werden Ressourcen effizient genutzt?
▪ Wie kann ich schnell einen Überblick meiner Applikation und
ihres Gesundheitszustandes erhalten?
▪ Wie wird mein Service genutzt?
▪ Wie zufrieden sind Benutzer mit meinem Service?
8. Noch nicht überzeugt?
8
▪ Ein kontinuierlicher, detaillierter und stets aktueller Einblick in
das Verhalten Ihrer IT-Systeme sowie in die Fachprozesse
ermöglicht es, Probleme automatisch zu erkennen und zu
beheben, bevor sie sich negativ auf die Kundenzufriedenheit
auswirken.
openapm.io
16. Agenda
1. Incident und Problem Management
2. Phasen des Incident Management
3. Herausforderungen und Risiken
4. Best Practices im Incident Management
5. Mehrwert erreichen
16
18. ▪ Incident (Vorfall) ist eine ungeplante Unterbrechung vom Service oder eine
erhebliche Minderung seiner Qualität.
▪ Incident Management minimiert die negativen Auswirkungen von Störungen,
indem der normale Betrieb so schnell wie möglich wiederhergestellt wird.
▪ Problem ist eine Ursache für einen oder mehrere Vorfälle.
▪ Problem Management verringert die Wahrscheinlichkeit und die Auswirkungen
von Vorfällen, indem Ursachen von Vorfällen ermittelt werden.
Incident Management
18
19. Phasen des Incident Management
19
Team
IT/Dev
Stack
Monitoring
Tools
Customers Support
Bemerken Kommunizieren Wiederherstellen Analysieren
20. ▪ Zu viele Alarme
▪ Fehlende Priorisierung
▪ Falsch positive Meldungen
▪ Unklare Zuständigkeiten
▪ Falsche Weiterleitung von Alarmen
▪ Fehlende Eskalationen
Herausforderungen und Risiken
20
Team
24. ▪ Wo befindet sich die Information über Vorfälle?
▪ Wer ist für was zuständig?
▪ Welche Kommunikationswege werden benutzt?
▪ Welche Eskalationswege gibt es?
▪ Welche Voraussetzungen müssen technisch erfüllt werden?
Prozesse definieren
24
28. ▪ Service-Zuständigkeiten abklären
▪ Monitoring aufsetzen
▪ SLAs, SLOs und SLIs definieren
▪ Run- und Playbooks anlegen
▪ Root Cause/ Ursachenanalyse durchführen
▪ Wissensaustausch und Vertrauenskultur fördern
Vor- und Nachbereitung auf Service-Ebene
28
29. ▪ Alarme richtig mappen
▪ Priorisierung der Alarme aktualisieren
▪ Nur kritische und wichtige Alarme verschicken
▪ Benachrichtigungsregeln anlegen
▪ Alarmregeln immer wieder hinterfragen
Vor- und Nachbereitung auf Alert-Ebene
29
32. ▪ Aussagekräftige Daten zu Applikationen und Services
▪ Nachverfolgbare und nachvollziehbare Alarme
▪ Unterstützung der Root-Cause-Analyse
▪ Einfache und verständliche Prozesse im Falle eines Incidents
▪ Schnelle Reaktionszeiten bei Service-Ausfall
▪ Mitarbeiterzufriedenheit durch weniger False Positives
▪ Höhere Zufriedenheit aller Stakeholder dank besseren Uptimes
Mehrwert von APM mit IcM
32