ついに誰かがDevOpsをわかりやすく説明してくれた

[[427652]]

この記事はWei XinyuとGuo Yuejunが執筆したWeChatパブリックアカウント「Big Data DT」から転載したものです。この記事を転載する場合は、Big Data DT パブリックアカウントにご連絡ください。

01 ウォーターフォール開発からアジャイル開発へ

DevOps の歴史について話すとき、まずアジャイル開発について話す必要があります。

アジャイル開発はソフトウェア指向であり、ソフトウェアはコンピューティング ハードウェアに依存します。世界初のコンピュータが登場したのは 1946 年であることは周知の事実ですから、ソフトウェア開発は人類の歴史に比べればそれほど長い期間ではありません。ソフトウェア開発と比較すると、人間は建物や橋を建設するなどのエンジニアリングの方が得意です。 1968年、ソフトウェア開発を促進するために、ソフトウェア分野にエンジニアリング手法が応用され、ソフトウェアエンジニアリングが誕生しました。

ソフトウェア エンジニアリングのアプローチには利点がありますが、多くの問題も生じます。重要な点は、ソフトウェアはエンジニアリングとは異なるということです。工学技術によって建設された橋梁や高層ビルは、完成後、通常、橋梁本体や高層ビルの使用要件に大きな変化はありません。しかしソフトウェアは異なります。エンドユーザー向けのソフトウェアの場合、ソフトウェアの機能に対する人々の要求は常に変化しています。

ウォーターフォール開発モデルでは、顧客のニーズが変化すると、ソフトウェアベンダーはソフトウェアを変更する必要があり、企業の競争力が大幅に低下します。

従来のソフトウェア開発プロセスは次のとおりです。

• 製品マネージャーは、最前線のビジネス部門と顧客から要件を収集します。これらの要件は、新しい機能に対する要件である場合もあれば、既存の製品機能に対する変更に対する要件である場合もあります。
• 次に、これらの要件を評価および分析し、製品ロードマップにまとめ、関連する作業を実行するために適切なリソースを割り当てます。
• 次に、プロダクトマネージャーが開発部門に要件を出力し、開発エンジニアがコードを記述します。
• 作成後は、さまざまな部門の担当者がコード構築、品質検査、統合テスト、ユーザー受け入れテストを実施し、最終的に製造部門に引き渡します。

この場合の問題点は、開発サイクルが比較的長く、変更があった場合には開発プロセスを繰り返す必要があることです。戦場のような今日のビジネスの世界では、ソフトウェアのバージョンのリリースが遅れると、リリースされる頃には市場で時代遅れになっている可能性があります。競合他社は、新しいソフトウェアのリリースを一歩早く行うことで、顧客と市場シェアを急速に獲得する可能性があります。

ビジネス環境のプレッシャーがあるからこそ、ソフトウェアベンダーは開発手法を改善する必要があります。

2001 年の初め、17 人の専門家が米国ユタ州のスキーリゾート、スノーバードに集まり、ソフトウェア開発チームがより迅速に作業し、変化に適応できるようにするいくつかの価値をまとめました。彼らは、ソフトウェア業界の歴史において最も重要な文書の 1 つである「アジャイル宣言」を作成し、署名しました。

アジャイル宣言の主な価値は次のとおりです。

• プロセスとドキュメントよりも個人と相互作用を重視します。
• 動作するソフトウェアは包括的なドキュメントよりも重要です。
• 顧客との協力は契約交渉よりも優先されます。
• 変化に対応することは計画に従うことよりも優先されます。

アジャイル宣言とアジャイル開発の価値とともに、対応する開発流派が後に登場しました。主なアジャイル開発の流派としては、エクストリーム プログラミング (XP)、スクラム、クリスタル メソッドなどがあります。この時点で、アジャイル開発には概念、方法、および実践があります。クラウド コンピューティングの概念の台頭とその継続的な実装により、アジャイル開発もツール化されました。

02 アジャイル開発からDevOpsへ

