DevOps を始めるための実践ガイド 目次 DevOps は適切な選択肢か ? 3 方向性を誤った開発と運用 5 機能不全のプロセスの 7 つの兆候 6 まとめ :DevOps への出発点 24 目次 2 DevOps は適切 な選択肢か ? アプリケーション・エコノミーにおいては、あらゆるビジネスがソフトウェア・ビ ジネスへと変化を余儀なくされています。そこで急速にビジネスの最重要分野 の 1 つになりつつあるのが DevOps です。 DevOps は新規アプリケーションの 市場へのデリバリの質と速度の向上を目的とします。 DevOps とは、そのため に開発と運用の緊密な統合を行うことを意味します。 当初は DevOps について一時的な流行に過ぎないと考えられることもありまし たが、今ではあらゆる企業が改めて注目するようになっています。 どの企業も「自分たちは DevOps の手法を自力で採用できるか、それはうまく 機能するか ?」と考え始めています。 DevOps を採用している平均的な企業では、市場投入時間が 20% 改善し、ソ フトウェア品質が 22% 向上、アプリケーション・デプロイの頻度が 17% 向上し ており、その結果、顧客が 22%、収入が 19% 増加しているという結果があり ます。 1 では、 個々の企業にとって、 DevOps には一体どのような利点が あるのでしょうか。 次の セクション 目次 DevOps は適切な選択肢ですか ? 「TechInsights Report:What Smart Businesses Know About DevOps」、2013 年 9 月 1 3 DevOps とは DevOps の導入を決定する前に、DevOps を正しく定義する必要があります。 DevOps は製品でも特定の技術でもありません。 DevOps は手法です。それに よって、ソフトウェア開発（Dev）と運用（Ops）という異なる機能を単一の継 続的なプロセスに統合します。 DevOps とは、開発と運用の間の障壁を取り除くことでもあります。 そうするこ とで、人材、プロセス、技術の活用が可能になり、ソフトウェア開発とリリース・ プロセス全体でコラボレーションとイノベーションが促されます。 DevOps では 開発と運用は 1 つのチームとして考え、行動します。 DevOps に終わりはありません。 開発チームと運用チームは新しい曲を練習す るシンフォニー・オーケストラ、 あるいは、 決勝戦を迎えるスポーツ・チーム のように最高の状態を目指し、 協力して前進します。 次の セクション 目次 DevOps は適切な選択肢ですか ? 4 方向性を誤った 開発と運用 開発チームの業務は開発期間の短縮と新製品開発です。 運用チームの業務は、安定性の確保、制御、予測です。この 2 つは多くの場合、 異なる幹部が管理しています。この 2 つは、まるで 2 つの異なる電車の線 路のようです。どんなに速く走っても、決して合流することはありません。 開発チームと運用チームに任せているだけでは、互いに話し合う努力はして もコラボレーションには至らず、結局、煩わしい手作業から解放されること はないでしょう。社員間の協力関係を構築できず、ソフトウェアの信頼性が 低下し、その結果、顧客は他社への乗り換えを検討するようになります。 先延ばししている余裕はないのです。 次の セクション 目次 方向性を誤った開発と運用 5 機能不全のプロセスの 7 つの兆候 開発チームと運用チームが協力して同じ方向を目指すことは容易なことではありません。まず、チームが異なる線路上にあ るのかどうか確認する必要があります。機能不全の兆候には以下があります。 1. ソフトウェアの欠陥がライフサイクルの終盤まで、あるいは最悪の場合、本番に至っても発見できない。 2. アジャイル開発を加速しても、本番導入後にその加速の利点が消失する。 3. 開発者とテスト担当者が必要なリソースにアクセスするのに時間がかかり、開発が遅延する。 4. 開発、テスト、本番で問題を特定できない。 5. 開発およびデプロイ時の単純な人為的ミスによって大きな混乱が発生する。 6. 開発チームは自分たちの仕事はアプリケーションの本番導入までと考えている。 7. 問題が発生すると、責任追及に終始して他のスタッフを非難する。 次のページからは、機能不全のプロセスで最もよくある兆候を確認し、機能不全から抜け出し完全に成熟した DevOps にす るための実用的なアドバイスを提供します。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 6 注意すべき兆候 : ソフトウェアの問題がサイクル 終盤まで検出されない 複雑なソフトウェアには必ず問題があります。 重要なのは、それらをプロセスの初期段階で検出することです。 開発 回帰テスト QA テスト 統合テスト パフォー マ ン ス・テスト ソフトウェア開発ライフサイクルの従来のウォーターフォールのアプローチでは、各段 階で問題修正のコストがかかります。本番環境でエンドユーザが大きな問題を見つけた となれば、開発中に検出した場合より 100 倍のコストがかかることもあります 2。 残念ながら、ウォーターフォールのアプローチでは、開発スケジュールの開始が遅れた り、ましてや厳しい期限が設定されている場合には、テストにあてる時間が足りなくなり ます。このような状況ではミスが多くなり、期限に間に合わせなければというプレッシャー に負けて、テストが途中であってもアプリケーションを本番環境に投げ込んでしまうこと になります。 修正のコスト が上昇 ユーザの受け 入れテスト 100 倍 本番 本番環境で 問題を検出 次の セクション 目次 機能不全のプロセスの 7 つの兆候 「Software Defect Reduction Top 10 List, Computer」（2001 年 1 月）、http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf 2 7 軌道修正の方法 開発とテストを並行 して実行する これは、新しい技術的なアプローチであるサービス仮想化によって、本番環境での 実際の動作をシミュレーションすることで可能になります。開発者とテスト担当者が実 際のインフラストラクチャのリソースを使用することはできないため、このアプローチ では仮想環境に本番環境全体を再構築します。バックエンドのインフラストラクチャ、 データベース、サーバおよび環境の残りの要素は仮想サービスとして利用できるた め、大勢のスタッフが大量のコンポーネントを同時に使用でき、お互いに影響を及ぼ したり本番環境に影響することもありません。すぐに開発とテストを並行して実行で きるようになります。 テストを自動化することでプロセスはさらに加速できます。 ユーザの受け入れテスト 開発 QA テスト パフォーマンス・テスト 本番 回帰テスト 統合テスト 次の セクション 目次 機能不全のプロセスの 7 つの兆候 8 本番環境のパフォーマンスをシミュレーションすることで、コ ラボレーションによるデータ・マイニングを通してより現実に 近づけることができます。この方法では、本番環境に組み込 まれたパフォーマンスをスキャンします。 データ・マイニングでは開発者や品質担当エンジニアに仮想 サービス・モデルが提供されます。 その仮想サービス・モデ ルは本番環境に見られるようなビジネス状況やシナリオをシ ミュレーションしたパフォーマンス・プロファイルを使用して、 サービス仮想化のあらゆるメリットを結集し、実際の環境にで きるだけ近い動作を再現します。 そうすることで、開発者や パフォーマンス・エンジニアは実際の環境における実際のコン ポーネントの動作とパフォーマンス特性を正確にエミュレート して制約を軽減できます。 初期段階で問題を検出すると、ソフトウェアの品質 が向上し、 少ない労力で開発期間を短縮できます。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 9 注意すべき兆候 : アジャイル開発を加速しても、本番導 入後にその加速の利点が消失する アジャイル開発はソフトウェア開発を加速するすばらしいアプローチです。ただし、ソフトウェア開発はアプリケーショ ンをユーザに提供するための 1 つのステップにすぎません。 開発チームと運用チームがコラボレーションしなければ、アプリケーションを「最高」の状態で本番環境に導入するこ とはできません。運用チームは開発に関与しない場合が多いため、アプリケーションの本番環境へのデプロイ方法を 完全に理解しているわけではありません。そのため、本番へのデプロイで試行錯誤が繰り返されて、時間が無駄に消 費されます。 また、開発チームだけでは顧客にアプリケーションを提供することはできません、開発プロセスの時間を短縮しても、 本番導入にかかる時間を短縮しない限り、 市場への投入を加速することは難しいと言えます。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 10 軌道修正の方法 初期段階で運用チー ムが関与する アジャイル開発の手法はインタラクティブなプロセスを中心に構築され、市 場ニーズに迅速に対応できます。その考え方は、段階的かつ頻繁に変更す るというもので、すべての変更を一括で適用するのとは異なります。運用も そのような市場ニーズに含まれています。 アジャイル開発を担当する部門にとって、市場ニーズを度外視したアプリケー ション開発は考えられません。本番環境のニーズにも同じ注意を払うべきで す。また、開発とテストは可能な限り現実に近い環境（本番環境にそのまま 導入できる）で行う必要があります。 問題のもうひとつの原因は、 手順を順番通りに実行することです。アジャイ ル開発に最も重点をおく組織でも、作業の大半を段階ごとに実行することが あります。段階的にプロセスをこなしていては、開発もデプロイも遅延する 可能性があります。可能な限り、チームは並行して作業を行い、並行で行 えない作業がある場合、その作業をそれ以前のプロセスに移動する方法を 考えます。運用チームは開発チームがアプリケーションのデプロイ作業を開 始するまで待つ必要はありません。運用チームも初期段階で参加し、開発プ ロセス中にデプロイ計画を作成すべきです。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 11 注意すべき兆候 : チームがリソースの使用を待たさ れ、スケジュールが制約される 複雑なアプリケーション開発では、それがたとえモバイル・アプリケーションのフロントエンドのサービスであっても、 アーキテクチャ全体の中間の統合レイヤの要素であっても、組織内の他のシステムやサービスからの情報が使用され ます。 開発者とテスト担当者はこのようなサービスに簡単にアクセスできません。 バックエンド ･ システムはインベントリ・ システムと同様、週に 1 回 2 時間だけテストのためにアクセスできるなどの制限があります。また、本番システムに 機密データがある場合などは、アクセスが禁止されたり拒否されることもあります。これらはすべて、アプリケーショ ンの開発とテストのプロセスにとって深刻な制約です。 ある企業の CTO が言っています。 「すべてが揃ってはじめて作業ができるのに、 揃っていた試しがありません。」 次の セクション 目次 機能不全のプロセスの 7 つの兆候 12 軌道修正の方法 サービス仮想化 を使用する サービス仮想化は実際の本番環境の動作をシミュレーションしている ため、大勢のスタッフが大量のコンポーネントを同時に使用でき、お 互いに影響を及ぼしたり本番環境に影響することもありません。 それによって制約が排除され、多くの組織でアプリケーションの開発 とテストの障壁が取り除かれます。テスト環境に実際の状況が反映さ れるだけでなく、異なるコンポーネントを同時にテストできるようにな ります。これまで順番に実行していた手順を並行して実行できます。 また、制約と障壁が排除されるため、開発サイクル全体を前倒しで 進めることができます。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 13 注意すべき兆候 : 問題を特定できない 原因は開発、テスト、 本番運用のコラボレーションの不在 開発、テスト、本番の各チームは大きく異なる環境で作業し、異なるシステムでそれぞれの作業を管理してい ます。それが、ソフトウェアの欠陥を修正できない原因になっています。 テスト結果が予測できない 現実的な状況でテストする機会がない 開発 テスト 本番 テスト 開発 フィードバックを共有していない 各部門のコミュニケーションがない • システム • プロセス 本番 • 人材 次の セクション 目次 機能不全のプロセスの 7 つの兆候 14 開発チームとテスト・チームは多くの場合、本番環境を利用できる保証がないた めにテスト環境を使用しますが、テスト環境では本番環境の機能が提供されるだ けで、本番環境が完全に再現されるわけではありません。こうしたテスト環境は 現実的ではなく、本番環境の条件を複製したにすぎません。 そのため、早い段 階のテストでは本番環境におけるアプリケーションの動作を予測できず、 アプリ ケーションが本番環境に移行された際にしばしば問題が発生します。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 15 また、運用、開発、テストのチームはそれぞれ、異なるシステム を使用して環境を管理しますが、運用チームと開発チームの間 に必要な フィードバック・ループが機能しない場合があります。 運用チームがアプリケーションに問題があることを把握していて も、開発チームにその問題を伝えない限り、開発チームが問題 の存在を知る機会はありません。開発チームは本番環境のアプ リケーションを監視できないため、どのような問題が発生して も間接的に知ることしかできません。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 16 軌道修正の方法 機能不全を防ぐための複数の 対策 まず、開発チームと運用チームを 1 つのチームとして認識することです。そのためには、 人材がチームとして作業できるように協力体制を整える必要があります。こうした組織 の変更にあっても、フィードバックを収集し、問題に対処する上で進捗状況を追跡して 共有するプロセスを確立します。 次に、テクノロジを使用します。人材とプロセスに取り組むのは重要ですが、システム を複合的な目的で稼動している場合、はるかにむずかしくなります。 テクノロジにはさまざまな種類があります。まず、開発、テスト、運用の各チームがワー クフロー（および問題）の管理に使用するシステムに相互運用性があることを確認し、 開発チームがテストや運用などの作業を確認できるようにします。そのためには、既存 のシステムを統合する必要がありますが、多くの場合、開発、テスト、リリースの全体 のプロセスのワークフローを統合するために開発されたソリューションの導入が功を奏 することがあります。 また、サービス仮想化などの本番環境の条件を複製した テスト環境を用意して、データ・ マイニングによって本番環境のログから検出された詳細なパフォーマンスのシナリオを 使用することも有効です。それによって、アプリケーションの実際のパフォーマンスを 予測しながらテストを実行できます。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 17 注意すべき兆候 : 人為的ミスによって デプロイ中に混乱と時 間の無駄が発生する ソフトウェアのリリースは多くの組織で大半が手作業に依存しています。 ソフトウェアの問題の原因のほとんどが設定の誤りにあるとしたら驚き でしょう。つまり、アプリケーション自体に問題がなくても、適切に設定 されていなければ問題が起こるのです。手作業で設定すると、必ずど こかで誤りが起こります。 誤りを犯すのは人間ですが、問題が起こるのはコンピュータです。特に デプロイ中のエラーは、同じエラーが数千、数百のサーバ、デスクトップ、 携帯デバイスに複製されるために大きな損害をもたらします。本番環境 で必要な設定とテスト中に必要な設定は異なるため、 テストは役に立 ちません。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 18 軌道修正の方法 多くの組織がスクリプトによってこの問題の解決を試みてきました。それ は確かに、完全に手作業のプロセスよりもましですが、手作業のプロセス と同じ問題をともないます。「移動する要素」と環境間で異なる設定が原 因となって、スクリプトはデプロイするシステムと同じくらい複雑になりま す。 スクリプトに頼らない対策が必要です。また、システムも必要です。特に 大規模なチームでは、コラボレーション、統合、コミュニケーションに対 する DevOps の考え方を強化するうえで、文書を含め、 新しいコードを 本番環境に自動で導入できるツールを社内で用意する必要があります。 リリースを自動化すると、テスト中に正常に機能した設定を本番環境に忠 実に移行できます。また、人為的ミスが排除され、ソフトウェア開発のラ イフサイクル全体が加速します。それによって、継続的デリバリが可能に なり、これまで数日、数週間または数か月を単位としていたアプリケーショ ンのアップデートも数分ごとに実行できます。 リリース自動化の最大の利点は、デプロイ中に不具合が発生した場合に正 常な状態に戻せることです。手作業のプロセスやスクリプトでは、ロール バックは悪夢のような作業です。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 19 注意すべき兆候 : アプリケーションの本番導 入で開発の関与が終わる これまで、アプリケーション開発は計画、コード作成、テストに 18 か月から 24 か月もかかる 大掛かりなプロジェクトでした。開発後、アプリケーションが本番環境に移行されると、開発チー ムは祝杯を挙げ、次の 24 か月のプロジェクトに取り掛かっていました。 開発チームがボールを打ったまま試合を放棄したら、 DevOps は必ず機能不全 になります。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 20 軌道修正の方法 DevOps を強化すると、テスト環境のアプリケーションをほとんどそのまま 本番環境に移行できます。 大量の新機能を含む大規模リリースの代わりに、新しいモデルでは新機能 を連続してリリースします。スマートフォン・アプリの出現により、アプリ ケーションは頻繁に更新されることになるでしょう。数か月おきに 1 つか 2 つの新機能をアップデートしないと、ユーザに魅力を感じてもらえないの です。 連続したリリースのために、 開発チームは 1 つのバージョンの作業を終 えたらすぐ、次に着手して、ユーザのニーズに応じて新機能を追加します。 その新バージョンのパフォーマンスに関して運用チームからのフィードバッ クを反映できれば理想的です。そうすることで、開発チームと運用チーム が完全に統合され、コラボレーションが実現します。また、運用チームは 開発チームの期待を理解し、開発チームはロールバックやバージョン管理 などの機能を備えた負荷ベースのツールを使用して、コードを本番環境に 適用できます。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 21 注意すべき兆候 : 問題が発生すると 責任追及が始まる 問題が発生すると、それによって責任追及が始まり、全員が争って他 の誰かの責任にしようとしていませんか。 DevOps とはチームとして協力し合うことであり、責任追及はコラボ レーションの作業環境にとって有害そのものです。 責任追及は、深刻な機能不全の兆候です。その習慣を止めない限り、 DevOps を成功させることはできません。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 22 軌道修正の方法 責任追及は学習行動です。 根絶するのはむずかしくても、その影響を低減する方 法はあります。 成功も失敗もチームの努力によるものだということを明確にします。成功するには 複数の人材が必要であり、複数の人材が関与すれば混乱が起こるのは当然です。 開発、テスト、本番のプロセスのすべての局面に共通の目標と目的を設定します。 運用チームが成功しない限り開発チームは成功しないこと（およびその逆）を目標 で明確に示します。開発チームと運用チームの全員がソフトウェア開発ライフサイ クルの開始時から話し合い、 全員がプロセスに「参加」すれば、本番環境に移行 する前の問題の予測と修正が簡略化されます。 誤りは学習の機会と考えます。 誤りの原因、その教訓、異なる方法、対処を必要 とする大きな問題の兆候であるか否かを分析します。誤りといわれるものの多くは、 プロセスに欠陥がある症状です。プロセスを改善して、誤りを排除します。 自動化して、 エラーの可能性を可能な限り排除します。 この 2 つを実現すると、 プロセスの品質が向上し、高価値の活動に人材を集中できるため、組織にとって大 きなメリットになります。すべてを自動化し、分析を基に追跡および調整します。ボー イング社がブラック・ボックスのない飛行機を製造したらどうなるでしょう。自動化 と分析がなければ、墜落した飛行機の原因を再現することはできません。 次の セクション 目次 機能不全のプロセスの 7 つの兆候 23 まとめ : DevOps への出発点 問題を認識することは、意味のある変化のための第一歩です。DevOps が組織にもたらす価値を確認すると、 苦境に陥っていた原因が機能不全のプロセスにあることに気づき、きっと驚くでしょう。 それでは、機能不全から抜け出して、DevOps を正しい軌道に乗せるにはどうすればいいのでしょうか。 当社は多様な組織に DevOps を導入してきましたが、その経験から、すべての組織にとって以下の 5 つが 必要だと確信しています。 • 開発、テスト、運用のすべてのチームを統合するアプリケーション・チームの編成 • 社員教育、コミュニケーション、多様なスキルの向上 • サービス・デリバリ・サイクルの再評価と再構築 • DevOps をサポートする新しい技術の評価 • DevOps の着手に適切なアプリケーションまたは適切なビジネス部門の選択 目次 まとめ 24 これらの順番は重要ではありません。重要なのは始めることです。 DevOps の開始点として、 誰もが注目している重要なアプリケー ションを選択します。 小規模から始めたいところですが、DevOps では、すでに問題を起こしている重要なアプリケーションに取り組 むことで最大の利益が得られます。そうすることで、「異なる方法」 に対する消極的な態度が改善され、DevOps の成功が組織に大きな 影響をもたらします。 最初に大きくて重要な問題に対応できれば、 組織のさまざまな場所でその成功を再現できます。 目次 まとめ 25 大きなメリットをもたらす DevOps の手法の詳細につい ては、CA Technologies の Web サイトをご覧ください。 http://www.ca.com/jp/lpg/devops-portfolio.aspx © 2014 CA. All rights reserved. CS200-86720
© Copyright 2024 ExpyDoc
