BOS: robuste Kommunikationsabläufe

Niemand möchte erleben, dass wichtige Kommunikationsabläufe plötzlich gar nicht mehr funktionieren. Schon gar nicht bei BOS oder wo es um Leib und Leben geht. Man erwartet, dass technische Systeme, die solche Kommunikationsabläufe unterstützen, robust sind. Wie man sich dieser Frage systematisch und mit Hausverstand näher kann, diskutiert dieser Beitrag.

Um ununterbrochene Verfügbarkeit zu erreichen, bedient man sich unter anderem des Konzepts der „Redundanz“ (= Überfluss), also des mehrfachen Vorhaltens von Ressourcen, Anlagen und Systemen. Dabei ergeben sich schon die ersten Missverständnisse. Bei Fachleuten der Rechts- und Wirtschaftswissenschaften ist „Redundanz“ ein primär nicht positiv besetzter Begriff: redundante Textpassagen in einem Dokument sind nicht gut und redaktionell zu bereinigen, redundante Doppelgleisigkeiten in der Organisation sind Verschwendung und abzustellen. In den Ingenieurwissenschaften hat Redundanz jedoch eine positive Bedeutung als eine seit Jahrtausenden bewährte Methode, um Robustheit zu erreichen. Man verseilt Drähte zu einem haltbaren Seil, man vermehrt die zu übertragene Information gezielt, um Übertragungsfehler erkennen und korrigieren zu können, man führt Anlagenteile oder auch ganze Anlagen doppelt oder mehrfach aus.

Im digitalen Zeitalter noch aktuell?

Gemeinhin kennt man die Formel „Risiko = Erwarteter Schaden mal Eintrittswahrscheinlichkeit“.

Obige Formel gibt aber keinen guten Rat für Ereignisse, mit deren Folgen wir nicht zurechtkommen und die ganz selten sind. Die Rede von Häufigkeiten (etwa 30-jähriges, 100-jähriges Ereignis) führt unseren Hausverstand in die Irre. Man meint ja, dass ein 30-jähriges Ereignis alle 30 Jahre eintritt - also irgendwann, wenn ich schon in Rente bin. Tatsächlich gilt das so aber nur für sehr langlebige Personen, die in ihrem 300-jährigen Leben schon 10 ebensolche Ereignisse erlebt haben…

Über die zeitliche Verteilung sagt das nichts: Das 30-jährige Ereignis kann bereits morgen eintreten, das 100-jährige vielleicht schon heute.

Hochzüchten von Einzelsystemen?

Wenn wir als „System“ eine Anlage oder Gruppe von Anlagen bezeichnen, die wesentliche gemeinsame Teile oder Risiken haben, dann hilft das Hochzüchten eines einzigen Systems nicht wirklich. Doppelte Netzteile und Baugruppen, strenge Audits, verschärfte Wartung, dickere Mauern: Den Umstand eines geballten Risikos bekommt man so nicht weg.

Statistisches Denken nach obiger Formel ist nur für häufige Ereignisse sehr hilfreich. Über seltene, schwerwiegende Ereignisse muss man auch deterministisch denken: Was tue ich, wenn morgen der ganz seltene Fall eintritt, dass „System A“ ausfällt?

Es hilft nur der berühmte „Plan B“: ein unabhängiges „System B“ Wo unverzichtbare Abläufe (Funktionen, Prozesse) von einem technischen System abhängig sind, hilft nur ein zweites System mit unabhängigen Risiken.

Für sehr wichtige Abläufe hält man in der Praxis auch ein drittes, seltener auch ein viertes oder weiteres System vor, durchaus auch mit geringerem „Komfort“ in der Funktionalität.

„Doppelte Systeme = doppelte Verfügbarkeit“: leider ganz falsch

Rechenübung: Zu einem „System A“ sieht man parallel ein weiteres, unabhängiges „System B“ vor, zum Beispiel mit einer moderaten Verfügbarkeit von 99%, also 1% Ausfallswahrscheinlichkeit (= 1/100 = 3,6 Tage jährlich). Die gemeinsame Wahrscheinlichkeit zweier statistisch unabhängiger Vorgänge ergibt sich aus dem Produkt der Wahrscheinlichkeiten. Die Ausfallswahrscheinlichkeit verbessert sich somit in diesem Beispiel durch das zweite „System B“ um den Faktor 100! Faktor 100 bedeutet z.B. eine Reduktion von 1 Tag Nichtverfügbarkeit pro Jahr auf nur 15 Minuten.

Wenn man dann noch ein drittes „System C“, an das man gar keine hohen Anforderungen stellen muss, dazu nimmt, kommt man in den Bereich unter einer Minute Nichtverfügbarkeit. Dann ist man meistens dort, wo man hinmöchte, wenn es „immer“ funktionieren muss. Die meisten kritischen Kommunikationsprozesse tolerieren Unterbrechungen unter einer Minute in Störungsfällen. Hochverfügbare Kommunikationsprozesse kann man praktisch nur aus 2-3 unabhängigen Parallelsystemen effizient bauen.

