when is it time to hire another SQL Server DBA?
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.
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.
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.
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:
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?"
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.
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.