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