Dann fange ich mit einem typischen Szenario an:
Kunde meldet eine gestörte Telefonie, keine ein- und ausgehenden Telefonate. Auf die Frage “alle Geräte oder nur ein einzelnes gibt es keine sinnstiftende Aussage, weil der Meldende das zunächst nur für seinen Bereich beschreibt und vllt. noch beurteilen kann, ob der gegenüberliegende AP auch betroffen ist.”
- Schritt aus administrativer Sicht war es in der Vergangenheit, schon während der Störmeldung und noch vor der ersten Rückmeldung an den Kunden auf eine Blick zu schauen, ob sich die Störung nur auf einzelne oder ggf. alle Endgeräte (manchmal auch eines bestimmten Herstellers - so was gab es in der Vergangenheit ja durchaus öfter) bezieht. Hier hat die Statusanzeige in der Geräte-Übersicht schon wesentlich beigetragen, weil sofort erkennbar war, welche Geräte aktuell registriert gewesen sind und welche nicht.
Das Ergebnis konnte dann sein, nur ein Gerät → “lieber Kunde, starte mal Dein Gerät neu” oder alle Geräte in einem bestimmten Abschnitt sind betroffen, Hersteller egal → “Lieber Kunde, in dem Netzwerkbereich gibt es Probleme, Lösung ist …” oder nur die Handsets von Hersteller XY sind betroffen - > “DECT-Gateway neu starten” usw. usf.
Das lässt sich nun auch alles noch ermitteln, ich muss aber dazu dann beispielsweise 30x auf das (i) klicken für mehr Informationen.
Gleiches gilt für die Softphones der Benutzer. Ob jmd. angemeldet war, ist direkt auf einen Blick erkennbar gewesen. Ob nach dem Pairing das Mobile funktioniert, war sofort erkennbar, da im gleichen Augenblick der Status “grün” wurde.
Nein, die Erfahrung der vergangenen Monate hat doch gezeigt, wie sehr auch Firmware-Versionen einzelner Geräte oder Hersteller elementar verantwortlich dafür sein können, dass sich ein Gerät nach einem Update der Serverkomponenten plötzlich unerwartet verhält.
Die erste Anlaufstelle ist hier doch zunächst mal das ureigene, von mir als Verantwortlichem gelieferte System (konkret die TK-Anlage), um für diesen Part eine Aussage treffen zu können und dann zu entscheiden, ob der Provider oder der Netzwerk-Verantwortliche ein Todo bekommt.
90% meiner Kunden betreuue ich nur in diesem Bereich und habe weder mit Routing/Firewall oder Internetgateway oder der Netzwerk-Infrastruktur etwas zu tun. Dafür bei jedem Kunden eine Monitoring zu platzieren, dürfte etwas schwierig werden, klingt aber nach einem interessanten Zusatzgeschäft. Leider erkennen die Anwender den Nutzen eines Monitorings nicht und für uns als Dienstleister bedeutet das aktuelle Verschlimmbessern erheblichen Zusatzaufwand in der Analyse.
Und wenn schon Monitoring, dann doch bitte die Option, dass der jeweilige Betreuer der Anlage die Instanzen in sein Monitoring integrieren kann, beispielsweise durch REST.-Api-Endpunkte o.ä.
Fazit: Die Status-Anzeige hatte hier schon eine erste Aussagekraft für die Erstanalyse. Und dass es geht, zeigen ja andere Hersteller jeden Tag eindrucksvoll, einschließlich entsprechender Link zu den Logfile-Einträgen mit der genaueren Ursache (bsp. 401 bei SIP-Registrierung) und Status-Anzeige ich Echtzeit ohne Browser-Refresh.
Ich verstehe natürlich, dass Rechenleistung ein kostbares Gut ist, vor allem wenn solche Dinge wenig performant erfolgen. Das dann aber zu entfernen weil halt zuviel Rechenleistung, halt ich jedoch für den falschen Ansatz.