Konzepte\Technische Systeme allgemein\QM und Fehlerrelevanz
SystemOptimierung durch Akzeptanz von Fehlern
K11704
|
05/01/2004
Sun 02.05.04 00:15
<bearbeiten>
Quelle: Der Spiegel, 16/2004 |
mit freundlicher Genehmigung [I925371
]
Interpretation, Kommentierung K11704.pdf
Vom Grundsatz ist die Idee nicht neu: In einem komplexen technischen System gibt es Komponenten welche die Fehlfunktion eines Teils erkennen und kompensieren. Beispiel hierfür sind z.B. s.g. Watchdogs. Bei Hängen eines Programmteils wird dieser neu gestartet. Andere Beispiele sind redundante Systeme wie Festplattenspiegelungen, zwei Außenbordmotoren statt einem usw..
Der Ansatz ist bei der Planung jeder Komponente, sei es nun Programmcode oder Arbeitsflußbeschreibungen,
von der Unmöglichkeit von Fehlerfreiheit auszugehen
. Immer daran zu denken was passiert, wenn es in diesem Arbeitsschritt zu einem Fehler kommt. Wie kann die Komponente konstruiert werden, daß eine definierte Wiederaufnahme möglich ist. Wie kann diese möglichst ohne einen undefiniertem Zustand im Gesamtprozeß zu hinterlassen umgangen, übersprungen werden.
Zurückkommend auf die Beispiele:
Gut gelungen ist das System doppelte Außenbordmotoren. Der Ausfall einer Maschine wird der zentralen Steuerungseinheit, hier Schiffsführer, durch ausbleibendes Motorengeräusch und Vortrieb signalisiert worauf vor Schäden (Abtreiben, Auflaufen, ...) umgehend die Funktion auf die zweite Maschine verlagert wird.
Bei Festplattenspiegelungen sieht es oft schon anders aus. Dem Kunden werden redundante Lösungen verkauft, gedacht wird jedoch nicht daran was passiert wenn die erste Platte ausfällt: Gar nichts, im System ist kein Arbeitsablauf für das zeitnahe Feststellen des Fehlers fixiert. Hierdurch wird der Ausfall der zweiten Festplatte zum Totalausfall verbunden mit unangenehmen Fragestellungen. Wäre an dieses Projekt von vornherein mit höherem Bewusstsein 'Es kann zu Fehlern kommen, was passiert wenn' herangegangen worden, so hätte z.B. im Übergabeprotokoll gestanden: 'Kunde überprüft wöchentlich Systemprotokolle, besonders zu beachten...'.
Werden Watchdogs bzw. wie im anhängenden Artikel empfohlen, nennen wir es, 'Ausfallüberbrücker' eingesetzt, so sollte dies auch wirklich bei der Konzeption der Einzelkomponenten Berücksichtigung finden. Also ggf. weniger Aufwand für Vermeidung von Fehlern und mehr für frühzeitige Integration von Fehlerkompensationsverfahren. Beispiel:
Angenommen anhängendes PDF läge in einem kostenpflichtigen Pressarchiv. Der Tscheche Otto Šimanek ruft das Dokument ab. Folgend angelegter Abrechnungsdatensatz für den Abruf wird aufgrund einer undurchführbaren Namensauflösung wie sich später herausstellt fehlerhaft. (Ursache: kein Index für
aufgrund irgendeines Sicherheitsupdates, Alias Pan Tau in dem etwas zu modischen, modernem System unbekannt)
[unbemerkter Fehler wird relevant]
Monatsende, die Abrechnung in der Zentraldatenbank wird gefahren. Bei der Sammelrechnung ACME/Prag kommt es zu Fehlern.
[Konzeption gewährleistet klare Unfallabgrenzung]
Die Teilfunktionen haben jedoch vor jeder Veränderung eines Datensatzes eine Bestätigung des Tansaktionskennzeichens 'begin accounting to invoice ID' abgewartet. Nach Übertragung der Position in die Rechnung wird 'ready transfered to UNsaved invoice ID' gesetzt. Erst nach bestätigter Sicherung der Gesamtrechnung werden die Stati auf 'ready invoiced by ID' gesetzt.
[Der Ausfallüberbrücker]
Weiterhin wurden die Einzelfunktionen so in die Abrechnungsroutine integriert, dass bei einem Fehler mit dem nächsten Rechnungsempfängers fortgefahren wird. So konnten 723 von 724 Rechnungen zugestellt werden, die Produktivität des Gesamtsystems musste nicht unterbrochen werden.
[Die Rekonstruierbarkeit]
Die Entwicklung konnte Rechnung #321.2004-Mar-31 am 17.4 freigeben. Dazu hat sie die Datensätze mit Status 'begin accounting to invoice ID' genau analysiert und den Fehler in einem nicht numerischen Item Summe lokalisiert. Nach Fixierung wurden dann alle Datensätze mit Status 'ready transfered to UNsaved invoice ID' zurückgesetzt und die Abrechnungsroutine wiederholt.
Thomas vom Braucke/Braucke/DE, 2004-May-01
s. a. QM und Fehlerrelevanz:
Minimierte Entwicklungs- und Fehlerbehungsaufwände durch geplantes Kompensationsverhalten
[K11705, 2004-May-01
]
Weitere Stichworte: fehlertolerante Systeme, Fehlertoleranz
©
1989 -
2025
Braucke NetServices, Thomas vom Braucke, Bielefeld, DE |
Impressum
,
Datenschutzerklärung
,
Kontakt
