Detection Pattern

Correlation (dt. Zusammenhang, Beziehung)

Wurde ein Error oder Failure entweckt, gibt es hierfür mehrere Ursachen. Beim Testen werden bereits mehrere Fehler gefunden, jedoch mit Sicherheit nicht alle. Für die gefundenen Fehler sollte eine Signatur erstellt werden (Stack Grösse, wurden Logs gesammelt, welche Funktionen sind nicht mehr verfügbar etc.). Die behobenen Fehler werden anhand dieser Informationen kategorisiert und allgemeine Fehlerbehebungsprozeduren definiert.

Tritt nun auf der Produktion ein Error auf, dann wird dieser anhand seiner Signatur kategorisiert. Für die Kategorie kann dann die bekannte Fehlerprozedur angewendet werden. Dadurch können auch Errors behandelt werden, welcher zum Zeitpunkt der Auslieferung noch nicht bekannt waren.

Errors (in Daten, Nachrichten etc) können sich schnell von einer Mitigation Unit auf eine andere ausbreiten. Aus diesem Grund sollte eine Unit of Mitigation isolieren und dadurch das überschwappen auf andere Teile im System mit einer Barriere verhindern.

Anschliessend kann die Fehlerbehandlung initiiert werden. Gegen Aussen soll das System eine Fail-Silent Meldung propagieren. Das System wird defakto in Quarantäne gesetzt.

Riding over Transients (dt. überspringen der Störsignale/flüchtige Erscheinungen)

Gewisse Fehler treten nur einmalig oder kurzfristig auf. Es soll verhindert werden, dass die Behandlung solcher Fehler das System unnötig belasten.

Das System sollte mittels Fault Correlation überwacht werden. Die Errors werden kategorisiert. Ist die Kategorie nicht als transient Errors definiert, dann sollte die Behandlung des Errors sofort beginnen. Ansonsten wird die Fehlerbehandlung nur eingeleitet, wenn der Fehler in der letzten Zeit häufig aufgetreten ist. Ansonsten wird der Fehler ignoriert (mit Ausnahme, dass der Counter erhöht wird). Für jede Fault Correlation kann ein maximales Aufkommen definiert werden, ab wann der Fehler behandelt wird.

Beispielsweise sollte ein einmaliger DB-Connection-Verlust keine Auswirkung haben. Schlagen jedoch mehrere Abfragen in kürzester Zeit fehl, sollte ggf. der Systemadministrator benachrichtigt werden. Würde der System-Administrator bereits nach der ersten fehlgeschlagenen Anfrage benachrichtigt, könnte dieser z.B. den DB-Server neustarten,
obwohl nur ein temporäres Problem bestand. Kurzfristige Fehler können zu unkorrekten Behandlungsmethoden führen und werden deshalb erst ab dem erreichen eines Threshold behandelt (Stichwort: LEAKY BUCKET COUNTER).

Wie kann erkannt werden, ob es sich um einen kurzlebigen (tranisent) oder einen wiederkehrenden (intermittent) Error handelt. Hierfür besitzt jede Unit of Mitigation ein Leaky Bucket Counter. Bei jedem auftretenden Error wird der Counter erhöht. In vorbestimmten Zeitperioden wird der Counter um jeweils eins reduziert, wobei der Wert nie unter 0 geht. Erreicht der Counter nun dennoch einen Threshold, dann handelt es sich um einen permantenten Fehler (wenn das hinzukommen von neuen Fehler schneller ist als das abfliessen, dann handelt es sich um einen permanenten Fehler). In jedem Fall sollte jedes einzelne Auftreten des Errors an den Fault Observer gemeldet werden.