この記事はGENDA Advent Calendar 2023の5日目の記事です。
はじめに
新しい会社にインフラエンジニアとして入社して、9か月が経過しました。 この9か月間、難なく対応できたこともあれば、非常に苦労したこともあります。 そこで今回は、入社してから「役に立ったスキル」と「補ったスキル」をそれぞれ振り返ってみようと思います。
役に立ったスキル
まずは、これまでの経験で培ったスキルのうち役に立ったものを紹介します。
AWSの知識
この能力を買われて採用されたのですから、ここは一番大事ですね。
特に、CloudFormationテンプレートを読み書きできることが大きく役立ちました。 入社してすぐ担当プロダクトのキャッチアップから入りましたが、インフラ構成図とCFnテンプレートをあわせて読むことで、インフラがどうなっているかスムーズに理解できました。 自分が使ったことのない機能が使われていても、テンプレートに設定内容が全て書いてあるため理解にはさほど苦労しませんでした。 各サービスができることを一通り知っていることも大きく作用していると思います。
他にも、以下のようなスキルが役に立っています。
- RDSのパフォーマンスインサイトや監査ログ出力、S3に出力したログをAthenaで読む、など調査に役立つ知識
- スポットインスタンスやリザーブドインスタンスといった費用削減の知識
- AWS CLIを使ったスクリプト開発スキル
トラブルシューティング能力
インフラエンジニアあるあるだと思うのですが、知らないプログラムでもログを元にソースコードを追いかけて問題箇所を特定するの、得意だったりしませんか？
「アプリ側でこのエラーメッセージが出るということは……、このエラーメッセージを定義している定数名はこれで、この定数が使われるシーンはここにあるから、なるほどこのメソッドで問題が起きているのだな。このときバックエンドではこのログが出ているから……、原因わかりました」
簡単な問題であれば自分で直してしまうこともありました。
ただこれは、あくまでエラーメッセージやログにヒントがあることが前提となります。 実装担当のエンジニアのみなさん、わかりやすいログを出してくださってありがとうございます。
手書きノートによる情報整理
以前、手書きノートのよさを語る記事を書きましたが、手書きノートを書く習慣は今でも健在です。
基本的にタスクの進め方について細かい指示はなく、どう進めるかは自分に任せられています。 そのため、数か月がかりで進めるような大きなタスクは自分で計画を立てて進める必要があります。 ゴールが遠すぎて、次に何をすればいいか迷ってしまう場面もしばしばありました。
そんなとき、手書きノートが役に立っています。
- 目指すゴールはどんな姿なのか
- ゴールに到達するには何を満たす必要があるのか
- どんな選択肢があり、それぞれのメリット・デメリットは何か
- 今できていることとできていないことは何で、できていないことは何でつまづいているのか
- 関係者は誰で、何を伝えておかないといけないのか
など、自分がおかれている状況をノートに書き出してみると、今の自分の課題や疑問が見えてきて、次にやるべきことが分かります。 例えば、「どうしてこの選択肢を選ぶのか、ちゃんと人に説明できる？ちょっと自信ないな……」と感じたら、「不安な部分をもう少し調べよう」「分かりやすい説明資料を書こう」というように次のアクションを決めることができました。
新しい会社に入社してから、ノートとボールペンの消費ペースが明らかに早くなっています。
補ったスキル
次に、これまで経験がなく学習が必要だったスキルを紹介します。
Amazon ECS
興味はありつつも実務で触れる機会の少なかったECSを、ここへきてガッツリ触っています。 「サービス？タスク？よくわかんない……」という状態から始めたため、習得するまでにかなり苦労しました。
とにかく事例を読み漁ってみたり、
ハンズオンをやってみたり。
ありがたいことに時間をかけてじっくりやらせてもらい、（いくつか課題は残るものの）自分ひとりで環境を構築できるまでになりました。
GitHub Actions
自分の担当プロダクトではCI/CDの一部にGitHub Actionsを使っています。 GitHub Actionsを使うのは初めてだったので、これも0から学習しました。
AWS公式が便利なアクションを提供しているので、変わったことをしなければ簡単に実装できるのが非常に便利です。 今回は上述したECSと合わせて、GitHubからECSにデプロイするワークフローを作りましたが、大まかな流れはほとんど公式サンプルの通りです。
ただし、正常系を書くだけなら簡単ですが、「リトライ時の挙動は？」「Revertしたときの挙動は？」というように異常系を考慮すると記述量が増えます。 これは全てのプログラミングに共通して言えることかもしれませんね。
Datadog
多機能な監視ツールです。 できることが多く、未だにすべての機能を把握しきれていません。
自分の担当プロダクトでは、ログ収集、APMのトレース、SLO、ダッシュボードを主によく利用しています。
入社時にはすでに前任者がいい感じにセットアップしてくれており、ログ収集とAPM、各種メトリクスは見られる状態でした。 前任者いわく「セットアップは簡単だった」とのことですが、それが本当ならこんな充実した機能を簡単に使えるのはすごいことだと思います。
入社してから自分で設定したものは、主に以下の2つです。
SLO
サービスの中でも重要な機能をSLI（Service Level Indicators, サービスレベル指標）として定義し、閾値を定めてSLO（Service Level Objectives, サービスレベル目標）を設定しました。 例えば、「〇〇機能が0.1秒以上かかっていたら異常なレスポンスとみなす」「7日間でレスポンスの99.9%が正常でなければならない」といった設定をしています。
SLI・SLOについては概念こそ知ってはいましたが、実務に取り込むのはこれが初めてでした。
ダッシュボード
現在起きている（または起こりそうな）問題を検知したり、過去に起きていた問題を調査するため、サービスの状態を俯瞰できるダッシュボードを作りました。 毎朝出勤してすぐ確認することを日課としています。
まだメトリクスを並べるしかできてないので、もう少し使いこなしたいです。
まとめ
自分のスキルが活かせるだけでなく、新しいスキルを伸ばす機会も得られたのがうれしいですね。
そんな弊社ではインフラエンジニアを募集中です。 イケてるインフラを作りたい！という方をお待ちしております。
来年もどうぞよろしくお願いいたします。
