この記事はeeic Advent Calendar 2015の15日目の記事になります。
※この記事は個人の見解であり、所属する組織の公式見解ではありません※
自己紹介
eeicからそこそこ大手なSIerに就職しました。
修士はもろもろのアレで行きそびれたので都合社畜2年目です。@amiq11とかと同期のeeic2012。
巷ではブラックでまとめられてしまう業界の雰囲気とかノリとか書きます。
キャプチャーザフラッグはしません。パケットキャプチャはします。
なにしてるの
俗にいうインフラエンジニアでクラウドとかLinuxとかミドルウェアの設定作業が多いです。
具体的にはLVM切ったりとかログがパンクしないようにメンテシェル書いたりとかバックアップスクリプト書いたりとか。
学科にいた頃書いてたものと比べると簡単だと思ってたんですが、
毎日動かしてもネットワーク切断などでエラーが発生しないようエラーハンドリングするのは意外と大変だったりします。
findとかいうコマンドが-exec内での成否を返してくれなかったりとかでブチぎれたりします。
オンプレの場合はサーバーを納入したりとか搬出したりとかもしました。
アプリレイヤから下はなんでもやるといった感じです。
当初からeeicではゲームAIとかやってたんで人工知能系（弊社だと呼び方違うんですが）を希望してたのですが
「クラウドとか興味ない？」って言われて当時utmcでやってたSalesforceの話を思い浮かべてあります！と言ってしまったのが運の尽き。
働き方
プロジェクトは提案活動から始まりますが、大抵は営業さんとお客さん付きの技術営業さん、
あとはシニアエンジニアが入るので新卒だとやるとしてもソリューションが実現可能かどうかという検証作業が主になります。
基本的には調べて報告するだけなので一番自由に時間を使える時期だと思います。もちろん場合によっては大変ですが。
設計・構築に入ると、各サーバのロール（Webサーバ,DBサーバ,MQブローカ,監視サーバ,アプライアンス,etc）に合わせて
CPUやストレージの割り当て（LVMを切る）やiptables(firewalld)、ネットワークの設定（ゲートウェイやIP割り当てなど）、
カーネルパラメータの設定、バックアップシェルなどの運用スクリプトの作成などなどをします。
運用スクリプトは基本的にcronやそれに類する商用製品で回すのですが、バッチを当ててからバックアップを行わないといけなかったりするので、フラグファイルを生成してそのフラグファイルのあるなしで前のジョブが終了したかを見たりします。
まあcronじゃなくてまともなジョブスケジューラを使えばその辺はもうちょっと綺麗にできるんですがポリシー的にOSS入れられないとか綺麗にするためだけに商用製品入れたくないとかだとエンジニアが面倒みないといけないと思います。
設計と構築はフェーズとしては明確に分かれてるんですが、若干構築を前倒しにして設計しながら構築することが多いです。
とはいえアーキテクチャ設計は提案時にある程度決まっており、基本設計（大まかにこういう方針で設計するという取り決め）はしっかりやったあとの話になります。
そしてネットワークの疎通確認や、OSの設定が正しいことの確認（最近はServerspecとか流行ってますがポリシー上使えないので自作のシェル使っています）、ミドルウェアの単体テストやパフォーマンステスト、さらにはアプリまで含めてのシステムテストなどを行います。この時期が恐らく最も忙しく、特にシステムテストは関係者全員を集めてトラブルがないかを確認するため、拘束時間が伸びる傾向にあると思います。
ここさえ乗り切ればあとは世界にIPを晒すだけです。既存の本番環境との切り替えの場合はBlue-Green DeploymentじゃないですがDNSを書き換えて（TTL短くするとか浸透を早くするTipsがいくつかあります。）振り先を新しい環境にすることで対応します。
ここまでくればインフラは技術支援に入るので適度に自学したりドキュメントを整理しながらトラブルに対応していきます。
時間的な忙しさとしてはプロジェクト終了間際の技術支援～提案開始時までが一番余裕があり、テストが一番余裕がないです。
ハマりポイント
たとえばネットワークは環境によって千差万別です。
クラウドでSDNを使う場合はVyattaなどのソフトウェアルータ、
オンプレミスならCisco製品などの知識が必要になります。
大抵はそれ専門の部隊がいるので任せちゃえばいいと思うのですが、問題が発生した時に切り分けられるだけの前提知識はあった方がいいと思います。（そういう場合特に効いてくるのはどっちかっていうと製品そのものの知識ではなくネットワークそのものの基礎力だったりするのですが）
結構問題になったのが全体のMTUをVyattaで調整する際、外向きのMTUをNTTフレッツの指定よりも大きめに設定してしまったために、一部のパケットが不通になるというものでした。
このときはアクセスする場所によってアクセスできたりできなかったりしたのでWireShark（クライアント側）とtcpdump（サーバ側）を使ってパケットキャプチャし、どこで不通になっているかを検証する羽目になったりしました。
他に大きなものとしては、DBサーバにおいて索引がバッファプールに載っていないがために性能があまりでなかったり、SQLクエリがやたらネストしてたりで遅くなってしまったケースなど、パフォーマンスチューニングの切り分けで苦労したりします（DBMSにもよりますが、せめて索引だけでも全部載るように調整した方がいいかと思います）。他にも色々あるのですがきりがないのでこの辺で。
やりがい
「アプリ以外全部」というくくりなので、ネットワーク-ハードウェア-OS-ミドルウェアまでは全てわかる必要があり、意外とやること多いと感じています。
特に問題が発生した場合はsyslogやミドルウェアのログはもちろん、インフラが原因であってもアプリのコードを読んで逆に問題個所を特定することもあるので、JavaやPHP、perlの知識なども役立ちました。
また、システムをきちんと作り上げてお客様に褒めていただくと頑張った甲斐があったなあと感じると思います。
お給料も上流の方なのでそこまで悪いとは感じないですし、そこそこ普通に暮らせていると思っています。
慣習とか
・テキストエディタ
Vimです。圧倒的にVimです。UTでは最初に触るのがEmacsだったりする人も多いかと思いますが、
サーバー管理寄りの世界では圧倒的にVimmerが幅を利かせています。
案件に入った当初とかは「Vim使えないんすかｗｗｗｗワロスｗｗｗｗ」みたいな扱いを受けたので速攻でVimtutorで勘を取り戻しました。
なんでお前のためにEmacsなんて入れなきゃいけないの？って感じの文化なので、慣れるしかないと思います。
まあVimでマリオもできることですし、慣れておいて損はないかと思います。
・エクセル
こいつを殺さないとSIerに明日はない。
とまで思ってますがお客様的にはいくら払ってでもエクセルに拘る理由があるようなので、
Forguncyよろしく効率化しましょう。シェルで環境のテスト用スクリプトを走らせ、
結果をC#やPowershell、ExcelVBAなどの.NetからExcelをいじれる言語を使って.xlsxファイルを自動生成するのがベターだと思います。
探せば社内ツールとかその辺に転がっていると思いますが、個人的には日本のためにOSSにするべきだと思います。マジで。私が勤務時間中に書いたのはちょっといろいろアレで晒せないから頼む・・・頼む！！
・議事録
なんかWordでまとめます。これはWebだろうと普通の企業だろうと書かないといけない場面もあるかと思います。音声認識でどうにかしようとしましたが、ちょっと手に余りました（認識精度がいまいちなの&自動でまとめるのしんどい）。研究室のNLPマンが似たようなことやってたと思うんで教えを乞いたい。
・残業
人と案件と立場によるけどする人はすごいする。しない人はほんとしない。
入った案件次第では先輩より先に帰るとかないわみたいな雰囲気だったりするので本当に案件依存です。
お勉強環境
SIerもWebもたぶんIT会社にくくられるところは一般に勉強会とかしたがります。
私は人工知能系の研究会みたいなのに所属してこういうAPIとeasyRTCというWebRTCのライブラリを使って
上記の議事録自動化アプリをPaaSを利用して作ったりしました。
WebRTCは他にPeerJSとかもありますが、個人的に切断管理とかルーム機能とかしっかりしてるのでライブラリ使うならこれ一択だと思います。イカデンワとかもこれらしいですね。
エラー時に勝手にDOMをcreateしたりするのでめっちゃカスタマイズしましたが気に入ってます。
最近のCloud Foundryはなかなかすごく、BluemixではJazzhubというGithub的なモノにpushするだけでビルドが走るようになりました。他にもSlack連携などもできるので「あれ…これ楽すぎて（インフラの）仕事なくなるんじゃね？」って思ったりしました。なくなったらなくなったでジャバを書いて生きていけばいいと思うんですが。
これからのインフラ
先ほど「あれ…これ仕事なくなるんじゃね？」って言いましたが、コスト的にPaaSはそこまで安くないので、
オンプレやIaaSそのものはなくならないかと思います。
IaaSもそこまで安くはないですが、そもそもPaaSでは動かないソフトも多いことや、運用面での問題もありエンタープライズではIaaSと比べるとそこまで採用されないかと思います。
将来的には、PaaS/IaaS、まあどちらでも良いのですがクラウドの柔軟性が浸透していくと、最低ラインのトラフィックはオンプレミスで管理して、トラフィックが増加する時間帯/曜日のみパブリッククラウドを用いて高速にAutoScaleするようなアーキテクチャが主流になっていくと思います。Dockerなどのおかげで時間レベルでリソースいじれるようになったので先進的なところでは徐々にそうなっていくんじゃないでしょうか。
まあそうなると（インフラがコード化するので）やっぱり仕事は徐々になくなっていくはずですが、Autoscaleしても問題ない疎結合な設計や、Infrastructure as a code、クラウド全般に詳しい人がそこまでいないので2020年ぐらいまでは食っていけると思います。たぶん。
eeicerの無為が業界を救うと信じて・・・！
ご愛読ありがとうございました！