運用保守エンジニアの仕事内容を1から100まで詳しく解説

仕事内容や特徴

 本ページはプロモーションが含まれています。

『運用保守エンジニアってどんな仕事をしているの?』

IT業界にあまり精通していない方にとって、運用保守エンジニアって何やっているかよくわからない存在ですよね。
今回は、「運用保守エンジニアなんて全く知らないよ~」という方から「なんとなく知っているけど詳しく知りたい。」という方まで現役エンジニアの私いけやんが分かりやすく、詳しく解説していきます。

運用保守の全体像

簡単に言うと…

システム運用保守とは完成したシステムやソフトウェアが正常に動き続けるように、監視や保守、問題解決を行うことです。
システムの健康状態を保ち、利用者がストレスなく安心してITサービスを利用するためのとても重要な役割を担っています。

定例業務と非定例業務

運用保守エンジニアの業務には定期的なサイクルや常時行っている定例業務とシステムに大きな変更が発生する際に実施する非定例業務があります。

定例業務と非定例業務に分けると以下の通りです。

定例業務 ・システムモニタリング
・ユーザーサポート
・トラブルシューティング
・システムアップデート
非定例業務 ・運用設計
・運用構築
・運用テスト
・システムテスト
・運用受け入れ

定例業務

システムモニタリング

概要

システムモニタリングとは、システムやソフトウェアが正常に動いているかを常に監視することです。
同義の言葉で「システム監視」という言葉を用いられる場合もあります。
エンジニアがシステムの動作状態をリアルタイムでチェックし、問題が発生する前に予防策を講じたり、早期に問題を発見して対処するために行います。

具体的な作業

システムモニタリングの具体的な作業は大きく分けると3つになります。

  • サーバの稼働状況チェック
  • エラー検知と伝達
  • 監視ツールの設定と管理
①サーバーの稼働状況チェック

みなさん、スマホアプリなどのサービスを使っている際に、『なんか処理速度が遅い!』と感じることはありませんか?
そんなときはシステムの稼働状況に異常が発生している可能性があります。
常にシステムを動かしているサーバーの稼働状態をチェックし、システムに異常が発生するのを未然に防ぐのです。

少し難しい用語になりますが、具体的にはCPUの使用率やメモリの容量、ディスクへのデータの出入りの頻度などシステムのパフォーマンスが基準値を満たしているかを定点的に確認しています。

②エラー検知と伝達

システムに異常が発生したことを知らせるメッセージを確認し、ユーザやシステムエンジニアに伝達する作業になります。
こちらは既にシステムに異常が発生した後の対応となりますが、ITサービスを利用する方やユーザにとって致命的な損害を与えないことを目的とし、早期対処を行うための仕事となります。
システム運用保守エンジニアの仕事における最重要ミッションと言えるでしょう。

プラスα知識

システム異常が発生した場合に、あらかじめシステム自身にエラーメッセージを解析、自動で必要な宛先に伝達する技術もあります。
人間よりシステムが自動的に処理をする方が対処のスピードが上がり、人件費も抑えられるというメリットがありますが、まだまだ人間の判断や切り分けが必要な作業もあるのが実態。

③監視ツールの設定と管理

システムの稼働状況を確認したり、エラーメッセージを確認したりする時は専用の大画面モニタやパソコンを使用します。
※一般的に「監視画面」と言われることが多いので、以降は監視画面と呼称します。
この監視画面にシステムから出力されるすべての情報を表示させようとするととんでもない量のメッセージが表示されてしまうので、重要な情報の絞り込みをする必要があります。
そのため、運用保守エンジニアは適切な情報をキャッチできるよう監視画面やシステムに対して監視の設定とその管理を行うのです。
上記の①、②に関連深い作業ですね。

監視ツールの設定の例)
  • いつ出力させるか(1分ごと、1時間ごと、1日ごと、etc)
  • どのような条件を付けるか(システム容量の○%を超えたら、同じエラーが10秒当たり○回繰り返されたら)
  • どのような形式で出力させるか(テキスト、グラフ)

ユーザーサポート

概要

ユーザーサポートは、システムを利用しているユーザーからの問い合わせや問題に対応する仕事です。
ユーザーがシステムの使い方に困ったり、何か問題が発生した場合、運用エンジニアがサポートを提供します。

具体的な作業

ユーザーサポートの具体的な作業は以下の3つになります。

  • 問い合わせ対応
  • トラブルシューティング支援
  • マニュアル作成
①問い合わせ対応

ユーザーから電話やメールによる問い合わせを対応をします。
基本的なシステムに対しては回答方法が記載されたマニュアルがあるため、手順に沿って回答していくのですが、異例的な問い合わせ内容に関しては、システムエンジニアやプログラマーに問い合わせを送り、返ってきた内容をまたユーザー側へ回答する必要があります。
問い合わせ内容の例を以下に書き出します。

問い合わせ内容の例
  • サービスの操作方法
  • エラー画面が出力されたときの対象方法
  • システム不具合についての状況確認
②トラブルシューティング支援

