Support 24×7 – What Saves You?
It’s 3:00 A.M. Your phone rings. You take the call and it turns out the system you are supporting is having issues all over the place and production is down. You pull out your laptop, turn it on and cringe at the bright light that suddenly appears. You try to get your brain moving towards actually coming up with a resolution, but don’t even know where to start. Here are a few very simple tips and tricks that can save you (and your customer) with troubleshooting support requests.
Turn it Off and On Again
“Turning things off and on again” is a concept that computer geeks joke about quite often. There is, however, something magical about resetting everything back to a clean starting point. It’s not always about literally cycling power to a device – it’s more about the concept. Most of the support calls that we have ever gotten have been resolved by stopping the system that includes what’s broken, making sure all of the components (data points, etc.) line up correctly and then restarting the process, whatever it may be. This is especially useful if the system falls into a funky state and cannot automatically get itself back to a good state.
Debugging Tools
Many development environments include tools to help you troubleshoot problematic custom code. Depending on how complex of a debugger the software includes, you may be able to pause the code’s run-time execution and view live values of tags or variables. This allows you to step through each line of code and view in real time exactly what the code does and where it’s breaking. If you have debugging tools at your disposal, your troubleshooting experience will most likely be significantly less painful. Perhaps this is something to keep in mind when choosing a development environment to utilize on your next project!
Log Files
If a code debugging tool is not available, log files might just be the key to restoring balance to the delicate ecosystem that is software troubleshooting. Log files allow you to potentially see a problem that has already happened in the past. Imagine supporting a system without log files. You would have to watch the system 24/7 without looking away in order to see the issue happen. I don’t know about you, but I have much more important things to do—like watch some paint dry and the grass grow. You can use your code to log important values or messages relating to an incident in order to figure out what went wrong the next time it happens. Using these values, you could trace through the code and figure out what the code would do with those values.
What other tips and tricks do you have for troubleshooting software issues? What has saved you on those late-night calls?