DevOps Days Tokyo 2012
DevOps Days Tokyo 2012[日本語募集枠] - connpass に参加しました。
UStream: http://www.ustream.tv/user/opencloudcampus
Facabook: DevOps Days Tokyo 2012 - ホーム | Facebook
togetter: DevOps Days Tokyo 2012 - Togetter
※togetterは自分でまとめたので漏れがいっぱいあるかもしれません。
前書き
少し前にALMとDevOpsについて学び、興味を持っていました。私の立場としてはDevです。仕事で継続的デリバリー（に近い）環境を構築するため、他のところはどうしているのか知るために参加しました。
私の考えを言うと、DevelopmentとOperationが相互関係になればよいというのは昔からあったけど、いきなりそれをやるには問題が大きすぎるから、少しづつ活動を続けてきて、ようやくそのレベルが実現可能になってきたと捉えています。
長い時間かけて作って、ようやくリリースしたら、使いものにならないといわれた／不具合・要求（欲求）違いがたくさんあった−そういうのがあると新規開発・改修の作業が削られてしまう（あるいは残業がとんでもなく増える）。あるいはそれはまだ良いほうで、「あいつらが作るシステムは信用できないから」なんて後ろ指をさされてしまうかもしれません。細かい意識・価値共有ができていれば、そんなことは回避できていただろうに・・・
では、細かい意識・価値共有はどうすればできるでしょうか。それはすばやいリリースができることです。リリースしたものを使ってもらって、「ここ、いつもミスするからこういう風にできるといいんだけど」とか「こういうこともしたいんだけど」とか言われたときに「分かりました。来月のリリースに含めます」と言うと、おそらく言った本人は忘れてます。言った言葉は覚えていても、そのときの気持ちは別のものになっているでしょう。一応ものが出来てるから相手も了承してくれるでしょうが、「う〜ん、こうではないんだけどな」という気持ちが残っているかもしれません（あるいは、言った時点の要求・欲求は満たしていても、リリース後の時点ではもっと別の要求・欲求が生まれていて、それをごちゃ混ぜにしているかもしれません）。そのため、なるべく早い時期に意識共有・確認できる体制にして、それを運用することが苦にならない環境を構築する必要があります。
これを実現するために、ITSやCIなどのツールがあります。OSSで優秀なものが増えたため、それらをサポートできるエンジニアがいれば問題ありません。まずはDevelopmentがOperationや顧客からの声を受け止める環境を作ること。そして、それを継続的に行う環境を作ることが今後課題となります。
DevOpsって
イベント前日に「DevOpsの定義ないよね」ってことで、「運を開く＝開運にしよう」ということになったそうです。なんだかよく分かりません。
イメージとしては、DevelopmentとOperationを分けていたことが、アイデアがお金になるまでの（時間などの）障害となっていたので、この障害をとっぱらってしおう、というものです。
DevOpsの考えは、改善を続ける、無駄をなくす、ムラをなくす、無理をなくす、というものです。DevelopmentとOperationのサイクルを作るのだから、何度やっても苦にならないものでなければならず、自動化する必要があります。自動化できないのであれば、業務を最適化して、自動化できる部分を模索します。この考えはJenkinsと同じです。
DevOpsの考えをなぞるには、THE LEAN STARTUP（邦訳：リーンスタートアップ）が参考になるそうです。また、これよりも先に The Four Steps to the Epiphany（邦訳：アントレプレナーの教科書）を読むことを勧められました。
ジョン氏のスライド: Devopsdays Tokyo 2012
全体的に
Chefの話が多かった気がします。Operationの自動化ですね。スクリプト＝ドキュメントなので、運用の変化もバージョン管理することができます。
並河さんのお話： 「DevOps Days Tokyo 2012」でChefの話をしてきたので資料を公開します - 元RX-7乗りの適当な日々
cockbookの日本語訳： http://wiki.opscode.com/pages/viewpage.action?pageId=24019581
オープンスペース
CIについてのグループに参加しました。DevOps的に、アプリのCIではなく、インフラのCIに焦点を当てたので、やっぱりchefの話が出ました。じゃあ、サーバーの設定や設定、連携など、インフラがきちんと動くか確認しているか、という話になりました。最初の構築は確認されているので良いけど、その後書き換えられたときはどうか。shellやzabbixでチェックしているとの話もありました。shinagawa.redmine第三回でも同じような話がありましたね。
継続的インテグレーション、継続的デリバリのように、継続的チェック(CC)が必要で、どうすればいいか考えていかないとね、が総括です。
その他
- Chefユーザーグループ発足！
- CloudだとモニタリングツールはNagiosやZabbixより、 SENSU のほうが良いらしい
- http://rundeck.org/:titl=RUNDECK というプロセス自動化ツールが手軽に使えて便利そうだと思った
所感
DevOps体制を作るにはAgile, Cloudなどを受け入れていないと難しいのではないだろうかと思いました。中途半端にやると部分コストがかかってしまいそうです（Private Cloudばかりにするとか）。Agileって言っちゃうと色んなことを含んでしまうのですが、DevelopmentとOperation間以前に、Development内で体制が出来ているかということです。ここでいうDevelopmentは例えばProgrammerやTester、別のチームのProgramemrなど。責任の押し付け合いや部署のごたごたを出してくるような体制のところはまず無理でしょう。顧客に強力してもらえないプロジェクトだと困難でしょう。
DevOpsはサービスの提供・運用を行う上で良い体制だと思うので、確かに世界的に流行するかもしれませんが、体制のないAgile開発、なかなかに高価なCloud環境の日本（の一部、けれども大きな存在）でどうやれば良いのか、考えることは多そうです。
