デブサミ夏2013のリンク

デブサミ夏2013「DevOps」&「Mobile」のカンファレンスに行ってきた。
資料リンクを張っておく。

【参考】
Developers Summit 2013 Summer：エンタープライズに向けた「DevOps」&「Mobile」のカンファレンス

「夏サミ2013」開催、講演関連資料のまとめ：CodeZine

Developers Summit 2013 Summer (夏サミ2013) #natsumi - Togetter

平日にもかかわらず、600人近い参加者がいたらしく、とても人が多かった。
DevOpsバブルみたいだった。

DevOpsの各講演は参考になったが、抽象的な話が多かった。
下記のTwitterがDevOpsの今の状況を表していると思う。

Twitter / yusuke_arclamp: DevOpsの話、もはや概念論はいいから具体的なリポジトリ戦略やデプロイ戦略をどうしているのか知りたい。さらにQAとの絡みやbizとの調整とか、考えないといかんことが多い。まったくもって楽をするのは大変だ。

そんな中で最も地に足が着いたDevOpsの講演は、IIJさんの下記発表だと思う。

夏サミ2013 Hadoopを使わない独自の分散処理環境の構築とその運用 from Developers Summit

10年以上前から、DevOpsなんて会社では普通でした、という言葉が印象的だった。

それから、長沢さんの講演では、スライド資料21枚目のメトリクス「サイクルタイム」「MTTR」が気になった。
後で聞いたら、DevOpsにおいて、ビジネス側と開発・運用側でお互いが共有し合えるメトリクスはこの2つだと。

夏サミ 2013 A2 セッション資料 #natsumiA2 from Tomoharu Nagasawa

ビジネス側ではコストや売上高などのKPIで見たいだろうが、開発・運用側とマッチしない。
開発・運用側のITメトリクスは素人には難しすぎて、ビジネス側の人は分かりにくい。

サイクルタイムは、要求の発生からリリースまでの時間、つまり、開発リードタイムだから、ビジネス側も認識できる。
サイクルタイムが短いほど、システムをリリースできる間隔を短くできるから、その分、ビジネスの競争力が増す。
リーンソフトウェア開発で最も重視されるメトリクスの一つ。

MTTRは文字通り、障害修復時間。
障害が発生して、暫定対応なり修正対応して、業務が復旧するまでの時間。
MTTRが短いほど、稼働率が長くなるので、業務への影響が最小限に抑えられる。
システムの信頼性という観点では、稼働率のメトリクスの方が重要だろうが、アジャイル開発の文脈では、MTTRを重視して、たとえ障害が起きたとしても修正しやすいシステムを重視する。

アジャイル開発のメトリクスでは、ScrumのVelocityが有名だが、リーンソフトウェア開発やDevOpsの観点が混じってくると、サイクルタイムやMTTRのメトリクス採取も必要になってくるだろう。
しかしながら、サイクルタイムやMTTRの収集・集計・評価の注意点やノウハウはまだ広がっていないので、今後の課題になるだろう。

DevOpsがもたらした技術は、ChefやInfrastructure as codeのようなインフラ管理のIT化と、MTTRやサイクルタイムあるいは大量のログを収集・分析するメトリクス分析の2つだと思う。
インフラ管理のIT化だけが注目されているが、最近のビッグデータへの注目も考えると、ITにおける有用なメトリクスの収集とその使い方も再発見されるものがあるだろうと思う。

今後も情報を追いかけてみる。