up vote 6 down vote favorite
1
share [g+] share [fb]

Been searching the web and asking my contacts, but other than some opinions, I'm not finding any kind of numbers nor matrix nor formula to guide on when it's time to add another DBA.

Are there any industry standards for this? Probably a tough question, as every situation is different. Some DBAs manage a farm of hundreds of production instances, but the instances are all identical. Some DBAs manage a very few instances, but also have development and network admin duties. We all know that the DBA career path has breadth.

A Microsoft field engineer once told me that the magic number is 30, as in, 30 applications supported. Some apps are simple, some less so, but if you've got a mix of apps, the fellow said, once you're at 30 it's time to at least consider hiring another DBA.

Obviously I'm looking to justify a recent request for another DBA at my company. Any help is much appreciated. Although I've targeted this for SQL Server DBAs, that's only because that's all I've administrated.

link|improve this question
In case I'm being a wimp, here's the load I have right now. When I was hired into this company of 800 folks, half of my time was to be spent administrating SQL Server. I inherited, in production, the following: 3 servers, maybe 15 applications, about 70 databases, and around 120 GB of data to backup. Now, two years later, I’ve gone from 3 production servers to 19 (with 17 in one HA mode or another); from supporting 15 vendor and in-house applications to about 45; from looking after 70+ databases to 481 databases; from backing up 120 GB to backing up 1.2 TB. Every system is different. – Oliver Jun 18 '10 at 19:06
I know your question is couched in general terms, but it might be easier for us to answer "when is it time for Oliver to hire another DBA?" Can you throw some specifics in here? Your company size, your application portfolio, any other duties that you cover, what your average week is like, and what other IT staff your company has? More ideas in my answer below. – mfinni Jun 18 '10 at 19:07
Haha - good timing. Yeah, it's definitely time to hire a contractor. They can help you standardize and perhaps automate, which will ideally 1. decrease your workload and 2. make it easier to scale and 3. make it easier to hire/contract someone to help when you do need it. – mfinni Jun 18 '10 at 19:09
feedback

3 Answers

up vote 5 down vote accepted

Perhaps rather than number of apps supported, consider SLAs (whether formal or informal). Consider the costs of inadequate support - whether due to workload or something going offline while the one DBA is on holiday or sick or whatever.

When you have an inadequate amount of people to meet your SLAs / targets / user expectations / whatever other metric, then it is time to start recruiting. When the cost of a DB being offline for a week 'cos the one person who knows enough to fix things is on holiday, then it is also time to start recruiting.

Based on your edit, I'd say its definitely time for you to hire a helper of some kind. I know you can automate a lot of day to day admin, that's what we all do, but it sounds like you have a lot going on however its sliced.

link|improve this answer
1  
yeah, that's been an issue for me .. in the two years I've been here, not once have I been able to take a vacation without being called to support something ..not sure how I would do SLAs .. it's all in-house, and the organization isn't yet large enough for that kind of formality .. liking your point, just not sure that's an approach that will work in my situation – Oliver Jun 18 '10 at 17:30
2  
Being able to take a vacation is a great reason to hire another DBA. Think of it this way, if you were to be hit by a bus what would happen to the company? Even with the best documentation there would probably have a month or two of serious downtime to get another DBA up to speed. Better to have a "hot standby" instead of a single point of failure. – Greg Bray Jun 18 '10 at 17:39
@oliver, I know what you mean, SLAs can seem like just so much paperwork in the wrong organisation, but you can still talk about expectations and needs and the cost of not being able to meet those, without going to the formal levels of SLAs for everything. – DJ Pon3 Jun 18 '10 at 21:24
feedback
up vote 3 down vote

I think it's something that is tough to define. Since you've mentioned that you have no real SLAs in place the only real way to define what kind of workload exists is by what you say. The fact that you can't take vacations without having to be called in to handle a problem is a definite problem.

If you're having a lot of trouble convincing your managers to hire a new DBA could you possibly look in house for some help? It can be a great way to bring someone up from a lower position or help somebody you work with that shares an interest in databases get into the field. Even on just a part time basis you could train them to handle some of the smaller things so you have less to worry about on a daily basis. This way if you need to take off for a week they would only need to call you if something major went wrong.

I think without an SLA system you're going to have problems no matter what since it will be difficult for you to justify needing more manpower for a job that you've been doing for 2 years just fine. Sure you see how much more work is required of you but without documentation and SLAs to track how things have changed it can be a tough sell.

link|improve this answer
even if I had SLAs, how does that tell me how much work a given DBA can handle? not trying to be smart, just pointing out that SLAs are agreements between departments .. the IT department still needs to know how much work a single DBA can handle – Oliver Jun 18 '10 at 18:45
1  
It's not really that it can point out how much you can handle but more that you could say "I can't meet these SLAs due to these reasons...". At which point you provide documented proof that your workload has been increasing and it's becoming more difficult to meet your agreements. The SLAs aren't really the gauge on the amount of work you can handle but they do show you how much work needs to get done. If you're no longer able to meet those agreements at a reasonable level (ex. you can't leave the office without having to be called about something) you may have a case for a new hire. – Sean Howat Jun 18 '10 at 19:15
+1 for the point about vacations - if you can't get a break without being disturbed this is bad for you and the company. It's a quite literally unhealthy habit to get into which will catch up with everyone sooner or later. – DJ Pon3 Jun 18 '10 at 21:26
feedback
up vote 2 down vote

Yesterday.

(minimum posting size inhibits pithy wit.)

(even if this earns a downvote, I thought it was funny. It's Friday.)

/Edit - a more serious answer. It's really hard to justify the jump from quanta=1 to quanta=2 for skilled tech staff. You can do a few things:

  1. Document your time. Use this to show how much time you spend, and when people propose new tasks or duties or applications, estimate the time required and say "which of the things, that i do currently, will this new thing require me to stop, automate, or hire to cover?"

  2. Look into a contract service that can do sporadic part-time work. Engage them to help you review and document your procedures, apps, and infrastructure, and then contract them again when you go on vacation to be your on-call. This way they know your systems, rather than end up with them being on-site and calling you anyway.

  3. Train existing non-DBA IT staff to be able to do light-duty or emergency triage work. This is assuming your company is big enough to have other IT staff, and specifically have someone with the right attitude, skills, and diligence to perform properly.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.