Sollten wir Programme entwerfen, die sich nach dem Zufallsprinzip selbst töten? [geschlossen]

Kurz gesagt, sollten wir den Tod in unseren Programmen, Prozessen und Threads auf einer niedrigen Ebene zum Wohle des Gesamtsystems auslegen?

Fehler passieren. Prozesse sterben. Wir planen eine Katastrophe und erholen uns gelegentlich davon. Aber wir entwerfen und implementieren selten unvorhersehbaren Programmtod. Wir hoffen, dass die Betriebszeiten unserer Services so lange sind, wie wir sie am Laufen halten möchten.

Ein Makrobeispiel für dieses Konzept ist der Chaos Monkey von Netflix , mit dem AWS-Instanzen in einigen Szenarien zufällig beendet werden. Sie behaupten, dies habe ihnen geholfen, Probleme zu entdecken und redundantere Systeme aufzubauen.

Ich spreche von einer niedrigeren Ebene. Die Idee ist, dass traditionell lange laufende Prozesse zufällig beendet werden. Dies sollte eine Redundanz im Entwurf erzwingen und letztendlich stabilere Systeme erzeugen.

Hat dieses Konzept schon einen Namen? Wird es bereits in der Industrie eingesetzt?

BEARBEITEN

Aufgrund der Kommentare und Antworten fürchte ich, dass ich in meiner Frage nicht klar war. Zur Klarheit:

• ja, ich meine zufällig,
• ja, ich meine in der Produktion und
• nein, nicht nur zum testen.

Zur Erklärung möchte ich eine Analogie zu mehrzelligen Organismen ziehen.

Organismen bestehen in der Natur aus vielen Zellen. Die Zellen verzweigen sich, um Redundanz zu erzeugen, und sterben schließlich ab. Es sollten jedoch immer genügend Zellen der richtigen Art vorhanden sein, damit der Organismus funktionieren kann. Dieses hochredundante System erleichtert auch die Heilung bei Verletzungen. Die Zellen sterben, damit der Organismus lebt.

Die Einbeziehung des zufälligen Todes in ein Programm würde das größere System zwingen, Redundanzstrategien anzuwenden, um lebensfähig zu bleiben. Würden dieselben Strategien dazu beitragen, dass das System auch bei anderen Arten von unvorhersehbaren Fehlern stabil bleibt?

Und wenn jemand dies versucht hat, wie heißt es? Ich würde gerne mehr darüber lesen, wenn es bereits existiert.

Nein.

Wir sollten eine ordnungsgemäße Behandlung fehlerhafter Pfade entwerfen und Testfälle (und andere Prozessverbesserungen) entwerfen, um zu validieren, dass Programme mit diesen außergewöhnlichen Bedingungen gut umgehen. Sachen wie Chaos Monkey können ein Teil davon sein, aber sobald man "willkürlich abstürzen lassen" muss, werden tatsächliche zufällige Abstürze zu Dingen, die Tester nicht als Bugs melden können.

Das Einführen von Fehlern in Software oder Hardware zum Testen von Fehlertoleranzmechanismen wird als Fehlerinjektion bezeichnet .

Aus Wikipedia:

Die Technik der Fehlerinjektion stammt aus den 1970er-Jahren, als sie erstmals zur Auslösung von Fehlern auf Hardware-Ebene eingesetzt wurde. Diese Art der Fehlerinjektion wird als Hardware Implemented Fault Injection (HWIFI) bezeichnet und versucht, Hardwarefehler innerhalb eines Systems zu simulieren. Die ersten Versuche zur Hardwarefehlerinjektion umfassten lediglich das Kurzschließen von Verbindungen auf Leiterplatten und die Beobachtung der Auswirkungen auf das System (Überbrückungsfehler). Es wurde in erster Linie als Test für die Zuverlässigkeit des Hardwaresystems verwendet. Später wurde spezielle Hardware entwickelt, um diese Technik zu erweitern, beispielsweise Geräte, um bestimmte Bereiche einer Leiterplatte mit starker Strahlung zu beschießen. Es wurde bald festgestellt, dass Fehler durch Softwaretechniken hervorgerufen werden können und dass Aspekte dieser Technik zur Beurteilung von Softwaresystemen nützlich sein können.

