インフラエンジニアってどんなことをしているの？現役インフラエンジニアに聞いてみた！

大きく、設計・構築／運用・保守で分けられます。

① 設計業務
クライアントにヒアリングを行い、要件を実現するために使用する機器や
システム構成・設定するパラメータなどを決めていき、要件定義書や基本設計書・詳細設計書を作成する業務です。

② 構築業務
作成した設計書に従い機器の発注、機器の組み立て(ラックに固定したり、配線したり)、OS・ソフトウェアのインストール、各種パラメータの設定を行い、システムとして要件を満たしているか、正しく動くか動作確認を行います。

③運用業務
システムが正しく動いているかを監視する業務です。システムのログを取ったり、異常がないか確認を行います。障害が起きた場合は、マニュアルに沿った対応や、他チームへの連携など、システムを正しく運用していきます。

④ 保守業務
システムを定期的にメンテナンスをしたり、セキュリティアップデートをしたりする業務です。
障害が発生した際には障害の解消と原因究明を行います。障害が発生した場合は、早急な対応をする必要があります。
また、システムがどのくらいのパフォーマンスを発揮しているかを監視し、期間経過によるリソースの枯渇を予測し、リソース枯渇解消のために拡張や過去データの削除などを提案します。

僕は現在、現在稼働しているシステムのリプレース業務を行っています。
OracleやOSをバージョンアップするため、バージョンアップ先のサーバー構築を行い、現在稼働しているシステムのデータを新しく構築したサーバ内に移す業務を担当しています。

好き嫌いは特にないので、最近よくやっている業務の話になりますが、
作業者の主観や習熟度で差異が出ないよう、また操作ミスが発生しないように、GUIでの操作ではなくCUIでの操作を中心に手順等を作成しています。

GUIを用いての作業手順を使用していた場合、作業担当者の習熟度によって「取得するファイルのフォーマット」や「見間違い押し間違いによる取得ミス」が発生していました。
そこで、CUIを用いて手順書に記載してあるコマンドを コマンド実行画面に張り付ければ、同じ設定で同じフォーマットのファイルを取得できるようにしました。
同じフォーマットで取得できるようにすることで、取得後の報告業務や資料作成をスムーズに行えるようになりました。

僕はフェーズでいうと、構築フェーズが好きです。
資料作成が苦手なので実際に手を動かす方が向いてる気がします。

はい、最初はアプリケーションエンジニアを志望していましたが、インフラも勉強してみたい気持ちがあり、いまはインフラ案件に参画しています。

参画前はアプリケーション開発を主にしていたので、それに比べるとインフラについてほとんど知らない状態で、不安な気持ちでやってみましたが、
何とか作業についていくことができ、任せてもらえる作業も理解しつつ進められています。

プログラムでは実際にユーザが閲覧する画面だったり、
ユーザ視点で考えて開発を進めていくと思いますが、
インフラではユーザが普段見ないシステムの基盤となる部分を構築していきます。

基盤を疎かにしたらまずいので、とても責任のある作業ですが、問題なく作業を完遂できると達成感があります。
さらに知識を深めて様々な作業に取り組むことができるようにしたいと思います。

確かに、そういうイメージはありますね。
基本的には365日24時間システムを稼働させる関係で急な障害対応を求められたり、利用者のいない時間帯でのリリースやメンテナンス作業の関係で、夜勤勤務が必要なケースもあり、これまでの生活リズムが崩れ体調を壊す可能性があるので体調管理には気を付ける必要があります。

また、インフラエンジニアの業務は担当範囲がとても広いため、あれもこれもとタスクを振られて全体のスケジュールや担当タスクを把握しきれず、つい期日を過ぎてしまいがちなので、タスク管理・スケジュール管理が苦手な人は苦労するかもしれません。

