サーバー運用は引き継げる状態か - 続けられる体制を測るための視点

サーバー運用の重さは、作業量ではなく「引き継げなさ」で測る

運用の負荷を訴えるとき、担当者はたいてい作業量の話をします。月にこれだけのアラートが来る、問い合わせが何件ある、休日にこれだけ対応した。事実としては正しいのですが、この説明では次の一手が決まりません。作業量を減らす方法が見つからないまま、精神論に着地しがちです。

視点を変えて、「この運用は、今の担当者が抜けても続くか」という問いを立ててみると、話が具体的になります。続かないとすれば、どの部分が続かないのか。それは手順が書かれていないからなのか、判断基準が共有されていないからなのか、そもそも誰も全体を把握していないからなのか。

この見方には実務上の利点があります。第 1 に、社内で説明しやすくなります。「忙しい」は主観ですが、「担当者が 1 週間不在になると障害対応が止まる」は事実として扱えます。第 2 に、優先順位が決まります。続かない部分から手を付ければよいためです。第 3 に、外部に相談する場合も、任せる範囲を切り出しやすくなります。

以降のセクションは、この「引き継げるか」という物差しで通していきます。

サーバー運用の年間サイクル - 日次から年次までの偏り

サーバー運用の業務は、機能ごとに分類されることが多くあります。監視、障害対応、バックアップ、セキュリティー対策、といった具合です。この分け方は理解には向きますが、引き継ぎの弱点を見つけるには向きません。

時間軸で並べ直すと、別の姿が見えてきます。

ここで注目したいのは、頻度が下がるほど手順が残っていないという傾向です。毎日やる作業は、誰かが休んでも別の人が肩代わりするうちに共有されます。一方、年に 1 回しかない作業は、前回やった人の記憶にしか残りません。

そして厄介なことに、業務への影響が大きいのはむしろ低頻度側です。ライセンスの更新を落とせばサービスが止まりますし、保守契約の更改を逃せば障害時に打つ手がなくなります。監査対応で必要な資料が見つからなければ、その場で作ることになります。

引き継ぎの観点で最初に手を付けるなら、日次業務のマニュアル化よりも、年 1 回の作業を書き出すことのほうが効率的です。項目数が少なく、影響が大きいためです。

日々の運用で実際に起きていること

ここからは具体的な業務を見ていきます。業務内容の網羅的な整理は関連記事「サーバー管理とは？具体的な業務内容や自社管理・委託管理の違いを解説」に譲り、本記事では「引き継ぎにくいのはどこか」という観点に絞ります。

監視 - しきい値を決めた人がいなくなると誰も触れない

監視ツールの導入自体は、多くの企業ですでに済んでいます。CPU、メモリー、ディスク使用率、サービスの応答を確認し、異常時に通知が飛ぶ仕組みまではできている。ここまでは引き継げます。設定画面を見れば、何を監視しているかは分かるためです。

引き継げないのは、その設定にした理由です。ディスク使用率 80 % で警告を出す設定になっているとして、なぜ 80 % なのか。85 % ではだめなのか。前任者が経験的に決めた数字であれば、根拠は残っていません。

すると何が起きるか。しきい値を変更する判断ができなくなります。毎週同じ警告が飛んでいて、実害がないことは経験的に分かっている。でも変更していいのか判断がつかないので、そのままにする。半年もすると、その通知は誰も見なくなります。通知が多すぎて機能していない監視は、実質的に監視がない状態と大きくは変わりません。

このケースで残しておきたいのは、監視項目の一覧そのものよりも、「この値にした理由」と「変更してよい条件」の 2 つです。

障害対応 - 復旧より前に「誰に確認するか」で止まる

障害対応の手順書を持っている企業は少なくありません。ログの確認箇所、再起動のコマンド、切り替えの手順。技術的な部分は書けます。