Ja. Nein, vielleicht.

Periodische Kündigung ist ein zweischneidiges Schwert. Sie werden mit der einen oder der anderen Kante getroffen, und welches der beiden kleineren Übel von Ihrer Situation abhängt.

Ein Vorteil ist die Zuverlässigkeit: Wenn Sie das Programm zwingen, willkürlich (oder vorhersehbar) und ordnungsgemäß zu beenden, können Sie auf dieses Ereignis vorbereitet sein und damit umgehen. Sie können sicherstellen, dass der Prozess beendet wird, wenn keine anderen nützlichen Aufgaben ausgeführt werden. Dies garantiert auch, dass Bugs, die sich über die genehmigte Laufzeit hinaus manifestieren würden, ihre hässlichen Köpfe in der Produktion nicht aufrichten, was eine gute Sache ist. Apache HTTPD verfügt über eine Einstellung, mit der Sie festlegen können, wie viele Anforderungen ein untergeordneter Prozess (oder Thread in neueren Versionen) vor dem Beenden ausführen soll.

Der andere Vorteil ist auch die Zuverlässigkeit: Wenn Sie nicht zulassen, dass das Programm lange ausgeführt wird, werden Sie niemals Fehler finden, die sich im Laufe der Zeit manifestieren. Wenn Sie schließlich auf einen dieser Fehler stoßen, ist es viel wahrscheinlicher, dass das Programm eine falsche Antwort zurückgibt oder überhaupt keine zurückgibt. Schlimmer noch, wenn Sie viele Threads desselben Jobs ausführen, kann ein zeit- oder zählungsbedingter Fehler eine sehr große Anzahl von Aufgaben gleichzeitig betreffen und insgesamt zu einem 3-Uhr-Trip ins Büro führen.

In einer Umgebung, in der Sie viele der gleichen Threads ausführen (z. B. auf einem Webserver), besteht die praktische Lösung darin, einen gemischten Ansatz zu wählen, der zu einer akzeptablen Fehlerrate führt. Wenn Sie 100 Threads ausführen, bedeutet das Ausführen eines Short-to-Long-Verhältnisses von 99: 1, dass nur einer langfristige Fehler aufweist, während die anderen weiterhin das tun, was sie tun, ohne zu scheitern. Im Gegensatz dazu besteht bei einer Laufzeit von 100% ein viel höheres Risiko, dass alle Threads gleichzeitig ausfallen.

Wenn Sie einen einzelnen Thread haben, ist es wahrscheinlich besser, ihn einfach laufen zu lassen und fehlzuschlagen, da die Totzeit während eines Neustarts zu einer unerwünschten Latenz führen kann, wenn echte Arbeit zu erledigen ist, die erfolgreich abgeschlossen werden würde.

In beiden Fällen ist es wichtig, dass die Prozesse überwacht werden, damit sie sofort neu gestartet werden können. Es gibt auch kein Gesetz, das besagt, dass Ihre anfänglichen Entscheidungen darüber, wie lange ein Prozess ablaufen soll, in Stein gemeißelt werden müssen. Durch das Sammeln von Betriebsdaten können Sie Ihr System optimieren, um Ausfälle auf einem akzeptablen Niveau zu halten.

Ich würde davon abraten, eine zufällige Kündigung vorzunehmen, da dies die Ermittlung zeitbezogener Fehler erschwert. Chaos Monkey sorgt dafür, dass die Überwachungssoftware funktioniert, was ein etwas anderes Problem darstellt.

Meinst du wirklich zufällig? Es klingt schrecklich, wenn sich Ihre Software zufällig selbst umbringt. Welchem ​​Punkt würde das dienen?

Ich vermute, Sie meinen damit wirklich, dass wir bei lang laufenden Threads / Prozessen realistisch sein sollten und akzeptieren sollten, dass je länger sie laufen, desto wahrscheinlicher ist, dass sie auf eine Art versteckten Fehler gestoßen sind und in einen nicht funktionierenden Zustand geraten sind Zustand. Aus rein pragmatischen Gründen sollte die Lebensdauer von Prozessen und Threads begrenzt werden.

