There are a number of things that a member of IT should adhere to, and I will openly state that I am slightly guilty of this particular rant today: Providing clear documentation on changes to a system.
This site, the server it is on, was reverted today due to a problem from a third-third party support team. 1&1 is my current host, but the Plesk Panel (made by the Parallels company, the same folks who do the virtualization alternative geared to the Mac OS) had a problem.
Specifically, Plesk has the ability to install software directly on the system, automatically with the variables you feed it (username, password, directory, subdomain, etc…), and bring it up with the database table ready to use. On-demand/JIT installs. Useful, similar to Fantastico/Softalicous, but baked directly into the control panel. That was broken, reporting that there was no command line interpreter, which is apparently a common issue that the solution will not be divulged to the public.
1&1 had to go to the Parallels support team to have this resolved. Oh, and they did resolve it. Apparently, I should have my main site PHP handler set to using FastCGI instead of the Apache module. How does that make sense? Really, it doesn’t, as most bash commands are common between different *nix OS’s, and if it’s trying to initiate a command via PHP, it should be able to, no matter the handler (see phpShell, a web based bash command tool).
Now, the problem was resolved. All good, yes? Nope.
The Parallels person deleted the MySQL database for this site, the main site. Somehow in all their tests and fixes, they installed WordPress five or more (5+) times. And in cleaning some previous instances, deleted the database.
That brings me to my point. If you are going to work on a client’s system, website, or other gadgetry, and it’s not in front of them where they can see what you’re doing, tell them. Verbally, or in writing. In some of my own website projects, I’ve added into the core configuration document (the one that most new admins will take a look at to get a clue of what’s going on) what configuration changes I’ve made, warnings about potential breakage if code is changed, and some tips on extending the code.
It’s just good practice.