DevOps戦略:ディシプリンドDevOpsを定義する – DDevOps#1

devops-practices

シリーズの最初のものとなるこの投稿では、DevOpsにおけるDAD的アプローチの概要を見ていく。まずDevOpsを定義することから始め(もっともこれはDevOpsコミュニティ内でずっと議論の絶えない、一筋縄ではいかない仕事だが)、その後、DevOpsへのDAD的アプローチを説明する。

DevOpsを定義する。
まず最初に、次の定義を提案する:

DevOpsとは、ITソリューションの開発(dev)とITオペレーション(ops)周辺の活動を合理化することである。

下の図1は、このアイディアをまとめたものだ。IT部門内の開発と運用のグループの間に存在し、彼らの効果的なコラボレーションを阻害する障壁を、最初にどう突破するかを示している。まだDevOpsの考え方を採用していない組織に対して、我々は”DevOpsギャップがある”という言い方をする。このギャップ故に、ソリューションのデプロイには長い時間を要し、コストも高くつくことになる。平均デプロイ間隔(mean time between deployments:MTBD )が数ヶ月といった長きに渡ることも珍しくない。市場競争力が低下し、リアルタイムでのインテリジェンスが欠如しているが故に、あなたがたITの取り組みを統制する能力が低下する。この記事の後半で説明する戦略を適用することで、組織がDevOpsギャップを解消すれば、前述した課題の類いにも効果的に対処できる。組織は作業するにあたり、コラボレーションと学習を主軸に据えた考え方を採用することによって、これを行う。もちろんアジャイルプラクティスと自動化によってサポートされている。

図1 ITソフトウェアの開発とIT運用とのギャップを解消するdevops-cycle3
ディシプリンド・DevOpsを定義する

DevOpsへDAD的アプローチを適用するとは何を意味するのだろうか?それは、普段だったら選択しないようなことでも、良いことであれば取り入れるという行動の原則を要求する。私たちは次の定義を提案する:

ディシプリンドDevOpsは、組織により効果的な成果(outcome)をもたらすために、ITソリューションの開発とIT運用の活動およびエンタープライズITの様々な活動を合理化することである。

違いを理解するために、DevOpsの定義によって影響を受ける組織の範囲を通して考えてみよう。図2が表現しているのは、DevOpsの取り組みで最初にターゲットとされる範囲である。開発チームとIT運用チームとの間の相互作用を見直すことが基本となる。図2で「運用(Operations)」ではなく、「IT運用(IT Operations)」という言葉を使っていることにご注意いただきたい。これは、多くの組織が、IT運用の活動とビジネス運用(business operations)の活動(たとえば販売、流通、マーケティング、などの活動)とを区別するという選択をしているためだ。もちろん、IT運用はビジネス運用をサポートするために存在している。

図2 DevOpsの初期

devops-dev-operation

組織によっては図3で示すようなアプローチで始めるところもある。特にシステムを実稼働させるためのリリースとデプロイの管理の責任を異なるグループが担っている場合だ。これらのリリース管理チームは、かならずしも常にというわけではないが、IT運用チームのサブグループであることが多い。一般市場に向けてソリューションを構築しているプロダクトの企業は、開発や運用から分離したリリース管理チームを持つことが珍しくない。なぜならリリースの作業には、ITとしてのリリースの活動、特にソリューションのアップデートを実運用に載せるという活動と、それと同様に顧客と接点を持つ活動(マーケティングや営業の類い)の双方が含まれるからだ。

ディシプリンドDevOps戦略は、リリース管理におけるITとビジネス的側面の両方の活動を合理化する。

図3 リリース管理活動が分離されたDevOps

devops-cycle1

図3は、正しい方向へのステップであることは明らかだが、これで完成ではない。ディシプリンドDevOps戦略は、エンタープライズアーキテクチャとデータ管理チームによって行われる、DevOpsを補強する様々な活動をも合理化する。DevOpsを補強するエンタープライズ·アーキテクチャの活動には、DevOpsに間接的に関わる組織の取り組みをガイドする技術およびビジネスのロードマップの定義、サポート、およびその進化が含まれている。転じて、これは実運用環境内で、共通し一貫した技術インフラの構築へと繋がる。これにより、共通のDevOpsプラクティス(例えば、継続的デプロイや、自動化されたエンド・トゥ・エンドの回帰テスト、そして運用のモニタリング)の実践が可能になる。

データ管理における補強的活動には、次に挙げるものが含まれる:データと情報の標準とガイドラインの定義、サポート、その進化:組織内に存在するデータソースの構築とサポート、その進化:データウェアハウス(DW)やビジネス・インテリジェンス(BI)の構築とサポート、その進化といったものだ。これらの活動のすべてについて、後日ブログ投稿でより詳細を説明する予定だ。

図4 ディシプリンド・DevOps – エンタープライズビュー

devops-practice-practicecycle

これら3つのビューすべてが有効なものであり、現在の状況に対して最も適切なパターンがどれかを、組織は決める必要がある。図2〜4は、まだ明文化していないDevOps成熟度モデルの観点から提示された – 図2で提示された初期のアプローチから始まり、リリース管理にフォーカスしてそれを改善し(図3)、最終的にはエンタープライズアーキテクチャやデータ管理といった他のIT活動を扱うように戦略を進化させる(図4)という姿だ。

引き続きブログを投稿していくが、そこではDevOpsが実際にはどのように機能するかというミステリーを取り上げつつ、ディシプリンド・アジャイル・デリバリー・フレームワークが、DevOps戦略をどのように扱うかを明確にしていく。

 

オリジナル:Defining Disciplined DevOps
URL: https://disciplinedagiledelivery.wordpress.com/2015/01/15/defining-disciplined-devops/

                                          (翻訳:藤井智弘)

Pocket