Ich glaube, dass der Apache-Webserver in den späten 90ern so etwas benutzte. Sie hatten einen Pool von Worker-Prozessen (keine Threads) und jeder Worker-Prozess wurde nach einer festgelegten Lebensdauer beendet. Dies verhinderte, dass der Server von Arbeitsprozessen monopolisiert wurde, die in einem pathologischen Zustand stecken geblieben waren.

Ich habe einige Zeit nicht in der Gegend gearbeitet, daher weiß ich nicht, ob dies immer noch der Fall ist.

Das Problem, das ich sehe, ist, dass wenn ein solches Programm abstirbt, wir einfach sagen: "Oh, es ist nur eine weitere zufällige Beendigung - kein Grund zur Sorge." Aber was ist, wenn es ein echtes Problem gibt, das behoben werden muss? Es wird ignoriert.

Programme, die bereits "zufällig" erstellt wurden, scheitern daran, dass Entwickler Rätsel machen, Fehler in Produktionssystemen auftreten, Hardwarefehler auftreten usw. Wenn dies auftritt, möchten wir dies wissen, damit wir es beheben können. Das Design von Programmen für den Tod erhöht nur die Wahrscheinlichkeit eines Scheiterns und würde uns nur dazu zwingen, die Redundanz zu erhöhen, was Geld kostet.

Ich sehe nichts falsches daran, Prozesse in einer Testumgebung zufällig zu beenden, wenn ich ein redundantes System teste (dies sollte mehr passieren als es ist), aber nicht in einer Produktionsumgebung. Würden wir alle paar Tage ein paar Festplatten aus einem Live-Produktionssystem entfernen oder einen der Computer in einem Flugzeug deaktivieren, da es voller Passagiere ist? In einem Testszenario - gut. In einem Live-Produktionsszenario möchte ich lieber nicht.

Das Hinzufügen eines zufälligen Beendigungscodes zur Anwendung sollte nicht erforderlich sein. Tester können Skripte schreiben, die die Prozesse der Anwendung zufällig beenden.

Beim Networking muss ein unzuverlässiges Netzwerk simuliert werden, um eine Protokollimplementierung zu testen. Dies wird nicht in das Protokoll integriert. Es kann auf Gerätetreiberebene oder mit externer Hardware simuliert werden.

Fügen Sie keinen Testcode hinzu. Führen Sie das Programm für Situationen aus, die extern erreicht werden können.

Wenn dies für die Produktion gedacht ist, kann ich nicht glauben, dass es ernst ist!

Erstens ist es keine ehrliche Umsetzung des Konzepts , wenn die Prozesse nicht abrupt beendet werden, sodass laufende Transaktionen und flüchtige Daten verloren gehen. Geplante, ordnungsgemäße Exits, auch wenn sie nach dem Zufallsprinzip ausgeführt werden, tragen nicht ausreichend dazu bei, die Architektur auf den Umgang mit echten, nicht ordnungsgemäßen Abstürzen vorzubereiten.

Wenn echte oder realistische Fehlfunktionen in die Anwendung eingebaut werden, können sie ebenso wie echte Fehlfunktionen zu einem wirtschaftlichen Schaden führen , und ein gezielter wirtschaftlicher Schaden ist im Grunde genommen per definitionem eine Straftat .

Möglicherweise können Sie Klauseln in der Lizenzvereinbarung umgehen, die die zivilrechtliche Haftung für Schäden aus dem Betrieb der Software aufheben. Wenn diese Schäden jedoch beabsichtigt sind, können Sie möglicherweise nicht auf die strafrechtliche Haftung verzichten.

Denken Sie nicht einmal an solche Stunts: Machen Sie es so zuverlässig wie möglich und fügen Sie gefälschte Fehlerszenarien nur in spezielle Builds oder Konfigurationen ein.

