Die Anforderung einer proaktiven Information über eingetroffene Ereignisse besteht immer mehr auch vom Business und nicht mehr alleine von der IT. Mit DERDACK Enterprise Alert und Signl4 bleiben keine eingetroffenen Ereignisse wie beispielsweise ein Incident aufgrund fehlender Kenntnis darüber unbearbeitet.
Die meisten Monitoring- und Alarmierungs-Systeme kennen die gängigen drei Benachrichtigungsvarianten - E-Mail, SMS oder ein speziell gescriptetes Ereignis. Die Alarmierung ist dabei aber meist an eine Gruppe oder an einzelne Piket Geräte gerichtet. Sind diese nicht erreichbar, haben sie eine schlechte Abdeckung oder sonstige Defekte, ist es schwierig weitere Personen aufzubieten.
Planung & Alarmierung kann so einfach sein
Wenn mit Alarmierung solche Probleme bestehen, was macht Enterprise Alert oder Signl4 besser? Nun dies lässt sich mit dem Wort „Close-Loop-Alerting“ am besten umschreiben. Ein Fehler wird nicht nur gemeldet und ein Alarm ausgelöst, sondern der Alarm wird auch kontrolliert. Ob er zugestellt und von der alarmierten Person entgegengenommen wird. Falls dies nicht geschieht, wird automatisch der nächste Team Member, die nächste Reaktionsvariante oder sogar eine Eskalation zum Vorgesetzten ausgelöst.
Wer jetzt denkt „wow, da gibt es garantiert viel zu konfigurieren“, den kann ich beruhigen. Auch dafür hat Derdack eine Lösung eingebaut. Mit dem Oncall Kalender wird ein Team bestückt, die einzelnen Personen manuell oder automatisch in faire Rotationen zugeteilt und prompt kommt z.B. der Netzwerk Alarm bei der richtigen Person an. Hat diese Person im Oncall Dienst einen speziellen Termin, wird einfach auf die sogenannte Replace Person umgeschaltet. In der Zeit von Azure und Office365 können Zugriffe und Personen aus dem AD / AzureAD inklusive Teamzuteilung synchronisiert werden und die Planung kommt aus dem StaffHub. Alarmiert wird dann direkt über Skype4Business, Mail, SMS oder der verfügbaren App, so das eine nette Stimme im Auto mir den Fehler vorliest. Ist doch klasse.
Wenn mit Alarmierung solche Probleme bestehen, was macht Enterprise Alert oder Signl4 besser? Nun dies lässt sich mit dem Wort „Close-Loop-Alerting“ am besten umschreiben. Ein Fehler wird nicht nur gemeldet und ein Alarm ausgelöst, sondern der Alarm wird auch kontrolliert. Ob er zugestellt und von der alarmierten Person entgegengenommen wird. Falls dies nicht geschieht, wird automatisch der nächste Team Member, die nächste Reaktionsvariante oder sogar eine Eskalation zum Vorgesetzten ausgelöst.
Wer jetzt denkt „wow, da gibt es garantiert viel zu konfigurieren“, den kann ich beruhigen. Auch dafür hat Derdack eine Lösung eingebaut. Mit dem Oncall Kalender wird ein Team bestückt, die einzelnen Personen manuell oder automatisch in faire Rotationen zugeteilt und prompt kommt z.B. der Netzwerk Alarm bei der richtigen Person an. Hat diese Person im Oncall Dienst einen speziellen Termin, wird einfach auf die sogenannte Replace Person umgeschaltet. In der Zeit von Azure und Office365 können Zugriffe und Personen aus dem AD / AzureAD inklusive Teamzuteilung synchronisiert werden und die Planung kommt aus dem StaffHub. Alarmiert wird dann direkt über Skype4Business, Mail, SMS oder der verfügbaren App, so das eine nette Stimme im Auto mir den Fehler vorliest. Ist doch klasse.
Warum nicht nur für IT?
Mit der Version 2019 wird Derdack Enterprise Alert, gemäss Techtalk mit den Entwicklern, die Mandantenfähigkeit einführen. Da Event Channels und Benachrichtigung Channels bis jetzt nur im Hauptserver definiert werden konnten, gab es regelmässig mit VOIP Benachrichtigungen und Bridge-to-Oncall (Rufbereitschafts Model) Überschneidungen. So können dann auch andere Bereiche der Firma von der automatisierten Information profitieren und es herrscht nicht mehr das E-mail-Alarmierungs-Chaos. Tendenziell werden zu viele Alarmierungen produziert, die dazu führen, dass Personen abstumpfen und im Falle eines wirklichen Problems nicht mehr reagieren. Instanzen könne auch mit Signl4 gemacht werden, hier verknüpfe ich einfach mehrere aufgeschaltete Azure Dienste mit unterschiedlichen Namespaces. Die Alarmierung ist da genau so einfach und direkt. Ausserdem habe ich mit Office365 Flow oder Azure LogicApp ein Sammelsurium an Möglichkeiten, in der richtigen Intensität mit dem richtigen Mittel zu alarmieren.
Mit beiden Lösungen, hat der Erfahrungswert gezeigt, dass der Bereich Incident-Reaction bis zu 75% schneller und präziser erfolgt und von den Supportern / Technikern / Engineers geschätzt wird.
Mit der Version 2019 wird Derdack Enterprise Alert, gemäss Techtalk mit den Entwicklern, die Mandantenfähigkeit einführen. Da Event Channels und Benachrichtigung Channels bis jetzt nur im Hauptserver definiert werden konnten, gab es regelmässig mit VOIP Benachrichtigungen und Bridge-to-Oncall (Rufbereitschafts Model) Überschneidungen. So können dann auch andere Bereiche der Firma von der automatisierten Information profitieren und es herrscht nicht mehr das E-mail-Alarmierungs-Chaos. Tendenziell werden zu viele Alarmierungen produziert, die dazu führen, dass Personen abstumpfen und im Falle eines wirklichen Problems nicht mehr reagieren. Instanzen könne auch mit Signl4 gemacht werden, hier verknüpfe ich einfach mehrere aufgeschaltete Azure Dienste mit unterschiedlichen Namespaces. Die Alarmierung ist da genau so einfach und direkt. Ausserdem habe ich mit Office365 Flow oder Azure LogicApp ein Sammelsurium an Möglichkeiten, in der richtigen Intensität mit dem richtigen Mittel zu alarmieren.
Mit beiden Lösungen, hat der Erfahrungswert gezeigt, dass der Bereich Incident-Reaction bis zu 75% schneller und präziser erfolgt und von den Supportern / Technikern / Engineers geschätzt wird.
Die App als mobile Kommandozentrale
Bis jetzt haben wir nur über die Information gesprochen, aber helfen mir die beiden Systeme auch bei der Bewältigung? Hier kommen die Auftritte der beiden Apps. Diese sorgsam und sehr intuitiv programmierten Apps bieten mir die Möglichkeit, vom Zentralsystem vorgeschlagene und automatisierte Lösungsworkflows auszuführen. Diese werden mit den entsprechenden Autorisierungen direkt vom Alarmsystem angestossen. Auch hier ein sehr gutes Beispiel aus dem Bereich „Digital hilft, analog entscheidet“. Zu verdeutlichen ist das mit nachfolgendem Beispiel.
Bis jetzt haben wir nur über die Information gesprochen, aber helfen mir die beiden Systeme auch bei der Bewältigung? Hier kommen die Auftritte der beiden Apps. Diese sorgsam und sehr intuitiv programmierten Apps bieten mir die Möglichkeit, vom Zentralsystem vorgeschlagene und automatisierte Lösungsworkflows auszuführen. Diese werden mit den entsprechenden Autorisierungen direkt vom Alarmsystem angestossen. Auch hier ein sehr gutes Beispiel aus dem Bereich „Digital hilft, analog entscheidet“. Zu verdeutlichen ist das mit nachfolgendem Beispiel.
Ein Fallbeispiel wie es im Buche steht
Dienstagmorgen 06:30 Uhr, ich sitze im Zug auf dem Weg nach Zürich. Beim morgendlichen Pflicht-Kaffee beginnt mich meine Enterprise Alert App lautstark über ein System zu informieren, das im Partner Datacenter steht und dessen SQL Service seit 5 Minuten beendet wurde. Wie es der Zufall so will, ist es das CRM System – eines der ersten Programme, auf das die Marketingabteilung am Morgen zugreifen möchte. Schritt 1: Ich quittiere den Alarm, so dass mein Vorgesetzter nachträglich sieht, dass ich meine Pikett-Pflicht erfüllt habe. Anstatt wie auf Kohlen rumzusitzen während mein Notebook den morgendlichen Offline Boot Prozess zelebriert und ich hoffe das die UMTS Karte mal genügend Verbindung fürs VPN hin bekommt, bleibe ich auf der App und schaue mir alle Detailinformationen an. Dann habe ich die Möglichkeit mit den Remote Tasks zumindest mal die ersten Fehlerbehebungen anzustossen. Ich entscheide mich für den klassischen Service Neustart auf dem betreffenden System. Um welchen Server und Service es sich handelt wurde mir vom Alarm in den Task übernommen und ich autorisiere den Task mit meinem persönlichen PIN Code. Reicht dies nicht, kann ich auch den Server neustarten oder schlicht eine Vorbereitete Nutzerinformation auslösen. Alles vorbereitet, alles standardisiert und auf die Bedürfnisse der User zugeschnitten.
Dienstagmorgen 06:30 Uhr, ich sitze im Zug auf dem Weg nach Zürich. Beim morgendlichen Pflicht-Kaffee beginnt mich meine Enterprise Alert App lautstark über ein System zu informieren, das im Partner Datacenter steht und dessen SQL Service seit 5 Minuten beendet wurde. Wie es der Zufall so will, ist es das CRM System – eines der ersten Programme, auf das die Marketingabteilung am Morgen zugreifen möchte. Schritt 1: Ich quittiere den Alarm, so dass mein Vorgesetzter nachträglich sieht, dass ich meine Pikett-Pflicht erfüllt habe. Anstatt wie auf Kohlen rumzusitzen während mein Notebook den morgendlichen Offline Boot Prozess zelebriert und ich hoffe das die UMTS Karte mal genügend Verbindung fürs VPN hin bekommt, bleibe ich auf der App und schaue mir alle Detailinformationen an. Dann habe ich die Möglichkeit mit den Remote Tasks zumindest mal die ersten Fehlerbehebungen anzustossen. Ich entscheide mich für den klassischen Service Neustart auf dem betreffenden System. Um welchen Server und Service es sich handelt wurde mir vom Alarm in den Task übernommen und ich autorisiere den Task mit meinem persönlichen PIN Code. Reicht dies nicht, kann ich auch den Server neustarten oder schlicht eine Vorbereitete Nutzerinformation auslösen. Alles vorbereitet, alles standardisiert und auf die Bedürfnisse der User zugeschnitten.
Cloud / Onpremise was geht?
Da sich Enterprise Alert und Signl4 wirklich auf die Alarmierung/Information konzentrieren muss natürlich ein bestimmtes Monitoring bereits vorhanden sein. Darum können auch die meisten gängigen Monitoring und Service Delivery Systeme wie System Center Operations Manager, Operations Manager Suite, HP Openview, ServiceKnow, PRTG oder auch LogCollector angeschlossen werden. Sei dies in der Cloud, OnPremise oder hybrid. Unsere Empfehlung ist aber klar zu fokussieren. Wenn die Mehrheit der informationsgebenden Systeme in der Cloud oder sogar nur SaaS Services sind, sollte ganz klar die Richtung Signl4 eingeschlagen werden (VOIP Integrationen ausgeschlossen).
Da sich Enterprise Alert und Signl4 wirklich auf die Alarmierung/Information konzentrieren muss natürlich ein bestimmtes Monitoring bereits vorhanden sein. Darum können auch die meisten gängigen Monitoring und Service Delivery Systeme wie System Center Operations Manager, Operations Manager Suite, HP Openview, ServiceKnow, PRTG oder auch LogCollector angeschlossen werden. Sei dies in der Cloud, OnPremise oder hybrid. Unsere Empfehlung ist aber klar zu fokussieren. Wenn die Mehrheit der informationsgebenden Systeme in der Cloud oder sogar nur SaaS Services sind, sollte ganz klar die Richtung Signl4 eingeschlagen werden (VOIP Integrationen ausgeschlossen).
Wenn man diese beiden Systeme und die Vorteile, welche sie mitbringen sieht, kann man sich wirklich die Frage stellen „Alarmierst du noch oder reagierst du schon?“
