デブサミ夏2013のリンク
デブサミ夏2013「DevOps」&「Mobile」のカンファレンスに行ってきた。
資料リンクを張っておく。
【参考】
Developers Summit 2013 Summer:エンタープライズに向けた「DevOps」&「Mobile」のカンファレンス
「夏サミ2013」開催、講演関連資料のまとめ:CodeZine
Developers Summit 2013 Summer (夏サミ2013) #natsumi - Togetter
平日にもかかわらず、600人近い参加者がいたらしく、とても人が多かった。
DevOpsバブルみたいだった。
DevOpsの各講演は参考になったが、抽象的な話が多かった。
下記のTwitterがDevOpsの今の状況を表していると思う。
そんな中で最も地に足が着いたDevOpsの講演は、IIJさんの下記発表だと思う。
10年以上前から、DevOpsなんて会社では普通でした、という言葉が印象的だった。
それから、長沢さんの講演では、スライド資料21枚目のメトリクス「サイクルタイム」「MTTR」が気になった。
後で聞いたら、DevOpsにおいて、ビジネス側と開発・運用側でお互いが共有し合えるメトリクスはこの2つだと。
ビジネス側ではコストや売上高などのKPIで見たいだろうが、開発・運用側とマッチしない。
開発・運用側のITメトリクスは素人には難しすぎて、ビジネス側の人は分かりにくい。
サイクルタイムは、要求の発生からリリースまでの時間、つまり、開発リードタイムだから、ビジネス側も認識できる。
サイクルタイムが短いほど、システムをリリースできる間隔を短くできるから、その分、ビジネスの競争力が増す。
リーンソフトウェア開発で最も重視されるメトリクスの一つ。
MTTRは文字通り、障害修復時間。
障害が発生して、暫定対応なり修正対応して、業務が復旧するまでの時間。
MTTRが短いほど、稼働率が長くなるので、業務への影響が最小限に抑えられる。
システムの信頼性という観点では、稼働率のメトリクスの方が重要だろうが、アジャイル開発の文脈では、MTTRを重視して、たとえ障害が起きたとしても修正しやすいシステムを重視する。
アジャイル開発のメトリクスでは、ScrumのVelocityが有名だが、リーンソフトウェア開発やDevOpsの観点が混じってくると、サイクルタイムやMTTRのメトリクス採取も必要になってくるだろう。
しかしながら、サイクルタイムやMTTRの収集・集計・評価の注意点やノウハウはまだ広がっていないので、今後の課題になるだろう。
DevOpsがもたらした技術は、ChefやInfrastructure as codeのようなインフラ管理のIT化と、MTTRやサイクルタイムあるいは大量のログを収集・分析するメトリクス分析の2つだと思う。
インフラ管理のIT化だけが注目されているが、最近のビッグデータへの注目も考えると、ITにおける有用なメトリクスの収集とその使い方も再発見されるものがあるだろうと思う。
今後も情報を追いかけてみる。
| 固定リンク
「ソフトウェア」カテゴリの記事
- マインドマップをFreeplaneに乗り換えた(2020.11.21)
- ソフトウェアの政治的影響力とは何だろうか(2020.07.07)
- DevOpsがアジャイル開発を促進する(2020.06.11)
- AzureクラウドデザインパターンとAWSクラウドデザインパターンのリンク(2020.06.09)
- Ruby技術者認定試験の感想(2020.05.08)
「経営・法律・ビジネス」カテゴリの記事
- みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない(2021.01.14)
- IPAがDXのパターン・ランゲージを公開している~新しい組織文化が新しい経営戦略を生み出す(2020.12.05)
- 組織は記憶能力を持つのか~トランザクティブ・メモリーという概念(2020.11.23)
- 手段を目的化するのは日本人の病(2020.11.07)
- 問題解決アプローチを見極める『クネビンフレームワーク』のメモ(2020.09.02)
コメント