システム障害で27時間勤務！？運用保守がきつい理由

IT業界で下流工程と言われる運用保守業務。
運用保守は、アプリケーションやサーバーを安定稼働させるために必要不可欠な業務です。
しかし、夜間・休日も働かなければいけない場合や、スキルが身につかないなどの口コミ・評判から運用保守業務が「きつい仕事」と感じている人もいるかと思います。

本記事では、運用保守業務が「きつい」と言われる理由を、現役エンジニアの体験談をもとにご紹介します。

運用保守業務とは

はじめに、運用保守業務についてご紹介します。
運用保守業務とは、Webサイトやアプリケーションを動かすサーバーなどのITインフラを安定稼働させるための業務です。

これには、サーバーやネットワーク機器の監視、障害発生時の対応、ソフトウェアバージョンアップやバックアップの取得などのメンテナンス作業が含まれます。

例えば、24時間365日稼働する必要があるサーバーですが、サーバーは精密機器であるため、経年劣化や不具合により故障する可能性もあります。
また、ヒューマンエラーや、第3者の悪意ある攻撃による、サーバーダウンやハッキングなどの危険性もあります。

上記のようなIT機器の異常時に迅速な対応を取り、また未然に予防することが運用保守業務における主な役割です。

運用保守がきついと言われる理由

次に、運用保守業務がきついと言われる理由について解説します。

ライフワークバランスが取りづらい

1点目は、ワークライフバランスが取りづらい点です。
運用保守業務は24時間365日の体制を要求されることが多く、シフト制での勤務が一般的です。
そのため、正月やお盆も働く必要がある場合や、夜勤により昼夜が逆転してしまう人もいます。

このような状況は、自身のライフワークバランスを著しく崩す原因となります。
家族や友人との時間も削られ、休息や自己充実の時間も確保しにくくなるため、精神的なストレスや身体的な疲労が積み重なっていきます。

業務が受動的になりがち

2点目は、業務の特性上、仕事が受動的になってしまうことです。
運用保守業務は基本的にシステムが正常に動作しているかを監視し、問題が発生した際に対応するという受動的な性質を持ちます。

そのため、モチベーションの維持が難しくなる人や、いつ発生するか分からない障害に対して精神が削られてしまう人が一定数います。

責任は大きいが、成果が見えづらい

3点目は、責任と成果が釣り合わない点です。
Webサイトやアプリケーションは、動いていることが当たり前とされており、システム障害が発生すると、クレームや企業としての信頼失墜につながります。
そのため、運用保守業務は非常に責任が重い仕事と言えます。

しかし、障害復旧をした場合でも、マイナスからのスタートであり、その成果は「通常の状態に戻った」「なぜ障害が起きたのか」という状態で終わってしまう場合があります。
また、予防保全をしたとしても、「問題が起きなかった」という形でしか表れないため、人事部や管理職などの非技術者にはその価値を理解しにくい場合があります。

インフラ障害で27時間勤務！？

ここからは、筆者が実際の運用保守業務で経験した、長時間勤務の体験談を紹介します。
私の場合は、夜間勤務の際に障害が発生し、27時間という長時間労働を経験しました。

インフラ障害の概要

はじめに、27時間業務に至ったインフラ障害の概要について紹介します。
私はルーターやサーバーの運用保守を担当する部署に所属しており、日中（9:00~18:00）・夜間（17:00~9:00）の2交代制で勤務をしておりました。
夜勤の場合は、1回の勤務で2日分働いて退社後はそのまま非番となるシフト体制です。

インフラ障害が発生した原因は、別部署の作業ミスによるものでした。
当時は別部署の作業を運用保守部署の私たちが把握しておらず、また作業実施部署も障害が発生しているという認識がありませんでした。
このようなコミュニケーションエラーにより、運用保守部署が原因不明の障害として扱ってしまったため、長時間障害となってしまいました。

時系列については後述しますが、インフラ障害は深夜1時に発生し復旧に4時間30分かかる長時間障害となりました。

なぜ長時間勤務に至ったのか

今回の事象では、発生から4時間30分で復旧となりました。
しかし、なぜ27時間という長時間勤務になってしまったのでしょうか。
それは、以下の理由があるためです。

• エンドユーザーへの情報開示

障害が発生した場合、エンドユーザーであるお客様に障害状況や影響範囲を開示しなければなりません。
また、SLA（Service Level Agreement）を結んでいる場合は返金が必要になる場合もあります。
そのため、影響範囲ユーザーの計算やサービス断時間の細かい計算が必要です。

• 時系列の整理

障害復旧後に障害時の対応経緯を細かく洗い出す必要があります。
これは企業にもよりますが、1秒単位で対応経緯を整理しなければなりません。
自身の作業ログや監視システムのエラーログ、上司・カスタマーサポートへの架電時間なども必要です。

• 関係各所への報告

経緯を洗い出した後は、管理職やカスタマーサポートへの説明が必要です。
管理職やカスタマーサポートは、お客様への説明やHP掲載の責務を担っているためです。

• チームへの周知・引継ぎ

チームへの周知・引継ぎも重要です。
運用保守はチームで行う業務であり、担当者が帰宅した後も引き続き技術的な電話対応・サポートを行う必要があります。
適切な引継ぎが行われなければ、同じ問題が再発するリスクが高まり、また同様の障害時に効率的な対応ができなくなる恐れがあります。

当時の時系列

対応時系列をまとめると、下記のようになります。
障害が起こらなければ9時に定時帰宅の予定でしたが、時系列の整理や報告などにより、翌20時の業務終了となりました。

• 17:00~翌1:00
  通常業務（メール確認、電話対応、定常業務）
• 1:00~5:30
  障害発生～復旧
• 5:30~9:00
  対応時系列の整理
• 9:00~15:00
  管理職、カスタマーサポートへの説明
• 15:00~19:00
  障害報告資料作成、チームへの引継ぎ
• 19:00~20:00
  通常業務分の事後処理

翌日からの仕事も膨大

障害対応は当日だけでなく、翌日からの仕事にも影響を及ぼします。
これは再発防止のための恒久対策が必要となるためです。
作業ミスの防止や部署間でのコミュニケーションエラーが再発しないよう、自動化やツールの開発、業務フローの見直しを行います。

これらの対策には、ツールの開発や他部署との調整、上長の確認などが必要であるため、数か月から半年ほど掛かることになります。

これらの業務は通常業務に追加される業務です。

そのため、担当者の業務負荷が一時的に増え、精神・肉体的にもつらい期間となります。

まとめ

今回は、運用保守業務がきついと言われる理由について、体験談をもとにご紹介しました。
ここまで読んでいただいた皆さまの中には、「運用保守部門に行くことはやめておこう」と思われた方がいるかもしれません。

しかし、ご安心ください。
今回のような長期間勤務は非常に稀なケースです。
私自身、4年間運用保守業務をしていましたが、このような長時間勤務は1回のみでした。

運用保守業務は基本的には残業時間が少なく、マニュアル通りの対応で業務を遂行することが可能です。
また、夜勤明けや振替休日などの平日に外出ができる、障害が発生していない場合は資格の勉強やゆったりした時間を過ごすことができるなどのメリットもあります。

エンジニアの登竜門とも言われる運用保守部門。
皆さんもチャレンジしてみてはいかがでしょうか。