aibouと言います。最近では社員から本名で呼ばれることはマレです。
前職ではサーバサイドエンジニアとしてJavaプロダクトのお守りをしていまして、6月に入社して半年ほどAWSのオペレーションエンジニア（造語）の仕事をしています。括りにとしてはインフラ園児ニアです。
僕が入社するまでは、インフラエンジニアがひとりしかいない状態だったので、現状の設定・構成等々は色々空気を読みつつ、自動化出来るところは自動化していこうということで複数のツール導入しました。
今回はその紹介をします。
chefspec
Gunosyでは、AWS Opsworksを利用してサーバの構築・デプロイまで実施しています。
Opsworksを使う以上、必ず使うのがプロビジョニングツール「Chef」です。
これまでウェイソイヤ（※）でトライアンドエラーによってレシピを作ってきたのもあり、レシピ自体の検証がかなり怪しい状態だったので、chefspecを入れてみました。
roadworker
Route53でのドメイン管理をRubyのDSLでコード化できるwinebarrelさんのツールです。
Route53では、設定変更の差分や以前の値の参照がかなり難しいので、バージョニング化できるのは本当に便利です。
piculet
EC2セキュリティグループをRubyのDSLでコード化できる、同じくwinebarrelさんのツールです。
こちらも差分や履歴を追いづらいのでメリットがありますが、それ以上にコメントをつけれるのが非常に大きいです。
これまでは登録済みグローバルIPとエクセルを照らし合わせる日々でしたが、その無駄作業から解放されました。
入れる前と入れた後で変わったこと
chefspec
chefspecを入れた結果、「テンプレートファイルに値入ってなかったテヘペロ」は事前に検出できるようになりました。
結構ありがたい反面、「生成されたテンプレートが対象のシステム的に正しいのか」という検証ができません。
test-kitchenあたりまで導入するべきかと悩むんですが、網羅するべき検証項目が多かったり、opsworks側で用意されているレシピを流したうえでテストすべきだと考えたりで、やや気が重い状態です。
serverspec？おっとその話はいまはやめておこう
codenized.tools
roadworker、piculetはかなり効果絶大で、これまで
チャット・口頭での依頼 → 作業実施 → 連絡
という一連の流れが、
プルリク → マージ → 自動反映
となり、インフラエンジニアへの負担が大幅に低減されました。
↑の方は解析チームの方なんですが、まともにレクチャーしてないのにもかかわらずプルリクを送ってきてくれました。
アプリケーションエンジニアにしっかりした人（≒ 空気読める人）が多くて、この運用が通用しているんだろうなぁと感謝しつつ、どんどん移譲していきたいです。
実際に運用してみたのを軽く書いたのがこちらです。
http://qiita.com/aibou/items/4144a4e8feb140fbc942
これから入れようとしているもの
Barkdog:
こちらもwindbarrelさんのツールで、datadogのアラートをDSLで管理できるようになります。
GunosyではOS内の監視・メトリックダッシュボードの作成にDatadogを利用しており、異常検知時はSlackやPagerDutyを経由して担当者に通知を投げます。
現状の設定がかなりカオス化してる（運用サービスによってアラートのレベルが違うことが原因）ので、バージョニング化・共通化を目指したいですね。
Terraform:
Opsworksを使ってサーバ自体の構築・デプロイまで自動化出来るようになりましたが、今後はOpsworksを含めたEC2 SecurityGroupやIAM roleの管理も自動化していきたいと思っています。
その手段としてTerraformを、また現状の状態を吸い上げるTerraformingを併用して運用したいなーという願望があったりします。
注釈
（※）については、後日12/10のGunosyアドベントカレンダーに記述予定です。