Echtzeitüberwachung könnte für beA nützlich sein

Lesedauer: 6 Minuten

Es gab wohl gerade erst wieder eine beA Störung, die angeblich behoben sein soll. So steht es zumindest auf der optisch aufgehübschten neuen Webseite der Bundesrechtsanwaltskammer:

vgl. Webseite der Bundesrechtsanwaltskammer am 28.9.2019 um 8:26 Uhr1)https://www.brak.de/

Sehr geil ist auch, dass bei Meldungen über Störungen grundsätzlich nicht da steht von wann die Meldung ist, auch nicht ob sie andauert oder ob der Fehler behoben wurde. Also irgendwie etwas sinnlos. Egal.

Wirklich irritiert hat mich eigentlich nur die letzte Headline darüber, dass es mittlerweile keine Störungen mehr geben soll. Denn seit heute Nacht um 3 Uhr schlagen verschiedene unserer Monitoring-Sensoren Alarm. Um unsere Kunden schneller und zuverlässiger zu informieren als es die BRAK tut überwachen wir z. B. die beA Anmeldeseiten. Und da wurde wohl offensichtlich gerade ziemlich viel umgestellt, zumindest sieht das in unserem Monitoring so aus:

Ausfallverlauf über gesicherte Anmeldeseite auf https://bea.brak.de

Oder in Zahlen ausgedrückt:

Eindeutige Verlangsamung der Webseite bis hin zum vollständigen Ausfall

Ob das beA System als solches funktioniert in dem Fall, in dem man schafft es zu erreichen, sei dahingestellt.

Was es mit der Störung auf sich hat kann ich leider nicht sagen, denn mehr als die Headline ist bei der BRAK wegen lauter Datenbankfehlern auf der BRAK Webseite nicht zu lesen. Am schönsten finde ich die blumig beschriebene URL mit dem Namen https://bea.brak.de/2019/09/25/stoerung-im-bea-tritt-nach-workaround-derzeit-nicht-mehr-auf/ :

Meldung der BRAK über behobene Störung vom 28.9.20192)https://bea.brak.de/2019/09/25/stoerung-im-bea-tritt-nach-workaround-derzeit-nicht-mehr-auf/

Auch die Meldung über die eigentliche Störung sieht nicht anders aus:

Meldung der BRAK über neue Störung vom 28.9.20193)https://bea.brak.de/2019/09/24/stoerung-im-bea-2/

Möglicherweise gibt oder gab es auch Fehler, die wieder einmal auf Störungen im egvp zurück zu führen sind:

Meldung des egvp, Stand 28.9.2019 8:45 Uhr4)https://egvp.justiz.de/meldungen/index.php

Das ist ja auch so ein Thema, solche Störungen von durch beA fremdgenutzten Systemen werden ja irgendwie nicht abgefangen. Man denke nur an die Fehler bei der Zustellbestätigung. Leider steht auch hier nur ein letztes voraussichtliches Ende um 10:29 Uhr mit Stand von 8:00 Uhr. Naja, ist ja schon fast zwei Tage her, wird wohl wieder funktionieren.

Fehler passieren. Auch bei uns. Aber bei einem so relevanten System wie beA, das bekanntlich gebeutelt ist von tagelang andauernden Ausfällen, ständigen Sicherheitsproblemen, Anbieterwechseln und durch die Bank miserablem bis gar keinem Support… ist da ein funktionierendes Monitoringsystem zu viel verlangt? Ist Aufklärung und Transparenz nicht förderlich für die Akzeptanz eines Zwangssystems?

Alle unsere Firmenkunden bekommen verpflichtend ein Monitoringpaket von uns, damit wir proaktiv handeln können.

Wie so oft hat unser Monitoring ja auch in diesem Fall – wieder einmal – die Fehler festgestellt bevor es die BRAK selbst überhaupt mitbekommen hat. Das ist schon etwas peinlich, liebe Kollegen. So etwas schafft nicht gerade Vertrauen in die Programmierer der BRAK.

Wenn ich einen Rat geben darf was Monitoring angeht: „Echtes“ Monitoring muss unabhängig und extern stattfinden. Monitoringsoftware, die als sogenannter Agent auf dem zu überwachenden System installiert wird (wie z. B. klassische RMM Tools dies machen) bringt gar nichts.

Ein Server kann sich nicht selbst überwachen. Mein Lieblingsbeispiel ist die Backupsoftware, die bei Fehlern per E-Mail benachrichtigt. Crasht das System, gibt es keine Sicherungen mehr. Weil aber das System gecrasht ist, werden auch keine E-Mails mehr mit der Fehlermeldung an den Admin verschickt. Logisch?

Genau deshalb und aus einer ganzen Reihe weiterer Gründe muss Monitoring immer extern und unabhängig funktionieren. Also gesondertes, externes Netzwerk mit mehrfach redundanten Netzwerkanbindungen, eigene Hardware, eigene Serversysteme und all das darf nichts mit dem zu überwachenden Netzwerk zu tun haben. Nicht einmal den gleichen Mailserver darf es verwenden.

Außerdem setzen wir in diesem Bereich nur auf kommerzielle Produkte (in unserem Fall PRTG5)https://www.de.paessler.com/prtg/pricing vom Nürnberger Unternehmen Paessler AG6)https://www.de.paessler.com/company/about-us), die unter Herstellersupport stehen. Das Thema Echtzeitüberwachung ist zu wichtig, als dass man dafür Nagios oder andere Bastellösungen zusammenschustern sollte. As zusätzliches, hochflexibles Entwickler-Tool mag sein, aber nicht zur Überwachung von kritischen Produktionssystemen. Zumindest nicht, wenn Sie Kunde von uns sind.

Denn wenn man diese paar Punkte beherzigt, dann lässt sich auch mit geringem Aufwand eine echte, funktionierende Echtzeitüberwachung einführen.

Die dauerhafte Überwachung der beA Webseite durch uns würde die BRAK übrigens für das gesamte Jahr nur knapp 1.200,- € kosten. Monitoring ist bei uns standardisiert und zu 100% automatisiert, dadurch wiederum auch nicht mehr teuer für den Einzelnen. Anders könnten wir die Menge überwachter Geräte nicht handeln (tagesaktuell 6440 Sensoren in unserer PRTG Instanz).

Wie viele Ausfälle des beA, die erst von der BRAK offiziell vermeldet wurden nachdem hunderte Anwender deren IT Support bemühten, braucht es eigentlich noch bis die Bundesrechtsanwaltskammer endlich handelt?

Hier klicken, um den Beitrag zu bewerten:
  1 Bewertungen

Quellenverzeichnis   [ + ]

patrick.ruppelt