3. Document, document, document
Of all these rules, this one may be the least followed. To be sure, documenting a problem and a resolution when you're in the middle of a chaotic situation may not be practical. That said, always hold a postmortem on the problem when the dust settles and go over the steps taken and the path to the solution. Write it down. Keep it safe somewhere, preferably on a wiki hosted on your intranet -- and backed up to several other places.
4. There's no magic in IT, but there is luck
As Thomas Jefferson said, "I find that the harder I work, the more luck I seem to have." The same is true in IT. The more time you spend researching aspects of your infrastructure, noting certain operating conditions of routers, switches, servers, and whatnot, the more in tune with your infrastructure you become. That homework allows you to sniff out problems in their very early stages and to move far quicker when the game's afoot. Also, there are plenty of ways to manufacture luck in IT. For example, use tools that automate network device configuration backups; that way, when a switch loses its mind, you can have it back up in minutes, not hours.
5. Make a backup of every configuration file before you modify it
This rule tends to apply only to Unix servers and network devices where configuration files exist for nearly all aspects of the device configuration. Before you go mucking around with sensitive configurations, save a copy to flash on a switch and maybe one to a TFTP host. On Unix systems, simply cp something.conf to something.conf.orig.
In a pinch, reverting to prior known-good status is as simple as copying the file back and restarting the service. This generally isn't possible on Windows, due to the registry and Windows' proclivity to complicate simple concepts. Even so, you can sometimes export a portion of the registry before messing with it so that it can be reapplied if all hell breaks loose. Note: As with all matters regarding the Windows registry, you take the life of the server in your hands when you make changes.
6. Monitor, monitor, monitor
An ounce of prevention is worth a month of work weekends. You should monitor every aspect of your data center, beginning with the temperatures of the room, the racks, and the servers -- plus, server process checks, uptime checks, ad infinitum. You should also implement centralized syslogging of all network devices, as well as set up trending and graphing tools to monitor bandwidth utilization, temperatures, disk partition use, and other datapoints. All of these monitors should alert you by any means necessary when they exceed reasonable thresholds.
When a database gets corrupted because a partition filled up, an email or SMS an hour before would have saved untold hours of work and downtime. There's no reason to put off monitoring your data center to the hilt.
These aren't just rules to follow -- they're rules that should be ingrained in your daily IT life. They're core concepts to many in the IT field, but to others, they're mythical -- kinda like ninjas.