世の中のブログではよく SIer から Web への転職の記事をよく見かけますが、プログラマの例が多く、インフラエンジニアの場合の記事が少ないように感じます。

私自身が今年8月で、SIer から Web のインフラエンジニアに移り1年が立ちました。今までの経験を振り返り、インフラエンジニアへ転職してどうだったかを一つの例として、書いて行こうと思います。

カスタマーサポート時代

新人配属から BtoB 向け SaaS のカスタマーサポートをしていました。

殆どの仕事は、契約周りやお問い合わせの回答を行い、たまに自社データセンターで運用しているサーバーのディスク交換やサーバーの追加作業を行っていました。

扱ってたサービスが社内ツールだったこともあり、プライベートクラウドとしてお客さんのデータセンターにサービスを構築しに行ったりもしていました。

あるときはサーバーのキッティング作業から Capistrano を書いたり、実際にWebサービスのリリースまで行い、あるときはずーっと電話やメールをしていたりと、"カスタマーサポート"+"インフラエンジニア" の二足のわらじを履くような状態でした。

インフラ技術を一通り経験できたのは非常に良かったと思います。

それとは別に当時流行っていた Chef や Docker を趣味でやっていて、自分の環境用に構築していました。

Web 業界のインフラエンジニアへ

紆余曲折あって、去年の8月よりインフラエンジニアとしてWeb業界へ移りました。

1年を通してどういったことを行ってきたか時系列で書いていきたいと思います。

キャッチアップ

移ってから最初の2週間は怒涛の技術キャッチアップでした。

インフラ技術については、ある程度趣味で触っていたこともあり、全くコンテキストが理解できないということはあまりありませんでした。

そのため、チュートリアルを踏むというよりは、実践を通して Why-How-What を共有することがメインでした。

このキャッチアップから、ほとんどの業務を回せるようになりました。

この業務が回せるようになったのは、用意してもらった資料と講義内容・演習課題が完璧だったからだと思います。理解しやすい構成になっていて、インフラエンジニアの教科書みたいになっていました。

この時に、実践と趣味では全然求められる知識の深さが違うというのを感じました。

スピード感をあわせる

オンプレミスから IaaS に移り、サーバーをどんどん作って壊しての世界になりました。またこれまでパートナー含めて2−3人位で運用と開発をしていたのが、一気に数十人のプログラマと数個の自社サービスを扱うようになりました。

そのため1年で倍のサーバーを扱うといったこれまでにない体験をしました。また、便利なツールを作ったり、全 OS を Ubuntu から CoreOS へ入れ替えたりと結構アグレッシブな体験もしました。

サーバーを1台買うのにベンダーに見積依頼して、WBSを書いて、ラッキングを行ってという長いスパンでやっていたのとぜんぜん違うスピード感で動いていて、今後は、こういった現場が増えていくんだろうなと思います。

スキル

Wantedly の文化を支えるインフラとビジネスの変化に強いインフラ / #jtf2016

現在、"プロダクティビティを高めるツール作り" や "新しいサービスを早く出せるための仕組み" をインフラチームでは行っています。

そのため、運用業務以外に、技術調査検証やコードを書いたりすることが業務のメインになっています。また、運用業務を減らすために既存基盤についてはどんどんコードを書いて自動化を行っています。

扱ってる技術のキーワードを並べると Docker や Capistrano だったりとこれまでとあまり変わりませんが、扱うサーバーの台数だったり、よりスケールしやすいように仕組みを入れたりするためにより深く知る必要があります。

細かくドキュメントを読んだり、オープンソースのコードを読んだり、世の中ではどうしているのか調べたりと、これまでのキーワードやニュースを追っていたのと全然違う「 Production で使えるのか？」という視点で見ていかないといけません。

カルチャー

Developer Infrastructure in Devlove Kansai

先日、元 Facebook の方から 立ち上げや Growth の話を伺いました。

その時に、

「今潤沢なエンジニアがいた時にどういう組織構成にするか？という質問に対して、ザッカーバーグはエンジニアの半分を社内インフラに当てる」

というエピソードを聴きました。

今までの経験からインフラ作業を片手間だったり、スポットで SE 業務を行ったりで、なかなか組織においてあまり重要なポジションではない印象でした。実際にそういう話を上の人から聞いていました。

インフラがすごく重要なポジションであるという話を聴いてカルチャーショックでした。

今の職場も同じ思想を持っておりプレッシャーもありつつ、すごくやりがいを感じています。

コーディング

アプリケーションを書くプログラマと比べると全然少ないけど、業務の殆どはコードを書きます。

Dockerfile や shellscript などから golang だったり Ruby を書いたりしています。この業界に移ってから最初は本当にこのコードを書くことが大変でした。そして今も結構崖っぷち感あります。

とりあえず毎日コード書いたらなんとかなるんじゃないかと思ってとりあえず芝を綺麗にしていました。

面白いことに半年もすると少しづつコミットの量が増えてきます。

最初の方はリアルにコミットの量が少ないと釘を刺され、崖っぷちで終わると思っていましたけど最近では全然指摘されなくなり、「書けるようになったね」と言われるところまで崖から少しずつ遠ざかってきました。。。

