In a well configured environment, "history" isn't going to be terribly useful -- admins should be using their own accounts and using sudo to execute commands as root.
In this sort of environment you want to look at your pam logs (/var/log/auth.log on debian-like distros, and iirc, /var/log/secure on RH-like). This gives you not only a list of what was run, but who ran it and when.
A reboot is the last thing you should be doing on a problematic box. A reboot should only be attempted if you're 100% sure that the problem can actually be solved by a reboot (for example in extreme cases a buggy kernel module might require a reboot, but even that's a very rare occurrence).
I've seen inexperienced sysadmins remotely rebooting a server only to discover that it won't boot up anymore because the original problem was that the server had run out of disk space.
That's a valid point; mention that one should not reboot until proven otherwise.
Same idea for services restart; don't do it unless absolutely needed. While it may be doing the trick in some cases it can also generate its own set of new false symptoms.
Take the example of :
- mysql is "slow"
- let's restart ! ...
- mysql init script has been puking dots (.) for the last 30 minutes on shutdown
