One thing lots of DBA teams, esp. the DBA managers, feel uncomfortable is that it is difficult to quantify/log DBA’s workload and as such it is hard to argue to the upper management for more justified budget and human resources. In worst scenario, this will cause the burn-out and low morale to the whole team.

I have thought it for some time and believe this can be solved by creating a “DBA Work Accounting” system, which will record the DBA work load.

The DBA Work “Accounting” system mainly serves the following purposes: 

1. Human resource capacity planning for DBA team

2. Improve DBA team visibility inside the corporation

3. Quantify / archive DBA work history for auditing

A DBA work accounting system would be created based on the following assumptions:

1. Each piece of DBA work should have a “cost” associated and can be “debited” from the DBA “annual work budget”

2. An account book should be set up, with items such as “Refresh a database”,”install a new sql server instance”, “reset a user password”, “team meeting”, “project meeting”, etc

3. Each account item has a value factor (in average), say “Install a new sql server instance” will cost 5 work unit, while “reset a user password” is 0.5 unit, and each DBA’s normal daily workload is 40 work unit (i.e. one dba can build 40/5= 8 new sql server instances per day)

With these assumptions, here are some implementation design points:

1. Create a manual logging system to log DBA work, for example, I just need to run a sp like the following

Exec usp_LogDBAWork @work_item=’Refresh QA Environment’, @DBA_name=’jeffrey yao’, @task_number=’Task13421’  — assume you have company-wide ticketing system that will track each task, otherwise, we can get rid of this @task_number parameter. 

This usp_LogDBAWork will auto log the work and add an accounting entry, and debit the “annual work budget”

2. Create some auto logging mechanism, for example, when we need to create a user, add some permission for a user, this can auto captured by a “trigger” or something else and then auto update the “accounting book”.

3. For some very hard-to-predict tasks, such as performance tuning / R&D work, just log the work unit as it is using the manual logging system. But the history data will serve for future reference.

With such a system, it will be easy to check the workload of the DBA team, and see whether the “annual budget” can accommodate the real work load. Also with such data in hand, it will be easier to ask for a bigger budget next time if the current budget estimation is in the low ballpark.

Strictly speaking, this is really not an “accounting” system because the basic requirement in accounting requires double-entry for each transaction, i.e. whenever you debit one account, you need to credit another, but I did not mention this “credit entry” in the system design (I actually could but that deserves a long article for explanation). So from this perspective, the proposed system is just a “booking” system at best. However this system still serve one important function – quantifying the DBA work and logging it. It will facilitate lots of interesting statistics, such as what are the most frequent DBA tasks, what are the most time-consuming tasks, total # of tasks, who spends most time on what tasks etc.

So far, I have not seen any company implemented such a system, and I’d welcome to hear any stories if you do have a similar system. I also wish that a third-party vendor can come up with such a product, which I’d say is somewhat like a niche-market professional HR management system.