DevOps～Webサービスの開発と運用の一体化という再パッケージングの概念
DevOpsという言葉を最近よく聞く。
DevOpsとは、Webサービスにおける開発と運用の一体化という意味で理解している。
感想をラフなメモ書き。
【元ネタ】
開発と運用の新しい関係、「DevOps」とは何か？ － Publickey
DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012 － Publickey
DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012 － Publickey
[資料公開]Chefの下準備 (#DevLove Chef de DevOps) | Ryuzee.com
リーン・スタートアップが生む価値――「Just do it！」の無駄を省く
リーン・スタートアップの実践――ソニックガーデンは2度ピボットした
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 － Publickey
システムの開発と運用の一体化という考え方は、業務システムの開発でも同様だ。
特にSIならば、苦労して新規開発した後、運用で定期的に保守料という形で現金を受け取り、売上を確保するビジネスが多いだろう。
では、従来のソフトウェア保守とDevOpsでは何が違うのか？
上記のpublickeyの記事を読むと、特にWebサービスの分野で、アジャイル開発やリーンソフトウェア開発、リーンスタートアップの概念を取り入れて、Webシステムを小刻みに開発しながら即運用していくビジネスモデルをサポートしているようだ。
DevOpsとは、Webサービスの開発と運用の一体化のアイデアであり、従来のソフトウェア保守の再パッケージングの概念とも言える。
僕が注目する内容は二つある。
一つは、信頼性の要件のうち、MTTR(障害修復時間)を重視すること。
DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012 － Publickeyには下記が書かれている。
(引用開始)
運用については、MTTR（Mean Time to Repair）つまりどれだけ早く復旧できるかが大事になっている。壊れることを予期しておくことが大事だ。
(引用終了)
つまり、HDDやネットワーク機器などは定期的に壊れることを前提として、復旧時間を短くできるように運用体制を整えておくこと。
また、ソフトウェアの障害修正や機能追加を定期的にアップデートできるような仕組みを取り入れておくことで、頻繁なVerUpができるアーキテクチャに設計しておくこと。
すなわち、壊れないシステムを作る発想よりも、素早く修復できるシステムの方が価値があるという考え方へ根本的に変わっている事実がある。
アジャイル開発のアイデアを製品開発、Webサービスへ発展させる: プログラマの思索
障害を故意に起こさせるツールで耐障害性を高める: プログラマの思索
アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索
特に最近は例えば、iPhoneや携帯のソフトウェアアップデート機能のように、ソフトウェアのアップデートだけでなく、OSそのもののアップデートも可能になったため、MTTRを短くするという考え方を実現しやすくなった状況がある。
また、たとえ壊れたとしても、信号機が壊れた時に必ず赤信号に倒すという例のフェイルセーフ、子供が誤ってシステムを誤動作させても怪我をさせないという例のフールプルーフ(チャイルドプループ)、システムを冗長化して稼働率を維持するという例のフォールトトレランスなどのような耐障害性を持つアーキテクチャ設計が重要になってきている。
現代は、ハードウェアは所詮は箱物であり、その中にあるソフトウェアやデータに価値があるのだ。
だからこそ、壊れないハードウェアを作るよりも、定期的に進化し続けるソフトウェアの方が重要になってきている。
もう一つは、DevOpsを支えるためのツールが揃ってくると、メトリクスが重要になってくるという話。
ここでは、従来のソフトウェアメトリクスではなく、リーンソフトウェア開発やリーン生産のアイデアを用いて、サイクルタイムやフィードバック時間、デリバリ効率などのメトリクスを収集して、開発チームにフィードバックし、運用を改善していくことを目指している。
DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012 － Publickeyの記事を読むと、リーン生産のアイデアを用いるだけでなく、メトリクスに上限と下限を用いる管理図も使っているようなので、色々アレンジしているように見える。
そして、ここからMetrics Driven Developmentのような考え方が出てくる。
つまり、改善のヒントになるようなメトリクスを収集していくことによって、ノウハウを蓄積し、継続的イノベーションが行えるような環境を整えていくこと。
多分、チケット駆動開発もこの流れの上で運用することも可能だろう。
例えば、運用中に発生した障害やインシデント、問合せを全てチケットに記録して定期的に集計することで、直近の傾向やリスクを分析でき、そこから運用を改善していくこともできるだろう。
DevOpsについても色々探してみる。
| 固定リンク
「ビジネス・歴史・経営・法律」カテゴリの記事
- 農林水産業はITと相性がいい(2023.01.09)
- 過学習に陥った人間や社会の事例は何があるのか(2023.01.09)
- 経営戦略とIT戦略をつなぐ鍵は何なのか(2023.01.04)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- TwitterやFacebookは人力キュレーションツールとして使う(2022.10.02)
「ソフトウェア工学」カテゴリの記事
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
- 組合せテストにおける因子と水準はどちらを最優先で考えるべきか(2022.12.04)
- XPエクストリームプログラミングは偉大だ～時代がその設計思想に追いついた(2022.11.16)
- 第23回東京Redmine勉強会の感想～コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ～時代がその設計思想に追いついた(2022.11.16)
コメント