Wir beschweren uns oft über Software-Fehler, die sehr ärgerlich sein und erhebliche finanzielle Verluste verursachen können. Unsere häufigste Schlussfolgerung ist, dass dem Entwickler (Anbieter, Integrator) sein Ruf egal ist, und er die Software nicht richtig austestet.
Schauen wir uns einmal an, inwieweit diese Aussage zutrifft, welchen Grad an Zuverlässigkeit wir von neuen Anwendungen oder Releases erwarten können und wie wir mit Ausfällen, Fehlfunktionen und daraus resultierenden Verlusten umgehen sollten.
Obwohl fast alle aktuellen Hardwaresysteme auf programmierbaren Elementen basieren (von Prozessor-Mikroprogrammen und Mikrocontrollern einzelner Systemblöcke bis hin zu größeren Softwarekomponenten wie BIOS), werde ich im Folgenden nur die Ebene der Anwendungssoftware behandeln und Fragen der Systemzuverlässigkeit und Hardware-Fehlertoleranz außen vor lassen.
Leider lassen sich die Ursachen für Ausfälle von Anwendungssoftware oft nur schwer von Betriebssystem- oder Hypervisor-Fehlern trennen, oder auch von den Fehlern in einer der Software-Einheiten, auf denen Anwendungssysteme basieren (einschließlich verschiedener Frameworks, Bibliotheken usw.).
Aber kommen wir zum wichtigsten Punkt: der Zuverlässigkeit der eigentlichen Anwendungssoftware.
Fehler und Misserfolge gibt es überall. Elon Musks Starship hatte mehrere misslungene (oder zumindest nicht ganz perfekte) Starts, und er hat auch nicht sofort herausgefunden, wie man die SpaceX-Booster-Stufen sicher landet. Andererseits liefen so komplexe Systeme wie das Space Shuttle schon bei ihren ersten Flügen reibungslos. Daraus lässt sich schließen, dass man in manchen Fällen eine außergewöhnlich hohe Software-Zuverlässigkeit erreichen kann (und in den genannten Beispielen spielt die Software natürlich die Hauptrolle), während in anderen Fällen Fehler toleriert werden können.
In unserer Praxis gab es zahlreiche Beispiele für menschliche Fehler bei der Installation und Konfiguration von Contact-Center-Software. Einmal erhielt ein IVR-Zweig versehentlich eine falsche Endung, was dazu führte, dass das Call Center falsch arbeitete. Ein anderes Mal wurde die Logik der Feiertags- und Wochenendschichten nicht richtig implementiert, so dass das Call Center am Wochenende nach der Werktagslogik zu arbeiten begann. Die Liste lässt sich weiterführen. Es ist möglich, die Entwicklungs- und Debugging-Prozesse in bestimmter Weise anzupassen, um die Anzahl der Fehler zu reduzieren, aber es ist ziemlich schwer, den menschlichen Faktor vollständig zu eliminieren.
Nicht nur Zulieferer und Entwickler, sondern auch Kunden sollten die Ursachen und die Logik von Ausfällen sowie die mögliche Vorbereitung darauf richtig verstehen. Also: Sind alle Software-Fehler von Natur aus gleich, oder lassen sie sich kategorisieren, um Präventionsmaßnahmen effektiv einsetzen zu können?
Ein möglicher Ansatz ist, mengenbasiert zu überlegen: Je mehr Instanzen eines Systems verwendet werden, desto mehr Aufmerksamkeit muss dem Debugging gewidmet werden. Obwohl ich im Allgemeinen zustimme, würde ich diesen Ansatz nicht überbewerten. Oft spielt er nur eine Rolle, wenn alle anderen Faktoren gleich sind, und diese anderen Faktoren können viel wichtiger sein. Raumfahrtsysteme zum Beispiel haben eine extrem geringe Anzahl von Instanzen – na und? Sollte man sie etwa nicht debuggen? Das wäre zu teuer...
Und da sind wir natürlich gerade am entscheidenden Punkt.
In den 1980er Jahren war ich an der Entwicklung von Software für eines der kritischen Systeme von Buran beteiligt (als Programmierer, aber auch als Analyst, Architekt und Projektleiter), und auch an anderen Projekten dieser Art. Später arbeitete ich mehr als 25 Jahre lang an kommerziellen Projekten. Nach 50 Jahren in der Branche habe ich viele Erfahrungen gesammelt, die ich analysieren und vergleichen kann: verschiedene Ansätze und Methoden sowie unterschiedliche Ergebnisse.
Fangen wir mit den Raumfahrtsystemen an. Ihr Hauptmerkmal ist, dass die Kosten eines Fehlers tendenziell nahezu unendlich sind. Folglich sind auch die Ausgaben für Maßnahmen zur Fehlervermeidung praktisch unbegrenzt. Dabei geht es nicht nur um die finanzielle Seite des Projekts, sondern darum, ein mehrstufiges und vielschichtiges Debugging-System aufzubauen, damit jeder potenzielle Fehler und jede Ungenauigkeit richtig diagnostiziert und beseitigt werden kann. Das bedeutete, alle Architektur-Ebenen zu kontrollieren.
Das ist leicht zu sagen; aber was ist mit Betriebssystemen und Bibliotheken? (Der Begriff „Framework“ wurde damals noch nicht verwendet.) Die Lösung war einfach: Sie wurden alle von Grund auf ausschließlich für diese eine Aufgabe entwickelt. Und was ist mit dem dynamischen Verhalten von Systemen, die externen probabilistischen Einflüssen unterliegen, so dass es unmöglich ist, ihr Verhalten genau zu reproduzieren (was eine notwendige Bedingung für effektives Debugging wäre)? Hierfür gab es eigene Methoden, die eine Kombination aus Debugging unter reproduzierbarem Systemverhalten mit modellierten äußeren Einflüssen sowie eine Registrierung ihrer Auswirkungen unter realen Bedingungen ermöglichten.
Das hört sich alles logisch aus; aber Fachleute können sich wohl vorstellen, dass Diagnose- und Debugging-Systeme auf diesem Niveau die Kosten für die Softwareentwicklung selbst um ein Vielfaches übersteigen, sogar um mehr als eine Größenordnung (und das gilt nicht nur für die Software – auch Hardware-Debugging-Equipment wurde eingesetzt).
Daraus können wir eine erste Schlussfolgerung ziehen: Im „normalen“ Leben sind solche Ansätze nicht anwendbar. Man würde nie dazu kommen, ein Produkt zu veröffentlichen.
Werfen wir noch einmal einen Blick auf Elon Musk. Auch seine Raumfahrtsysteme versagen manchmal (sie stürzen ab oder explodieren). Weiß er nicht, wie man Debugging- und Diagnosesysteme verwendet? Wohl kaum. Ich nehme an, dass er die Kosten der Ausfälle mit den Kosten der Fehlersuche abwägt. Mit anderen Worten: Die Debugging-Kosten gleichen ungefähr den Kosten bei potentiellen Fehlern, und es macht keinen Sinn, den Aufwand für Systeme und Verfahren der Vorab-Fehlersuche weiter auszubauen. Es ist billiger, das System in realen Tests auszuprobieren; das ist die reale Auswirkung der Tatsache, dass ein wirklich umfassendes Debugging, wie oben erwähnt, um ein Vielfaches teurer ist. Übrigens muss man auch die Kosten der eigentlichen Zeit, die für das Debugging aufgewendet wird, bedenken – einschließlich der Kosten für nicht fristgerechte Vertragserfüllung, für Verluste durch schnellere Konkurrenz, usw.
Das ist natürlich alles Spekulation; Musks Abwägung basiert wahrscheinlich auf Intuition. Aber das Prinzip gilt trotzdem.
Kommen wir zurück auf den Boden der Tatsachen, zu unserer Call-Center-Software.
Man muss zwischen drei Arten von Komponenten unterscheiden, die unterschiedlichen Einfluss auf die Zuverlässigkeit des Gesamtsystems haben.
Der erste und kritischste Komponententyp, was seinen Einfluss auf die Zuverlässigkeit angeht, ist der Kern. Hier werden die Anrufsteuerung, die Verbindung zum Telefonanbieter und der Datenaustausch (Audio, Daten, manchmal Video) mit den Agent-Arbeitsplätzen abgewickelt.
Es gibt viele Instanzen (der Kern wird unverändert in allen Installationen verwendet) und eine direkte Auswirkung auf die Verfügbarkeit des gesamten Systems, da diese Software die eigentlichen Call-Center-Funktionen bereitstellt.
Die Anforderungen sind damit denkbar hoch, vielleicht so hoch wie bei echten Raumfahrtsystemen (na ja, vielleicht nicht ganz – aber auch nicht allzu weit davon entfernt). Die Kosten eines Ausfalls können hoch sein, nicht nur, weil die Ausfallzeit jeder realen Installation teuer ist, sondern auch, weil sich diese Kosten im Verhältnis zur Anzahl der verwendeten Instanzen erhöhen. Ein weiterer Multiplikator der Fehlerkosten: Es ist schwierig, Workarounds für den Kern zu bauen, und nur die Entwickler des Systems können das Problem finden und beheben.
Der zweite Komponententyp sind diverse Servicefunktionen, darunter die Agent-Schnittstelle, Standard-IVR-Blöcke, verschiedene Integrations-APIs usw. Es gibt viele solcher Funktionen, und nicht alle von ihnen werden in jedem einzelnen Projekt verwendet, so dass die Anzahl der Instanzen jeder Funktion generell viel geringer ist als die des Kerns. Außerdem ist es in jedem einzelnen Fall in der Regel möglich, Ausfälle solcher Komponenten durch die Implementierung temporärer Funktionen und anderer Workarounds zu kompensieren; dies verschafft dem Entwickler Zeit, den Fehler ohne größere Einbußen zu beheben.
Die Anforderungen an die Zuverlässigkeit sind bei dieser Art von Funktion in der Regel geringer, ebenso wie die Bandbreite der Debugging-Möglichkeiten (solche Komponenten unterscheiden sich stark, und das hohe Entwicklungstempo lässt ein gründlicheres Debugging nicht zu).
Hier sind einige Möglichkeiten zum Schutz vor Fehlern in diesen Komponenten:
a) Zunächst ist es wichtig, das System so zu testen, wie es für die Kundenanforderungen konfiguriert ist, und zwar unter möglichst realitätsnahen Bedingungen (während der Roll-Out-Phase, also in Vorbereitung auf den Betrieb). Das bedeutet, dass alle Anrufverarbeitungswege getestet werden müssen. Wenn es zu viele Kombinationen von Parametern gibt, mit denen die Agents arbeiten werden, müssen zumindest die häufigsten zum Testen ausgewählt werden (wobei zu bedenken ist, dass jede nicht getestete Kombination einen potenziellen Ausfall bedeutet). Die gleichen Überlegungen gelten für andere Funktionen.
b) Organisieren Sie eine Testphase, um Fehler zu erkennen. Während dieses Zeitraums werden die wahrscheinlichsten Fehler auftreten. Daher sollte die Testphase alle möglichen Modi abdecken (alle Inbound- und Outbound-Projekte, Integrationsarten usw.) Dies ist im Wesentlichen ein umfassendes Debugging der Software in einer realen Umgebung. Wenn Sie diesen Ansatz ignorieren, erhöht sich das Risiko von späteren Geld- und Reputationsverlusten signifikant.
c) Das Roll-Out-Team (der Systemintegrator oder das Professional-Services-Team des Anbieters) sollte während der Testphase in Alarmbereitschaft sein und gemeinsam mit dem Kunden Entscheidungen über Notfallmaßnahmen treffen, wenn Fehler oder Ungenauigkeiten festgestellt werden.
d) Der Anbieter muss bereit sein, kurzfristig Korrekturen vorzunehmen. Er sollte sich darüber im Klaren sein, dass die Wahrscheinlichkeit von Fehlern bei Komponenten des zweiten Typs erheblich ist, und einen Prozess zur Korrektur von Fehlfunktionen innerhalb eines sehr begrenzten Zeitrahmens entwerfen.
Der dritte Typ von Komponenten ist der fehleranfälligste. Dabei handelt es sich um die Anpassung des Systems an Kundenanforderungen (IVR, Agent-Bildschirme, Anrufrouten, Berichte, angepasste Skripte, usw.). Natürlich gilt es, Unachtsamkeiten des Roll-Out-Teams oder mangelndes Debugging zu vermeiden – aber der Einfluss des berüchtigten „menschlichen Faktors“ ist viel höher, da die Debugging-Möglichkeiten auf der Ebene der Systemkonfiguration oft sehr begrenzt sind.
Denken Sie an die Kosten für Debugging-Tools, die in der Raumfahrtindustrie verwendet werden. Natürlich ist die Situation bei diesem Teil von Call-Center-Projekten nicht damit vergleichbar, vor allem weil in diesem Fall das Budget in der Regel keine gesonderten Debugging-Mittel vorsieht (wie etwa die Simulation aller Arten von Anrufen, das automatische Testen verschiedener Betriebsarten oder die Simulation aller Arten von realen Situationen). Somit besteht das Debugging letztendlich aus Tests anhand einzelner Beispiele, mit manuellen Einstellungen, manuellen Anrufen (die z. B. nicht den gesamten Wählplan abdecken), unvollständigen Tests der Kombination von IVR-Bedingungen, Integrationsparametern und anderen Bedingungen. Es ist möglich, ein Vier-Augen-Prinzip sowohl für Code- als auch für Einstellungstests zu verwenden, aber das erhöht die Kosten erheblich und ist nicht immer effektiv.
Was machen wir also mit dieser Art von Komponenten? Wie schützen wir uns vor Fehlern? Im Allgemeinen sind die Ansätze die gleichen wie für den zweiten Typ. Die gute Nachricht ist, dass alle Lösungen, die Komponenten vom Typ 3 abdecken, von den implementierenden Teams selbst entwickelt wurden, so dass man sich mit Problemen nicht an den Hersteller wenden muss. Die schlechte Nachricht ist, dass die Fehlerwahrscheinlichkeit bei Komponenten vom Typ 3 in der Regel höher ist als bei Komponenten vom Typ 2.
Welche Schlussfolgerungen können wir aus all dem ziehen?
1. Die Kosten für Verluste durch Systemfehler stehen in einem Gleichgewicht mit den Kosten für Tests und Fehlerbehebung. Das ist eine universelle Regel, die sowohl für Raumfahrtsysteme als auch für Call Center und generell für jede Art von Softwarelösung gilt.
2. Die Zuverlässigkeit des Systems kann erheblich gesteigert werden, wenn der Kunde sorgfältig auf die Abnahmetests achtet und bereit ist, Zeit und Geld für zusätzliche Tests bereitzustellen.
3. Die Bereitschaft, Fehler und Einstellungsprobleme zu beseitigen und ein ganzheitliches Debugging (also eine Testphase) richtig zu planen, ist entscheidend für die Minimierung von Schäden, die durch Fehler entstehen.
4. Wenn die Kosten von Fehlern hoch sind, wie z. B. bei Notrufsystemen, sollte das Projekt spezielle Werkzeuge (sowohl Software als auch Hardware) für verschiedene Arten von Tests und Testautomatisierung vorsehen, die bei der Fehlersuche verwendet werden.
Weitere Aspekte
Es gibt viele weitere Themen wie Hardware-Failover, Fehler auf Plattformebene (von Betriebssystemen, Hypervisors, Container-Management-Tools usw.) oder dynamische Software-Failover. Ich bin nicht auf die Verwendung von Monitoring eingegangen, entweder automatisch oder manuell, für Benachrichtigungen über vorkritische und kritische Situationen. Und das Thema Backup ist ein eigener Bereich, der eine große Rolle bei der Sicherstellung eines unterbrechungsfreien Betriebs spielt. All diese Themen überschneiden sich mit den Überlegungen in diesem Artikel, sind aber nicht deckungsgleich mit ihnen; sie sind jedoch genauso wichtig, wenn es darum geht, die Kosten von Ausfällen sowie die Zeit für deren Behebung zu reduzieren.