Möglicherweise möchten Sie im Kontext fehlertoleranter verteilter Systeme nach " proaktiver Wiederherstellung " und " Verjüngung " suchen , um willkürliche Fehler zu beheben (dh nicht nur abgestürzte Prozesse, sondern auch beschädigte Daten und potenziell böswilliges Verhalten). Es wurde viel nachgeforscht, wie oft und unter welchen Bedingungen ein Prozess (im abstrakten Sinne kann es sich tatsächlich um eine VM oder einen Host handeln) neu gestartet werden soll. Intuitiv können Sie die Vorteile des Ansatzes dahingehend verstehen, dass Sie es vorziehen, mit einem toten Prozess als mit einem Verräterprozess umzugehen ...

Das ist wirklich nichts anderes als testen. Wenn Sie eine jederzeit verfügbare Failover-Lösung (wie Netflix) entwerfen, sollten Sie sie testen. Ich weiß jedoch nicht, ob zufällige Exits, die über die gesamte Codebasis verteilt sind, eine geeignete Möglichkeit sind, dies zu testen. Wenn Sie nicht wirklich testen möchten, ob Ihr Design widerstandsfähig ist, um sich selbst in den Fuß zu schießen, ist es angemessener, es zu testen, indem Sie die Umgebung um den Code herum manipulieren und überprüfen, ob es sich ordnungsgemäß verhält.

Wenn Sie keine redundanten Systeme entwerfen, sollten Sie diese Funktion nicht hinzufügen, da Sie einige zufällige Exits hinzugefügt haben. Sie sollten nur die zufälligen Ausgänge entfernen, und dann werden Sie dieses Problem nicht haben. Möglicherweise fällt Ihre Umgebung immer noch aus. Zu diesem Zeitpunkt werden Sie den Code entweder als nicht unterstützt / nicht repariert kennzeichnen oder ihn gegen diesen Fehler absichern und einen Test hinzufügen. Tun Sie das oft genug, und Sie werden feststellen , dass Sie tatsächlich sind ein redundantes System entwerfen - siehe Szenario # 1.

Irgendwann stellen Sie möglicherweise fest, dass Sie nicht mehr sicher sind, welche Fehler behandelt werden oder nicht. Jetzt können Sie den Teppich nach dem Zufallsprinzip herausziehen, um die Fehlerstellen zu erkennen.

Das einzig interessante am Netflix-Beispiel ist, dass diese Tests in der Produktion durchgeführt werden. Das ist in gewisser Weise sinnvoll - einige Bugs sind in Wirklichkeit reine Produktionssachen, die in einer isolierten Umgebung nur sehr schwer oder gar nicht zu simulieren sind. Ich vermute, dass Netflix eine lange Zeit in Testumgebungen verbracht hat, bevor sie dies in der Produktion tun konnten. Und alles, was sie tun, ist zu versuchen, Abstürze während der Geschäftszeiten zu verursachen, was für ihren Markt einen gewissen Sinn ergibt, für viele andere aber nicht.

Der Begriff, den Sie suchen, wurde kürzlich von Nassim Nicholas Taleb geprägt: Antifragility. Sein Buch Antifragile ist auf jeden Fall zu empfehlen. IT wird kaum erwähnt, aber die unausgesprochenen, offensichtlichen Parallelen sind am inspirierendsten. Seine Idee ist es, die Skala von fragilem <-> robustem <-> robustem <-> Antifragilem zu erweitern. Fragile Pausen mit zufälligen Ereignissen, robustes Management mit zufälligen Ereignissen und anti-fragile Gewinne mit zufälligen Ereignissen.

Es hängt davon ab, ob. Ich habe bemerkt, dass Programmierer dazu neigen, die Techniken, die auf ihre spezifische Domäne zutreffen, zu übermäßig zu verallgemeinern, wobei sie alle anderen ignorieren. Zum Beispiel kann es sinnvoll sein, ein Programm auf Kosten der Behebung aller Fehler freizugeben ... es sei denn, Sie programmieren Fluglotsen, Kernreaktoren usw. "Nicht optimieren - die Kosten für Programmierer sind höher als die Kosten für die Programmausführung" sind nicht erforderlich Gültig für HPC, da dort ein relativ einfaches Programm monatelang Cluster belegen kann usw. (oder sogar ein beliebtes Programm, das von einer großen Anzahl von Benutzern verwendet wird). Selbst wenn die Firma X Y aus einem sehr guten Grund tut, müssen Sie nicht unbedingt ihren Schritten folgen, da Ihre Situation möglicherweise anders ist.

