我一直在網上搜尋並詢問我的聯絡人，但除了一些意見之外，我沒有找到任何類型的數字、矩陣或公式來指導何時添加另一個 DBA。
有這方面的業界標準嗎？可能是一個棘手的問題，因為每種情況都不同。有些 DBA 管理著包含數百個生產實例的場，但這些實例都是相同的。一些 DBA 管理很少的實例，但也承擔開發和網路管理職責。我們都知道DBA的職業道路是廣闊的。
一位 Microsoft 現場工程師曾經告訴我，神奇的數字是 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 員工，特別是擁有正確態度、技能和勤奮的人員來正常工作。