アーキテクチャ

マイクロサービスのための綺麗なAPI設計

設計と読み替えた方が業界によっては想像がつきやすいかもしれません。純粋にセンスと言われたりする部分でもあります。ここはそもそもの経験値の差も大きい部分です。

わかりやすい例だと Microservices で、実際にグローバル分散システムの経験と実績を持っている人と持ってない人で抑えるポイントが全然違ったりします。

コードを書く上でもこのスキルは必須ですし、エンジニアとして成長していくためにもここの スキルは必須だと思います。

ここができている人とできてない人の違いは、その人がいることで来年、再来年インフラ基盤が常に成長できそうだなと傍から観て思えるかどうかだと思いました。

他のWeb業界の人や SIer 、ベンダーの諸先輩方とも話をしていて、同じようなことを仰っていてなんとなく感覚的にあるんだろうなと思います。

例えコードがかけたとしても、「この人がいれば事業を支えるインフラが成長しそうだな」っと思える人は本当に少ないです。こういう人がどの業界でも会社を支えているんだろうなと思います。

インフラエンジニアにとってどういう現場が良い？

つらつらと書いてきましたが、SIer にいても Web にいても、インフラの経験は出来ると思います。受託でもどれだけ相手企業の成長にコミット出来るかで Web 業界と同じ体験も出来ると思います。

事業が成長するかどうかで、たくさんスケールするインフラを構築する機会があることが多いし、最初からでかいインフラを見ていいればその分、大規模インフラの知見も得られると思います。逆もしかりですね。

数年間変化がなかったりやってることが変わってなかったら、インフラエンジニアとして危険だと思った方が良いと思います。

1年を通して

スピード感を合わせる -> スキル -> カルチャー -> コーディング -> アーキテクチャ と分類して1年を通して経験をまとめました。

これを気にインフラエンジニアとしてどういう風に成長していきたいか考えるキッカケになれば幸いです。

Next

今はアーキテクチャについて考えています。

どうなったら力が付くのだろう。。。

最近 1on1 で話をしていた内容をご紹介してこの Blog を締めくくりたいと思います。

2つの力を付けることでだいぶ良くなるのでは？というアドバイスを頂いたので紹介します。

抽象度を上げる

今自分自身の課題は何かを振り返ってみて「どうしたいのか」「今後どうなるのか」で迷いが出る部分だと思っています。

実装までたどり着ければそれなりに進むけど、その前段階で設計とか方針で迷うことが多々あります。

一個の細かい課題に対して解決を探そうとするといろいろ方法があってどれを実施しようか迷う、そんな時は抽象度(レイヤー)を上げて考えるといいというアドバイスを頂きました。

例えば、世の中のアルゴリズムというかプログラミングで言うと、
上から順番に計算していくのが手間だったのを最初は関数でまとめた。
それでもFATになったからクラスが出来て、
Application単位が出来て、
サーバー単位が出来て、
サービス単位が出来てという風にどんどん抽象度を上げていって解決を図っていることが多い。

1. 一個一個の問題を同類文意で並べる
2. 各問題の解決策を出す
3. 一個抽象度を上げてまとめて課題を取り扱って解決出来ないかを考える

以上のような、考え方の癖をつけると良いというアドバイスを頂きました。

センスを磨く

設計、方針は自分でどこまで詰めれるかがポイントで、考える人のセンス次第で決まって来る場面が多いです。

とは言え、センスは普段の訓練で磨くことが出来るという話を聞きました。

例えば、log について何を出せばいいかを考えた時に、

before

1. とりあえずデフォルトのままにしといて、今まで何かあった際に log を観て適当にそれっぽいものを都度ググる
2. 最近ネットで話題になってたのを使う

after

1. logはどうなっていると使いやすいのか?
2. logはそもそも何があるのか？
3. syslog や application log や nginx や apache log がどういうフォーマットになっているか?
4. どういう形式になっていると取り扱いやすいのかモニタリングツールを調べる
5. ネットワークが切れた時やmemory が枯渇した時に syslog は何を出すのか？ appplication log は？ nginx や apache のlogは何を出力する？
6. 最終的に何を log を出力して、どういった形でまとめられると使いやすいのか？
7. これらをまとめて、どういう log をどういうフォーマットで、どれをどう出すべきかを決める

上の2つの違いはググる前に仮説を立てて課題解決をしているかどうかの違いです。

仮説を立て、分類し、答えを一旦自分の中で出してからググることで、自分の間隔と世の中で活躍しているエンジニアとの考え方のギャップを埋めていく訓練になるということでした。

それ以外に、自分自身で一度分類を行うため、今自分自身がどういう技術を知らないのかを把握するのにも役に立ちます。

最近では、何かわからないことがあるとすぐにググってしまい、単発の回答だけで満足してしまいがちです。そのため、なかなか思考力が育たなくなって来ているのではないか？という話をしていました。

ググる前に、一度仮説を立てて、整理する訓練をすることでどんどん力がつくとアドバイスを頂きました。

二年目も頑張るぞ(๑•̀ㅂ•́)و✧