Die wesentliche Pointe: Diese Methode ist die wirtschaftlichste, weil sie erstens als einzige das Ziel tatsächlich erreicht und zweitens die Einzelsysteme nicht teuer auf höchste Verfügbarkeit „hochgezüchtet“ sein müssen. Das ist in der praktischen Verfügbarkeit und praktischen Projektumsetzung von großer Bedeutung.

Der Hebel ist der Umstand, dass die Systeme unabhängig sind und keine gemeinsamen Risiken haben dürfen und eben nicht, dass jedes Einzelsystem als „Sicherheitssystem“ hochgezüchtet ist.

Praktisch bis drei zählen

In praktischen Lösungen wählt man in der Regel den Ansatz, dass das „System A“ die maximale Funktionalität bietet und effiziente, personal- und ressourcenschonende Prozesse optimal unterstützt. Das „System B“ ist öfter bewusst einfacher und bietet weniger „Komfort“, lässt aber die Einsatzziele ohne Einschränkungen erreichen. So ergeben sich einerseits wirtschaftliche Gesamtkonzepte, die aber andererseits auch der Schulung des Personals sowie dem Betrieb entgegenkommen: Das „System B“ muss intuitiv zu verstehen und zu bedienen sein. Die nachhaltige Schulung einer großen Zahl von Personen auf Systeme, die nur fallweise genutzt werden, ist häufig nicht erfolgreich möglich. Ein „System C“ bietet - wenn es benötigt wird - oft nur eine einfache Rückfallebene, mit der die Kommunikation sichergestellt werden kann, gegebenenfalls mit organisatorischem bzw. personellem Mehraufwand.

Wichtig ist auch, das Problem für jeden der Kommunikationsvorgänge einzeln zu analysieren und zu lösen, weil für verschiedene Kommunikationsvorgänge verschiedene technische Lösungen zur Verfügung stehen. Ein Beispiel: Im Falle des Ausfalls eines komfortablen „System A“ stehen zum Erteilen eines Einsatzbefehls durch eine Leitstelle häufig eine Vielzahl von technischen Optionen zur Verfügung. Ganz anders gelagert ist häufig das Problem der Alarmierung, also Einsatzkräfte überhaupt erst einmal zu erreichen, damit sie tätig werden und gegebenenfalls ihrerseits mit der alarmierenden Stelle Kontakt aufnehmen.

Für die Einzelsysteme ergeben sich hinsichtlich Verfügbarkeit entspannte Anforderungen: Für das „System A“ ist es akzeptabel, dass es regulär in jenem Umfang nicht verfügbar sein darf, in dem man das „System B“ ohnehin testen muss und möchte. Beispielsweise: Alle 6 Monate „System B“ testen sind 2 Tage im Jahr. Das wäre als Milchmädchenrechnung: 99,5% Verfügbarkeit für „System A“. Das schafft man in der Praxis gut.

Die enormen Vorteile einer solchen Architektur im betrieblichen Alltag bei geplanten Nichtverfügbarkeiten (Wartung, Updates, Systemerneuerungen, etc.) und für Wartungsbereitschaften sind sehr erwähnenswert und leuchten leicht ein.

Alles entscheidende Abläufe (z.B. Alarmierung und BOS-Kommunikation) auf ein (!) System zu stützen, darf man wohl als nicht rationales Risikoverhalten einstufen.

Der Benchmark: Lernen von der Feuerwehr

Das Feuerwehrwesen ist durchgängig nach dem Prinzip der Zwei- bis Dreifachheit strukturiert: Trupp = 2–3 Mann / Gruppe: 2–3 Trupps / Zug: 2–3 Gruppen / Verband (2–3 Züge) / Atemschutz-Angriffstrupp hat seinen Rettungstrupp / hydraulisches Rettungsgerät kommt immer mit Zweitgerät / zwei-, bis dreifacher Brandschutz usw. Diese Strukturen haben sich - bei sehr individueller Handhabung im Detail - nicht zuletzt durch die durchgängig innewohnende Redundanz bewährt.

Schon von König Salomon liest man in der Bibel: „Zwei sind allemal besser dran als einer allein. […] Noch besser sind drei; es heißt ja: „Ein Seil aus drei Schnüren reißt nicht so schnell.“

„Bis drei zählen können“ gilt gemeinhin als Chiffre für Grundkenntnisse in Rechnen, Mathematik und analytischem Denken. Die Formel „zwei bis drei Mal“ entspricht einer seit Jahrtausenden bewährten Erfahrung. Dieses Prinzip sollte auch im Bereich der Kommunikationssysteme für BOS durchgängig selbstverständlich werden.