Normalerweise sind die Fehlerbehandlungsroutinen der schlechteste Teil des Codes - obwohl es einfach zu sein scheint, ist es schwierig zu simulieren, dass nicht genügend Arbeitsspeicher vorhanden ist oder dass eine wichtige Datei nicht vorhanden ist. Aus diesem Grund lese ich Texte, in denen vorgeschlagen wird, dass der Unix-Kernel einige Systemaufrufe nach dem Zufallsprinzip abbricht. Es würde jedoch das Schreiben einfacher Programme erschweren (wenn ich 3 C ++ - Bibliotheken zusammenstecken müsste, um ein Programm mit 2 Dateien auszuführen, wenn ich mich nicht um die Fehlerbehandlung kümmern möchte). Auch mit Ausnahme von GC müssen Sie sicherstellen, dass Sie den konsistenten Zustand hinter sich gelassen haben (stellen Sie sich eine Ausnahme vor, während Sie einen Knoten zu einer verknüpften Liste hinzufügen).

Je mehr verteilte Dienste Sie haben, desto häufiger stellt sich die Frage nach dem "Wie häufig" und dem "Wenn" oder "Wann". In Rechenzentren gehört das Ersetzen von Festplatten in RAIDs meines Wissens zur Routine - keine unerwarteten Ausfälle. Wenn Sie in großem Maßstab arbeiten, müssen Sie dies berücksichtigen, denn selbst wenn die Wahrscheinlichkeit eines Ausfalls einer Komponente gering ist, besteht die Möglichkeit, dass etwas ausfällt.

Ich weiß nicht genau, was Sie tun, aber um zu wissen, ob es sich lohnt, müssen Sie überlegen, ob Sie Fehler berücksichtigen müssen (wenn Sie sie ignorieren) oder ob die Analyse zu kostspielig ist (wenn Sie Fehler in Kauf nehmen) Entwicklungszeit berücksichtigen).

Der IIS-Server verfügt über eine konfigurierbare Funktion, mit der Arbeitsprozesse automatisch wiederverwendet werden, nachdem sie eine bestimmte Menge an Arbeitsspeicher verbraucht oder eine bestimmte Anzahl von Anforderungen bearbeitet haben oder eine bestimmte Zeit lang am Leben waren. ( http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx ) und ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx? Mfr = true )

Wenn ein CONTAINER wie IIS dies tut, ist es sinnvoll, den Server vor unerwünschten Prozessen zu schützen. Ich würde es jedoch vorziehen, dies deaktiviert zu lassen, da es keinen Sinn ergibt, wenn Sie Ihren Code ausreichend getestet haben.

Wir arbeiten bereits an unzuverlässigen Schichten (Hardware, Netzwerk), daher würde ich niemals Code schreiben, der seine Threads oder Prozesse absichtlich zufällig abbricht. Zufälliges Töten ist auch aus wirtschaftlicher Sicht eine schlechte Idee - niemand würde meine API verwenden, wenn er annehmen würde, dass ich sie so programmiert habe, dass sie zufällig abstürzt. Wenn ich eine API verbrauchen oder ein System mit zufällig abstürzenden Threads verwenden würde, müsste ich eine Menge Geld ausgeben, um einen Überwachungsmechanismus zu schaffen, der robust genug ist, damit ich nachts ruhig schlafen kann.

Stattdessen, wenn ich ein System oder eine API entwickeln würde, würde ich Skripte schreiben oder ein Geschirr verwenden, das dies nur tun würde, um die Belastbarkeit des Systems zu testen. Und ich würde einen solchen Testlauf für alle Builds durchführen, um fehlerhafte Builds zu identifizieren. Obwohl dies ein notwendiger Test wäre, könnte es niemals ein "ausreichender" Test sein.

Es gibt eine Literatur zu dieser Idee, die sich Crash-Only-Software (auch Recovery Oriented Computing) nennt, und Sie können mit diesem Usenix-Papier von Candea & Fox aus dem Jahr 2003 beginnen Halten Sie Ihre Programme immer an, indem Sie sie beenden, sodass Sie einen einzigen Kill-Schalter als Abschaltknopf und einen einzigen, gut trainierten Startpfad für die Wiederherstellung haben.

