We just discussed the use of positive controls in hypothesis driven troubleshooting. Next, we need to talk about their opposite, negative controls. Where a positive control is something that we expect to produce a result, a negative control should produce either no result or a negative result. For instance, you might expect a certain IP to not respond to ICMP, or to receive permission denied when using the wrong password.

Negative controls can be used as part of the baseline, just as positive controls are. Before you implement a service, the client should get no response from the service. Disabled or inactive members should also provide no response. Attempting to access the service on something that isn’t hosting the service at all should certainly provide no response. An invalid password generates an invalid password error. Instead of assuming everything behaves the way you expect, test each assumption and classify it properly as a negative or positive control.

A negative control can also be used to ensure that troubleshooting goes according to plan and individual steps do not have inadvertent side effects. A firewall rule to allow access to a set of networks and ports should not allow access to other ports, and a negative control that continues to work ensures that this is the case before and after the change. If you aren’t sure of the effect of something, the combination of negative and positive controls can help you determine that effect.

One thing to note: Where positive controls are helpful in their own right, negative controls almost always require additional positive controls to be useful in troubleshooting. If something is not responding and continues to not respond, that information on its own rarely moves the diagnosis or recovery forward.

You now have the tools to build two sets of experiments, before any change occurs and after a change is made, to test your hypothesis and carry on effective troubleshooting. I hope this helps!