The DBA Code of Ethics - Draft 1
Introduction
I recently wandered upon a discussion on Slashdot about a sysadmin who planted a logic bomb in his former employer's system and tried to profit from it. While appalled at the story itself, the discussion inside Slashdot led me to a sysadmin Code of Ethics at the SAGE site (System Administrators Guild). I found this interesting reading and encourage everyone to spend a few minutes there.
I also thought there should be a similar code of Ethics for DBAs. Since I like to write and had a few minutes, I started one and welcome your comments. This is a draft and (hopefully) will evolve into a code that we can post on this site for everyone to use and adapt for their organizations.
The DBA Code of Ethics
A Database Administrator
Canon 1 - The DBA must protect the integrity of data
This is as basic as it gets. We are the guys that need to protect the data, a large part of which is ensuring the integrity of it. I know what we don't control the application and we certainly don't have any control over the users entering data, but we can make a difference. Through tight change controls and review, we can ensure that good quality code is placed on our servers. Especially for the insert/update/delete code, we can try to prevent integrity by ensuring that data is transactionally consistent. And we can insure that the proper versions or at least know what versions of code are on the server.
Through the use of strong Referential Integrity, we can prevent orphans and other data mismatches don't occur. Through regular maintenance we can prevent indexes and tables from getting corrupt.
Through education we can help developers and end users to understand the importance of having "good" data, data that is intact. We can help them to learn that enforcing good source data is vital to ensuring the database can do it's job.
Canon 2 - The DBA must ensure that the system is properly accessed by authorized users
To some extent, you could argue that this should be part of Canon 1, but I think it's important enough that calling it out helps. We have to ensure security in two senses to be sure we can fulfill this item.
The first thing we need to do is obvious. We must ensure that unauthorized users do not access our systems. This is accomplished by patching the server, using strong passwords, protecting those passwords and regularly changing them. Ensuring that externally exposed servers are hardened, etc. The basic security stuff that everyone seems to shoot for.
The second part of this canon, however, is the harder one to meet. The one that everyone complains about and generates the most questions that I see. We must ensure that access is proper. Kind of a funny word, but what I mean by this is that we need to be sure that people have access to only the data they are authorized to see. This equates (usually) to object type permissions though it could be row based if you have some type of system for this. And it also means read as well as change permissions. Allowing someone to read information they shouldn't might be more dangerous to your company than allowing them change access. Here we should not be allowing "as" to be used for access to a database, perhaps not even DBO. Again, it's an education battle, one I've fought many times with vendors in trying to show them that they do not need "as" or similar access for their application.
Canon 3 - The DBA should do everything possible to ensure the database is available when it is needed.
I struggled with this one quite a bit. I originally had something about uptime in here, but I realized that uptime isn't a good number. My database might be up, but if users cannot access it for some reason, security, network, etc., then is it really up? Even though these items might not be in my domain, they are usually something I can influence or at least facilitate the process of getting them changed for a user.
I also struggled with the timing. Should we shoot for 99% uptime? 99.99%? Having some goal like this doesn't seem quite right, at least to me. Instead I think we should be shooting for having the database available when it NEEDS to be and when it doesn't, to me those are downtimes that we should take to be proactive on the systems. At J.D. Edwards we had a scheduled Friday night downtime practically every week. We didn't always take the boxes down, but that was a good time to do work on the database, like an index rebuild since it was a point where the database did not need to be available (thank god we had this for v7 boxes) and if performance wasn't up to par, it wasn't a big deal.
Canon 4 - The DBA should continually be improving their databases..
This was another stretch. I started with the word "performance" in the statement, but decided it should be too limiting. Our job is to improve the database and although performance is important, it is only one aspect. Storage use, schema design, and probably a few other things are important and as a professional DBA, we should be improving the system over time. In some way.
This is not the final version, but the first draft of things that I think an administrative DBA should be adhering to. Please spend a few minutes and submit some feedback below so I can modify this into something of which we can all be proud to support.
Steve Jones
©dkRanch.net January 2004