The Doppler Quarterly (日本語) 冬 2016 | Page 13

成熟度レベル
レベル1
アドホック
レベル2
再実行可能
レベル3
定義済み
レベル4
測定
レベル5
最適化
人々
サイロベース
非難、責任のなすりつけ
エキスパートへの依存
説明責任の欠如
プロセス
テクノロジー
• 手動のプロセス
• 内部的な情報が規範
• 予測不可能、リアクティブ • 手動による構築と展開
• 手動によるテスト
• 環境不整合
• 管理された
コミュニケーション
• 限定された知識共有 • サイロ内でのプロセス構築
• 基準がない
• 既 知のことを反復できるが
未知のことに対応できない •
•
•
•
• コラボレーションが存在
• 共有された意思決定
• 共有された説明責任 • SDLC 全 体にわたって自動
化されたプロセス
• 組織全体にわたる基準 • 各コミットの自動化された構築サイク
およびテストサイクル
• プッシュボタン展開
• 自動化されたユーザーテストおよび承
認テスト
• ボトルネックの解消に重点
を置いた、共有された測
定基準に基づくコラボレー
ション • プロアクティブなモニタリング
• ビジネスの目標に向けて収集 /
分析された測定基準
• 目に見える適切な測定基準を構築 • 目に見える適切な測定基準を構築
• 自動ロールバックによるオーケストレー
ションされた展開
• 非機能要件の定義および測定
• 組織全体に浸透した継続的
改善の文化 • セルフサービスの自動化
• リスクおよびコストの最適化
• 高度な実験 • ゼロダウンタイム展開
• イミュータブルインフラストラクチャ
• あえて失敗することにより耐障害性を
積極的に強化
•
•
•
•
自動化された構築
ストーリー展開の一部として
書かれた自動化されたテスト
労力が必要だが再実行可能なリリース
図1: DevOpsの成熟度モデルは、
組織が、 DevOpsプロセスとテクノロジーから価値を得られる度合いに注目します。
ステップ4: DevOpsプロセスの定義
DevOps プロセスの定義方法を知ることのできるリソース
は数多くあります。DevOps プロセスとはアジリティの自動
化です。ただし、DevOps プロセスの種類の数は、企業
の種類と同じくらい多いため、ニーズに最適なものを選択
する必要があります。
図 2 に、出発点として使用できる完全な DevOps プロセス
を示します。場合によっては、不要なステップや、追加が
必要なステップもあります。一貫して行う必要があるのは、
継続的な、開発、統合、テスト、展開、運用のためのサポー
トです。使用するツールとステップは事業要件と技術要件
によって異なります。
クラウド環境のDevOps
このプ ロ セ ス は 一 般 的 に Linux、Apache、MySQL、
PHP/Python/Perl (LAMP) スタックなどの従来のプラッ
トフォームから、新しいパブリックまたはプライベートクラ
ウドにまで及びます。図 2 に典型的な区分を示します。た
だし、プロセスはすべてのクラウドプラットフォームとクラ
ウド DevOps ツール、または従来のプラットフォームすべて
とオンプレミス DevOps ツールにまたがることができます。
ステップ5: ターゲットクラウドプラットフォー
ムの定義
アプリケーションホスティングのターゲットプラットフォーム
の定義が重要な理由は 2 つあります。1 つ目は、ターゲッ
トプラットフォームが、選択した DevOps ツール、とりわけ
運用の自動化ツールと深く関わることです。2 つ目は、それ
により DevOps プロセスがさらに定義されます。プラット
フォーム関連の変更はないとの声が多くとも、変更はある
のです。
テストと展開プロセス、および自動化のニーズにより、クラ
ウドプラットフォーム間、そして従来のプラットフォーム間
でさえ多くの変更が発生します。
適切なターゲットクラウドプラットフォームを選択すると、
複数のプラットフォームを選択することになる場合があり
2016年冬号 | THE DOPPLER | 11