「インフラ経験0の新卒エンジニアがインフラエンジニアになるまで」を読みました
はてなブックマークにインフラエンジニア関連の記事が上がっていたので、感想を書いてみたいと思います。
感想
インフラエンジニアのレイヤーが曖昧になっている
全体としてまず感じることは、インフラエンジニアという言葉のレイヤー（階層）がとても曖昧になってしまったことです。
レイヤー、ということでその階層をまとめます。
・ミドルウェア
・OS付属のライブラリ（OS標準のリポジトリで管理できるレベルのもの）
・OSそのもの
・仮想マシンの管理
・ロードバランサー
・ファイアウォール
・ストレージ
・ネットワーク設計（IPv4, IPv6）
・サーバーラック
・ケーブリング（LANケーブル・電源ケーブル）
・回線（インターネット回線、専用線等）
・データセンター
・バックアップ、監視、定期バッチ実行等の運用管理
アプリケーションのみ携わっている方は、上記のレイヤーをあまり意識しないかと思います。最近はクラウドを利用している場合は、物理的なものは抽象化され、クラウドベンダー側で管理してくれるようになりました。一方、オンプレミスのシステムをまだ運用しているのであれば、上記のレイヤーは相変わらず存在します。
昔は、インフラエンジニアと言えばサーバーとネットワークに分かれる、というのは度々書いていますが、クラウドが出てきたことにより、両方を一人のエンジニアが担当することも普通になってきました。ネットワーク設計は、クラウドだとGUIで設定した通りに論理的に動くので、CISCOだJUNIPERだYAMAHAだ・・といったベンダー間のお作法を吸収する必要もなくなりました。サーバーも段ボールから開梱して部品を組み立てて・・・データセンターに運んでケーブルを・・みたいな作業からも解放されました。
結果として、インフラエンジニア＝クラウドエンジニアという傾向がこの文章から見ても強くなっているのではないかな？と思いました。悪い意味で言えば、どんな分野でも少人数で対応しなければいけなくなり、若い人が短時間で把握するのは難しくなっているという感覚です。
少人数の体制は危険、でも・・。
おそらくこの記事の会社でも、「隣に座られていた先輩エンジニアが、1人でリニューアルのインフラ基盤の構築」を今後も手掛けるのはマズイと言う感覚があり、著者が冗長化の意味でアサインされたのではないかと思います。
経験的な話なのですが、せっかく体制に余裕ができたと思ったら、急に退職する話になります。もう何度も何度もあります。絶対に冗長化したほうがいいんですが、せっかくできたと思ったら辞める話になる。
これはなんなんでしょうね。きっと、自分が辞めてもすでに誰かと共有しているので大丈夫、という心理が働くんですかね？。たまたまマネジメント側にいるとたまったものではないです・・。属人化ダメ。けど、解消すると人が辞めるんじゃ元も子もない。
この仕事、オレじゃないと誰もできない、そんな感覚ってもしかするとインフラエンジニアには必須のエキスなのかもしれないです（ある意味迷惑ですが（笑））。
おそらく、サブの人は、今のままだとメインの人がいて出世できないから、手ごたえができた時点で他社で勝負してみようと思うんだろうなあ・・。
インフラ＝クラウド、というのは実はそうとう新しい
下記の表現は、私の考えるインフラとは、全く別の定義なんだなあという感想です。
インフラに興味があったとはいえ、入社前にはHeroku上にRailsアプリケーションを乗せるくらいの経験しかしたことがなく、Webアプリケーションがリクエストを処理する仕組みやネットワークの仕組みなどは、全く理解していない状態でした。
更に、リニューアル後のインフラ環境はAWSを使ったクラウド上に構築することが決定されており、AWSを使ったクラウドの基礎知識も必要でした。
インフラと言えば、どうしてもデータセンターやインターネット回線や構内LAN、サーバーやネットワーク機器周りの下のレイヤのイメージです。いきなりクラウドのある世代は、インフラのイメージが１８０度変わってしまっているんだろうと感じました。
yum -y updateは、こわい
このケースの場合は仮想環境ということで、スナップショットを取ってから適用すべきでしょうね。アプリケーションに不具合があったら戻しを行うプランとすべきでしょう。
また、rubyをインストールするだけなら、rubyをインストールするだけの作業にすればよいのに、OSのパッケージ全体をアップデートするのはリスクしかないのでは？とも思います。
また、-y付きというのは、途中の大事なメッセージを読み飛ばしたり、また途中で中止するような状況（作業中に地震とか・・）が起こっても引き返せないなど、リスクがあります。私なら、-yはつけさせないかなあ。
なお、yum updateを定期的に行うのがセキュリティーポリシー、というのはこれは間違いではないので、是非、以下の運用手順をお勧めします。
・問題が起こっても業務影響の起きない環境（ステージング環境）を横に用意する
・本番適用前に、ステージング環境で適用テストを実施する
・適用後の動作テストは、できるだけ早く終わるように自動化するなど手順を整えておく
・本番適用は、ステージング環境で問題なく完了した後に、業務影響がない時間に実施する。また動作テストでNGだった際には、スナップショットから戻すなど、中止する方法も整えておく
そもそもカーネルはアップデートしないで、yum update -yだけするというが許されるなら、rubyだけ入れとけばよかったのではと思う次第です。
慎重に・・とは言うけれど
本番環境でコマンド打つ際に心が震えるようになったら、インフラエンジニアとしてはまずレベル１クリアだと思います。
サーバに変更を加えるコマンドはめちゃくちゃ慎重に打つ
暫くは上長に見てもらう or 上長に打ってもらう
で、上長に打ってもらってばかりいたら、成長しません。
基本は手順書を作って、上長に承認してもらい、あとはその手順書を遵守することだと思います。重要な作業の場合は二名体制で臨むべきです。そして、一つ一つの結果を注意深く見て、例外が起きたらそこで手を止めることが重要です。
慎重、というのはこれも危ない言葉です。手順をちゃんと理解していないと、そのコマンドが何をするかわからないので慎重になりようがないのです。
従って、手順書作成の時点で、慎重かどうかがわかります。このコマンドの意味は何？、と質問されてきちんと答えられることが慎重と言うのだと思います。
コマンドを打つ時の慎重さも重要ですが、実は作業実施前に９割は決まっていると思っています。
もっとベテランになると、各種障害の対応など、手順書なしでも作業しなければいけません。これは手順書無しだから慎重ではないのではなく、手順書を書かなくてもコマンドの意味を熟知しているから、そのコマンドを投入する事をリスクなくできるというだけです。ですから、知識が浅い人は、ベテランのように手順書無しでOSのコマンドをパシパシ叩くのは、とてもリスクがあるというのが私の意見です。
業務上知識が足りないから裏で勉強するというのは非常に効率的
AWSが仕事上振ってかかったら、どんな手段でもいいのでさっさと身に着けてしまえば、仕事が相当楽です。社内外の誰かに尋ねられたときに答えられないと、信用を無くします。また、各種タスクの生産性も全然変わってきます。
プライベートの時間を削ると幸福度が下がる、という見方もありますが、むしろ会社にいる時間を有意義にしたほうが幸福度が上がります。四の五の言わずさっさと身に着けてしまうに限ると思います。とくにインフラ関連は、自社だけではなく他社でも同じように使えるので、一生使えるという、相当に投資効果が高い分野です。
仕事で使う予定のない勉強は、なかなかモチベーションも上がらないのですが、筆者のように社内基盤自体がAWSになるという状況で、インフラ基盤の役割が回ってきたら、何にも優先してまず裏で勉強して、誰かに尋ねられたら、生まれる前から分かっていたかのように答える。これが王道だなあと思います。
また、資格については、私はそんなに大事だとは思っていません。10年経ったらただの紙です。むしろ勉強するためのモチベーションとして考えたほうがいいと思います。資格があろうがなかろうが、仕事はやらなきゃいけないですから。
AWSエンジニアとインフラエンジニア、という哲学的な話
最後まで読むと、インフラの話がAWSになっていて、考え込んでしまいました。
今の世の中なら、AWSだけの業務経歴であっても別の職場で活躍はできると思います。ただインフラエンジニアを標ぼうしつつ、業務経歴がAWSだけだとすると、これはインフラエンジニアじゃなくてAWSエンジニアですよね、と言ってしまうと思います。
あと20年後、どうなっているか。
ますますサーバーサイドはAWSに飲み込まれて行って、AWSエンジニア＝インフラエンジニアという世界がやってくるのか。今のところ、筆者の会社でも開発環境はオンプレミスのようですが、きっと開発環境もAWSに移行してしまうのでしょうね。
そんな会社ばかりになれば、AWSエンジニアという職制が確立するのかもしれません。
私の予想としては、オンプレは残ると思っています。データの中身によってパブリックプライベートが使い分けられ、その間をプライベート回線でつなくというハイブリッド利用が現在のトレンドになっていると思います。
クラウドサイドだけ扱うクラウドエンジニア（私もそうですが）を極める場合は、どうしてもオンプレミスの知識も必要です。完全にオンプレミスから離れたいなら、PaaS的な使い方を極めていくことになります。その時点で、インフラ屋、ではないかなとおもいます。プラットフォーム屋という言い方が近いです。
まとめ
普段、インフラエンジニアなど基盤系の職制は、なかなか表舞台に出にくいので感想を書いてみました。インフラや本番運用の世界は深くて厳しいので、ぜひ、先輩から学んでどんな現場でも活躍できるスーパーエンジニアを目指してほしいものだなあと思います。上に書いたように、AWSだけがインフラではないですし、本番運用の安全オペレーションはITILみたいなところもかじったほうが良いかもしれません。
20代の若いうちに裏で必死に勉強していれば、30代40代で活躍できると思います。インフラ関連に携わっている若い人を今後も応援したいですね（私の周りにもあまりいないので）。
新人エンジニアのためのインフラ入門 ThinkIT Books
