【サーバーエンジニア編】障害対応でヒーローになるな！サーバー保守で「想定外の炎上」を防ぐ、先回りのマネジメント術

はじめに

「エンジニア」とひと口に言っても、ソフトウェア、フロントエンド、サーバーなど、その役割によって現場で直面するトラブルはさまざまです。
本連載では、PMO(Project Management Office)として多くの現場を経験してきた甲州が、それぞれのエンジニアが抱える課題の回避策を深掘りしていきます。

第7回の主役は、「サーバーエンジニア」です。サーバーエンジニアの業務は、大きく次の2つに分けられます。

• ゼロからシステム基盤を作り上げる「新規構築」フェーズ
• 完成したシステムを維持・メンテナンスし続ける「運用・保守」フェーズ

この記事は特に、後者の「運用・保守」業務に携わっている方、あるいはこれから携わる方に向けて書いています。

毎日同じような監視業務やメンテナンスを繰り返していると、「自分は成長しているのだろうか」「構築をやっている同期の方が輝いて見える」と悶々としてしまうことはありませんか？ しかし、「今あるものを維持しながら、どう良くしていくか」を考える運用・保守業務の中でも、十分に成長できる機会は眠っています。

今回も失敗事例を紹介しつつ、あなたが日々行っている業務の価値を再認識し、キャリアアップにつなげるためのPMO視点を解説します。

サーバー保守現場の失敗事例
──「想定外」が招く悲劇

システムが安定稼働しているとき、サーバーエンジニアの存在は空気のように扱われがちですが、ひとたび問題が起きれば矢面に立たされます。ここでは、よくある2つの失敗事例を見ていきましょう。

失敗事例1：データ容量90％の警告音

ある日、サーバーのディスク使用量監視アラートが鳴り響きました。「使用率90％超過」。担当エンジニアは慌てて不要なログファイルを削除し、一時的な容量拡張などの暫定対応を行い、なんとかシステム停止の危機を乗り切りました。

エンジニア本人は「迅速に対応してシステムを守った」と胸をなでおろしています。しかし、クライアントの反応は冷ややかなものでした。なぜなら、暫定対応に「想定外の追加費用」が発生し、さらには、そのための社内説明、報告書まとめ、費用支払の対応などの業務が発生し、「本来業務」にかけるべき時間が取れず、クライアントの業務を一時的ではあるものの止めてしまう事態になってしまったからです。

クライアントからすれば、「なぜ90％になるまで放っておいたのか？ 急に費用がかかると言われても困る」というのが本音です。

今回のような対応に関してはシステム稼働当初は想定しておらず、クライアントとベンダー間で取り決めも行っておらず、契約書にも具体的に記載されていない内容でした。

失敗事例2：「早急に対応」の罠

ある金曜日の夕方、クライアントのシステムでサーバーダウンが発生しました。運用保守契約書には、障害発生時の対応として「早急に対応すること」とだけ記載されていました。

エンジニアチームはシステムの完全復旧に時間がかかると判断し、「土日は業務影響が少ないため、週明けの月曜日に根本対応を行おう」と判断しました。

しかし月曜日の朝、クライアントから大クレームが入ります。クライアントが想定していた「早急に」とは、「(土日を返上してでも)数時間以内に」という意味だったのです。

さらに、ダウンの原因は契約当初には想定していなかった「突発的なアクセス数の増加」でした。「アクセス増を想定した設計になっていないじゃないか！」「早急に対応してからから契約違反だ！」と、事態は大きなトラブルへと発展してしまいました。

マネジメント視点で
トラブルを未然に防ぐ回避策

これらの失敗は、技術的なスキル不足が原因ではありません。どちらも「マネジメント視点」が欠けていたことで起きた悲劇です。では、どうすれば防げたのでしょうか。

この失敗事例を読んで「そんな低レベルなことは起きる前に対処しておけるだろ！」と思った方もいるかもしれません。しかし、失敗の理由はいつも後から分かるものです。

