インフラエンジニアの仕事内容を、私が実際に経験した2社の仕事をもとに書きます。1社目は受託でお客さんのAWS環境を運用保守する会社、現職は自社開発の会社です。これからインフラエンジニアを目指す方の参考になればと思います。
インフラエンジニアの仕事内容は会社・案件・工程で違う
インフラエンジニアは、サーバーやネットワークなどの基盤を、設計・構築・運用する仕事です。ただ、実際の仕事内容は企業によって違います。担当する案件によっても、上流工程なのか運用保守なのかによっても違います。一口に「インフラエンジニア」と言っても、言い表せないところがあります。
工程が分かれていて、受託か自社開発かといった会社のタイプによって、担当する範囲が変わるからです。人によっては、開発のほうまでやっていることもあります。
私自身も、1社目と現職でやっていることがかなり違います。1社目では、AWSの仮想サーバーであるEC2や、データベースのサービスであるRDSなど、お客さんのAWS環境を運用保守していました。
現職では、インフラをコードで管理するIaCのツールであるTerraformを使っています。設定を部品のようにまとめて使い回す「モジュール化」も進めています。アプリを、動かすのに必要なものごとコンテナという箱にまとめて動かすDocker・ECSも使っています。セキュリティでは、AWSのセキュリティのサービスであるGuardDuty・Security Hubを使っています。
インフラエンジニアの主な仕事
会社によって違いはありますが、インフラエンジニアがよく担当する仕事は次のとおりです。
- サーバーやネットワークの構築：サーバーやネットワーク機器を用意し、設定して使える状態にする
- 監視と障害対応：CPU・メモリ・ディスクの使用率などを監視し、異常があれば原因を調べて直す
- 設定変更とアップデート：依頼に応じて設定を変え、OSやソフトのセキュリティ更新を当てる
- バックアップ：データを定期的に保存し、戻せるかを確かめる
- セキュリティ対策：アクセスできる人や権限を管理し、不正なアクセスを防ぐ
- 費用の管理：使っていない機器やリソースを整理し、費用を抑える
工程ごとの仕事
インフラの仕事は、要件定義、設計、構築、テスト、運用・保守と工程が分かれています。要件定義と設計は上流工程、それより後は下流工程と呼ばれます。
- 要件定義：お客さんの要望を聞いて整理し、何を作るかをまとめる
- 設計：要件に合わせて、サーバーやネットワークの構成・スペックを決める
- 構築：設計どおりにサーバーやネットワークを作り、設定する
- 運用・保守：作ったシステムを監視し、障害対応や設定変更・アップデートをして、安定して動かし続ける
私は1社目で運用保守から入り、構築にも関わりました。現職では運用に加えて、開発もしています。
1社目：受託でAWSの運用保守（1日の流れ）
私は未経験から、クラウドエンジニアとして1社目に入りました。小さな会社で、受託でお客さんのAWS環境の設計構築や運用保守をする会社です。客先に行くのではなく、自社内で業務を行うタイプの会社でした。
勤務は3交代のシフト制でした。出勤は朝6時、昼14時、夜22時の3パターンで、夜勤のときはリモートで働いていました。
1日の基本的な流れは次のとおりです。
- 出勤したら、まずメールチェック
- 優先順位が高い順に、運用保守の作業（サーバーの設定変更、RDSの設定変更など）
- 月次レポートの作成、コストの調査
- 障害があれば、障害の対応を優先する
業務の中で一番多かったのは、メールで届くアラートへの対応と、問い合わせ対応です。運用改善もかなり多く、監視のしきい値の見直し、手順書の整備、定型作業の自動化、使っていないリソースの整理をしました。コマンドを打つのは、主に障害調査と構築のときでした。
調査した障害には、CPUやメモリの使用率の高騰、ディスクの容量不足、サイトが見られなくなる障害、設定変更のあとの不具合などがありました。
お客さんとの定例会もありました。定例会では、インフラの改善点を提案します。障害が起きたときは、その原因の説明や対策についても話しました。
1社目で分かったのは、定型業務をやるだけでは、そこまでスキルは身につかないということです。一方で、新しく起きた障害について調査する、対策を考える、応急対策を考えるといった経験では、とてもスキルがつきました。一口に運用保守といってもいろいろだなと思いました。1社目としては、いい経験が積めたと思っています。
現職：自社開発でインフラと開発（1日の流れ）
1社目は2年で辞めて、自社開発の会社に移りました。動機は、技術のスキルを上げたかったことです。1社目では、コンテナもIaCも使っていませんでした。
現職ではインフラを担当していますが、アプリ側も見ていて、開発も任されるようになりました。触っているのは、Terraform・Docker・ECS・EC2です。Terraformのモジュール化も進めています。セキュリティでは、GuardDutyやSecurity Hubを使っています。使う技術はCTOが決めていて、私はそれを使う側です。入社1年目なので、技術選定に関わる立場ではありません。
1日の基本的な流れは次のとおりです。
- 朝ミーティング
- インフラのタスク（設定変更、OSやRDSのアップデートなど）があれば、そちらを行う
- インフラのタスクがなければ、開発を行う
プロダクトが昔からあるので、問い合わせ対応やバグ修正もかなり多いです。
現職ではアプリ側も含めて担当しているので、より広い視野でインフラを見られるようになりました。アプリケーション側から見た良いインフラの設計についても、考えるようになりました。たとえば、開発者が変更を本番に出しやすい構成や仕組み、本番とそろえた開発・検証の環境です。
自社開発の会社のインフラエンジニアの仕事
自社開発の会社では、開発チームと近い位置で、自分たちのサービスの基盤を見るのが仕事になります。
受託との一番の違いは、開発チームとの近さです。自社開発の会社では開発チームが同じ会社にいるので、アプリ側まで一緒に見ることになります。
求人を見ると、サービスの監視の仕組みづくりと障害対応や、CI/CD（コードの変更を自動でテストして本番に反映する仕組み）の設計・改善といった仕事が挙がっています。
私の現職では、クラウドの費用の管理もしています。毎月のクラウド費用を確認し、使っていないリソースを消したり、サーバーやデータベースのサイズを見直したりして、費用を下げました。費用が一定を超えたら通知されるアラートも設定しています。
役割としては、ソフトウェア開発の手法でサービスを安定して動かし続けるSRE（Googleが始めた考え方）に近づいていきます。開発チームと同じ側に立って、基盤を見る立場です。
技術以外に必要だったスキル
技術以外では、タスクマネジメントと説明のスキルがとても重要でした。どちらもインフラエンジニアに限らず必要なスキルかもしれません。
タスクマネジメント
タスクを管理して、優先順位をつけることが重要でした。運用保守の作業がある中で障害が起きると、割り込みが入るので、作業のスケジュールを調整する必要があります。設計構築にも納期があり、お客さんとやり取りすることもあります。忙しい時期もありました。
他の人に依頼する作業は早めに出して、待ちが発生しないようにします。お客さんへの確認が必要な場合も、早めに連絡します。リマインドが必要になることもありました。
説明のスキル
障害が起きたときには、その内容を説明する必要があります。お客さんとの定例もあったので、説明する場面は多くありました。現職でも、インフラの変更や障害を、開発メンバーに説明する場面があります。
説明するときは、結論から話すようにしていました。障害の説明では、原因・影響・対策の順で話します。専門用語は、分かりやすい言葉に言い換えるようにしていました。
インフラエンジニアのやりがい
私がやりがいを感じるのは、障害を解決できたとき、改善が役に立ったとき、サービスを支えている実感があるときです。
1社目では、CPUやメモリの高騰、ディスクの容量不足、サイトが見られなくなる障害などを調査しました。監視のしきい値の見直しや、定型作業の自動化といった改善もしてきました。
インフラエンジニアに向いている人
インフラエンジニアに向いているのは、責任感がある人、学び続けられる人、原因を調べるのが好きな人だと思います。
システムを止めないことが仕事なので、責任感が必要です。クラウドなど、使う技術も変わっていくので、学び続けることも大切です。そして、障害の調査や切り分けが多いので、原因を調べるのが好きな人は向いています。
私も1社目で一番スキルがついたのは、新しく起きた障害の原因を調べ、対策を考えたときでした。
まとめ
インフラエンジニアの仕事内容は、会社・案件・工程によって違います。
私の場合、1社目は受託でお客さんのAWS環境を運用保守する仕事で、障害の調査や対策を考える経験でスキルがつきました。現職は自社開発で、インフラと開発の両方を担当し、より広い視野でインフラを見られるようになりました。どちらの会社でも、技術以外にタスクマネジメントと説明のスキルが重要でした。
やりがいを感じるのは、障害を解決できたときや、改善が役に立ったときです。責任感があり、学び続けられ、原因を調べるのが好きな人に向いている仕事だと思います。
コメント