運用保守作業では新しいものを作るというよりも、システムが正しく動くように務める裏方作業のため、どうしても影が薄くなりがちです。
そのシステムが障害なく動くためには必要な人員なのですが軽視されてしまうこともあります。
「新しい手順」、「新しい手法」というのは「今のままでも、運用上問題なく行っているのだから」と受け入れられないこともあるので、なぜ「この手順に変えたいのか」、「この手法を取り入れたいのか」を順序だてて説明し、今の手順と新しい手順のメリットデメリットをわかりやすく説明する必要があり、そういった部分が苦労する部分ですかね。

リプレース作業では、稼働中のシステムとの整合性を保つのが難しいポイントだと感じています。

OSやソフトウェアをバージョンアップしたことよるデフォルト設定の差異や、設定ができなくなる、動作が変わるなど、稼働中のシステムを使っているお客様が問題なく使えるように構築していくのが難しいです。

設計フェーズからプロジェクトに携わることで、システムの全貌をより知ることができる点はやりがいを感じます。

それに、システムの規模が大きければ大きいほど社会への影響度も高く、リリース後実際にクライアントがシステムを利用しプロジェクトが無事に完遂したとき、達成感を感じます。
また、[設計]＞[構築]＞[リリース]＞[運用・保守]と、長期契約がほとんどでクライアントや現場の方との信頼関係を築きやすく、次回の仕事に繋がる可能性が高いのも良いですね。

運用保守作業というのは、誰が実施しても同じ結果が得られるようにマニュアルを用意(作成)しておく必要があります。
そのため、知識があると省略してしまう操作も手順としてマニュアルに記載し、マニュアルをお渡しした別のチームやお客様からお褒めのお言葉をいただいたくこともあり、やりがいを感じます。

前述で述べた業務効率化によって、業務において当初かかっていた時間から大幅に短縮できました。 その空いた時間で別の作業を実施するなど、時間を有効に使うこともできるため、効率的に物事に取り組めます。

現在参画している案件が、多くの技術者が参画している大きなシステムで、その一員として作業をしています。大規模システムがどのように開発・構築されていくのか、優秀な技術者はどのような作業をしているのか、エンジニアにとって知っておきたい情報を知れるが楽しいポイントです。
また、現在は検証サーバを扱っているのでいろいろと中身を見れたり、設定を変えて上手くいくか試すことができるので楽しいです。

よくメモを取って、様々な視点を持ってよく気づきがある人だと思います。

業務を通して、メモの大切さが良くわかりました。また、稼働中のシステムとの整合性チェックやエラーの解決をする際に人とは違う着眼点があるとスムーズに解決することがあり、色々な新たな知識が増えたりすることがあります。

インフラという広い範囲で言えば、細かいことに気が付き、それを修正するのが苦にならない人でしょうか。
どうしてもサーバを触る機会が多く、1つの設定ミスやフラグの管理ミスで上手く動かなくなってしまう事もあるため、間違いが起こらないように何人もの目で確認し、設定ファイルを機械的に比較してから適用したりしています。
また、動かないときには「なぜ動かない」のかを様々な観点から観察し、解決を図るためそういった作業が苦にならない人に向いているのではないでしょうか。

プロジェクトをスムーズに進行させるためにも、クライアントの要件を引き出し理解することができれば、フェーズの手戻りを少なくできるため、コミュニケーション能力が高い人はとても重宝されると思います。

それと、インフラに限った話ではないですが、障害やトラブルとは常に隣り合わせのため、発生しうるリスクを予め予想し対策を考えるのが得意な人はとても向いていると思います。

インフラはどう転んでも裏方です。ですが、インフラが無ければ社会の様々なサービスは成り立ちません。
例えば電車の運行システムも、スマホの通信システムも、インフラが無ければ成り立たない、それらのシステムの基盤となるのがインフラであり、そのインフラを扱うのがインフラエンジニアです。
社会の様々なサービスの根幹を一緒に担ってみませんか？

ラピードアクトにはシステムエンジニア、インフラエンジニアの両方のエンジニアが所属しています。
インフラエンジニアの方でもシステムの知識は持っておいたほうがいろいろな面で有利ですし、その逆もしかりです。
両方の知識を身に着けるうえでラピードアクトの環境はとても良いものだと思っています！