ユーザーからの問い合わせを受けて、回答を返したが問題が解決しなかった時や、ユーザーからもらった情報からシステムの状態をうまく把握できなかった際には運用エンジニア側が実際に操作を遠隔で実施してあげる場合があります。

③マニュアル作成

ユーザー向けの操作マニュアルの作成やFAQ(よくある質問の回答集)を作成するのもユーザーサポートの仕事の一つとなります。

トラブルシューティング

概要

トラブルシューティングとは、システムに発生した不具合や問題を迅速に解決することです。
システムが正常に動かなくなった場合、運用保守エンジニアはその原因を特定し、問題を解決するための手順を実行します。

具体的な作業

トラブルシューティングの具体的な作業は以下になります。

  • エラーの原因調査
  • システム復旧
エラーの原因調査

システムに異常が発生した場合には、監視画面にエラーメッセージが出力されます。
そのメッセージからどこに異常があるのかを特定し、システムログを確認してどこに原因があるのかを調査します。
過去事例があり原因の特定にほとんど時間がかからない場合もありますし、未知の事象で原因特定に何時間もかかってしまう場合もあります。

システム復旧

システム異常の原因が特定出来たら、システムを正常稼働させるための復旧作業を行います。
迅速な対応が求められるものの、被害を拡大させないように確実な手順を踏まなければなりません。
未知の事象であれば、システムの仕組みを理解したうえでどのように復旧させればよいかを考え、手順書を作成し、本当にうまくいくかを検証(テスト)し、復旧を行うという段取りを踏みシステムの復旧を行います。

システムアップデート

概要

システムアップデートは、システムやソフトウェアを最新の状態に保つために、定期的に新しい機能を追加したり、セキュリティを強化したりする作業です。
アップデートの内容は目的別に分けられ、「マルウェアやウィルスから守るため」「小規模な機能変更や追加のため」「小規模な不具合の改修」と大きく3種類になります。

具体的な作業

システムアップデートの具体的な作業は以下になります。

  • アップデートスケジュールの作成
  • 新機能のテスト
  • アップデートの実施
アップデートスケジュールの作成

システム製造者側の都合でアップデートをするわけにもいかず、ユーザーや関連会社、時には政府への調整が必要になります。
ユーザーへ悪影響を及ぼさないように(もしくは影響を最小限にするために)利用者が多い曜日や時間帯を避けるなどの考慮をして、周囲との合意が取れ、初めてアップデートのスケジュールが確定されます。

プラスα知識

生活インフラを支えている用な公共システムや基幹システムはかなり調整が面倒くさかったりします。
例)高速道路料金徴収所、銀行などの金融系

新機能のテスト

アップデートを実施した後にシステムが正常に稼働するかどうかのテストを、本番の環境ではなくテスト用に設けられた擬似的な環境で行います。
ここで問題なく正常にシステムが稼働することを確認してから、本物のシステムをアップデートすることができます。

アップデートの実施

システムに対するアップデーを実施します。
アップデーをして、『はい、終わり。』ではなく、その後もシステムが正常に稼働しているかのを確認を行います。
問題なく動作していたらシステムのアップデート作業は終了です。

非定例業務

運用設計

概要

開発者が作ったシステムや機能をただ稼働するだけでは安定したサービスの提供はできませんし、ユーザー側への付加価値もイマイチなものになってしまいます。
そのため、運用設計では安定したサービスを提供するために必要な上述で解説した定例業務の追加や変更、削除を検討し、どのように行っていくのかを設計していくのです。
ユーザ側への付加価値を提供するための運用もここで検討します。

具体的な作業

運用設計の具体的な作業は以下になります。

  • 運用項目の追加検討
  • 運用フローの策定
運用項目の追加検討

システムの変更に対応した定例業務の項目追加や見直しをします。
「システムモニタリング」でいうと、システムのリソースが強化されれば処理速度や容量のチェック基準値のレベルをあげます
「トラブルシューティング」でいうと、新しい機能を作成したのであれば、ユーザー側に起こりうる問題も増えるというのが常です。
そのため、考慮が必要になった問題に対する対処項目も洗い出しをして、最終的に運用設計書という形で定義をします。

運用フローの策定

運用項目の追加がされると、その作業を行うためのルールや流れを取り決める必要があります。
関連人物は誰でどのタイミングでコミュニケーションやアクションを起こすのかなど、ルール的なものを定めたり、各タスクの先行後続関係や条件分岐をフローに起こしてあげます。
こちらも運用設計書に定義する内容です。

運用構築

概要

運用設計で策定された項目に対し必要作業の詳細手順を作成したり、効率を上げるために自動化をするという作業を運用構築工程で実施します。

具体的な作業

運用構築の具体的な作業は以下になります。

  • 手順書の作成
  • 自動化ツールの作成
  • 環境設定
手順書の作成

定例業務を実施する際に必要な手順書の作成を行います。
作業ミスが起こらないように、内容のわかりやすさや視認性の高さが求めらる大事な工程になります。

自動化ツールの作成

システム運用をより効率化するために人の手作業ではなく、可能な範囲はシステム自身、もしくは別のシステムに実施させることが求められます。
そこで運用保守エンジニアは自分たちが行わなければいけない作業を自分たちの代わりに実施してくれるツールを作成するのです。
自動化ツールには作業項目におけるすべての処理を賄うものから、一部の処理をツールで残りの処理は手作業というものまであります。

