もしあなたが新会社のIT DevOpsプロセスを設計するとしたら、より正確な予測を行い、アプリケーションを迅速に配信するために何を自動化しますか。
IBMのAutomation Value Servicesソフトウェア担当副社長のChris Farrellは、「多くの企業はアプリケーションのおかげで存在しています。つまり、アプリケーションのパフォーマンスは、収益を除くと最も重要な尺度であることを意味します」と述べています。「アプリケーションがビジネスである企業の場合、スピードは武器であり、アプリケーションの品質を代表して競合相手と競り合っているのです。」
現在のハイパー・デプロイメントの世界では、継続的インテグレーションと継続的デリバリー（CI/CD）の実現について、組織がどのように考えるかについて方向転換が重要だとFarrellは述べています。「デプロイの間隔について話すのではなく、期間ごとの更新数を検討する必要があります」とFarrellは言います。「その期間が短ければ短いほど、競争力が高まります。」
IBMの「Rethink & Automate」シリーズは、リーダー層を対象とし、グリーンフィールドの視点からのアプローチで自動化を取り入れることで、ビジネスとITの共通プロセスを再構築することを目的としています。一般的なDevOpsプロセスは、計画、コーディング、構築、テスト、リリース、デプロイ、運用、監視の8つのステップからなるサイクルです。8つのステップのうち1つでも遅くなると、パイプライン全体のスピードに影響します。
IBM Institute for Business Valueが発表した論文『The speed of smarter architecture』の中で、IBMのHans A.T. Dekkersは、「デジタル・スタートアップ企業は別として、既存の大企業にとってスピードを向上させることがさらに重要になっているようです」と述べています。「S&P 500企業の平均寿命が60年（1960年代）から20年未満（現在）まで下がり、その一方で売上高がさらに上がる傾向が加速しているのを見ると、スピードによる影響が大きいことがわかります。」
無料のオートメーション・イノベーション・ワークショップで、IT DevOpsプロセスを改善する新しい方法を知ることができます。
CI/CDを実現するには、開発者は一度ビルドすればどこにでもデプロイでき、パイプラインを継続的に管理できる必要があります。ここでは、Farrellが自動化により典型的なサイクルを再設計する方法を示します。改善には「DevOpsに真剣に取り組み、継続的デリバリーを達成したいという強い願望」が必要であるとFarrellは指摘しています。
モニタリングからオブザーバビリティーへの移行
「これは意外に思われるかもしれませんが、DevOpsプロセスをゼロから再設計するとしたら、最初に焦点を当てるのは最後のステップである監視になるでしょう」とFarrellは言います。「従来型モニタリング（監視）領域のツールの使用をやめて、できるだけ早くオブザーバビリティー（可観測性）に移行する必要があります。オブザーバビリティーを適用するワークロードが増えるほど、Opsメンバーは開発者や他の対象分野の専門家を関与させることなく、問題からその根本原因まで迅速かつ正確にナビゲートできるようになることに注意してください。」
ITにおける可観測性とは、分散アプリケーションとそれが実行されているハードウェアおよびネットワークから定常的に流れるパフォーマンス・データを集約、相関付け、分析するためのソフトウェア・ツールとプラクティスを指します。これにより、アプリケーションとネットワークのトラブルシューティングとデバッグを効率的に行うことができます。オブザーバビリティーは、より高速、動的に、分散してデプロイできるクラウドネイティブ・アプリケーションにさらに適切に対応するために、アプリケーション・パフォーマンス監視（APM）から自然に進化したものです。
監視以外にも、DevOpsプロセスの各ステップには、プロセスを高速化、統合、自動化する多くのツールがすでに用意されています。「従来の監視ツールは、パイプラインの高速化や最新の技術スタックに適切に対応できず、特に手動でのセットアップ、再構成、再デプロイメントにより処理が遅くなります」とFarrellは言います。オブザーバビリティー・プラットフォームは、コンテキストによる可視性を提供することで理解しやすく、あらゆる変化にリアルタイムで対応するため常に最新の状態に保たれます。
オブザーバビリティーはまた、アプリケーションとインフラストラクチャーを結びつけます。これは、アプリケーション・コード、コードベース・インフラストラクチャー、ハードウェア・スタックの間の境界線が曖昧になる中で必要なことです。「パイプライン全体のスピードの必要性を考えると、プラットフォームはアプリケーション・コード自体と同じくらい柔軟で高速化できなければなりません」とFarrellは言います。
オブザーバビリティーを自動化してスピードと結果の向上を実現
「オブザーバビリティーに移行する必要は絶対にありますが、それは自動化されたものである必要があります」とFarrellは言います。分析エンジンを備え、自動化されたオブザーバビリティー・プラットフォームでは、プラットフォーム自体が問題を理解し、問題の内容、推奨事項、修復事項を提供できるようになります。問題の診断に時間を費やす必要はもうありません。それは自動的に行われます。
IT DevOpsプロセス全体の自動化は、スピード以外にも多くのメリットをもたらします。継続的なフィードバックは、開発者が継続的な改善に向けて迅速かつ断固とした行動を取れることを意味します。エラー検出の改善により、開発者は、Farrellが「壊滅的」と表現するようなエラーが発生する前に修正できるようになります。そして最後に、システム統合によりチームのコラボレーションが向上し、チーム内のすべてのITおよびDevOpsの専門家が、同僚の作業を遅らせることなくコードを変更し、フィードバックに対応し、問題を修正できるようになります。
「ソフトウェア配信スピード」とも呼ばれ、開発と更新（および組織がDevOpsプロセスの改善で重点を置くべきもの）のスピードを表す用語
ソフトウェア（またはアップデート）が資金を生み出し始めるまでにかかる時間
ビジネス（およびそれに関連するアプリケーション）がビジネス環境の変化にどれだけ効果的に対応できるか
DORA 2018レポート『Accelerate: State of DevOps』（ibm.com外部へのリンク）によると、「エリート・パフォーマー」組織では、コードのデプロイ頻度が46倍、コミットからデプロイまでのリードタイムが2,555倍速く、変更失敗率が7倍低く、インシデントからの復旧時間が2,604倍速い結果となっています。デプロイ頻度を増やすと、新しいソフトウェアのリリースが加速され、インシデントの解決が何千倍も速くなり、そのメリットが飛躍的に大きくなることがわかります。「ここで注目したい相関関係は、デプロイまでのスピードの高速化にもかかわらず、変更の失敗率が低くなっていることです」とFarrellは言います。
組織がプロセスの8つのステップすべてを自動化すると、より高い品質と顧客満足度の向上が期待できます。しかし、Farrellは、最大のメリットはスピードだと言います。「私が経験した、ある銀行の例をご紹介します。この組織では、商品の考案から本番環境での稼働まで10カ月から12カ月かかっていましたが、新しいDevOpsプロセスを導入すると、その期間は2週間になりました」とFarrellは言います。「市場での成功という、絶対的で直接的な結果が得られるのです。」
アプリケーションのパフォーマンス監視を強化しましょう。