アジャイル開発について話していますが、アジャイル開発と DevOps の関係は何でしょうか?アジャイル開発は開発分野における概念です。これはアジャイル開発段階に基づいており、次の段階があります。

アジャイル開発 → 継続的インテグレーション → 継続的デリバリー → 継続的デプロイメント → DevOps

アジャイル開発から DevOps まで、前の段階は後の段階の基礎となります。段階が進むにつれて、各段階の概念はより多くのプロセスをカバーするようになります。最終的に、DevOps は開発段階と運用段階全体をカバーします。各ステージには異なる範囲が含まれるため、各コンセプトによって提供されるツールも異なります。詳細については、図1〜2を参照してください。

図1-2 アジャイル開発からDevOpsへの進展

• 継続的インテグレーション: コードがトランクに統合される前に、すべてのコードが自動テストに合格する必要があります。 1 つのテスト ケースでも失敗すると、統合できません。継続的インテグレーションの目標は、高品質を維持しながら製品を迅速に反復できるようにすることです。
• 継続的デリバリー: 開発者は、ソフトウェアの新しいバージョンを品質チームまたはユーザーに頻繁に提供し、レビューしてもらいます。レビューに合格すると、コードがリリースされます。審査に合格しなかった場合は、修正して再度提出する必要があります。
• 継続的デプロイメント: コードがレビューされリリースされた後、エンドユーザーに配信するために本番環境に自動的にデプロイされます。

DevOps は、ソフトウェア開発チームと IT チーム間のプロセスを自動化し、ソフトウェアをより迅速かつ確実に構築、テスト、リリースできるようにする包括的な一連のプラクティスです。

03 ロッキード・マーティンにおけるDevOpsのメリット

企業が DevOps を実装する主なメリットは、ソフトウェア配信の速度が大幅に向上することです。ここでは、ロッキード・マーティンの事例を用いて分析します。

ロッキード・マーティン F-22 ラプターは、ステルス性、スピード、機敏性、状況認識力のユニークな組み合わせにより、世界最高の戦闘機の 1 つです。ロッキード・マーティンは、米国空軍と協力して、F-22 ラプター戦闘機に重要な機能をより迅速かつ低コストで提供するための機敏な新しいアプローチを開発しています。 F-22 ラプターは世界で最も先進的な戦闘機の 1 つであり、技術的優位性を維持するには、急速な革新に常に重点を置く必要があります。

従来のウォーターフォール開発プロセスでは、戦闘機に重要な機能を十分迅速に提供することはできません。これまでロッキード・マーティンは、既存のアーキテクチャの要件を特定し、新しい機能を開発するのに 5 ～ 7 年を要していました (F-22 はもともと 1990 年代初頭に製造されました)。この時間のかかるプロセスは、コードの品質と統合の問題と相まって、大幅なやり直しとカスタマイズを招き、ソフトウェア主導のイノベーションに対するロッキード・マーティンの期待に応えられなくなったモデルとなってしまいました。

ロッキード・マーティンにとって、F-22 ラプターを最前線に維持することは、ハードウェアをアップグレードし、最新のソフトウェア プラットフォームを導入するだけでは不十分です。代わりに、創造的でアジャイルな方法論をアプリケーション開発に適用し、イノベーションとコラボレーションに根ざしたチーム文化の構築も目指しています。

これを実現するために、ロッキード マーティンは、アジャイル、MVP (Minimum Viable Product)、DevSecOps (セキュリティが組み込まれた DevOps) など、ソフトウェア用語集で一般的な原則とフレームワークを採用することを検討しました。

ロッキード・マーティンでの 8 週間の Red Hat Open Innovation Lab 研修を通じて、Red Hat はロッキード・マーティンが F-22 ラプター戦闘機のアップグレードのためのウォーターフォール開発プロセスをアジャイル手法と DevSecOps プラクティスに置き換え、米国空軍のニーズに迅速に対応できるよう支援しました。

