This is the "I don't know how my network works, so let's throw a wrench into the works and see what happens, fix it, rinse, repeat" form of network and systems engineering. It's certainly useful at various points in tuning performance, but it doesn't replace actually designing your system to resist these problems to begin with.<p>Even if you introduce these network performance issues, the results are meaningless if you don't have instrumentation ready to capture metrics on the results throughout the network/systems. Everyone wants to write about what happened when they partitioned their network. But you notice how nobody writes about the netflows, the taps, the service monitors, the interface stats, the app performance stats, the query run times, host connection state stats, miscellaneous network error stats, transaction benchmark stats, and hundreds of other data sources that are required to analyze the resulting network congestion.<p>To me it's much more vital that I can correlate events to track down an issue in real-time. You will never be able to identify all possible failure types by making random things fail, but you can improve the process by which you identify a random problem and fix it quickly.