[BNS]
Knowledge Base
| Dokument
erstellt
Thomas vom Braucke/Braucke/DE
Sat 05/01/2004 02:41 PM
Änderung
Thomas vom Braucke/Braucke/DE
Sun 09/26/2021 05:39 PM
verantwortlich
Thomas vom Braucke/Braucke/DE
Status
abgeschlossen
Wichtigkeit
C
Stand
Sat 05/01/2004 02:41 PM
Sun 02.05.04 00:15
Konzepte
K11704
Listung im Hilfe-Index
Fehlertoleranz
Technische Systeme allgemein
QM und Fehlerrelevanz
SystemOptimierung durch Akzeptanz von Fehlern
.
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 -
2024
Braucke NetServices, Thomas vom Braucke, Bielefeld, DE |
Impressum
,
Datenschutzerklärung
,
Kontakt
