Quicksearch
Disclaimer
The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
Navigation
Wahre Worte
Sunday, July 30. 2006
Comments
Display comments as
(Linear | Threaded)
Failure Fencing:
http://mysqldump.azundris.com/archives/49-Security-and-the-real-world.html
Ab Folie 5.
Solange man Space Invaders Security betreibt, wird man niemals gewinnen können - man kann Space Invaders nicht gewinnen.
http://mysqldump.azundris.com/archives/49-Security-and-the-real-world.html
Ab Folie 5.
Solange man Space Invaders Security betreibt, wird man niemals gewinnen können - man kann Space Invaders nicht gewinnen.
Naja, auch Informatikern ist klar, daß die Praxis anders aussieht als das idealisierte theoretische Modell (von denen das determinstische Modell allerdings auch nur das einfachste unter vielen anderen, z.B. probabilistische Modellen ist).
Im wesentlichen geht es darum, qualitativ brauchbare Dienste zu entwickeln; ein Dienst kann auch dann noch brauchbar sein, wenn er nicht unter allen Bedigungen einwandfrei arbeitet (der Fehler sollte allerdings als solcher erkannt werden). Fehler weisen allerdings oftmals auch aud Designschwächen hin. Die Frage ist also, ob dein fehlerhafter Code/Design auch zukunftssicher ist (wartbar, erweiterbar etc).
Was mich in der Praxis nervt sind selbsternannte Praktiker, die unter dem Deckmantel der pragmatischen Abkürzung herumwurschteln. Das hat nichts mit Pragmatismus zu tun, sondern ist nur eine Ausrede für Unfähigkeit sauber zu arbeiten. Was dabei herauskommt ist in der aktuellen ACM Communications unter dem Titel "What Road ahaead for Microsoft and Windows" zu lesen.
Summa S: Fehlertoleranz ist etwas anderes als der Verzicht auf Korrektheit und Determinsimus.
Im wesentlichen geht es darum, qualitativ brauchbare Dienste zu entwickeln; ein Dienst kann auch dann noch brauchbar sein, wenn er nicht unter allen Bedigungen einwandfrei arbeitet (der Fehler sollte allerdings als solcher erkannt werden). Fehler weisen allerdings oftmals auch aud Designschwächen hin. Die Frage ist also, ob dein fehlerhafter Code/Design auch zukunftssicher ist (wartbar, erweiterbar etc).
Was mich in der Praxis nervt sind selbsternannte Praktiker, die unter dem Deckmantel der pragmatischen Abkürzung herumwurschteln. Das hat nichts mit Pragmatismus zu tun, sondern ist nur eine Ausrede für Unfähigkeit sauber zu arbeiten. Was dabei herauskommt ist in der aktuellen ACM Communications unter dem Titel "What Road ahaead for Microsoft and Windows" zu lesen.
Summa S: Fehlertoleranz ist etwas anderes als der Verzicht auf Korrektheit und Determinsimus.
#2
on
2006-07-30 17:51
Ich hatte in meiner bisherigen Karriere viel mit Informatikern frisch von der Uni zu tun, die dem Bild nachhingen, das ihr Code irgendwann hunderprozentig ist. Sie haben sich aber keine Gedanken darueber gemacht, wie sich darum kümmern, das ihr Code im Fehlerfalle in die sichere Richtung fällt und wie sie Auswirkungen eines Fehlers einschränken können. Die Notwendigkeit dazu wird vielen erst bewusst, wenn sie sich die Zähne in dem einen oder anderen Projekt abstossen. In Usecases wird oftmals definiert, was eine Komponente machen soll, und wie sie auf Fehler des Nutzer reagieren soll, aber selten wie sich die Fehler einer Komponente im Gesamtsystem und nach aussen auswirken.
Von daher finde ich beispielsweise das Trustsoft-Graduiertenkolleg der Universität Oldenburg eine hervorragende Einrichtung, da es unter anderem genau um diese Themen dort geht. Wie lerne ich mit den Fehlern leben, die zwangsläufig passieren.
Ich will hier nicht den Verzicht auf Determinismus und Korrektheit propagieren, aber beides darf nicht zum Glauben führen, das man auf Mechanismen zur Fehlertoleranz verzichten kann.
Von daher finde ich beispielsweise das Trustsoft-Graduiertenkolleg der Universität Oldenburg eine hervorragende Einrichtung, da es unter anderem genau um diese Themen dort geht. Wie lerne ich mit den Fehlern leben, die zwangsläufig passieren.
Ich will hier nicht den Verzicht auf Determinismus und Korrektheit propagieren, aber beides darf nicht zum Glauben führen, das man auf Mechanismen zur Fehlertoleranz verzichten kann.
#2.1
on
2006-07-30 18:08
Oh je, ein echtes Fettnapf-Thema, aber ich versuche es mal in Kürze. Wer sich auf die Füße getreten fühlt, der... ok, der... soll damit einfach leben. 
1. Zur Bemerkung von Steffo ("Was mich in der Praxis nervt sind selbsternannte Praktiker, die unter dem Deckmantel der pragmatischen Abkürzung herumwurschteln."): jawoll, so ist es. Ich nenne das "fröhliches Vor-Sich-Hin-Dilettieren". Auch "gefährliche Halbwissende" genannt. Es darf sich ja gern jeder im Rahmen seier Möglichkeiten betätigen, aber das Problem ist, diese Leute wissen meist nicht wann sie fragen müssen! Und wer räumt dann hinter ihnen auf? Genau. Ich sage nur: "Wieso? Transaktionen braucht man doch eigentlich nicht?".
2. Es gibt in der Tat eine Sorte Informatiker, vorzugsweise (aber nicht nur) frischgebackene, die im Endergebnis schlicht nichts für einen Kunden nutzbares hinbekommen. Entweder weil sie nicht fertigwerden oder weil sie ein System bauen, das völlig an den Kundenanforderungen vorbeigeht, weil der Kunde für sie maximal dieses lustige Männchen in den Usecase-Diagrammen ist.
3. Der überwiegende Teil eines Entwickleralltags beschäftigt sich doch mit eher bodenständigen Problemen, bei denen zumindest lokale Korrektheit möglich (gut, sagen wir: guten Gewissens anstrebbar) ist. Ich werde sie vielleicht nicht immer erreichen, aber es ist schlicht das billigste es zu versuchen. Ein unscharfer Klassenkontrakt, weggelassene Transaktionen, bröckelige Fehlerbehandlung, das sind alles Dinge, die auf Dauer sehr sehr teuer werden und auf keinen Fall unter dem Deckmäntelchen des Pragmatismus verborgen werden sollten. Es holt einen einfach immer wieder ein.
4. Ich turne ja nun inzwischen auch an die 20 Jahre in der IT rum, habe die Uni nur gestreift und - mich eingeschlossen - eine endlose Zahl an "Praktikern" erleben dürfen. Ich möchte es mal so vormulieren: diejenigen Praktiker, die es zu meiden gilt, erkennt man meist am Inhalt ihres Bücherregals. Ganz ohne Grundlagenwissen geht's halt doch nicht, wenn man gut sein will.
5. Fehlertoleranz auf Komponentenebene finde ich klasse, Fehlertoleranz auf Ebenen darunter ganz furchtbar - ein echter Irrweg, der nur dazu führt daß man Fehler verschleiert und zu spät findet und/oder dem Benutzer nicht, oder nicht korrekt kommuniziert.
Beispiel: wenn eine Java-Methode einen falschen Parameter bekommt, soll sie bitte in Form einer Exception Laut geben, anstatt auf irgendwelche Defaults zu gehen. Hier ist Fehlertoleranz fehl am Platz und Fehlererkennung gewünscht. Wenn dagegen ein System einen Service aufruft, sollte es das Ergebnis prüfen, und wenn dieses dubios erscheint, a) einen Fehler loggen und b) schauen, ob es Recovery-Möglichkeiten gibt.
6. Die im verlinkten Artikel angesprochenen Beispiele für akzeptiertes fehlerhaftes Verhalten, z.B. durch veraltete Daten, haben eines gemeinsam:
Bevor man dies bewußt so konstruiert, muß man eines tun, nämlich die Frage beantworten: was ist das schlimmste, das passieren könnte und wie oft wird es durchschnittlich eintreten? Und dann sicherstellen, daß der Kunde das auch in der Form einer bewußten, dokumentierten Willensentscheidung akzeptiert. Und für die Formalästheten: dann ist das System auch wieder korrekt im Sinne der Anforderung.
1. Zur Bemerkung von Steffo ("Was mich in der Praxis nervt sind selbsternannte Praktiker, die unter dem Deckmantel der pragmatischen Abkürzung herumwurschteln."): jawoll, so ist es. Ich nenne das "fröhliches Vor-Sich-Hin-Dilettieren". Auch "gefährliche Halbwissende" genannt. Es darf sich ja gern jeder im Rahmen seier Möglichkeiten betätigen, aber das Problem ist, diese Leute wissen meist nicht wann sie fragen müssen! Und wer räumt dann hinter ihnen auf? Genau. Ich sage nur: "Wieso? Transaktionen braucht man doch eigentlich nicht?".
2. Es gibt in der Tat eine Sorte Informatiker, vorzugsweise (aber nicht nur) frischgebackene, die im Endergebnis schlicht nichts für einen Kunden nutzbares hinbekommen. Entweder weil sie nicht fertigwerden oder weil sie ein System bauen, das völlig an den Kundenanforderungen vorbeigeht, weil der Kunde für sie maximal dieses lustige Männchen in den Usecase-Diagrammen ist.
3. Der überwiegende Teil eines Entwickleralltags beschäftigt sich doch mit eher bodenständigen Problemen, bei denen zumindest lokale Korrektheit möglich (gut, sagen wir: guten Gewissens anstrebbar) ist. Ich werde sie vielleicht nicht immer erreichen, aber es ist schlicht das billigste es zu versuchen. Ein unscharfer Klassenkontrakt, weggelassene Transaktionen, bröckelige Fehlerbehandlung, das sind alles Dinge, die auf Dauer sehr sehr teuer werden und auf keinen Fall unter dem Deckmäntelchen des Pragmatismus verborgen werden sollten. Es holt einen einfach immer wieder ein.
4. Ich turne ja nun inzwischen auch an die 20 Jahre in der IT rum, habe die Uni nur gestreift und - mich eingeschlossen - eine endlose Zahl an "Praktikern" erleben dürfen. Ich möchte es mal so vormulieren: diejenigen Praktiker, die es zu meiden gilt, erkennt man meist am Inhalt ihres Bücherregals. Ganz ohne Grundlagenwissen geht's halt doch nicht, wenn man gut sein will.
5. Fehlertoleranz auf Komponentenebene finde ich klasse, Fehlertoleranz auf Ebenen darunter ganz furchtbar - ein echter Irrweg, der nur dazu führt daß man Fehler verschleiert und zu spät findet und/oder dem Benutzer nicht, oder nicht korrekt kommuniziert.
Beispiel: wenn eine Java-Methode einen falschen Parameter bekommt, soll sie bitte in Form einer Exception Laut geben, anstatt auf irgendwelche Defaults zu gehen. Hier ist Fehlertoleranz fehl am Platz und Fehlererkennung gewünscht. Wenn dagegen ein System einen Service aufruft, sollte es das Ergebnis prüfen, und wenn dieses dubios erscheint, a) einen Fehler loggen und b) schauen, ob es Recovery-Möglichkeiten gibt.
6. Die im verlinkten Artikel angesprochenen Beispiele für akzeptiertes fehlerhaftes Verhalten, z.B. durch veraltete Daten, haben eines gemeinsam:
Bevor man dies bewußt so konstruiert, muß man eines tun, nämlich die Frage beantworten: was ist das schlimmste, das passieren könnte und wie oft wird es durchschnittlich eintreten? Und dann sicherstellen, daß der Kunde das auch in der Form einer bewußten, dokumentierten Willensentscheidung akzeptiert. Und für die Formalästheten: dann ist das System auch wieder korrekt im Sinne der Anforderung.
#2.2
on
2006-07-30 19:45
Ja, den Buchtest kann man gut gebrauchen. Wenn man bei einem "Entwickler" Java for Dummies findet, sollte man sehr vorsichtig sein.
Letztlich muss man beides in Balance bringen. Fehlertoleranz und Korrektheit. Schönes Beispiel ist für mich das von Kris gewählte Beispiel der Mailquota. Kommt das Ergebnis nicht oder ist es offensichtlich schwachsinnig, so kann man sich dafuer entscheiden, ob man die Mail bounced oder einfach annimmt und eine Warnung ins Logfile schreibt. Oder ob einfach eine Seite nur mit der Hälfte der Informationen dargestellt wird. Fällt es einem Kunden wirklich auf, wenn bei Amazon die Empfehlungsbox fehlt. Wegen einer nicht reagierenden Komponente zu warten ist keine Option, wartende Kunden kaufen nichts. Eine Exception zu werfen ist auch ganz schlecht. Es gibt nichts peinlicheres als einen Stacktrace auf einer Webseite
. Und wenn sich dann doch mal ein Fehler in die Steuerung der Landeklappen eines Flugzeugs einschleicht, moechte ich auch, das die Rechner noch sinnvoll reagieren und nicht einfach einen Bluescreen auswerfen und garnichts mehr tun.
Sicher ist nur, das man sich immer bewusst dafür entscheiden muss, wie man die Fehlertoleranz gestaltet. Es darf nich dazu führen, das man sich in die Hängematte des Failure Fencings legt und sich denkt "Wenn ich Mist baue, ists schon nicht so schlimm".
Es ist halt die Frage, was kann ich maximal dadurch verlieren, wenn ich einen Fehler durchgehen lasse. Und wie Steffo in der gemeinsamen Bürozeit öfters sinngemäss gesagt hat: "Man kann das Problem auch organisatorisch absichern".
Letztlich muss man beides in Balance bringen. Fehlertoleranz und Korrektheit. Schönes Beispiel ist für mich das von Kris gewählte Beispiel der Mailquota. Kommt das Ergebnis nicht oder ist es offensichtlich schwachsinnig, so kann man sich dafuer entscheiden, ob man die Mail bounced oder einfach annimmt und eine Warnung ins Logfile schreibt. Oder ob einfach eine Seite nur mit der Hälfte der Informationen dargestellt wird. Fällt es einem Kunden wirklich auf, wenn bei Amazon die Empfehlungsbox fehlt. Wegen einer nicht reagierenden Komponente zu warten ist keine Option, wartende Kunden kaufen nichts. Eine Exception zu werfen ist auch ganz schlecht. Es gibt nichts peinlicheres als einen Stacktrace auf einer Webseite
. Und wenn sich dann doch mal ein Fehler in die Steuerung der Landeklappen eines Flugzeugs einschleicht, moechte ich auch, das die Rechner noch sinnvoll reagieren und nicht einfach einen Bluescreen auswerfen und garnichts mehr tun. Sicher ist nur, das man sich immer bewusst dafür entscheiden muss, wie man die Fehlertoleranz gestaltet. Es darf nich dazu führen, das man sich in die Hängematte des Failure Fencings legt und sich denkt "Wenn ich Mist baue, ists schon nicht so schlimm".
Es ist halt die Frage, was kann ich maximal dadurch verlieren, wenn ich einen Fehler durchgehen lasse. Und wie Steffo in der gemeinsamen Bürozeit öfters sinngemäss gesagt hat: "Man kann das Problem auch organisatorisch absichern".
#2.2.1
on
2006-07-30 20:19
The author does not allow comments to this entry
The LKSF book
The book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0
Contact
Networking
xing.com
LinkedIn
Facebook
My photos
- mail: joerg@c0t0d0s0.org
Networking
xing.com
My photos
Comments
about End of c0t0d0s0.org
Mon, 01.05.2017 11:21
Thank you for many interesting
blog posts. Good luck with al
l new endeavours!
Fri, 28.04.2017 13:47
At least with ZFS this isn't c
orrect. A rmdir for example do
esn't trigger a zil_commit, as
long as you don't speci [...]
Thu, 27.04.2017 22:31
You say:
"The following dat
a modifying procedures are syn
chronous: WRITE (with stable f
lag set to FILE_SYNC), C [...]
Kris hat einen lebendigen, informativen Text über Service Oriented Architectures (SOA), über Skalierbarkeit und Fehlertoleranz großer Softwaresysteme geschrieben. Lebendig meint hier, dass an den Praxisbeispielen web.de, amazon und MySQL erklärt wird,
Tracked: Jul 30, 16:22