インフラエンジニアの仕事は、外から見ると地味に見えるかもしれません。 でも現場でやっていると、技術だけで完結する仕事は意外と少ないです。 確認、調整、説明、ちょっとした気づかい。 今回は、そんなインフラの人間くさい部分について書いてみます。
インフラエンジニアの仕事って、外から見るとかなり地味に見えると思います。
プラットフォームを整える。 サーバを作る。 ネットワークをつなぐ。 監視を入れる。 手順書を書く。
文字にすると、どうしても淡々としています。
でも実際に現場でやっていると、技術だけで完結する仕事は思ったより少ないです。
むしろ、人との確認、調整、説明、ちょっとした気づかいの積み重ねがかなり多い。
今日はそのあたりの、少し人間くさい話を書いてみます。
地味に見える仕事の裏側
インフラの仕事は、成果が見えづらいことがあります。
障害など何も起きない。 サービスや業務が止まらない。 問い合わせが来ない。
本当はそれが一番ありがたい状態なのですが、何も起きないと「何をしたのか」が伝わりにくい。
たとえば、監視設定を見直したり、バックアップやログの取得状況を確認したり、手順書の1行を直したり。 どれも派手ではありません。
でも、こういう小さな作業を放っておくと、あとから困ることがあります。
- 障害時に誰に連絡すればよいか分からない
- 復旧手順の前提が古い
- アラートは出ているのに、誰も見ていない
そうならないように、地味なところを少しずつ整える。
インフラの仕事には、そういう側面がかなりあると思っています。
技術より先に、確認が必要なこともある
以前は、インフラエンジニアの仕事は、もっと技術寄りのものだと思っていました。
Linuxのコマンドを覚える。 AWSのサービスを理解する。 ネットワークの仕組みを押さえる。 アーキテクチャに手を加えて、より良い構成にしていく。
もちろん、それらはとても大事です。 技術を知らなければ、そもそも設計も構築も運用もできません。
ただ、実務では技術に入る前に、確認しておかなければならないことがよくあります。
たとえば、こんなことです。
- このサーバやシステムは誰が使っているのか
- 止めてもよい時間帯はいつか
- 止まると困る時間帯はいつか
- 変更した場合、誰に影響が出るのか
- 障害時の連絡先は誰か
- 最終的に判断する人は誰か
こうした確認を飛ばしてしまうと、技術的には正しい対応をしているはずなのに、現場では思わぬトラブルにつながることがあります。
たとえば、設定変更そのものは正しくても、利用者が多い時間帯に作業してしまえば業務に影響が出ます。
サーバを再起動する手順が正しくても、事前に関係者へ連絡していなければ「聞いていない」と問題になることもあります。
障害時の対応方法が決まっていても、誰が判断するのかが曖昧だと、復旧作業がなかなか進まないこともあります。
つまり、技術的に正しいことと、現場で問題なく受け入れられることは、必ずしも同じではありません。
インフラの仕事では、こういうことが意外とよく起きます。
ここが、インフラの人間くさいところだと思っています。
確認、調整、説明があとから効いてくる
インフラの仕事では、確認や調整がかなり多いです。
正直、面倒に感じることもあります。 「早く設定したい」「早く作業を終わらせたい」と思うこともあります。
でも、あとからじわじわ助かるのは、だいたいこの地味な確認です。
- 作業前に影響範囲を確認していたから、関係者への連絡が早かった
- 手順書に前提条件を書いていたから、別の人でも作業できた
- 監視アラートの意味を整理していたから、障害時に慌てずに済んだ
こういう積み重ねがあると、現場は少し落ち着きます。
すごい技術で一発解決するというより、困りそうなところを先回りして減らしておく。
個人的には、これもかなり大事なインフラの仕事だと思っています。
何も起きない状態は、勝手にはできない
インフラの仕事は、何も起きないと目立ちません。
でも、何も起きない状態は、勝手にできているわけではありません。
誰かが設定を確認している。 誰かがログを見ている。 誰かが手順を直している。 誰かが「これ、本番でやって大丈夫ですか」と立ち止まっている。
そういう小さな確認が積み重なって、何も起きない状態・平和な状態が保たれます。
だから、インフラエンジニアの仕事は地味だけど、意外と人間くさい。
技術だけではなく、人が困らないようにする仕事でもある。 最近はそんなふうに思っています。
今日の学び
インフラエンジニアの仕事は、サーバやネットワークだけを見ているわけではありません。
実務では、人との確認、調整、説明がかなり大きな割合を占めます。
カバーしなきゃいけない範囲が広くて、大変なことも多いんですがね……。
インフラエンジニアだけ、という話ではないのですが、地味に見える仕事でも、あとから現場を助けることがあります。
むしろ、何も起きない状態を支えているのは、そういう地味なことだったりします。
自分の仕事が見えづらく感じる日もありますが、ちゃんと意味はある。
そう思えるだけでも、少し気持ちが楽になる気がします。
次に読みたい記事
この話は、次の記事にもつながります。
- 何も起きないを作る仕事の難しさ
- “確認しました”の中身が人によって違いすぎる問題
- 運用設計は、地味だけど一番あとから効いてくる
- 現役インフラエンジニアが調べた：インフラPMとは何をする仕事なのか
技術の話だけではなく、現場でどう動くか、どう伝えるか。 そのあたりも少しずつ書いていきます。
CTA
この記事が参考になったら、スキ・フォローしてもらえると嬉しいです。
今後も、現役インフラエンジニア目線で、AWS・監視・設計・運用改善・インフラPMについて整理していきます。