書きにくいのは、その手前です。「このサービスを今止めてよいか」「誰の承認が要るか」「どの部門に先に連絡すべきか」。これらは組織の事情なので、手順書に書くと生々しくなります。結果として書かれないまま、経験のある担当者の判断に委ねられます。

平日の日中であれば、まだ確認が取れます。難しいのは夜間と休日です。エスカレーションの条件が決まっていない環境では、担当者は 2 つの選択肢のあいだで迷います。自分の判断で動いて、後から問題になるか。誰かに連絡が付くまで待って、復旧が遅れるか。どちらを選んでも、後で何か言われる可能性が残ります。

この状態が続くと、担当者は「自分がやったほうが早い」という結論に落ち着きます。引き継ぎが進まない理由の一つが、ここにあります。

バックアップ - 戻せるかを最後に確かめたのはいつか

バックアップの取得設定は、たいてい整っています。難しいのはその先で、実際に復旧できるかを定期的に確認している企業は多くありません。

リストアテストには検証環境と作業時間、そして場合によっては業務停止の調整が必要です。日常業務が詰まっている状態では、優先順位が下がります。「取れているから大丈夫だろう」で数年が経つ、というのはよくある話です。

年 1 回でも、対象を絞ってでも実施しておくと、いざというときの判断材料が変わります。加えて、テストの記録が残っていること自体が、引き継ぎ資料として機能します。

パッチ適用 - 当てない判断のほうが記録に残らない

更新プログラムの適用は、セキュリティー上は早いほうがよく、業務影響の面では慎重にならざるを得ない領域です。基幹システムに関わる更新なら、業務部門との調整に数カ月かかることもあります。

「今回は当てない」という判断自体は、状況によっては合理的です。困るのは、その理由と再検討の時期が残っていないときです。半年も経つと当事者ですら経緯を思い出せなくなり、そのまま放置され、気づけば機器ごと保守期限を迎えていた、という着地になりがちです。

「続けられるか」を測る 5 つの問い

ここまでの内容を、自社に当てはめて確認できる形にします。次の 5 つの問いに答えてみてください。答えに詰まった項目が、体制の弱いところです。

問い 1: 今の担当者が 1 週間不在になったとき、運用は回りますか

回らないとすれば、止まるのは作業でしょうか、判断でしょうか。作業が止まるなら手順書で対応できます。判断が止まるなら、判断基準の言語化が必要になります。この 2 つは打ち手が違うため、切り分けておくと着手しやすくなります。

問い 2: 監視のしきい値や通知先を、根拠を説明したうえで変更できますか

変更できない設定は、実質的に触れない設定です。時間とともに実態と合わなくなり、通知が形骸化します。

問い 3: 直近 1 年以内に、実際に復旧を試したことがありますか

試していない場合、復旧できるかどうかは推測です。推測を前提にした事業継続計画は、いざというときに機能しないことがあります。

問い 4: パッチを当てなかった判断について、理由と再検討時期が記録に残っていますか

残っていない場合、その判断は「忘れられた」状態と区別が付きません。後から見た人には、放置されているようにしか見えません。

問い 5: 夜間・休日の対応範囲について、社内で合意が取れていますか

合意がない状態で担当者が個人的に対応を続けていると、その運用は担当者が代わった時点で消滅します。引き継ぎようがないためです。

なお、これらの問いのうち、監視ツールの導入で改善が期待できるのは主に問い 2 の周辺です。ツールは状況の可視化と作業の削減には有効ですが、業務影響の判断基準や承認フローまでは代替しません。ツールを検討する場合も、通知ルールと一次対応の流れをあわせて設計する必要があります。

保守期限と予算周期のズレ

サーバー本体、OS、ミドルウエア、バックアップソフト、セキュリティー製品には、それぞれサポート期間があります。この期限が、運用体制の見直し時期を実質的に決めています。

ここで実務的に効いてくるのが、時間の粒度の違いです。

• 保守期限は、メーカーの都合で決まります。年単位で、こちらの事情とは関係なく来ます