問題の当事者は、その場その場で判断し、対応しているはずです。今回紹介している失敗事例は、発生事象は違えど、運用保守の現場ではよく起きていることです。

サーバーエンジニアのみなさんも、現在担当している案件を見直してみることをおすすめします。何も問題が起きていないときこそ、見直しや予防策を考えて対策を打つ良い機会です。

ここからは、今回の失敗事例を回避するための回避策を紹介していきます。

回避策1：起きてからの対応ではなく、
起きる前の行動！アラートが鳴る「前」のシナリオを描く

失敗事例1の原因は、「90％になってから対応したこと」です。優秀なマネージャーは、起きてからの対応ではなく起きる前の行動をとります。

例えば、容量が70％に達した時点で、過去のデータ増加傾向から「いつ90％に達するか」を割り出します。そして、事前にクライアントへ「〇ヶ月後に容量が90％に達する見込みです」と伝えます。

その際、ディスク拡張に〇〇円の費用が必要になりますが、予算の確保をお願いできますか？」と提案(計画と対策)をしておくのです。

事前に合意が取れていれば、90％に達した時の対応は「計画通りのスムーズな作業」となり、追加費用も「想定内の予算」として快く承認されます。「想定外の突発的な緊急対応」から「計画的な保守対応」に変わるのです。やっていることは同じでも、対応の扱いが全く違います。

回避策2：契約とSLA(サービスレベル合意)の「解像度」を上げる

失敗事例2のトラブルは、「早急に」という曖昧な言葉で合意してしまったこと、そして「想定ケース(アクセス増)」の取り決めが甘かったことが原因です。

マネジメント視点を持つエンジニアは、契約書やSLAの解像度を徹底的に上げます。「障害レベルごとの対応時間(例：レベルAは4時間以内、レベルBは翌営業日まで)」「障害レベルの決定フロー」「土日祝日の対応の有無と追加費用」「想定アクセス数を超過した場合の責任分界点」などを、細かく、具体的に握っておくのです。

「そこまで細かく決めると嫌がられるのでは？」と思うかもしれませんが、平時のうちに細かいルールを決めておくことこそが、有事の際にお互いを守る最大の盾となります。

システム構築プロジェクトのように短期間で決めきる必要はありません(本当は構築時に運用要件を決めておいてほしいですが)。既に運用保守を行っていて、大きな問題が起きない場合は、時間的な余裕があるはずです。

月に1度や半年に1度の定期報告の場面でリスク項目として議題を上げ、時間に余裕があるときに決めていくことができるはずです。

項目数が多い場合は、優先順位を決めて重要な項目を先に決めるように進めていけば、クライアントにも負荷がかからずに喜ばれるはずです。

「何も起きない」は、あなたが優秀な証拠

最後に、サーバーの運用・保守に従事する皆様に、PMOとして強く伝えておきたいことがあります。

毎日、サーバーが落ちることもなく、システムが当たり前のように動いている。周りからは「何もしていない」ように見られ、評価されにくいと感じるかもしれません。

しかし、「何も問題が起きずに安定稼働できている」ということは、あなたが裏で事前に手を打ち、先回りしてリスクを潰しているからに他なりません。

「安定稼働とは、実は一番すごい成果」だと私は思います。「問題が起きてから火消しに走るヒーロー」は目立ちますが、真に優秀なエンジニアは「火事そのものを起こさせない(あるいはボヤで食い止める)人」です。

今回紹介したような、事前のリソース計画(容量予測)や、ステークホルダーとの明確な合意形成(SLAの明確化)といったマネジメント視点を取り入れることで、あなたの業務は単なる「作業」から、ビジネスを支える「提案業務」へと進化します。

始めは小さな改善提案から始まるかもしれませんが、徐々に視点が広がっていくはずです。

今携わっている「維持・メンテナンス」の仕事に誇りを持ち、マネジメント視点を取り入れて、さらなるキャリアアップを目指してください。