我一直在网上搜索并询问我的联系人，但除了一些意见之外，我没有找到任何数字、矩阵或公式来指导何时添加另一个 DBA。
对此有任何行业标准吗？这可能是一个难题，因为每种情况都不同。有些 DBA 管理着数百个生产实例，但这些实例都是相同的。有些 DBA 管理着很少的实例，但也承担着开发和网络管理的职责。我们都知道，DBA 的职业道路很广阔。
一位微软现场工程师曾经告诉我，神奇的数字是 30，即支持 30 个应用程序。有些应用程序很简单，有些则不那么简单，但如果您有多种应用程序，这位同事说，一旦达到 30 个，就该至少考虑聘请另一位 DBA 了。
显然，我正在寻找理由来证明我公司最近要求另一位 DBA 的请求。任何帮助都非常感谢。虽然我的目标是 SQL Server DBA，但那只是因为我管理的就是这些。
答案1
也许，与其考虑支持的应用程序数量，不如考虑 SLA（无论是正式的还是非正式的）。考虑支持不足的成本——无论是由于工作量还是由于 DBA 休假或生病等原因导致某些东西离线。
当你没有足够的人手来满足你的 SLA/目标/用户期望/任何其他指标时，你就该开始招聘了。当数据库离线一周的成本（因为唯一一个知道如何修复问题的人正在休假）时，你就该开始招聘了。
根据您的编辑，我认为您肯定需要聘请某种帮手。我知道您可以自动化很多日常管理工作，我们所有人都这样做，但听起来您有很多事情要做，无论如何。
答案2
我认为这是一个很难定义的问题。既然你提到你没有制定真正的 SLA，那么唯一真正定义工作量的方法就是你所说的。你不能休假，否则必须被叫去处理问题，这肯定是一个问题。
如果您很难说服经理聘请新的 DBA，您是否可以寻求内部帮助？这可能是将某人从较低的职位提拔上来或帮助与您一起工作的对数据库感兴趣的人进入该领域的好方法。即使只是兼职，您也可以培训他们处理一些较小的事情，这样您就不必每天担心了。这样，如果您需要休假一周，他们只需要在出现重大问题时给您打电话。
我认为，如果没有 SLA 系统，无论如何你都会遇到问题，因为你很难证明需要更多人力来完成一项你已做了 2 年的工作。当然，你知道需要做多少工作，但如果没有文档和 SLA 来跟踪事情的变化，那么销售就会很困难。
答案3
昨天。
（最小发布大小会抑制简洁的智慧。）
（即使这会遭到反对，我仍然认为它很有趣。今天是星期五。）
/编辑 - 一个更严肃的答案。对于熟练的技术人员来说，从 quanta=1 到 quanta=2 的转变确实很难证明是合理的。您可以做以下几件事：
记录你的时间。使用它来显示你花费了多少时间，当人们提出新的任务或职责或应用程序时，估计所需的时间并说“我目前做的哪些事情，这个新事物需要我停止、自动化或雇佣人员来处理？”
寻找可以做零星兼职工作的合同服务。聘请他们帮助您审查和记录您的程序、应用程序和基础设施，然后在您休假时再次聘请他们为您值班。这样他们就了解您的系统，而不是最终让他们到现场并打电话给您。
培训现有的非 DBA IT 员工，使他们能够胜任轻型或紧急分类工作。前提是您的公司规模足够大，可以拥有其他 IT 员工，特别是拥有具有正确态度、技能和勤奋精神的人员来正确履行职责。