• 予算は、年度単位です。決算期をまたぐ調整が必要になります

• 検証と切り替えは、月単位です。テスト、移行、並行稼働の期間が要ります

この 3 つが噛み合わないと、「期限は分かっていたが、予算を取る時期を逃した」「予算は付いたが、検証の時間がない」という状態になります。期限の 1 年前に着手できると、この 3 つを順番に処理する余裕が生まれます。

期限が迫ってから検討を始めた場合、更改・延命・隔離・移行といった選択肢を比較する時間が残らず、消去法で決めることになりがちです。

EOL や保守終了そのものの考え方については関連記事「EOL・EOSL とは？メーカー保守終了後のリスクと対応策を分かりやすく解説」を、基盤全体の更新計画については「IT インフラ構築の進め方 - EOL・運用負荷・属人化を踏まえた判断軸」をあわせてご覧ください。

説明を求められたときに答えられない、という形の影響

運用体制を整えないまま時間が経つと、どこかで大きな障害が起きる。そう説明されることが多いのですが、実際にはもう少し手前で影響が出ます。

取引先の調査票が届いたときです。「サポートが終了したソフトウエア、機器の使用状況について記載してください」といった項目に、答えられない。あるいは、正直に書くと不利になるのではないかと迷う。

監査や親会社からの照会でも同じことが起きます。構成情報が最新でなければ、質問に答えるために現物を調べるところから始めることになります。数日かかる作業です。

サイバー保険の更新や、取引開始時のセキュリティー要件確認でも、運用状況の申告を求められる場面が増えています。

これらに共通するのは、答えられない理由が「対応していないから」ではなく、「対応状況を把握していないから」である点です。実際には妥当な運用をしていても、記録がなければ説明できません。そして説明できない状態は、対応していない状態と同じように扱われます。

障害による停止は分かりやすい影響ですが、日常的に効いてくるのはこちらのほうです。

委託を検討したときにつまずく 3 つの場面

運用を外部に任せるという選択肢は、体制が続かないと判断した場合に現実的な候補になります。ただ、検討を始めると、いくつかの場面でつまずきます。順に見ていきます。

稟議の段階 - 効果を数字で説明できない

最初のつまずきは、稟議書を書く段階です。上長から「委託すると年間いくら下がるのか」と聞かれます。

ここで困るのは、現状の運用コストが数字になっていないことです。担当者の人件費のうち、どれだけがサーバー運用に使われているのか。夜間対応の時間は、どこにも計上されていない。障害が起きたときの機会損失は、見積もったことがない。

比較の土俵がない状態で委託費用だけを出すと、単純な追加コストに見えます。実務的には、「コストが下がるか」ではなく「今この運用を続けた場合に、いつ、何が起きるか」で説明したほうが通りやすい傾向があります。担当者の退職リスク、保守期限の到来時期、障害時の復旧見込み時間。これらを並べるほうが、意思決定の材料になります。

契約の段階 - 範囲を決めるために、現状把握が必要になる

次のつまずきは、委託範囲を決める段階です。何を任せるかを決めるには、今何をやっているかを一覧化する必要があります。

ところが、その一覧がない。担当者の頭の中にはあるが、書き出したことがない。結果として、委託の検討を始めたのに、現状の棚卸しから始めることになります。

これは遠回りに見えますが、実際には避けて通れない工程です。そして、この棚卸しをした時点で、「思っていたより自社でやれることが多かった」「逆に、この部分だけ任せれば十分だった」という気づきが出ることもあります。委託するかどうかにかかわらず、やっておく価値のある作業です。

運用開始後 - 確認依頼が増えて、想定ほど楽にならない

3 つ目は、委託を開始したあとです。一次対応は任せられるようになったのに、担当者の負荷が思ったほど下がらない。理由は、確認依頼が増えるためです。

