今年（2023年）1月に開発からインフラへ鞍替えとなりました原井です。
今回は、異動後約4か月（※）で考えたことを書いてみます。
※途中、開発プロジェクトの応援要員期間が2か月ほどあるため
仕事内容について
まずは、異動前・異動後の、実作業と利用する言語やツールなどをリストアップしてみました。
★Before
●サーバーサイドのプログラムを開発
使用言語は主にPHP、たまにPython、ごくまれにKotlin/Java。
●インフラ業務経験は皆無（※）に近い。
※GMOリサーチ入社以前、WindowsServerの設定をやったことがある程度。
基本的なbashコマンドは叩ける。
Linuxでアカウントを作るくらいはできる。
★Now
●サーバー構築：CentOS7→AlmaLinux8へのリプレースが現在のメイン業務
◎AWS CLIを叩いてEC2インスタンスを作る
◎現行サーバーの構成からAnsible playbookを作成する
◎playbookを実行して現行のAlmalinux8版サーバーを作成する
●サーバーや各種ミドルウェアのアカウント作成・削除
●AWS ロールやポリシー、s3バケット、ssmパラメータの作成
●ネットワーク関連作業（DNS,LB,SSL証明書etc）
●データベース関連作業
●データセンターで物理サーバーの入れ替え
この中で、初めて触ったものは、
●AWSコンソール
●Ansible
●LB管理画面
●VMware 管理画面
●メール監視
●6年間未担当のサービスのプログラム
ほとんど初めてのことばかりです。
ちなみに、マネージャーやチームリーダーには、EC2インスタンスを操作する方もいます。私の位置的に、管理系の作業とは距離があったため、初物が多かったです。
なお、引継ぎまで至っていない業務として、外部業者との交渉や、予算管理・契約関連も存在します。
インフラ業務を担当して感じた開発との違い
上述どおり、仕事内容が全然違うので、戸惑うことも多い日々です。
具体的に、両者がどう異なるのか、こちらもリストアップしてみました。
★開発業務
●柔軟な正解
●要件を満たす、というゴールは決まっているが、かならず開発すべき、でもない
●時に運用で対応するという選択肢も出てくる
●機能をフル装備してリリース延期するか、一部機能を削ってオンスケでリリースするか、状況によって変わる
●要件定義後に要件が変わることがある
●あるプロジェクトの担当になると、完了まで集中する（２～3か月）
※障害対応は最優先
※長期プロジェクトはフェーズを分ける対応をしている
●一つ開発言語を知っていたら別の言語もどうにか対応できる
●インフラ的なことを知らなくても開発はできる
★インフラ業務
●こうあるべき、と決める必要がある
※拡張も見越して要件を決め、利用機器やサービスに規定される分、変更の余地が少ない
●とにかく作業対象が広い（AWSだけでも多機能すぎる）
●応用がきかない（メーカーによっても操作やコマンドが変わる）
●長期と短期が両極端
◎長期は、2年後3年後の対応すべきことまで決まっている
◎短期は、その日その日で作業が変わる
◎開発者が作業できるように、他部署メンバーの業務が滞らないように、あるいはセキュリティ対応として退職者の処理を速やかに行うなど、割り込みが頻発する
●作業は、サービスが止まる危険性と隣り合わせ
●様々な作業で特権を利用することが多いため、緊張感が高い
※開発時はコマンドやリリースツールに置き換えていることが多いが、インフラは手順書を作成し、正誤確認が必要
※もちろん、機器の冗長化や作業範囲・順序の工夫によってオペレーションミスが発生した際のリスクを可能な限り低減した上で作業しています。
●力仕事がある（物理サーバー入れ替え。サーバーは重い）
●LB管理画面、Vmware管理画面のUIが不親切で使いにくい
●予算が高額になる（物理機器の購入やリースがあるため）
開発業務は、良くも悪くも「何をすべきか」がある程度わかっていることが多く、思い返すと、以下のようなことを中心に考えていたように思います。
- 仕様は？
- どのように実現するか？
- そもそも実現できるのか？
- 実現が難しければ、逃げ道はあるか？
- 開発にはどのくらいの時間が必要そうか？
一定程度、思考のルーティン化ができるのが開発業務じゃないかと思います。
そして、サービスイン時期が決まっているので、短期集中することができます。
一方で、インフラ業務は、知らないことや初めてのことの連続で、教えられたことをなんとかこなす状態に加え、優先順位が日々変わり、かつ対応する領域が全然違ったり。
年1回しか発生しない作業も存在しますので、経験を積めばルーティン化できるかもしれませんが、それは果たしていつになるのか、見当もつきません。
開発経験はインフラ業務に役に立っているのか？デメリットは？
やってることが全然違うとぼやいたところで、とはいえ、開発業務の経験がまったく役立たずだったかと言えば、そうでもありません。
現時点のメイン業務、サーバーリプレースでは、GMOリサーチ社のサービスの仕様をある程度知っていることはメリットかと感じています。
- 当該サービスに関連するサービスをある程度わかっているから、調査対象を絞り込みやすい
- 実行するAPIや参照するデータベーススキーマを知っているため、比較的スムーズに動作確認できている
あと、毎年の情報棚卸業務をスクリプト化もやりやすかったと思います（今ならAIにさくっと作ってもらえそうですが）
デメリットは、現状特に感じていません。
ソフトウェアの世界と違って、ハードウェアの世界の要素が強い分、ツール類のUIが使いにくいことに不満を感じるくらいでしょうか。
最後に
今回は、同じエンジニアでありながら開発エンジニアとインフラエンジニアではまったく違う領域だということを書いてみました。
実は、ジョブチェンジしてまだ4か月であること、できることがあまりに少ない状態で、この記事を読んでプラスになるようなことはなにか・・・と考えたら、全然書けなかったのです。
これが、1年後であっても、同じように悩んでもがいていて、いったい何ができるようになったんだろう・・・と自問自答する自分が容易に想像できます。
その一方で、開発者になったのがだいぶ前で記憶も薄れてはいるものの、この4か月ほど手探りの状態ではなかったと思います。
これを踏まえて、ここはもう、少なくともGMOリサーチでは珍しい、開発→インフラへ異動した人間の正直な感想を書くくらいしかできない、と開き直ったのがこの記事になりました。
念のため、追記しておきますが、インフラメンバーは、他に2人いて、この方々がGMOリサーチのインフラ屋台骨を支えており、私は、彼らが忙しくて優先順位を下げざるを得ない作業を拾っているに過ぎないのが現状です。
有益な情報とはいいがたいですが、開発業務とインフラ業務の文化の違いを感じていただければ幸いです。
読んでいただきありがとうございました。