Lockheed Martin と Red Hat は協力して、Red Hat OpenShift Container Platform に基づくオープン アーキテクチャを構築し、F-22 チームがアプリケーションの開発と配信を加速できるようにしました。

ロッキード・マーティンは、アジャイル変革の取り組みをリードし、F-22 にオープンソース・アーキテクチャを実装するとともに、組み込みシステムのネットワークを整理して、米国空軍のニーズに適応しやすい、よりアジャイルな製品を作成するために、Red Hat Open Innovation Labs を選択しました。 Red Hat Open Innovation Labs は、メンターシップを通じて、Lockheed Martin のチームがアジャイル開発方法論と DevSecOps プラクティスを導入できるよう支援しました。

ディスカバリーセッションとアーキテクチャレビューに続いて、Red Hat は、信頼できるエンタープライズ Kubernetes プラットフォームである Red Hat OpenShift Container Platform に基づいて、Lockheed Martin 向けの環境を構築しました。 OpenShift は開発者のイノベーションに最適化されており、セキュリティ、運用管理、アプリケーションとコンテナの管理統合に関する IT の課題に対処する顧客を支援します。

OpenShift は、業界で最も認知されているオペレーティング システムの 1 つであり、Linux コンテナー テクノロジーをサポートし、Common Criteria 認定サポートを最初に受けたオペレーティング システムである Red Hat Enterprise Linux の信頼できる基盤によって駆動されており、Lockheed Martin とその顧客が設定した高度なセキュリティ標準を満たすのに最適なプラットフォームとなっています。

Red Hat Open Innovation Labs と Lockheed Martin のコラボレーションでは、5 人の開発者、2 人の運用スタッフ、1 人の製品オーナーからなる部門横断的なチームが協力して、OpenShift 上で F-22 向けの新しいアプリケーションを開発し、素晴らしい成果を上げました。その後、ロッキード・マーティンは 6 か月をかけて、OpenShift、アジャイル手法、DevSecOps の成功を 100 名の F-22 開発チームに拡大しました。

ロッキード・マーティンのアジャイル変革は成果を上げた。最近のキックオフ ミーティングで、F-22 ラプター スクラム チームは将来のスプリントを予測する能力を 40% 向上させました。プログラム開始からわずか1年後、ロッキード・マーティンは予定より3年早く、航空機に新たな通信機能を搭載する計画だ。ロッキード・マーティンは、このアプローチを F-22 開発組織全体に拡大し続けています。

Red Hat Open Innovation Labs は、Lockheed Martin と協力して、同社の文化、プロセス、テクノロジーを変革するだけでなく、チームの実際の働き方を見直すよう促しました。ロッキード・マーティン F-22 ラプター開発チームは、障壁を取り除き、オープンな作業環境を構築することで、DevSecOps 文化をさらに一歩進めました。

著者について: Wei Xinyu、Red Hat 副主任ソリューションアーキテクト。彼は IaaS と PaaS に関する豊富な経験を持ち、企業におけるオープンソース ソリューションの推進と応用に尽力しています。プリセールスの観点から、彼は金融業界と自動車業界における Red Hat の複数の PaaS プロジェクトを主導しました。彼は Huawei、IBM、VMware で勤務した経験があります。

Guo Yuejun は現在、VMware でソリューション エンジニアとして働いています。彼は、Red Hat で PaaS コンサルタントとして、また AWS コンサルティング サービス チームでクラウド アーキテクチャ コンサルタントとして勤務しました。彼はプライベート クラウドとパブリック クラウドのエコシステムに精通しています。 2015年にコンテナ技術に触れて以来、PaaS構築の最前線で活動しています。私は数多くの OpenShift プロジェクトの入札、PoC、コンサルティング、実装に参加し、多くの企業のデジタル変革の実現を支援してきました。

この記事は、「OpenShift in Enterprise Practice: PaaS DevOps Microservices」(第 2 版) から抜粋したもので、発行元の許可を得て公開されています。