ディシプリンドDevOps

このセクションでは、DevOpsに対するDAD的アプローチを提示する。DevOpsを定義することから始め -DevOpsコミュニティの中で議論が続くように、簡単な話ではないのだが -、続けてDAD的アプローチを紹介する。DADフレームワークによって、DevOps戦略がどのように扱われるか明らかにしていくつもりだが、それによって、DevOpsが実際にはどのように行われるのかについての疑問に答えていく。最後では、DevOpsのマインドセットへの移行についていくつかアイディアを提示する。

目次

1.DevOpsを定義する

2.DevOps とディシプリンド・アジャイル・デリバリー (DAD)

3.なぜディシプリンドDevOpsなのか?

4.まとめ

 

1. DevOpsを定義する

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

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

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

1.1 ディシプリンド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をサポートするエンタープライズ·アーキテクチャの活動には、他の部門の活動に指針を与えるIT技術ロードマップの定義とサポート、進化が含まれる。転じて、これは本番環境内で、共通し一貫した技術インフラの構築へと繋がる。これにより、共通のDevOpsプラクティス(例えば、継続的デプロイや、自動化されたエンド・トゥ・エンドの回帰テスト、そして運用のモニタリング)の実践が可能になる。 データ管理のサポート活動には、次に挙げるものが含まれる:データと情報の標準とガイドラインの定義、サポート、その進化:組織内に存在するデータソースの構築とサポート、その進化:データウェアハウス(DW)やビジネス・インテリジェンス(BI)の構築とサポート、その進化といったものだ。これらの活動のすべてについて、後述する。
図4. ディシプリンド DevOps – エンタープライズ視点
devops-practice-practicecycle
これら3つのビューすべてが有効なものであり、現在の状況に対して最も適切なパターンがどれかを、組織は決める必要がある。図2〜4は、まだ明文化していないDevOps成熟度モデルの視点から見たものだ – 図2で提示された初期のアプローチから始まり、リリース管理にフォーカスしてそれを改善し(図3)、最終的には、エンタープライズアーキテクチャやデータ管理といった、他のIT活動を扱うように戦略を進化させる(図4)という姿だ。

1.2 DevOpsの共通した定義はなぜ難しいのか?

現在の市場環境には、共通の定義を決めることを難しくさせている、大きな要因がいくつかある:
  • 専門化が進んだIT要員  多くのITの専門家は未だに専門性を高めることを指向しているープログラマや、運用エンジニア、エンタープライズアーキテクト、データベース管理者(DBA)といったような。その結果彼らは、自身の専門性というレンズを通して世界を見がちになる。プログラマはDevOpsのソフトウェア開発の側面だけにフォーカスし、運用エンジニアは運用の側面だけにフォーカスする。エンタープライズアーキテクトは長期の計画とモデリングにフォーカスし、DBAはデータ管理にフォーカスする。”ビッグピクチャ”全体を見ている人は、ほとんどいない。
  • アジャイリストは、継続的デリバリーにフォーカスする  まさに今、アジャイルやリーン開発者は、多大な労力を、継続的デリバリーを実現することに投入しており、それによって効率的に価値を本番環境に定期的にデプロイしようとしている。進化したチームは、自動化されたリグレッションテストや継続的統合(CI)、そして継続的デリバリーのようなプラクティスを適用することで、毎日 – 日に何度でなくとも – 毎日リリースしている。その結果、コミュニティの中でのDevOpsにまつわる議論のほとんどは、これらのトピックスにフォーカスしている。時には、他のプラクティス – カナリアテスト、フィーチャートグル、本番環境のモニタリングフレームワークへと、横道にそれることもある。疑いもなくこれらのテクニックは重要であるが、しかしまだDevOpsの範囲を完全にはカバー出来ていない。これらのプラクティスやその他の情報は後述する
  • 運用の専門家はフラストレーションを抱えている   運用グループの多くは、開発チームによって強いられている更新頻度の多さに、すでに圧倒されている。この状況は、一貫性のない技術の使用によって、しばしば悪化することになる ー 規律のない開発チームにエンタープライズ対応の意識が欠けていることによって、運用グループは全開発チームによって使われている、過剰なほどの技術プラットフォームをサポートする必要がある。さらに悪いことに、社内の運用プロセスは、しばしばITILやITSMのヘビーな実装に基づいており、運用エンジニアが開発チームと、よりうまく共同作業できるような合理化がされていない。
  • ツールベンダーのオファリングには制限がある   この結果、ツールベンダーのDevOpsは自社のツールがサポートするDevOpsのある局面にフォーカスすることになり、かれらがオファー出来る領域という狭い議論になりがちだ。そう、ツールは重要だ、だがそれはDevOpsの一部に過ぎない。フルレンジのツールをベンダーが提供している場合ですら、そして実際にツール連携がスムーズに機能する(そう、ALMベンダーのような)場合ですら、それらのツールをどう効果的に使うのか、あなた自身が理解する必要があるだろう。やや古い言い回しを借りると、「DevOpsツールを使っても、馬鹿は馬鹿(A fool with a DevOps tool is still a fool.)」ということだ。
  • サービスベンダーのオファリングには制限がある   ツールベンダーにかかわる課題と同様に、サービスベンダーもまたDevOpsでの自身の豊富な経験を過大にアピールする。 検証してみればわかるが、ツールベンダーと同様、彼らのDevOpsの定義とは、彼らが現在サポートすることができるものにフォーカスしている。
  • ツールベンダーはDeveOpsをマーケティングのバズワードとして扱う   遠慮無しに言わせてもらえれば、多くのベンダーが既存のプロダクトを使って、手始めにそれらをDevOpsプロダクトとしてマーケティングしている(それらがDevOpsのプラクティスを実際にはどの程度うまくサポートしているかにはかかわらず、だ)。仮に、それらのプロダクトは従来の作業のやり方をとてもうまくサポートしてきたかもしれないが、いざDevOpsのサポートとなると、少しくらい新しい機能を付け加えたところで、むしろ寄せ集めで洗練さをかいたものになってしまっている。
  • クラウドこそDevOpsというビジョン 特にクラウドベンダーが言っていることだが、多くのレトリックがある。いわく、クラウドベースのツールやデプロイメント環境が、DevOpsを成功させるためには死活的に重要だと。もちろんそうだろう、クラウドベースのインフラがDevOpsプラクティスの多くを可能にしているのはあきらかだし、それが与える選択肢によって、私達も適切なときにはクラウドベースの技術を活用する環境で作業する方を好む。しかし、クラウドは、DevOpsの前提条件というわけではない。
 ポイントは、実際には何がDevOpsなのかに関して、我々の業界内での合意を妨げる要因が複数あるということだ。それが暗示しているのは、誰かが読者にDevOpsについてアドバイスする時には、彼らが実際に議論している対象のスコープを読者が理解する必要があるということだ。DevOpsが何か、それが読者の属する組織にどのように適用できるかを理解するもう一つの方法は、(定義を求めるのではなく)読者が使うことの出来るDevOpsの様々な戦略やプラクティスを探索することだ。

2.  DevOpsとディシプリンド・アジャイル・デリバリー(DAD)

