Netzwerk-Chaos-Tests unter Windows
Chaos-Testing bedeutet, absichtlich etwas kaputtzumachen, während du zusiehst, um herauszufinden, was deine Software dagegen tut. Auf der Netzwerkebene ist genau das dieses Tool: eine Möglichkeit, einen Fehler in eine Anwendung einzuspeisen und zu sehen, ob sie überlebt.
Die Fehler, die du einspeisen kannst
| Fehler | Was er nachbildet |
|---|---|
| Verlust, Beschädigung, Duplizierung | Ein verschlechterter Pfad. Pakete verschwinden, kommen beschädigt an oder kommen doppelt an. |
| Latenz, Jitter, Spitzen | Ein langsamer oder instabiler Pfad, einschließlich des mehrsekündigen Aussetzers, der Timeouts bricht. |
| Verbindungs-Resets | Eine Firewall oder ein Load Balancer, der Verbindungen mitten in der Übertragung beendet. |
| Verbindungsausfälle | Der Pfad verschwindet und kommt in einem Zyklus wieder. |
| Gesperrte Adresse oder gesperrter Port | Eine Abhängigkeit ist unerreichbar, während alles andere funktioniert. |
| Internet weg, LAN am Leben | Die Form des Captive Portals: Lokal geht es, die Welt nicht. |
Was Chaos von Rauschen unterscheidet: Wiederholbarkeit
Ein zufälliger Fehler, der sich nicht wiederholen lässt, liefert eine Geschichte statt eines Fehlerberichts. Jede Zufallsentscheidung hier stammt aus einem Seed, sodass derselbe Befehl denselben Durchlauf reproduziert: dieselben verlorenen Pakete, derselbe Jitter, in derselben Reihenfolge:
BeanNetworkTester.exe --loss 15 --rst-prob 5 --seed 42 --target myapp.exe --duration 120
Das ist der Unterschied zwischen „es ist letzten Dienstag einmal umgefallen“ und einem fehlschlagenden Test, den jemand anderes ausführen kann.
In einer Pipeline
Die Befehlszeile meldet über Exit-Codes, sodass ein Build „die Anwendung ist fehlgeschlagen“ von „das Tool konnte nicht starten“ unterscheiden kann, und die Sitzung endet von selbst: Es gibt keinen Aufräumschritt, den man vergessen könnte:
BeanNetworkTester.exe --loss 10 --rst-prob 5 --target myapp.exe --duration 90 --format json > chaos.ndjson
Eine Folge von Fehlern statt eines einzelnen ist eine Szenario-Datei, und auch diese sind wiederholbar. Siehe Szenarien über die Zeit und Netzwerktests in CI für die Exit-Codes und den Runner, den es braucht.
Wo der Wirkungsradius endet
Zwei Grenzen, beide gewollt. Die Störung erreicht einen Prozess, eine PID, eine Adresse oder einen Port, wenn du sie darauf richtest, sodass der Rechner, an dem du arbeitest, weiter funktioniert. Und es ist ein einzelner Rechner: Das ist Fehlerinjektion für einen Client und seine Verbindung, nicht für einen Cluster. Suchst du Chaos über Dienste und Knoten hinweg, ist das eine andere Art von Werkzeug, und dieses hier ist das Stück, das das Netzwerk unter einer einzelnen Windows-Anwendung kaputtmacht.
Alles ist auf der Stelle umkehrbar. STOP stellt das Netzwerk wieder her, ein Zeitlimit tut dasselbe, und ein Watchdog im Tool beendet die Erfassung, falls das Tool selbst stirbt: Ein Fehler, den du eingespeist hast, darf den Durchlauf, der ihn eingespeist hat, nie überleben.