AWS運用保守の仕事内容を実体験で解説|3年間で担当した監視・障害対応・追加開発

AWS運用保守で監視と障害調査を行う女性エンジニア AWS・クラウド

AWSの運用保守では、実際にどのような仕事をするのでしょうか。

私は転職前に約3年間、AWS環境の運用保守と追加開発を担当しました。日常業務は監視や障害対応だけではなく、問い合わせ対応、設定変更、手順書作成、新規サブシステム向けのサーバ構築など幅広いものでした。

この記事では、私が実務で担当した内容と、経験を通して身についたこと、難しかったことを具体的に紹介します。これからAWS運用に携わる方や、インフラエンジニアからクラウドエンジニアへの転職を考えている方の参考になればうれしいです。

AWS運用保守で日常的に担当した5つの仕事

1.監視

システムやサーバの状態を監視し、異常を示すアラートが発生していないか確認していました。監視製品の操作方法だけでなく、アラートの意味や確認すべき項目を理解しておくことが重要です。

アラートが出たからといって、すぐに重大な障害と判断できるとは限りません。まず状況を確認し、影響範囲や緊急度を整理したうえで、必要な対応へ進みます。

2.障害対応

障害が発生したときは、決められた手順に沿って状況確認や復旧対応を行いました。過去に発生した事象であれば、既存の手順や対応履歴を参考にできます。

一方、原因が分からない障害では、どこから調べるべきか判断するところから始まります。サーバ、ネットワーク、アプリケーション、監視ログなど、複数の観点から情報を集めて切り分ける必要があり、調査と解析に苦労しました。

3.問い合わせ対応

利用者や関係者から届く問い合わせにも対応していました。設定や仕様を確認し、必要に応じてログや構成を調査して回答します。

単に回答するだけではなく、相手が何に困っているのかを整理し、専門用語を使いすぎずに説明する力も必要でした。

4.設定変更

運用中のシステムに対する設定変更も担当しました。変更前には影響範囲、作業手順、確認方法、問題が発生した場合の戻し方を整理します。

本番環境の変更では、小さな設定でもサービスへの影響が出る可能性があります。そのため、事前確認と作業後の確認を丁寧に行うことを意識していました。

5.手順書作成

監視や障害対応、設定変更などの作業を、担当者が変わっても同じ品質で進められるように手順書を作成しました。

実際の画面や確認ポイント、作業を中止すべき条件まで記載することで、作業ミスを減らせます。手順書を書く過程で、自分の理解が曖昧な部分にも気づけました。

運用保守だけでなく追加開発も経験した

運用保守と並行して、新規サブシステムに関する追加開発も担当しました。具体的には、次のような作業です。

  • Windowsサーバの構築
  • Linuxサーバの構築
  • Active Directory(AD)の構築
  • LDAP連携
  • 振る舞い検知製品の導入

運用中の環境を見るだけでなく、設計内容を確認しながら新しいサーバや認証連携、セキュリティ製品を組み込む経験ができました。WindowsとLinuxの両方を構築したことで、OSごとの設定や運用方法の違いも学べました。

よく利用したAWSサービスはEC2とVPC

業務で特によく利用したAWSサービスは、EC2とVPCです。

  • EC2:仮想サーバの確認や操作、設定変更、障害調査など
  • VPC:ネットワーク構成や通信経路、セキュリティ設定の確認など

運用保守を通してAWSの基本操作には慣れましたが、当時担当していたサービスや業務範囲は限られていました。転職後にTGW、WAF、CloudFront、API Gateway、コンテナなどへ触れ、AWSにはさらに幅広い構成があることを実感しました。

この経験については、AWS運用保守を3年経験しても転職後に知識不足を感じた理由でも詳しく紹介しています。

AWS運用保守で身についたスキル

3年間の業務を通して、主に次のスキルが身につきました。

  • AWSの基本的な操作
  • 監視製品の操作とアラート確認
  • 障害ごとの対応手順
  • ログや構成情報を使った原因調査
  • 安全に設定変更を行うための準備と確認
  • 再現性のある手順書を作成する力

特に役立ったのは、障害発生時に慌てず、分かっている事実を整理して一つずつ確認する習慣です。クラウドサービスが変わっても、切り分けの考え方は現在の業務に生きています。

最も大変だったのは、原因不明の障害調査

運用保守で最も難しかったのは、手順書に載っていない障害への対応でした。原因が不明な状態では、最初に何を確認すればよいのかも自分で考えなければなりません。

私は、まず発生時刻や影響範囲、直前の変更有無を整理し、ログや監視情報を確認していました。その後、サーバやネットワークなどの観点から可能性を絞ります。初めは調査に時間がかかりましたが、対応履歴を確認したり周囲に相談したりしながら、少しずつ切り分け方を身につけました。

運用保守経験を転職で伝えるときのポイント

運用保守という言葉だけでは、実際に担当した範囲が採用担当者へ伝わりにくい場合があります。私は、監視や問い合わせ対応に加えて、障害調査、設定変更、Windows・Linuxサーバ構築、AD構築、LDAP連携、セキュリティ製品導入まで経験したことを具体的に整理しました。

職務経歴書では、利用したサービス名だけでなく、担当した作業と自分の役割を書くことが大切です。私が4ページの職務経歴書にクラウド経験をまとめた方法は、インフラエンジニアの職務経歴書の書き方で紹介しています。

インフラからクラウド分野への転職を検討している方は、7年目でクラウドエンジニアへ転職したロードマップも参考にしてください。

まとめ

AWS運用保守では、監視、障害対応、問い合わせ、設定変更、手順書作成を日常的に担当しました。さらに追加開発として、Windows・Linuxサーバ、AD、LDAP連携、振る舞い検知製品の導入も経験しました。

当時よく利用したAWSサービスはEC2とVPCで、AWSの基本操作や障害対応の進め方を身につけられました。一方、原因不明の障害では調査の入口を見つけることが難しく、運用保守ならではの大変さもありました。

運用保守の経験は、担当業務を具体的に言葉にすれば、クラウドエンジニア転職でも十分にアピールできます。日々の作業を「何を考え、どこまで担当したか」という視点で整理しておくことをおすすめします。

タイトルとURLをコピーしました