Ich bin mir nicht sicher, wie gut die Idee angekommen ist, aber einige der spezifischen Techniken bleiben nützlich. Sie können beispielsweise nicht darauf vertrauen, dass sich Ihre Software bei Aufforderung selbst herunterfährt, und verwenden dazu spezielle Überwachungsprogramme (z. B. Supervisord usw.). Überlegen Sie außerdem sorgfältig, welcher Programmstatus von wesentlicher Bedeutung ist, und stellen Sie sicher, dass er zu geeigneten Zeiten in einem Datenspeicher gespeichert wird um die Wiederherstellung zu ermöglichen (zB eine SQL-Datenbank).

Wirklich zufällig, nein. Es ist jedoch wahrscheinlich eine gute Idee, Prozesse / Threads mit langer Laufzeit in einem bestimmten Intervall zu beenden / neu zu starten, oder nachdem sie für eine bestimmte (aber von bestimmten Kriterien abhängige) Dauer inaktiv waren oder eine bestimmte Art von Task ausgeführt haben. Langfristig laufende Prozesse bauen unweigerlich einen Zustand auf, der veraltete Dinge einschließt. Vermutlich bleibt der Speicher erhalten und verhindert, dass Auslagerungsspeicher freigegeben werden, der beim Beenden bereinigt wird (oder werden sollte), wodurch die allgemeine Systemstabilität verbessert wird.

Dies hängt von der Art der Anwendung ab, die Sie entwerfen.

Zufällige Abstürze sind eine hervorragende Möglichkeit, die Robustheit verteilter (vernetzter) Systeme zu testen und zu verbessern.

Im Netflix-Beispiel, wenn Ihr Programm von Remotediensten abhängt, die aus verschiedenen Gründen, die Sie nicht kontrollieren können, ausfallen (Festplatte geht kaputt, Stromausfall, Meteorabstürze im Rechenzentrum usw.). Ihr Dienst muss trotzdem weiterlaufen.

Wie machst du das? Hinzufügen von Redundanz und Skalierung ist eine häufige Lösung.

Wenn zum Beispiel eine Maus durch das Stromkabel Ihres Servers kaut, sollte Ihr Dienst eine Lösung haben, um weiterlaufen zu können. Es kann zum Beispiel redundante Backup-Server behalten, die es stattdessen verwendet.

Wenn es sich bei Ihrem Programm jedoch um eine Einzelprozessanwendung handelt, die nicht in einem Netzwerk ausgeführt wird, kann das Beenden des Programms nichts testen, da es keine Möglichkeit gibt, sich davon zu erholen.

Hier ist ein zusätzlicher Kommentar zum Chaos Monkeys-Konzept: http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

Es ist möglich, dass aufgrund der kosmischen Strahlung ein zufälliger Bitwechsel auftritt . Dieses Problem wurde erkannt und verschiedene Techniken wurden entwickelt, um das Auftreten von Bitflips zu verhindern.

Es ist jedoch nicht möglich, das Problem zu 100% zu beheben, und eine Speicherbeschädigung kann immer noch Probleme verursachen, und diese Probleme treten immer noch auf ( mit sehr geringer Wahrscheinlichkeit ).

Nun zur Beantwortung Ihrer Frage. Ob Sie ein sehr robustes System entwerfen müssen oder nicht, hängt davon ab, was Sie tun. Wenn Sie ein Raumschiff erstellen müssen, machen Sie es besser super robust, und dann müssen Sie jedes mögliche Problem berücksichtigen.

Wenn Sie eine normale Desktop-Anwendung entwerfen müssen, sollten Sie zufällige Abstürze als Fehler in Ihrem Code betrachten.

Das scheint keine absurde Idee zu sein.

Android OS beendet und startet Benutzer-Apps / -Dienste ständig nach dem Zufallsprinzip. Nach meiner Erfahrung hat es mir auf jeden Fall geholfen, tiefer über Fehlerbedingungen nachzudenken und robustere Architekturen zu entwerfen.