「この作業を実施してよいでしょうか」「業務影響はどの程度でしょうか」「優先度の判断をお願いします」。委託先は社内の事情を知らないため、判断を伴う場面では必ず確認が入ります。これは委託先の質の問題ではなく、構造的にそうなります。

この負荷を減らすには、契約時に判断基準そのものを渡しておく必要があります。どのシステムがどの業務を支えているか、停止できる時間帯はいつか、誰に連絡すればよいか。これらが文書として渡っていれば、確認の頻度は下がります。渡っていなければ、毎回聞かれます。

つまり、委託がうまくいくかどうかは、委託先選びと同じくらい、渡せる情報を持っているかに左右されます。ここでも、引き継げる状態にあるかという問いに戻ってきます。

保守や運用の外注判断そのものについては、関連記事「保守管理とは？業務内容・運用管理との違いから外注判断のポイントまで徹底解説」でも整理しています。

運用の記録は、誰のために残すのか

運用記録は、形式的な作業と受け取られがちです。実施した作業を書き残しても、読み返す機会はそう多くありません。

一方で、後になって効いてくるのは、実施しなかった判断の記録です。「なぜこのパッチを当てていないのか」「なぜこの機器を残しているのか」「なぜこの設定なのか」。これらは、担当者が代わったとき、監査や取引先から照会を受けたとき、そして更改を検討するときに必ず問われます。

記録の書き方には、実務上の差が出ます。たとえば同じ状況でも、次のような違いがあります。

書きづらい例

「一部の機器でサポート終了後も稼働を継続しています」

説明として成立しやすい例

「業務システム A のサーバー 2 台が、サポート終了後も稼働しています。当該機器は業務ネットワークから分離し、外部通信を遮断したうえで、アクセス可能な端末を 3 台に限定しています。更改は次期予算での対応を予定しており、それまでの間は四半期ごとに稼働状況を確認しています」

後者が「対応済み」でないことは変わりません。ただ、リスクを認識していること、暫定の手当てがあること、解消の見込みがあることの 3 点が示されています。照会する側が知りたいのは、たいていこの 3 点です。

そして、この書き方をしておくと、引き継ぎ資料としてもそのまま使えます。次の担当者は、なぜその状態なのかを推測せずに済みます。

引き継ぎ診断シート - 「誰が答えられるか」を書き出す

最後に、自社の状態を確認するための簡単な方法を紹介します。チェックリストではなく、設問ごとに「答えられる人の名前」を書き出す形式です。

使い方は単純です。書き終えたら、同じ名前が何回出てくるかを数えます。

すべての行に同じ名前が入っているなら、その人が抜けた時点で運用は止まります。空欄がある行は、社内の誰も把握していない領域です。名前が 2 人以上入っている行は、比較的安全です。

このシートには、もう一つ使い道があります。上長や経営層に体制の課題を説明するとき、埋まったシートをそのまま見せるのが、いちばん伝わります。「属人化しています」と言うより、「この 9 項目のうち 8 項目が 1 人に集中しています」と示すほうが、話が早く進みます。

すべてを一度に解消する必要はありません。空欄の行と、業務影響の大きい行から順に手を付けるのが現実的です。

よくある質問

Q1. サーバー運用と保守、管理は何が違うのですか

明確な定義があるわけではなく、企業によって使い分けが異なります。実務上の目安としては、運用は「止めないための日常的な活動」、保守は「不具合が起きたときに正常な状態へ戻す活動」、管理は「構成や権限などの状態を把握し統制する活動」と整理すると理解しやすくなります。

ただし、言葉の定義より実用的なのは、委託契約や社内の分担のなかで責任範囲がどう区切られているかを確認することです。用語が揃っていても、契約書の対象範囲が違えば意味がありません。

Q2. 手順書を作る時間が取れません。何から書けばよいですか

すべてを書こうとすると、たいてい途中で止まります。優先順位を付けるなら、発生頻度が低く、業務影響が大きいものから書くのが効率的です。

