DevOpsはデリバリーで終わらない

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

デプロイの遅れによってリリースが遅延するのであれば、どれほど迅速に提供できても意味がありません。NetOpsでは自動化とオーケストレーションの導入が進みつつありますが、デプロイの迅速化には大きな課題が立ちはだかっています。その取り組みを支援するうえで、DevOpsは最適な立場にあります。

デジタルトランスフォーメーションにはDevOpsが不可欠

デジタルトランスフォーメーションとDevOpsの間に関連性があることは明らかです。DXを背景に、48%の組織がアプリをより頻繁に本番環境へ移行しようとしています。また、62%がITシステムとプロセスの自動化およびオーケストレーションを進め、52%がアプリの開発方法（アジャイルなど）を変革し、42%がコンテナとマイクロサービスを検討しています。アプリケーションの基礎となる構成要素から市場投入の手法に至るまで、デジタルトランスフォーメーションによって、DevOpsは「継続的デリバリー」を「継続的デプロイメント」へと拡張できるようになります。ここで「デリバリー」とは市場投入ではなく、本番環境への移行を意味します。本番環境ではデプロイプロセスが開始され、アプリケーションが利用可能な状態になります。

なぜなら、「利用可能」とは、単に「アプリが問題なく動作している」という意味ではないからです。アプリケーションサービスとして実装し、デプロイする必要がある一連の要件も含まれます。スケーラビリティ、セキュリティ、パフォーマンス、監視のすべてが整って初めて、アプリケーションは「利用可能」と見なされます。これらが、今日の「デプロイパイプライン」を構成しています。

自動化とオーケストレーションの可能性を実現するには、デプロイメントにDevOpsが必要

残念ながら、デリバリーとデプロイにおける自動化の現状は、ジョージ・ジェットソンとフレッド・フリントストーンのスキー旅行に例えると、あまりにも的確に表現できます。未来から来たジョージはジェット推進式のスキーに乗る一方、過去の世界に暮らすフレッドは人力式のスキーで何とか滑っています。ロケット推進式のスキーに乗るジョージ・ジェットソンが、継続的デリバリーを実践するDevOpsだと考えたなら、そのとおりです。そして、NetOpsがほぼ手作業で継続的デプロイを実現しようとしていると考えたなら、それも正解です。

NetOpsは、現在、組織で平均14種類利用されているアプリケーションサービスのプロビジョニング、デプロイ、運用を担っています。これには、スケーラビリティ（負荷分散やイングレス制御）からセキュリティ（Webアプリケーションファイアウォールやボット対策）、さらにはアプリケーションを支えるスタック全体のパフォーマンスを向上させる、あまり知られていないサービスまで、あらゆるものが含まれます。

現在、NetOpsにもより速く進むためのスキーはありますが、DevOpsのようなロケット付きスキーはまだありません。

パイプライン自動化の格差が、もどかしい遅延を招く

「継続的デプロイ」の実現に必要な各種アプリケーションサービスコンポーネントの自動化率にはばらつきがあります。大半の組織が依然として手作業に頼る原因となっている、この「不均衡な力」を取り除く必要があります。特に、デプロイ関連のコンポーネントを1つも自動化していない組織では、この課題が顕著です。これは、ロケット推進式のスキーと従来型のスキーほどの違いです。パイプラインの一部を自動化できた組織でも、一貫した自動化には至っていません。4つの主要コンポーネントをすべて自動化している組織は、わずか21%です。自動化できた領域が1つだけの組織は11%、2つの組織は25%です。

飛行中に突然、スキーに付いていたロケットがなくなる状況を想像してみてください。

デプロイを迅速化するために、従来のように「人員を増やして問題に対処する」方法に頼ることは、もはやできません。人員を増やしても、プロダクション環境へのデリバリーから消費者への提供に至るまでの間に、コミュニケーションの階層やプロセス上の障害が増え、遅延がさらに深刻になるだけです。

こうした遅延は、ビジネス部門を待たせるため不満を招きます。さらに悪いことに、遅れを取り戻そうとして、セキュリティなどの手順が省略されることも少なくありません。この問題を解決するには、継続的デプロイを遅らせている「不均衡な力」を特定し、対処する必要があります。

この「不均衡な力」とは何か、DevOpsでどうバランスを取り戻せるのか？

デプロイのバランスを崩す要因は、NetOpsが挙げる課題に表れています。スキル、ポリシー、予算、統合は、継続的デプロイの実現を大きく阻む要因です。誤解のないように言えば、NetOpsはスクリプトを作成でき、実際に日常的に作成しています。しかし、スクリプティングは自動化ではなく、最大14種類に及ぶ可能性のあるデバイス、システム、サービスを横断して統合するというニーズには対応できません。NetOpsには、こうした異種システム間の統合を可能にするだけでなく、一貫性、予測可能性、再現性のある方法でデプロイプロセスを推進するツールと手法を特定し、実践するための支援が必要です。

ここでDevOpsが、NetOpsによる継続的デプロイの実践を成功に導くために役立ちます。

ITと開発の垣根を越えた連携が不可欠

文化は不可欠です。行動や実践に現実的な影響を及ぼします。チーム構造だけでもパイプラインの自動化は大きく変わり、従来型の単一機能チームは、DevOpsを推進する現代的なチームに後れを取っています。より協力的なチーム構造を目指してください。同様に、協力的なチームでは主要な指標について認識を合わせる必要があります。指標を共有することで、NetOpsとセキュリティ部門は不利益を被ることなく継続的デプロイに取り組めます。現在、NetOpsの約4分の3は「ネットワーク稼働時間」で評価されています。デプロイ頻度は、評価指標としてほとんど重視されていません。ネットワークの稼働維持こそが注力すべき対象であるため、そこに集中することになります。指標を共有すれば、NetOpsはビジネスが求める、より迅速で頻繁なデプロイに注力できるようになります。

最後に、相互理解が欠かせません。全員が同じチームの一員であり、意外に思われるかもしれませんが、重視していることも同じです。NetOpsもDevOpsと同様に、パイプラインの自動化を非常に重視しています。DevOpsは、統合、ツール、スキルセットに関する障壁への対処と克服において、NetOpsより10年先行していることを忘れてはなりません。協働型チームは、デリバリーからデプロイまでをカバーするツール（JenkinsやGitHub/GitLabなど）の標準化を推進することで、こうした取り組みを支援できます。

ランチ勉強会を開催しましょう。NetOpsの担当者にメンター役を申し出て、実務のコツを学ぶ機会となる知見や、チュートリアルおよびコミュニティへのリンクを共有します。また、「Automation Center of Excellence」やコミュニティを立ち上げ、ベストプラクティスの確立、ソリューションの共有、そしてこうした「不均衡を生む要因」への対処に役立つ知識共有を促進しましょう。

DevOpsはデリバリーで終わるべきではなく、終わることもできません。アプリケーションは、対象ユーザーの手に届くまで、本当の意味で「完成」したとは言えません。そこに至るまでの時間を短縮するには、デプロイと、それに伴う複雑なデバイスおよびアプリケーションサービスのパイプラインを自動化する必要があります。DevOpsには、NetOpsのスキーにロケットを取り付け、ビジネスが求めるスピードでNetOpsも前進できるよう支援するためのスキル、ツール、経験があります。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事