環境設定

運用設計にて定められる新しい監視基準値やその他の変更点を反映するという作業も運用保守エンジニアが実施する作業の一つです。
上述している監視画面へ出力させるメッセージ対象の変更などもここに該当します。

運用テスト

概要

運用テストでは運用構築にて作成された手順書、ツール、環境設定値が問題ないことの確認をする仕事です。

具体的な作業

運用テストの具体的な作業は以下になります。

  • 運用テスト計画の作成
  • テストケースの作成
  • テストの実施
  • 不具合の対処
運用テスト計画の作成

運用構築工程で作成された成果物が問題ないことを確認するのが運用テストの役割です。
そのために、『どのようなテストをすればいいんだっけ?』を考え方針を立て、計画書の作成を行います。
ここで抜け漏れが発生すると定例業務をいざ開始した際に、作業がうまく進まなかったり、想定外の事象が発生してしまうので有識者を交えた確実な計画の策定が求められます。

テストケースの作成

テスト計画を作成したら、テストを実施する際のケース(テストを行うための手引きみたいなもの)を作成します。
何をするか、どうなったら合格なのかの基準を明確に定義をしてあげます。

テストの実施

作成されたテストケースをもとにテストの実施を行います。
内容は運用構築工程で作成された手順を一通りやってみたり、ツールを実行してみたり、監視画面を起動してメッセージの出力確認などを行います。

不具合の対応

運用テストでうまくいかなかった手順があったり、ツールの実行時にエラーが出てしまったりしたら、その項目に対する手当をしてあげます。
そして合格するまで再テストを繰り返します。
テストを実施して不具合を検出し解消することで、ITサービスの品質を高めていくのです。

システムテスト

概要

システム全体が意図通りに機能するかを確認するための包括的なテストをシステムテストと言います。

具体的な作業

システムテストの具体的な作業は以下になります。
基本的な流れは運用テスト同様ですね。

  • システムテスト計画の作成
  • テストケースの作成
  • テストの実施
  • 不具合対応
システムテスト計画の作成

システムテストはシステム全体におけるテストのため、運用保守エンジニアだけではなくアプリケーションを開発した開発系システムエンジニアと一緒にテストを行います。
個別の機能や運用は前段のテストで実施しているので、システムテストでは実際に機能をリリースした状態を作り、問題なくシステムが動作するか運用保守エンジニアの定例業務が適用されるかを確認する必要があります。
このような目的に則したテスト計画を策定します。
運用テストの際より規模が大きい環境や関連人物を考慮する必要がありますね。

テストケースの作成

出来上がったテスト計画書をもとにテストケースを作成します。
テスト実施内容と合格条件を明確に記載します。

テストの実施

テストケースをもとにテストの実施を行います。
運用テストで実施した内容から以下のような観点が追加されたテストが行われます。

運用テストから追加される観点
  • アプリケーションの機能と手作業までの一通りの流れがうまくいくか
  • 処理速度などの性能は問題ないか
  • 運用テストで網羅的にチェックできなかった観点
不具合対応

システムテストを経て、うまくいかなかった項目における対処を実施し、合格するまでテストを繰り返します。

運用受け入れ

概要

開発されたシステムが運用チームに引き渡される際に行う手続きのことを運用受け入れと言います。

具体的な作業

運用受け入れの具体的な作業は以下になります。

  • ドキュメントの更新
  • トレーニング
ドキュメントの更新

システムの設計書や運用手順書を最新の状態に更新し、不明点や不足がないかをチェックします。
プロジェクト内で作成した手順書の更新漏れがあると直接的にユーザーの業務影響に繋がってしまうので確実な対応が必要になります。

トレーニング

運用チームが新しいシステムの管理方法を学ぶためのトレーニングを実施します。
運用手順書は基本的に誰が見ても作業を実施できるように作成されていますが、作業の確実性やスピードを向上させるために作業を実施する人が擬似環境で作業を行ったたり、ドキュメントを読み込んだりしてトレーニングを行います。
ここでは、運用監視オペレータという役割の人が主にトレーニングの実施、運用保守エンジニアはそのサポートや教育をする、という形になります。

運用監視オペレータとは?

運用監視オペレータの仕事とは?

まとめ

運用保守エンジニアのお仕事について、ご理解いただけましたでしょうか?
以下に関連リンクを掲載しておきますので、運用保守エンジニアに興味が湧いてきた方はぜひご覧になってみてください!

運用保守エンジニア関連記事

保守・運用の違いとは?

いけやん

いけやん

現役システムエンジニアのいけやんです。 駆け出しシステムエンジニアやIT業界に転職を考えている方のために有力な情報発信をしていきます!

関連記事

特集記事

コメント

この記事へのコメントはありません。

いけやん

いけやん

現役システムエンジニアのいけやんです。 このブログは駆け出しシステムエンジニアやIT業界に転職を考えている方のために有力な情報発信をしていきます!

にほんブログ村

CLOSE