概要
@koemuさんにお声がけ頂いて、ITインフラ 業務自動化現状確認会 - connpassに行って来ましたのでそこで思ったことなどつらつらと。 どなたがどんな資料発表されたとかはITインフラ 業務自動化現状確認会を催しました #infra_auto | こえむの編集後記がイケてるのでもろもろ引用させて頂いております。
以下、発表者の方々それぞれ思ったことを(自分のは解説ですが
@noexpectの話
参考発表資料:チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化
* いろいろ都合で当日資料はインターネッツには公開しておりませぬ
自分の話なのですが、以下夏のプログラミングシンポジウムというところでお話した内容をざっくりまとめてます。
アラートメールをJIRAに流して対応したかを管理するツールを作った話と、業務の依頼がJIRAで来た場合にその対応ノウハウを自動でそのJIRAに添付するツールを作った話になります。
前者は監視システムから来るのはいいけどたくさん来るとどれ対応したか分からなくなるよね?誰がどれ対応したの?をちゃんとチケット管理すると機械的に捌けていいよね、という話です。
後者は定型依頼というものが社内でだいたいJIRA依頼でくるのですが、その対応ノウハウがみんなそれぞれ好きにドキュメントまとめてた。なので一元管理して、かつJIRAチケットにコメント追記してあげるとわざわざ資料を探さなくていいし、必要とあればその資料を更新すればいいのよね?というのが把握しやすくなるものです。
要するに折角ためたノウハウ=ドキュメントをちゃんと見せてあげて有効活用してあげようという感じです。自ずと目に入るドキュメントにもし不備あればそのメンテナンスもちゃんとしようという気になりますし。
@rrreeeyyyさんのお話
発表資料:Itamae使ってみた
ansibleはパワフルでエージェントレスでいいけど、テストはserverspec一強で、言語が異なるのは不便。そこででいい感じのDSLとエージェントレスなItamaeというのが便利。
そもそもプロビジョニングもテストも本来は同じことをやってその確認をしたいだけ。 なのでプロパティは必要なところ一箇所いじればそれぞれで同期とってやってくれるべきだよね、できます!
思ったこと
確かにプロビジョニングとテストって一体となってやるべきものなのでそこをつなげて使えるのはいいなと。
@oko_changさんのお話
Cloud Automatorの中の仕組みのお話。
awsのcloud watchとかops worksとか、あとPaperTrailがデータの追跡にいいとか。
Saasをいろいろ束ねて使ってるとその設定は結局どうしよう?な問題がある。
思ったこと
Saasの設定どうしよう問題は全くだなというかWebベースは人はいいけと機械が読みづらいのはたしかになと。
@y05_netさんのお話
発表資料:インフラ自動化とテストについて
rundeckがサーバにsshでちょめちょめするのにいいらしい。
serverspec-runner作ったよ。 テスト結果をマークダウンなAAで表形式で表示したりcsvで出力できて、テスト結果をいわゆるテスト結果.xlsみたいなので提出を求められても大丈夫だよ。
思ったこと
テストしてるの大事だけど、そうしてることを報告する義務もあるわけで、いわゆるsurverspecの結果観せてもわからない人もいるので、descriveと結果を人間にも読みやすい形でxlsなりしかるべき表示するのは大事だなと。
テストの成果物はどうあるべきか?はとてもいろいろ考えるべき問題だなと思いました。
@koemuさんのお話
構築、監視、ドキュメント、いろいろ業務で不便なところが出てくることがある。というのもDCたくさんあったりで統一環境がないため。 ほぼフルオートでそこができれば便利になる。
作ったものはnoukaでインベントリ管理していろいろ試行錯誤してドキュメント作成自動化をしている。
思ったこと
@y05_netのお話でもそうでしたが、結局自分がやった仕事に対するドキュメントというか人に説明できるようなものをしかるべく準備するのは大事だなと。
また後述しますが社内で何かしら便利なツールなりの布教には地道なハンズオン定期開催などたゆまぬ努力が必要なのは自分もそう物事を進められればいいなと思いました。
@kuwa_twさんのお話
chefの闇の話。
レポジトリ間の依存度高ぇ問題。
confがものによって正規化されてなくて混在しててよくわからない問題。
レシピの名前被り問題。
コミュニティクックブックは使いたいけどどこまで使っていいか問題。
chef-serverやめてchef-soloとberkshelfだよな!と思ったらchef-zeroが...
思ったこと
まさにchefの闇感というか使ってく上でまったくだなと思う問題ばかりでしみじみと...
chefそのもののよりそれらを管理するのがだいぶ複雑になってきているのは難点だなと。
@hokkai7goさんのお話
*なるほどなと思ってたらメモとれず...
@tnmtさんのお話
Puppetでひたすらデモして頂きました。
vagrant+virtualboxだと他のインスタンス落とすと釣られて落ちるやつが居る問題はKVMあるあるなのと同様かも?
ホスト一元管理は大事。そもそもフォームにはどういう情報が入ってるべきかの設計もどうすればいいのやら?というかみんな試行錯誤。
思ったこと
ホスト一元管理の問題はどこでもあるのよね、というかいろんな環境があるとそれらをまとめたマスター作るのそもそも相当難しいなと。
理想像としてはホストネームとかサーバ情報とか設定ひと通り入れると自動でプロビジョニング走るところまで統合されてるのがいいよね!という話はそこそこ聞くけどなかなか難しいよねと。
@buty4649さんのお話
hubotのお話。
hubotはデーモンで簡単にレスポンス返すところのフレームワークがそろってるのでささっと使うのに便利。各言語のライブラリをそのまま使うより。
ただcoffeeスクリプトの学習コストはちょっと気になる。あと非同期パターンになれてないと書きづらいかも。
思ったこと
hubotというかhipchatとかでいろいろ飯テロbotとか作ってたりするけど、結構玩具はできるけど現世利益高いの作るにはどうするといいのかな?というところが結構疑問。
chatopsもいいけど、それシェル or GUIからやるのとどう違うの?というかそこら辺をメリットいろいろ文章化できるといいのかな?とか。
@OmochiStrikeさんのお話
オフレコ話だけと大変興味深かった。
全体を通して思ったこと
- エンジニア以外の人とのプロトコルをプログラムで実装する必要がある(テスト結果非エンジニアの人でもわかりやすくとか
- サーバなりの一元管理は最初はあまり気にしないけど後からじわじわつらくなる
- ツール開発をチームで進めるにはたゆまぬハンズオンや布教が大事
- もっとみんなそれぞれツールの闇を話すべき(圧力をかけられてもｹﾞﾌﾝｹﾞﾌﾝ
総括
自分のは結構インフラエンジニア感にじみ出ない話になってしまったのでちと残念だったなぁ、と。みなさんは普段の業務フローとかで結局どういうことをしてるのかな?というところが気になりました。
ずっとchef触るなりエンジニアリングしてるのかな?感もありますが、たぶん仕事の要件を確認したりとかいろいろあるのではないかな?と。 そう思いつつ、個人的にはインフラエンジニアガチ勢というよりはミッションスペシャリスト?的に目の前の仕事をしたかったり。技術の力も使いつつ、あるいはイケてるワークフローでいろいろ簡単にしたいなと思いました。
(まぁ素直に技術力が足りないので僻んでないで技術力あげろよ、と。とはいえいろいろある道具をどうやるとより上手に使えるのかな?と。 技術にどっぷりハマらない(道具づくりだけに注視しすぎて車輪の再発明にならない感じの)さじ加減でやってきたいなとか。)