ウェブで検索したり、連絡先に尋ねたりしましたが、いくつかの意見以外に、別の DBA を追加する時期を示す数値やマトリックス、数式は見つかりません。
これに関して業界標準はあるのでしょうか? 状況はそれぞれ異なるため、おそらく難しい質問でしょう。DBA の中には、数百の運用インスタンスのファームを管理している人もいますが、インスタンスはすべて同一です。また、ごく少数のインスタンスを管理しながら、開発とネットワーク管理の業務も担っている DBA もいます。DBA のキャリア パスが幅広いことは誰もが知っています。
マイクロソフトのフィールド エンジニアがかつて私に、魔法の数字は 30 だ、つまり 30 個のアプリケーションをサポートすることだ、と言ったことがあります。アプリケーションには単純なものもあれば、それほど単純でないものもありますが、複数のアプリケーションが混在している場合は、30 個に達した時点で、少なくとももう 1 人の DBA を雇うことを検討する時期だと、そのエンジニアは言いました。
明らかに、私は最近、会社で別の DBA を求める要求を正当化しようとしています。どんな助けでも大歓迎です。私はこれを SQL Server DBA 向けにターゲットにしていますが、それは私が管理してきたのがそれだけだからです。
答え1
おそらく、サポートされるアプリケーションの数よりも、SLA (公式または非公式) を検討してください。ワークロードが原因か、1 人の DBA が休暇中または病気などの理由でオフラインになっているかにかかわらず、サポートが不十分な場合のコストを検討してください。
SLA、目標、ユーザーの期待、その他の基準を満たすのに人員が不足している場合は、採用を開始する時期です。問題解決の十分な知識を持つ 1 人の担当者が休暇を取っているために、DB が 1 週間オフラインになるコストがかかる場合も、採用を開始する時期です。
あなたの編集内容から判断すると、間違いなく何らかのヘルパーを雇う時期だと思います。日常的な管理業務の多くを自動化できることはわかっていますし、それは私たち全員がやっていることですが、あなたはさまざまなことを抱えているようです。
答え2
これは定義するのが難しいことだと思います。実際の SLA は設定されていないとおっしゃっているので、どのような作業負荷が存在するかを定義する唯一の方法は、あなたが言うことです。問題に対処するために呼び出されずに休暇を取ることができないという事実は、間違いなく問題です。
マネージャーに新しい DBA を雇うよう説得するのに苦労しているなら、社内で助けを求めてみてはいかがでしょうか。これは、低い地位の人を昇進させたり、データベースに興味を持っている同僚をその分野に進出させるのに素晴らしい方法です。パートタイムでも、小さな問題のいくつかを処理できるようにトレーニングして、日々の心配を減らすことができます。こうすれば、1 週間休む必要がある場合、何か大きな問題が発生した場合にだけ連絡すれば済みます。
SLA システムがなければ、2 年間問題なく行ってきた仕事にさらに人員が必要であることを正当化するのは困難であるため、いずれにしても問題が発生すると思います。必要な作業量が増えることはわかりますが、状況の変化を追跡するためのドキュメントと SLA がなければ、説得するのは難しいかもしれません。
答え3
昨日。
(投稿サイズが最小であるため、簡潔なウィットが妨げられます。)
（たとえこれが低評価を受けたとしても、私は面白いと思いました。今日は金曜日ですから。）
/編集 - より真剣な回答。熟練した技術スタッフにとって、quanta=1 から quanta=2 へのジャンプを正当化するのは非常に困難です。いくつかの方法があります。
時間を記録します。これを使用して、費やした時間を示します。また、新しいタスクや義務、アプリケーションが提案されたときに、必要な時間を見積もり、「現在行っている作業のうち、この新しい作業を行うために、どの作業を停止するか、自動化するか、または人員を雇用するか」を検討します。
時々パートタイムの仕事を請け負ってくれる契約サービスを検討してください。手順、アプリ、インフラストラクチャのレビューと文書化を手伝ってもらい、休暇中にオンコールで対応してもらうために再度契約します。こうすることで、結局現場にいて電話をかけてくるという事態にならずに、システムを把握できます。
既存の非 DBA IT スタッフをトレーニングして、軽作業や緊急トリアージ作業ができるようにします。これは、会社が他の IT スタッフを雇用できるほど大きく、特に適切な姿勢、スキル、勤勉さを持ち、適切に業務を遂行できる人材がいることを前提としています。