デブサミ夏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における有用なメトリクスの収集とその使い方も再発見されるものがあるだろうと思う。
今後も情報を追いかけてみる。
| 固定リンク
「ソフトウェア」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
「ビジネス・歴史・経営・法律」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 営業は顧客の”購買代理人”である(2023.08.16)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
- ChatGPTで起きている事象の意味は何なのか(2023.04.02)
コメント