具体的には、年 1 回のライセンス更新、保守契約の更改、リストアテストの手順あたりです。項目数が少なく、かつ落とすと影響が大きい領域です。日次の作業は、毎日やっている分だけ他の人にも伝わりやすいため、後回しでも大きな問題になりにくい傾向があります。

Q3. 監視ツールを導入すれば、夜間対応の負担は減りますか

減る部分と残る部分があります。異常の検知と通知は自動化できるため、常時画面を見続ける必要はなくなります。

一方で、通知を受けて「今すぐ対応するか、朝まで待てるか」を判断する部分は残ります。この判断基準が言語化されていない状態でツールを導入すると、通知の数だけが増えることもあります。ツールの導入を検討する場合は、あわせて通知ルールと一次対応の流れを設計しておくと、効果が出やすくなります。

Q4. 外部に委託すれば、社内に知識がなくても大丈夫ですか

一次対応や定型作業は委託できますが、社内に一定の知識が残っていないと、委託先とのやり取りが成立しにくくなります。業務影響の判断、作業可否の承認、更改の投資判断は自社側に残るためです。

また、委託先を変更する場面や、社内で運用を巻き取る場面では、構成情報と運用手順が社内に残っているかどうかが大きく影響します。「任せる」ことと「把握しなくてよい」ことは、分けて考えておくほうが安全です。

Q5. 体制の見直しは、どのタイミングで始めるとよいですか

きっかけとして扱いやすいのは、機器やソフトウエアの保守期限が視野に入ったときです。更改の検討と体制の見直しは論点が重なるため、同時に進めると社内の議論が整理しやすくなります。目安としては期限の 1 年前です。

もう一つのタイミングは、担当者の異動や採用が話題に上がったときです。引き継ぎの必要が現実的になる場面なので、体制の話を持ち出しやすくなります。

Q6. 情報システム担当が 1 名しかいません。何から始めればよいですか

まずは、本記事の引き継ぎ診断シートを埋めてみることをお勧めします。1 名体制であれば、ほぼすべての行に自分の名前が入るはずです。そのうえで、空欄になった行を確認してください。自分でも答えられない項目があれば、そこが最も優先度の高い箇所です。

1 名体制で属人化を完全に解消するのは現実的ではありません。目標は「誰でもできる状態」ではなく、「不在時に外部や他部門が最低限の判断をできる状態」に置くほうが、達成可能です。

まとめ

サーバー運用の負荷は、作業の量では説明しきれません。同じ作業量でも、引き継げる体制と引き継げない体制では、抱えているリスクが大きく異なります。

本記事で整理した内容を、改めて 4 点にまとめます。

• 「引き継げるか」を物差しにする。
  忙しさは主観ですが、続けられるかどうかは事実として説明できます

• 年 1 回の作業から書き出す。
  頻度が低く影響が大きい領域ほど、記録が残っていません

• 保守期限は 1 年前から動く。
  期限・予算・検証は時間の粒度が違うため、順に処理する余裕が要ります

• やらなかった判断こそ記録する。
  引き継ぎと説明責任の両面で、後から効いてきます

唯一の正解はありません。同じ規模、同じ業種でも、既存資産の状況と運用に充てられる人員が違えば、適した体制は変わります。まずは引き継ぎ診断シートを埋めて、同じ名前が何回出てくるかを数えるところから始めてみてください。

自社だけで判断材料を揃えるのが難しい場面では、外部の知見を借りるという選択肢もあります。横河レンタ・リースでは、IT 基盤の構築から運用設計まで、現状の整理段階からのご相談を承っています。 

横河レンタ・リース株式会社では、ITインフラの機器提供に加え、設計・構築、運用支援、セキュリティー対策の整理についてご相談を承っています。更改を検討する段階で、現行環境と運用課題の整理から一緒に確認したい場合は、お気軽にお問い合わせください。

お問い合わせ (総合) | 法人向けパソコン (パソコン) ・計測器レンタルなら横河レンタ・リース