この章では、DevOpsに有効な戦略を集め概要を見ていこう。筆者達は、以下に挙げるカテゴリーでそれらの戦略をまとめた:
次に挙げる表1は、この記事でカバーされる戦略のリストだ。
表 1. 検討する意味のある DevOps 戦略
戦略 カテゴリー
非同期サポート サポート(ヘルプデスク)
自動ダッシュボード 基本
自動デプロイ 運用
自動リグレッションテスト 開発
カナリアテスト 開発
共同作業 基本
継続的デプロイ 開発
継続的改善 基本
継続的統合(CI) 開発
継続的リリース機能 リリース管理
データおよび情報ガイドライン データ管理
デプロメントテスト 運用
開発者による運用 チーム編成
開発者によるサポート サポート(ヘルプデスク)
開発ガイドライン エンタープライズ・アーキテクチャ
開発インテリジェンス 開発
災害対策計画の策定 運用
フィーチャーアクセス制御 開発
フィーチャートグル 開発
統合変更管理 基本
統合構成管理 基本
統合デプロイ計画 リリース管理
ITインテリジェンス データ管理
モニター機構の組込み 開発
ワンチーム 基本
オンラインディスカッションフォーラム サポート(ヘルプデスク)
オンライン情報 サポート(ヘルプデスク)
運用インテリジェンス 運用
プリプロダクション(本番前)テストサンドボックス サポート(ヘルプデスク)
運用への引き渡し チーム編成
本番サポート チーム編成
データソースの品質 データ管理
ランダムに行われる災害シミュレーション 運用
リリースブラックアウト期間 リリース管理
リリースサービスストリーム リリース管理
リリーストレイン リリース管理
リリースウィンドウ(クイックケーデンス) リリース管理
リリースウィンドウ(スローケーデンス) リリース管理
再利用マインドセット エンタープライズ・アーキテクチャ
スケジュールされた災害シミュレーション 運用
自己回復 開発
セルフテスト 開発
リリースプラクティスの共有 リリース管理
ソリューションのモニタリング 運用
スプリットテスト 開発
本番環境に基づいた開発とテストの標準環境 リリース管理
標準プラットフォーム 運用
サポートアラート サポート(ヘルプデスク)
サポートサンドボックス サポート(ヘルプデスク
同期サポート サポート(ヘルプデスク)
技術的負債マインドセット エンタープライズ・アーキテクチャ
技術ロードマップ エンタープライズ・アーキテクチャ
トレーニング、教育、メンタリング 基本
保証期間 チーム編成

2.1  基本戦略

ディシプリンドDevOpsをサポートする、一般的な戦略をまず挙げよう:
  • 共同作業  DevOpsの基本理念は、開発者、運用スタッフ、およびサポート担当者が定期的に緊密に協力しなければならないと謳っている。そこには、彼らがお互いを重要な利害関係者と認識し、積極的に協力する機会を探さなければならないという意図が、暗黙のうちに含まれている。アジャイルコミュニティで常識とされるプラクティスに、”オンサイト顧客”(出自はエクストリーム・プログラミングXP)がある。これは、アジャイル開発者がビジネスサイドにより近づいていくよう促している。DADアプローチを採用するアジャイリストは、さらに一歩進めた「積極的な利害関係者の参加」プラクティスを実践する。このプラクティスでは、ビジネスサイドの利害関係者だけでなく、運用やサポートスタッフも巻きこんで、彼らのすべてと緊密に連携しなければならないと謳っている。これは双方向で行われる:運用とサポートスタッフもまた、喜んで開発者と密接に協力しなければならない。
  • 自動ダッシュボード  自動化されたダッシュボードを使うというプラクティスは、IT インテリジェンスと呼ばれるが、これはビジネス・インテリジェンス(BI)アプリケーションをITに効果的に適用したものだ。これには、開発インテリジェンスと運用インテリジェンスの2つの側面がある。開発インテリジェンスは、メトリックを生成する機能を持った開発ツールを使用する必要がある。例えば、構成管理(CM)ツールは、誰がいつ何のためにチェックイン/アウトしたのかを記録する機能をすでに持っている。継続的統合ツールも同様な機能を持っており、ビルドが行われた時に、どれくらい多くのテストが実行され、どれくらいテストに時間がかかり、ビルドがうまくいったのか、どれくらいのテストがパスしたのか等々の情報を記録する。この種の生データが自動的に分析されダッシュボードに表示される。運用インテリジェンスは、以前議論したアプリケーション監視の一様態である。自動化されたダッシュボードを使うと、組織全体でメトリックを収集するオーバーヘッドを劇的に抑えることができる(すべてを自動化できるわけではないから、完全になくすことは出来ない話なのだが)。自動化されたダッシュボードは、組織のガバナンスチームへリアルタイムの洞察をもたらす。
  • 統合構成管理   開発者と運用担当者は、構成管理(CM)について異なる視点を持つことが珍しく無い – 開発者は、ソリューションをビルドし構成を変更する時に、自分達の作成したアセットを管理する一連の戦略として構成管理を理解している。その一方で、運用担当者は、組織の実運用インフラストラクチャーを構成しているアセットを管理する一連の戦略として、CMを理解している。両者のアプローチを統合して結合するべきだ。これは、開発者にとっては大きな変更となる可能性がある。なぜなら、彼らは現在作業しているソリューション構築の文脈でしかCMを考えていないことが多いからだ。DevOps環境では、開発者がエンタープライズ対応という意識と能力を持ち、より大きな全体像を理解する必要がある。彼らのソリューションは、運用中の他のアセットとどのように連携し、それらを活用するのだろうか?その他のアセットは、開発中のソリューションを活用するだろうか?これらは、開発チームが自らのプロダクトと依存関係のあるあらゆる事を理解し、管理する必要があるだろうということを意味している。統合された構成管理は、新しいリリースがもたらす潜在的な影響を、運用スタッフが理解する助けとなる。それによって、新しいリリースへの許可を出すタイミングを、決定しやすくなる。
  • 統合変更管理   組織全体へのサポートを向上させるためにITインフラストラクチャは進化していくが、ITの観点からは、この進化を成功裏にすすめかつ意味のあるものにするためには、変更管理は欠くことの出来ない活動である。多くの技術あるいは類似の技術の様々なバージョンさえ、単一のソリューションの開発に使われるため、プロジェクト·チームレベルでの変更管理には十分な注意が必要だ。DevOpsは、運用に関わるエンタープライズレベルの課題を持ち込むために、統合された変更管理戦略ははるかに複雑になる。非常に多くのソリューションが稼働する本番環境では、同時に相互作用しあうということを考えておくべきだ。統合された変更管理では、組織レベルでの技術の変化の影響を理解するために、開発チームは運用チームと密接に協力しなければならない。このアプローチは、積極的な利害関係者の参加、統合された構成管理、および自動テストといった前述したプラクティスに依存する。
  • トレーニングと教育、メンタリング   予想されているように、DevOps戦略を学び適用するためには、手助けが必要になる。
  • 継続的改善   DADチームは、自身の経験からだけでなく他の人からも学ぶために努力するので、一緒に作業するやり方を継続的に改善することができる。もちろんそこにはDevOpsへのアプローチ方法も含まれる。
  • ワンチーム   DevOpsの考え方の重要な側面は、「彼らと私たちという考え方」から「私たちという考え方」にシフトしていることだ。私たちは、単一の、合理的なチームとして、みな協力し合いながら作業する。これを突き詰めた形が「あなたがたがビルドし、そしてあなたがたが実行する」という哲学だ。そこでは、開発も運用もデータ管理チームもなにも分離しておらず、その代わりにプロダクトのライフサイクル全体に責任を持つプロダクトチームがあるだけだ。

2.2 チーム編成戦略

 開発と運用各々の専門家が共同で作業する際に適用できる、チーム編成戦略について見ていこう。小さくはじめて、やがて大きな効果へと繋げていこう。
  • 運用への引き渡し  開発チームがソリューションを本番環境にのせた後は、運用チームがその稼働とサポートの責任を担う。この時点で、開発チームは解散されているか、あるいは別の作業へと移っていくことが珍しくない。2〜3名の開発者を、リリース後も必要に応じてメンテナンスアップデートを開発する保守チームとして編成したり、あるいはこの手の作業を既存の保守チームに移管することに責任を持たせるという手もある。この戦略の利点は、開発チームをそのまますべて維持するために、組織がもはや投資する必要がないということだ。その一方で、メンテナンスと機能追加のために長期にわたり必要とされる、チームの知識と専門技術を失う危険性がある。これは特に重大な不具合が発生した時に、大きな問題となりうる。
  • 保証期間  この戦略では、ソリューションがリリースされた後あらかじめ定められた期間内であれば重大な不具合に対応することに、開発チームはコミットする。たとえば、開発チームは、製品リリース後の最初の30日間、重大度1または重大度2の不具合を無償で修正することを求められるというケースだ。保証期間戦略は、それに伴うリスクを低減するため、(前述の)運用への引き継ぎ戦略と組み合わされることが多い。開発チームが固定価格モデルで契約している場合、あるいはアウトソーシングでは、保証期間戦略は普通に採られている。なぜなら、利害関係者は、支払った価格に見合ったレベルの品質を手にしたことを確認したいからだ。
  • 本番サポート   エンタープライズ環境では、ほとんどのアプリケーション開発チームは、すでに運用されているサービスの、新しい(次の)リリースに取り組んでいる。彼らは新リリースの開発をするだけにとどまらず、運用中に発見された重大な問題にも対処する責任を、併せ持っている。開発チームは、しばしば「レベル3サポート」と呼ばれることがある。それは、彼らが重大な運用上の問題を修正する場合に、関与する第3番目(そして最後の)チームだからだ。このやり方の最も有利な点は、特定のソリューションに起因して発生した運用の緊急事態が、そのソリューションに最も詳しい人達ーつまりそのソリューションを実際に開発した人達によって解決されるということだ。別の利点として挙げられるのは、運用時に発生する様々な事象を開発者に認識させ、彼らがソリューションを設計する方法をまず最初に改善するという機会を与えるということだ。潜在的に重大な欠点は、運用での緊急事態を修正する必要性が、新しい機能に取り組んでいる開発者の気をそらせるという点だ、
  • 開発者による運用   この戦略は、開発チームを運用サポートチームに転換させ、彼らが開発したソリューションの運用とサポートの責任を持たせるというものだ。これは「あなたがたがビルドし、そしてあなたがたが実行する」と、しばしば呼ばれている。この戦略を採用すると、開発チームがソリューションの開発時に、運用やサポートが容易にできることに焦点を合わせるようになったり、最もそのソリューションに詳しい人達が、それをさらに発展させるということが確実になるという恩恵が得られる。しかし、この戦略を採ると、異なるプラットフォームで稼働する、サイロ化されたソリューションを開発するスクラムチームが出来上がるー幸いなことに、DADチームはエンタープライズを常に意識(Enterprise aware)しており、アーキテクチャオーナーの役割をチームに組み込み、チームをガイドすることで、まさにこの類いのアーキテクチャー上の誤りを避けることができる。 もうひとつの一般的な戦略は、あなたのチームに運用経験の豊富な人を引き入れるというものだ。開発者が運用を主導するという戦略は、様々なレベルでサポート品質のリスクを引き起こす。たとえば、チームによってサポート品質にばらつきが発生するようなケースだ。 今一度確認しておくが、エンタープライズを常に意識するチームは、共通のガイドラインに従う重要性を理解しているし、自分達のやり方を改善するために、他のチームを助けることを厭わない。

上記の4つの戦略が示すのは、DevOps戦略といえる唯一のものは、開発者主導による運用であるということだ。この本番サポート戦略は、間違いなく正しい方向への第一歩であり、多くの企業で十分に運営されているところが見られる。あなたの組織の事を考えた場合、我々は開発者主導による運用を試してみて、どの程度うまく機能するか実験してみることをお奨めする。その良好な結果に驚かれることだろう。

2.3 開発戦略

ディシプリンドDevOpsでよく使われる開発のプラクティスを以下に挙げる:
  • カナリアテスト   カナリアテストは小規模な実験だ。新しい機能を一部のエンドユーザに提供し、その機能が彼らの興味をひくものか否かを判断出来る。見方を変えると、開発チームはこのテストから、機能の(もしあれば)真の潜在的な価値について、洞察を得ることが出来る。例えば、あるeコマース企業は、関連する2つの商品を割引価格で購入することができる新しい機能が売上を伸ばすだろうと考えているかもしれない。同時に、これが全体の収益を減少させる可能性を恐れているかもしれない。そこで、彼らは、顧客の5%に2週間の間だけこの機能を提供するカナリアテストを実行することにした。売上と収益を追跡し、この新機能へのアクセスを提供されていない顧客と比較するのだ。新機能がカナリアテストを成功裏にパスすれば、その後、より広い範囲のエンドユーザに提供される(何段階のステップを経て、最終的にすべてのユーザに展開するというやり方もある)。カナリアテストは、パイロットテストの極端な形態として見做すことが出来る。
  • スプリットテスト  A / Bテストとしても知られているスプリットテストは、2つ以上のオプションが並列で実行され、それらの有効性が比較される実験である。例えば、銀行が現金自動預け払い機(ATM)を使った、2つの口座間での資金転送のために、3つの異なる画面設計アプローチを考えたとしよう。エンドレスの会議やフォーカスグループ、あるいはモデリングセッションを行う代わりに、銀行は3つすべてを実装しサービスとして並行して提供する。私がATMを使用する時はアプローチAの画面が現れ、あなたがログインするときにはアプローチBが現れるといった具合だ。
    ATMのソフトウェアには、重要な利用状況を把握するためのメトリクスを収集する機能が組み込まれているので、銀行はどのアプローチが最も効果的か決定することができる。スプリットテストの終了後、もっとも効果が高かったアプローチによる画面が、ATMのすべてのユーザに提供される。
  • 自動リグレッションテスト    アジャイルソフトウェア開発者は、”品質感染症”と呼ばれることがあるが、それは彼らが質の高いコードを書くことにフォーカスし、出来るだけ早くから出来るだけ頻繁にテストをしたいという欲求を持っているからだ。その結果、自動化された回帰テストは、アジャイルチームにとって共通のプラクティスとなっている。時にはテスト駆動開発(TDD)とふるまい駆動開発(BDD)といった、テストファーストのアプローチに拡張されていることもある。リグレッション·テスト·スイート(S)には、機能テスト、パフォーマンステスト、システム統合テスト(SIT)、および受け入れテストと、その他多くのカテゴリーのテストを含む。アジャイルチームは、普通日に何度も自動化テストスイートを実行し、問題をすぐに解決するので、実践していないチームではなしえないような高いレベルの品質を達成するし、開発者はそれを楽しんでいる。テストによっては、特にロード/ストレステストやパフォーマンステストのように、実行に長い時間がかかるものもあるので、異なるタイミングで実行するテストの組み合わせを、いくつか用意することになるだろう(例えば、ある種のテストはコードがチェックインする度に実行されるが、ある種のテストは1日のうちの決まった時間に実行される。また、あるテストは夕方に一度実行され、あるテストは週末に実行される、といったように)。品質に対してこれまで以上にフォーカスするというのは、運用スタッフにとっては良いニュースだ。なぜなら運用スタッフとは、ソリューションは本番サービス稼働前に十分な品質が確保されていなければならないと主張するものだからだ。
  • 継続的統合 (CI)  継続的統合(CI)は、ファイルが構成管理(CM)システムにチェックインされるたびに、自動的にプロジェクトをビルドし検証するという原則だ。次の図に見られるように、検証は、自動リグレッションテスト、さらには、静的または動的なコードおよびスキーマ·分析などの、複数のアプローチで行われる。CIは、コードの不具合に関して迅速なフィードバックを提供することで、開発者が少しずつ繰り返し行われる定常の手順で、安全に高品質のソリューションを開発することを可能にする。devops-practice-cycle
  • 継続的デプロイ (CD)   継続的デプロイは、継続的統合のプラクティスを拡張したものだ。継続的デプロイでは、あるサンドボックスで統合に成功したら、その変更されたコードは次のステージのサンドボックスに自動的に引き渡される(”昇格する”とも呼ばれる)。ソースファイルの変更を受けて、そのサンドボックスで実行されているCI機構があなたのソリューションに統合する。下図を見るとわかるように、この自動的な昇格は、いかなる変更も人によって検証されなければならないポイントー一般的には開発から運用へと遷移するタイミングまで続く。今や先進的なチームは、本番環境へのデプロイまで自動的に行っている。継続的デプロイによって、開発チームは、新たな機能が識別され運用に供されるまでの時間を短縮させることができる。それは、ビジネスの応答性能を高めることに繋がる。しかし、開発チームが未成熟な継続的デプロイを行っていると、本番環境に潜在的に不具合を紛れ込ませることになり、運用上のリスクを増加させることが起こりえる。エンタープライズレベルで継続的デプロイを成功させるためには、すべてのサンドボックスで実行される、効果的な継続的統合戦略が必要だ。devops-practice-releasepipeline
  • 開発インテリジェンス   これはデータウェアハウス(DW)/ビジネスインテリジェンス(BI)アプリケーションであり、チームがどのように作業しているか関する洞察を提供するものだ。多くの開発プラットフォームが提供する自動化されたチームダッシュボードは、開発インテリジェンスの単純なものだが、より洗練された(そして有用な)アプローチは、様々な開発ツールからの情報を結び付け統合されたダッシュボードをチームに提供するものだ。さらに洗練度があがると、異なるデリバリーチームの情報を吸い上げて統合し、ポートフォリオ管理ダッシュボードを提供する。開発インテリジェンスは、ITインテリジェンスのサブセットである。

ディシプリンドDevOpsの考え方を理解している開発者がソリューションをビルドする際に採用する、運用に親和性の高い共通の機能を以下に挙げてみよう。

  • フィーチャーアクセス制御機能   カナリアテストやスプリットテストのような実験的な戦略をサポートするために、ある特定の機能へのユーザアクセスを制限する機能が必須となる。このアプローチは、設定とデプロイが簡単にできなければならない。よく使われる方法としては、XMLベースの構成ファイルを利用するもので、実行時にメモリに読み込まれ、アクセス権限を制御するためのメタデータが記述される。
  • モニター機能の組込み  ディシプリンドDevOpsの考え方を理解している開発者は、計測機能ーログの出力とよりリアルタイムに近いアラートーを彼らのソリューションに組み込む。この目的は、運用に入っているシステムを、(ほぼ)リアルタイムで監視出来るようにすることだ。リューションを運用し続ける責任を担っている人々、問題をデバッグし解決する責任を担っている人々、運用インテリジェンスを利用する人々にとって、この機能は重要だ。
    モニタリング機能を組み込むことで、カナリアテストやスプリットテストの際に、テスト中のフィーチャーや戦略の有効性を判断するために必要なデータを収集することができるようになる。
  • フィーチャートグル  フィーチャトグルは、適切な場合に機能をオン/オフできるようにする、便利なソフトウェアスイッチのことだ。よくある使い方は、価値ストリームーエピックあるいはユースケースで記述されるーを提供する一連の機能群を、ユーザの受け入れ準備が整った暁に一斉にオンにするといったものだ。フィーチャーがうまく機能していない(エンドユーザにとって有用性が見いだせなかったり、結果として売上減になったり・・・)とわかった時に、特定のフィーチャーをオフする場合にも、フィーチャートグルはよく使われる。
    フィーチャートグルのもう一つの利点は、機能を本番運用に院栗メンタルにデプロイできることだ。
  • セルフテスト  ソリューションをより堅牢で、操作しやすいモノにする1つの戦略は、セルフテストが出来るようにすることだ。基本的な考え方は、適切に稼働するか否かを本番稼働中に検証できる基本的なテストを、ソリューションの各コンポーネントに含めるというものだ。例えば、アプリケーションサーバーが、オペレーティングシステムやフレームワークのバージョンが適切かを、スタート時に確認するというような基本的なテストを実行する。サーバー稼働中に、データソースやミドルウェアサービスといった関連する他のコンポーネントが利用可能かどうか定期的にチェックすることもある。問題が発見されたときには最低でもログに記録されるべきだし、さらには人による介入が必要なケースにはアラートが挙がったほうがよい。もっと言えば、ソリューション自体が問題からの回復を試みるとなお良い。
  • 自己回復   システムに問題が発生した際に、自動的にそこから回復し以前と同様にサービスを継続させられるのがベストだ。例えば、システムがデータソースが使えなくなったと発見した場合に、データサービスの再起動を試みるといったことだ。再起動が失敗したら、利用できる場所に変更トランザクションを記録し、データサービスが再び復旧するまでそれを処理する。この良い例がATMである。 ATMは、銀行の財務処理システムへの接続を失った際に、限定された機能ではあるが一定の期間独立に使い続けることが出来る。ATMは人々が自身の口座からお金を引き出すことを許す。ただし、過剰に引き出す事がないよう、金額に制限をかけはする。人々は、口座に入金することもできるが、現在の残高を照会したり、最近の取引の記録を見ることは出来ないだろう。自己回復機能は、エンドユーザーに優れた体験を提供し、組織にかかる運営上の負担を軽減する。
ここまでで、一連の開発プラクティスと機能実装について、概要を見てきた。次に、運用をより合理化する探索を見ていこう。

2.4  運用戦略

次に、運用での技術面の戦略について見ていこう:
  • ソリューションのモニタリング  名前が示すように、これは、運用に入った後稼働しているソリューションやアプリケーションを監視するという運用プラクティスである。オペレーティングシステム、アプリケーションサーバー、および通信サービスなどの技術基盤プラットフォームは、ツール(例えば、Microsoft管理コンソール、IBM Tivoli Monitoringの、およびjManageなど)を使って監視する機能を提供していることが珍しくない。しかし、アプリケーション固有の機能を監視するーたとえば特定のタイプのユーザに使われているのは、どのユーザーインターフェイス(UI)機能かといったーためには、組織の監視インフラに準じた監視機能をアプリケーションに組み込む必要がある。開発チームは、このような運用面での要求に注意する必要があるし、そのような機能の組みいれを簡単に行えるフレームワークを利用出来ることが、より望ましい
  • 標準プラットフォーム  継続的デプロイメントや初期のアーキテクチャ構想のようなソフトウェア開発プラクティスは、運用インフラの一貫性が維持されていてこそ可能になる。一握りの標準のハードウェア構成に展開する方が、ユニークなモノが無数にある環境に展開するよりもはるかに簡単だ。インフラのソフトウェア(オペレーティングシステム、データベース、ミドルウェア等)のバージョンが一貫しているほうが、デプロイはより簡単だ。たとえば、Oracle DBのすべてのインスタンスが11.2.1.3であり、11.2.0.0、12.0.1.0あるいは11.2.1.3がさまざまな場所にインストールされていないという状態だ。また、最初にインフラストラクチャ·ソフトウェアパッケージに一貫性があると、アーキテクチャ上の決定を行うことが非常に容易になる。たとえば、サーバーオペレーティングシステムとしてLinuxを標準化したら、Windows、z/OSおよび他のものは運用しない(さらには、積極的にそれらを引退させる)といったようにだ。
  • デプロイメントテスト  ソリューションあるいは運用インフラを構成するコンポーネントをアップデートしたら、デプロイが成功したかを検証する、短時間で実行可能なテストを実施すべきである。必要とされた正しいバージョンがインストールされたか?そして、それらはすべて適切なサーバーにデプロイされたか?データベース変換が正常に行われたか?必要なら、適切な通知が行われたか?展開プロセス全体が、要求された時間枠内で実行したか?
  • 自動デプロイ  デプロイは、手動ではなく自動化されるべきである。これはデプロイ作業の一貫性を高め、継続的デプロイの実現をサポートする。自動化に向けての作業の一部を割いて、自己回復とセルフテストの両方をサポートするべきだ。
  • 運用インテリジェンス   これはデータウェアハウス(DW)/ビジネスインテリジェンス(BI)アプリケーションであり、読者の運用やサポート作業に関する洞察を提供する。運用チームは、ソリューションごとに独立したダッシュボードを提供するし、個々のソリューションによって生成された情報を結合し統合されたダッシュボードを提供するものだ。さらに進んだものではITポートフォリオ管理の視点で情報の共有を実現しさえする。運用インテリジェンスはITインテリジェンスのサブセットになる。

次に、運用時の減災(Disaster mitigation)という観点での戦略を見ていくことにしよう。

  • 災害対策計画の策定  統制のとれた組織(Disciplined oraganization)は、様々な運用の失敗に対処するための計画を決めるだろう。起こりうる災害・失敗の例としては、サーバーのダウン、ネットワーク接続のダウン、電力喪失、ソリューションのデプロイの失敗、インフラ導入の失敗、自然災害―火災、洪水―、テロ攻撃その他諸々がある。この計画作業では、潜在的な問題の識別、それらの問題に対処するための戦略の識別、そして、災害の影響を軽減するためのメカニズムをどこに置くことが適切かが検討される。この類いの災害・失敗に対して取り得る戦略には、セルフテストと自己復旧を行うソリューションの構築や、運用インフラに冗長性を持たせる、適切な災対手順を用意するといったアプローチがあり、シミュレートされた災害でそれらの戦略を実行することができる。
  • スケジュールされた災害シミュレーション  災害に備えたプランが定められているということと、それが実際に機能するか否かを知っておくというのは大事なことだ。統制のとれた組織では、問題発生時の影響軽減戦略が実際にどのように機能するかを確認するために、災害シナリオを実行するだろう。たとえば、停電の緊急時計画では、意図的にデータセンターの一つで停電をシミュレートしてから、リカバリ計画が有効に動作するかどうかをテストする。スタッフが緊急時に迅速かつ適切に行動できるよう、必要な手順を「身体に覚え込ませる」ために、消防訓練と同様に、これらのシミュレーションは、定期的に行われるべきだ。スケジュールされた災害シミュレーションの利点は、利害会関係者に最小限の影響しか与えないだろうという時点で意図的に実行できることだ。欠点として挙げられるのは、少なくとも実行に先立ち人々に知らせることによって、シミュレーションに対して心の準備が出来てしまい、「不意の状態」を作れないことだ。だから実際に緊急事態が起こった場合に人々がさらされるであろうストレスを、現実的なレベルでシミュレートすることができない。
  • ランダムに行われる災害シミュレーション  高度に練度が上がった組織では、サーバーやサービス停止をランダムに引き起こすサービスを本番環境内で実装するだろう。この機能の例が、AmazonのWebサービス(AWS)で提供されているカオスモンキー(Chaos Monkey)だが、同様の機能性が多くの組織で実装されている。カオスモンキーは、本番環境にランダムに問題を注入して、それによってIT運用部門がそれらを克服することが出来るか否かを確認することができる。ソリューションが、発生した問題から本当に自動的に復旧できるか、失敗するにしても少なくともオペレータに警告を発することができるかが検証される。

皆さんが予想されるように、真に統制された組織は、以上に挙げた戦略すべてを採用している。

2.5  サポート(ヘルプデスク)戦略

ソリューションサポート(ヘルプデスク)戦略にはいくつかあるが、それらは組み合わせることが出来るし、適切なモノを選択することもできるだろう。以下に見ていこう:
  • オンライン情報 「自己解決(Self Serve)」を促すとてもよく行われる戦略は、オンラインのアセットを開発・維持することだ。FAQページ、トレーニングビデオ、ユーザマニュアルといった類いのものがそのアセットにあたる。この戦略は、エンドユーザが自分自身をサポートし問題を解決することを促しているが、「TAGRI(They Ain’t Gonna Read It:彼らはそれを読むつもりはない)症候群」に苦しんでもいる。
  • オンラインディスカッションフォーラム  多くの組織では、エンドユーザー同士がお互いを助けあいながら自社システムの使い方を学習できるように、社内にディスカッションフォーラムを立ち上げている。これは、エンドユーザーが自分で問題を解決するにあたって、効果的に機能する助け合いオプションである。大きな利点は、「パワーユーザー」や場合によっては開発チームのメンバーが、問題と格闘している他のユーザを助けにやってくるだろうという点だ。潜在的な欠点は、問題がタイムリーに解決されない場合に、ディスカッションフォーラムが苦情フォーラムになってしまうリスクがあることだ。
  • 非同期サポート  非同期サポート戦略では、エンドユーザーがヘルプ要求を提出し、その後少し時間をおいて、誰かが助けに戻ってくる(望むらくは)。非同期サポートを実装する一般的な方法は、標準化されたサポート電子メールまたはサポートリクエストページ/画面を実装するなどだ。多くの組織で、ヘルプを必要とする人々の待ち時間を制限するために、サービスレベルアグリーメント(SLA)を設定しているのがよく見られる。
  • 同期サポート  同期サポート戦略では、エンドユーザーがリアルタイムでサポート担当者(アプリケーション開発者の一人であるかもしれない)と接触する。オンラインチャットソフトウェア、ビデオ会議、電話等がよく使われる。同期サポートの重要な利点は、その応答性だ。しかし、同期サポートは、運営が高くつく可能性があり、エンドユーザにとっていらいらの元になり得る。特に、サポートデスク機能がアウトソースされ、所定のスクリプトにただ従うだけのような担当者の場合は、顕著だ。
  • サポートアラート  この戦略では、ソリューション自体がエンドユーザに影響を及ぼすような重大な問題ー例えばデータソースやサービス/コンポーネントが稼働しない等ーを検出する。このようなイベントが発生し、ソリューションが迅速に復旧することができない場合、エンドユーザーは問題の通知を受け、場合によっては「助けが必要ですか?」と尋ねられる。yesを選択すると、問題解決に適切なサポート担当者と、その場で直接コンタクトが取られる。これは、ソリューションの自己回復プロセスの一部である。
  • 開発者によるサポート  戦略は、開発チームが自分達で構築したソリューションサポートを行うというものであり、「DevOps戦略:開発」で紹介したものだ

さらに、ソリューションサポートを行っている人は誰でも(開発チーム自体であっても)、エンドユーザーが経験する問題を再現できる環境が必要になりだろう。 利用できるオプションを挙げよう。

  • プロダクション(本番)環境   本番環境で充分な場合もあるが、なんらかの規制の下にある環境、特に生命に不可欠で財務上重大な規制環境下では、これが認められない。
  • プリプロダクション(本番前)テストサンドボックス  プロダクション前のテスト環境を使用してプロダクションの問題をシミュレートすることができるよう、環境を用意している組織もある。 問題を再現しようとする際に、本番環境が危険にさらされないことは、大きな利点だ。テスト環境が本番環境と異なるため、報告されたすべての問題をシミュレートできない場合もある。
  • サポートサンドボックス  一部の組織では、サポートスタッフが本番での問題をシミュレートできるように特定の環境を設定している。 この戦略は、本番前のテストサンドボックスと同種のトレードオフに加えて、別の環境に関連する追加のコストと保守というトレードオフがある。

2.6 リリース管理戦略

DevOpsをサポートする主要なリリース管理戦略4つを採り上げる。効果のあまり高くないものからより高いものへと、順に紹介していく。
  • リリースウィンドウ(スローケーデンス)  リリースウィンドウは、一つ以上のチームが本番環境にリリースまでの期間のことだ。リリーススロットは、リリースウィンドウのサブセット(あるいはリリースウィンドウ全体のこともある)であり、この枠の中でチームがソリューションを本番環境へデプロイすることもあるうる。たとえば、本番へのリリースは土曜の夜午前1時から午前5時の間(リリースウィンドウ)に行わなければならず、そのウィンドウの中で最大4リリースまでは行うことができる(リリーススロット)。リーンの用語では、リリーススロットは、チームがデプロイできるカンバンカードに事実上相当する。リリースウィンドウは、システムの利用状況が比較的低調な時間帯に合わせて設定されるのが普通だ。もっとも昨今のグローバル化が進み24×7運用があたりまえの時代には、このウィンドウはあまり意味を持たなくなったが。これにスロー・ケーデンス・アプローチを適用すると、リリースウィンドウは長くなり、1週間に一度など滅多になく、それどころかもっと長くなりさえするだろう。このアプローチの利点は、それがビジネス利害関係者に対しては、一貫したケーデンスでリリースを行い、デリバリー·チームに対しては一貫したリリース目標日をもたらすことだ。スロー・ケーデンス・リリースウィンドウの欠点は、複数チームをサポートする場合にリリース管理プロセスのボトルネックになることだ。各ウィンドウ(期間)中に、あまりに多くのリリーススロットだけがあり、しかもその数は簡単に増やされうるし、これによってチームの意識が将来のリリースウィンドウに向けさせられる。チームが継続的デリバリー戦略に移行し始めると、この問題はさらに悪化してしまう
  • リリーストレイン  リリーストレインというアイディアは、ある”列車(トレイン)”に乗っているすべてのチームが、同じリリースケーデンス・・・例えば、四半期に一度か、月に一度、あるいは週に一度・・・で活動するというものだ。この戦略は、一般的により大規模なプログラム(訳注:いわゆるポートフォリオープログラムのプログラム)、またはチーム・オブ・ チームズ(team of teams)と呼ばれる独立したチームの各々が大きな枠組みの中の一部として活動する形態で採用される。リリーストレインが刻むビートを共有することによって、利害関係者に対しては一貫性したリリーススケジュールを提供し、開発チームのためのラリーポイント(= 各々が開発していた成果物を集めて統合するタイミング)を提供する。列車のメタファーは、実際に非常にうまく機能する。あなたのチームがリリース日を逃し(リリースできず)、列車に乗り遅れれば、列車はあなたなしで 先に行ってしまい、あなたは次に乗車できる場所で待機する必要がある。依存関係も尊重される。例えば、複数のコンポーネントを一緒に出荷する必要がある場合、それらは同じ列車に乗らなければならない(家族が一緒に旅行するようなものだ)。主な欠点は、開発チームが共通のリリーススケジュールに制約され、それがリーンや継続的デリバリー戦略を難しくすることだ。潜在的な欠点は、スロー・ケイデンス・リリースウィンドウのボトルネック問題に苦しむ可能性があることだ。
  • リリースウィンドウ(クイックケーデンス)  継続的デプロイメントをサポートするためには、特に多くのデリバリー·チーム全体を考えた場合、多数のリリーススロットが必要になる。これが暗に示すのは、あなたもこれまで以上に多くのリリースウィンドウを必要とするだろうということだ。クイック・ケーデンス・リリースウィンドウの利点は、スロー・ケーデンス・リリースウィンドウやリリーストレインに起因するボトルネックの影響を受けづらいだろうということだ。
  • 継続的リリース機能  このアプローチでは、デリバリー·チームは、必要なときにいつでも本番環境にリリースすることが許されている。多くの点で、単にリリースウィンドウを24/7にする、これまでのリリースウィンドウ戦略の拡張です。これは本来の意味で、継続的デリバリーをサポートする唯一の戦略です。これを可能にするためには、DevOpsプラクティスのホストがひつようとされる。例えば、完全に自動化されたデプロイメント、完全に自動化されたレグレッション・テスト、フィーチャーのトグル、自己回復コンポーネント、および諸々が必要とされる。
私たちが経験したところでは、今日ほとんどの企業は、スロー・ケーデンス・リリースウィンドウ戦略を採用しているが、同時にクイック・ケーデンスバージョンに至る進化の入口に立っている。 継続的デリバリープラクティスによってよりも、ソリューションデリバリーチームがアジャイルテクニックを適用することで動機付けされることのほうが多い。
 私たちは、大規模なプログラムがリリーストレイン戦略を採用するのは見ている。この戦略は1990年代にマイクロソフトやラショナルといった複数のプロダクトを同時に出荷するソフトウェア・スイート製品を販売していたソフトウェア企業によって開拓されてきた。近年、OpenUPやSAFeフレームワークがリリーストレイン戦略を広めている。 継続的リリース・アベイラビリティ戦略は、EtsyやAmazonといった、高度なDevOps組織で採用されている。
それらに加えてDevOpsをサポートするリリース管理戦略は複数存在する:
  • 統合デプロイ計画  開発チームの視点で見ると、デプロイメント計画作りは、組織の運用部門やリリース管理部門のスタッフと常にやり取りすることが求められる:いくつかのケースでは、運用部門の中にリリースエンジニアと呼ばれる専門の渉外担当を置き、彼/彼女を介してやりとりしている場合もある。あなたがディシプリンドDevOpsの考え方を採用するとすぐに理解することになるのは、運用スタッフがすべての開発チームと一緒に作業する必要があるので、デプロイメント計画にはチーム横断のアプローチが必要であろうということだ。運用スタッフにとってはこれはニュースではない。しかし、自分達だけで、サイロ化された環境で作業することに慣れている開発者にとっては驚きとなる(幸運なことに、この戦略は、DADの”Move Closer to a Deployable Release process goal”(未訳)に組み入れられている)。チームがまだこれをやっていない場合は、組織全体のデプロイスケジュールの中でリリース·スロットをめぐる争いを始める必要があるだろう。
  • 本番環境に基づく開発とテスト環境の標準化  開発チームは、開発、テスト、本番環境との整合性が高まるほど、テストとデプロイがより簡単になることを知っている。複数のチームが作業する環境でこれが暗に意味するのは、最終的には環境の多くの側面が事実上標準化されるだろうということだ。開発者は、別の開発ツールを選択することができるが、インフラの側面ーオペレーティングシステム、アプリケーションサーバー、ミドルウェア、データベース、などーでは、リリースプロセス全体が合理化され、時間をかけて整合性が取られることとなるだろう。
  • リリースサービスストリーム  DADフレームワークの主要テナントは、すべてのチームがユニークであるという点だが、それはチームによっては他のチームよりもより多くの助けを必要とするモノがあるということを暗示している。チームの成果物の品質レベルは異なっており、自動化の程度も様々、さらには異なるリリースケーデンスを採用しているといった具合にだ。その結果、これらの状況に対応できるように、リリース管理戦略は、高い柔軟性が求められる。その方法の一つは、ソリューションデリバリーチームに、状況に合わせた異なるサーバーストリームやサービスレベルを提供することだ。たとえば、あなたのチームは基本的なリリース管理サービスストリームを持っているかもしれない。そこでは、リリース管理エンジニアが積極的にデリバリー·チームを支援し、開発成果物を本番環境へのデリバリーし、さらに彼らのプロセスのどこかを自動化する手助けを始めてさえいるかもしれない。
    他方極端な例では、デリバリーチームに対して、継続的デリバリーサービスストリームを提供している可能性もある。その種のストリームでは、テストとデプロイメントプロセスが完全に自動化され、成功にデプロイされるその仕組みに対して高い信頼が寄せられているかもしれない。
    そしてもちろん、これらの両極端の間にいくつかの他のサービスストリームの形態がありうる。このアプローチの利点は、スケジューリングの複雑さのコストが僅かに大きなものになるが、非常に柔軟であることです。
  • リリースブラックアウト期間  一部の組織では、よほどのことがない限り、本番環境に新機能をリリースしないと決めた期間を設定している。この種のブラックアウト期間は、多量のビジネストランザクションが発生する時期に設定されることが典型だ。例えば、多くの北米の小売企業は11月半ばから1月上旬のホリデーセールスシーズンのブラックアウト期間を設定することが多い。多くの組織では会計年度の終わり近くに設定する。年度の終わりに必要な処理を終わらせることに集中するためだ。
  • リリースプラクティスの共有  これは本当にプロセス改善の問題だが、リリース管理に関わる人々は誰でも、効果的なプラクティスをチーム間で共有するために積極的に努力すべきであると指摘する価値がある。学びを共有するというのは、エンタープライズ対応の重要な側面の一つだ。

2.7 データ管理戦略

ディシプリンド・アジャイル・デリバリー(DAD)フレームワークにおけるデータ管理とは、データ指向アーキテクチャ、ポリシー、およびプロセスに焦点を当てた、実行(Run:運用)時の活動を意味する。組織の、データを核とした諸々の活動に対する長期にわたる計画作成の取り組みは、エンタープライズアーキテクチャの取り組みの一環であることに注意しよう。

 同様に、組織のエコシステムのデータまわりの開発は、ソリューションデリバリー・チームによって為される。
データ管理は運用業務の重要な要素なので、ディシプリンドDevOps戦略の影響を被る。経験によれば、以前紹介した一般的なDevOps戦略に、以下に挙げるようなDevOpsをサポートするデータ管理戦略を加える必要がある。
  • データおよび情報ガイドライン  開発と、データや情報ソースの応用利用との間により高度な一貫性を確保するための直接的な方法は、チームが利用する共通のガイダンスを策定することだ。このガイダンスには標準ポリシーとガイドラインの両方が含まれる。利用者間のコラボレーションとオープンなやり方で定義され、サポートされ、そして時を経て進化し続ける。
  • データソースの品質  ファイル、データベース、およびデータフィードなど、本番のデータソースは、簡単に利用出来る高品質なアセットであるべきだ。データソースに記録された後、それらのレコードが高品質であることは特に重要で、それがあってこそそれらは簡単に利用され、進化するのだ。残念ながら、多くの組織では、これは空想の域を出ていない。ディシプリンドDevOpsの考え方では、チームはデータソース内の技術的負債を増やすことについては非常に注意を払い、彼らが見つけた技術的負債を返済するために払う労力に投資することがより重要である。
  • IT インテリジェンス  ITインテリジェンスは、データウェアハウス(DW)/ビジネスインテリジェンス(BI)ソリューションの作成・サポートとその進化、そしてオペレーションという活動である。これにより、あなたの会社のIT活動全般の管理とガバナンスをサポートする。ディシプリンドDevOpsの観点から見ると、ITインテリジェンスには、2つの重要な側面がある:デリバリーチームがどのように機能しているかへの洞察を提供する開発インテリジェンスと、運用で何が起きているのかを提示する運用インテリジェンスだ。多くの開発プラットフォームが提供する自動化されたチームのダッシュボードは、開発インテリジェンスの単純な形態だが、より洗練された(そして有用な)ものは、様々な開発ツールからの情報を統合し、統合ダッシュボードに表示するものだ。さらに有用なのが異なるデリバリーチームからの情報を集約/統合し提示するポートフォリオマネージメントダッシュボードだ。
同様に運用チームも各々のソリューション毎に独立したダッシュボードを持っている。各々のソリューションによって生成された情報を結合し統合されたダッシュボードに提示したり、ITポートフォリオマネージメントビューで共有すればさらに有用なものとなる。

2.8 エンタープライズ・アーキテクチャ戦略

DADフレームワークは、アーキテクチャに関連する活動や、アーキテクチャオーナーという役割を明確に定義しており、エンタープライズ対応(Enterprise-aware)という哲学を前面に打ち出している。我々の経験では、ディシプリンドDevOpsの考え方を組織に適用するにあたって、アジャイル・エンタープライズ・アーキテクチャは、実現のための鍵となることが実証されてきた。
一般的なDevOps戦略に加えて、DevOpsをサポートするエンタープライズ・アーキテクチャの活動がいくつかあるので、以下に見ていこう。
  • 再利用マインドセット  エンタープライズ・アーキテクチャの労力が将来に実を結ぶために重要なことは、IT部門、そして組織全体に再利用のマインドセットを定着させることだ。再利用のマインドセットが定着したデリバリー・チームは、既存のデータソース、サービス、コンポーネント、フレームワーク、テンプレート、および他の多くの資産を活用するように努めている。このマインドセットは、エンタープライズ・アーキテクト(理想的には、アーキテクチャ・オーナーとしてITデリバリー・チームのアクティブメンバーであることが望ましい)による教育、コーチングとメンタリングを通して植え付けられる。また、ITデリバリー・チームが使うべき、あるいは使用すべきではない技術を示す技術ロードマップによって可能となる。そしてもちろん、発見しやすく理解しやすく、適用して真の価値を提供できる高品質なアセットの存在が再利用を可能にする。
  • 技術的負債マインドセット  エンタープライズ・アーキテクチャの取り組みでは、デリバリーチームが技術的負債を発見した時にその負債を返済するよう、彼らを動機付けるアプローチを推進すべきだ。さらに重要なのは、最初の段階でそのような負債をかぶらないようにすることだ。多くの技術的負債戦略が、DADフレームワークに埋め込まれているが、技術的負債のマインドセットなしでは、無駄に終わることが珍しく無い。エンタープライズアーキテクト(しばしば、デリバリー・チームのアーキテクチャ・オーナーとして機能する)は、技術的負債に関連する問題を中心に、開発者をコーチし、メンターとしての役割を果たす必要がある。同様に、この技術的負債にかかわってコラボレートする、よりシニアなマネージャーや利害関係者を教育するために役立つはずだ。技術的負債を回避し取り除くためには投資が必要であり、普通IT投資の判断は彼らの手にあるからだ。
  • 開発ガイドライン  エンタープライズ・アーキテクチャの重要な側面は、ITデリバリー・チーム全体で共通の懸念に対処するためのガイドラインの開発である。組織は、セキュリティガイドライン、接続のガイドライン、コーディング標準、および他の多くを開発することがある。共通の開発ガイドラインに準ずることで、ITデリバリーチームはより一貫性のあるソリューションを構築し、それは転じて本番稼働時により簡単に操作できサポートできるソリューションとなり、DevOps戦略をサポートする。共通の開発ガイドラインの潜在的な欠点は、開発者がそれらによって制約を感じるかもしれないということだ。この問題への対抗策は、ガイドラインはデリバリーチームとのコラボレーションを通して開発され進化されるべきであり、上から課せられるべきではない。
  • 技術ロードマップ  エンタープライズ・アーキテクチャでは、技術ロードマップの定義、サポート、そしてそれを進化させるという活動が含まれ、そのロードマップが組織の他の活動(同様に重要なビジネスのロードマップはプロダクトマネージメントの範疇)をガイドする。このロードマップは、本番環境に共通の一貫した技術的インフラストラクチャーを構築することを助ける。この技術インフラが共通のDevOpsプラクティス―継続的デプロイ、自動化されたエンドトゥエンドのリグレッションテスト環境、以前のブログでも議論した運用のモニタリング―を実現するのだ。

技術ロードマップの重要な側面は、既存のITインフラストラクチャと、そのインフラの将来ビジョンの両方を捉えることだ。ここでITインフラとは、ネットワーク、ソフトウェアサービス、サーバ、ミドルウェア、および主要な構成要素となる少数のデータ・ソースが含まれている。以下の図に見られるように、技術インフラへのビジョンを作る際、考慮すべき2つの問題がある。

  • オーナーシップ  あなたの組織は自身のインフラストラクチャを所有し運営するのか、あるいは外部の専門家にその一部または全部をアウトソースするのだろうか?アウトソーシングオプションには、他の組織(HPやIBMなど)が外部の組織(AmazonやGoogleのような)が提供するクラウド技術を使ってあなたの会社のデータセンターを運用するという従来のアプローチも含まれる。独自のインフラを所有することの利点は、かなりの部分をコントロールできることだ。これはITソリューションのセキュリティと整合性を保証しなければならないときに非常に重要だ。アウトソーシングは、潜在的に規模の経済からITインフラストラクチャとコスト削減を管理する上でより大きな柔軟性をもたらす。しかし、アウトソーシングは、より洗練されたガバナンスを必要とし、前述した従来のアプローチの場合には、アウトソーサーがあなたの要求にタイムリーに応答できない場合、潜在的なボトルネックになる。
  • 仮想化  特定のソリューションのニーズを満たすために構築された、あるいは可鍛性(※訳注)と進化のしやすさを実現するためにソフトウェア化(softwarization)されたITインフラストラクチャの構成要素があるか?ソフトウェア化―ソフトウェア定義インフラストラクチャ(SDI)として知られている―では、ITインフラストラクチャの要素が完全に仮想化される。ソフトウェア化は、ソフトウェア定義データセンター(SDDC)、ソフトウェア定義(SDS)、およびソフトウェア定義ネットワーク(SDN)を包含したITインフラストラクチャモデルを含む。ソフトウェア化は、通常、ファイアウォールの両側で、クラウドベースのテクノロジを使って実装される。さらに進んだ仮想化のソリューションでは、ITインフラストラクチャの柔軟性とプログラマビリティを高めており、それによってリソースの最適化を可能にする。その一方で、仮想化がもたらすより大きな柔軟性は、あなたのテスト作業の複雑さを増加させ、運用での課題をシミュレーションすることをより難しくする。
    ※訳注 ”可鍛性”:原文では”malleable”。外的圧力を受けても破壊されることなく変形できる能力。ここでは、ビジネス等の外部環境の変化に呼応して変化できる柔軟性という意味。EA matrix

3. なぜディシプリンド DevOpsなのか?

このセクションでは、あなたとあなたの組織の両方がディシプリンドDisciplined DevOpsの考え方を採用することを検討すべき理由を簡単に説明した。 あなた個人としては、いくつか興味深い利点がある。 まず、ITプロフェッショナルとしてより生産的になり、昇進の機会を増やし、あなた自身の市場価値をより魅力的なものにすることに繋がる。 第2に、面白い、付加価値の高い仕事に集中することができ、仕事上のより大きな満足を得ることができる。 第3に、伝統的なIT組織で見られて機能不全の政治の多くは、ディシプリンド DevOpsの考え方に移行する際に効果的に排斥され、作業環境をより楽しいものにする。

組織がDisciplined DevOpsの考え方を採用することを検討する理由はたくさんある。 以下の表2は、潜在的な利益とその達成方法をまとめたものだ。

表2 ディシプリンドDevOpsのマインドセットを根付かせるための取り組み

利益 達成方法
市場投入を短期化
  • 自動化により移行作業を短時間化
  • より早く実装できるよう機能を細分化
デプロイコストの削減
  • 自動リグレッションテスト
  • 自動デプロイ
  • 合理化されたリリース管理
デプロイ平均間隔の改善
  • 継続的統合や継続的デリバリーといったプラクティスによって、チームはもっと頻繁にデプロイ出来るようになる
  • デプロイにかかるコストを削減すると、チームはもっと頻繁にデプロイできるようになる
品質の改善
  • 自動リグレッションテストやリファクタリング、独立テストといったアジャイルテストや品質向上テクニックの採用
  • アジャイルやリーンの戦略をエンタープライズに適用すると、より全体的な視野を得られるようになる。その結果として、再利用が促進され、技術的負債の削減/回避が進む。
  • データ管理にアジャイルやリーンの戦略を適用することで、組織全般に渡るデータ品質が向上する。
市場競争力の改善
意思決定の改善
  • 開発インテリジェンス戦略から、リアルタイムで洞察を得る
  • 運用インテリジェンス戦略から、リアルタイムで洞察を得る
  • 市場への投入が短時間化しフィードバックサイクルが短くなることで、チームは簡単に試行することができ、利害関係者が実際に欲しているモノを発見できるようになる。

4. まとめ

ここまでディシプリンド DevOpsをサポートする重要な戦略をみてきたので、まとめとして特に重要な成功要因と感じるものを挙げていこう。

  •   IT組織全体で協調的で敬意を払う文化を構築すること 私たちの経験では、ディシプリンド DevOps戦略を採用する際には、人々とその共同作業の仕方が成功の主要な決定要因となる。残念なことに、組織内で文化的変化をもたらすことは、ほんの一握りの新しいプラクティスを導入することよりもかなり難しい。
  •  人々に焦点を当てるが、プロセスやツールを忘れないこと DevOpsは主に考え方だが、このセクションで見てきたように、採用を検討する必要がある潜在的なプラクティス/戦略(プロセスのもの)が多数ある。これらのプラクティス/戦略は、既存のツール(現在は異なる方法で使用されているが)や何らかの理由で採用する必要が明確な新しいツールよってサポートされる必要がある。
  •  選択肢があるのはよいことである このセクションでは、多くのオプションが用意されていることが明らかになった。それぞれのオプションには長所と短所がある。単一のアプローチは完全ではなく、すべての状況に対して機能する単一のアプローチは存在しない。あなたには選択する必要があるというだけではなく、実際に選択肢が存在するということは、信じられないほど良いことなのだ。

 

オリジナル: Disciplined DevOps
http://www.disciplinedagiledelivery.com/disciplineddevops/
(翻訳:藤井智弘)

LINEで送る
Pocket