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についても色々探してみる。
| 固定リンク
「ビジネス・歴史・経営・法律」カテゴリの記事
- 戦前の日本人の気質はまだ成熟していない青年期と同じだった(2022.06.14)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 経済学や心理学の実験で得られた理論は再現性があるのか?~内的妥当性と外的妥当性の問題点がある(2022.06.04)
- 中国人の価値観の考え方(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「ソフトウェア工学」カテゴリの記事
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- ソフトウェアテスト技法練習帳はテストケースの切り方に困っている人向けにおすすめの本だ(2022.05.14)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント