ポイント: 2022年のDevOpsの状態レポートは、DevOpsの進化に焦点を当て、自動化、クラウド採用、文化的変革を強調しています。組織は、文化的抵抗や技術的障壁といった課題に直面しながら、成功するDevOpsプラクティスを追求しています。
- 自動化は効率とサービスの質を向上させます。
- 変化に対する文化的抵抗は一般的な障壁です。
この記事では、Puppet、BMC、DevOps Institute、Google Cloudからの最新のDevOpsレポートの概要を紹介します。それから、成功した組織がDevOpsを採用するために取るべきステップを読み進めてください。興味のある部分にジャンプしてください:
Puppetの2021年DevOpsの状態
毎年、PuppetはDevOpsの状態について報告し、最近BMCやその他の業界リーダーがスポンサーとなった10回目の版をリリースしました。この10年間で、レポートは35,000人以上の技術専門家に調査を行い、年間結果は大きな影響力を持っています。
DevOps Institute
2021年のレポートでは、Puppetは世界中から2,657件の回答を受け取り、その大多数は1,000〜10,000人の従業員に分類され、40％が技術分野に属しています。
このレポートは、前回のものからわずか1年以内に発行され、DevOpsの歴史的進化を見つめ直し、成功に向けた自動化、クラウド、人と文化の重要性を強調しています。Puppetは、DevOpsが次のような段階に進化したと述べています:
“DevOpsをうまく行っているチームの多くは、もはやDevOpsについて話すこともなく、それが彼らの働き方の一部となっています。”
それでも、まだその旅の半ばで立ち往生している組織にとっては、技術や人々をより良く把握することが前進するための鍵となります。
Puppetは、その中間グループ全体で、ブロッカーや課題が、低レベルでは技術的、文化的、組織的なミックスから、ほぼ完全に文化的（組織の同意、リスク回避、不完全なフィードバックループ、最適でないチーム定義など）に変化することを発見しています。
また、レポートはDevOpsの歴史を調べ、DevOpsが何であるか、何でないかの大局を見つめ直します。
- DevOpsは自動化だけではありません。高度に進化した企業は、広範囲にわたる自動化を実装している可能性が高いですが、自動化が得意なことがDevOpsが得意であることを意味しません。調査対象の62％の組織は、高度な自動化があっても、DevOpsの旅の中間段階に留まっていると報告しています。
- ほとんどの人がクラウドを使用していますが、多くの人がそれをうまく使用できていません。組織は、クラウドや自動化を使用するだけで高度に進化するとは期待すべきではありません。進化の中間段階にある組織の65％が公共クラウドを使用していると報告していますが、そのうちの20％だけがクラウドを最大限に活用しています。
- チームのアイデンティティと明確な相互作用のパラダイムが重要です。企業は組織の構造とダイナミクスによって最高レベルへ進化することが妨げられています。「DevOpsが得意な」組織は、強力でよく理解されたアイデンティティを持つチーム、明確な責任と高い自律性を持ち、他のチームとの間で明確なコミュニケーションチャネルを持っています。
その他の重要な発見には次のようなものがあります:
- 文化的ブロッカー、例えば変化に対する組織の抵抗、レガシーアーキテクチャ、スキル不足、自動化の限界、目的や目標が不明瞭であることなどは、依然として中進化企業に存在しますが、低進化組織に対しては特に深刻です。
- “DevOpsチーム”の存在は業界にとって混乱を引き起こし、多くの組織にとって、ほとんどの場合、組織の進化を助けることはありません。Puppetは、チーム名があまりあいまいでなく、明確に定義された責任がある組織が、IT機能のパフォーマンスが高くなる可能性が高いことを発見しています。
- 良好なセキュリティ慣行とより良いセキュリティ結果はDevOps慣行によって可能になります。DevOps慣行が改善されると、DevSecOpsは自然に続いてきます。
- プラットフォームチームは、既存の自動化を活用することでDevOps変革を加速できます。また、PuppetのDevOpsモデルにおいて最も高度に進化した組織は、開発者向けのセルフサービスを可能にし、開発者体験をキュレートするプラットフォームモデルを採用しています。
- 古い（レガシー）ITインフラストラクチャやアプリケーションのモダナイゼーションには、分析、わかりやすいカテゴリへの分類、明示的な目標設定とアクションプランが必要です。
PuppetとBMCによるDevOpsウェビナー
「DevOpsをうまく行っているチームの多くは、もはやDevOpsについて話すこともなく、それが彼らの働き方の一部となっています」とPuppetは発見しましたが、他の組織は半ばで立ち往生しています。
続編ウェビナー「DevOpsの状態: 中途半端に立ち往生」において、BMC製品マネージャージョン・スティーブンス・ホールがPuppetのCTOナイジェル・カーステンとともにレポートについて話し、組織が前進するためには技術と人をより良く理解する必要があることを強調しました。彼らの会話からの重要なポイントは次のとおりです:
- サイズがDevOpsの成功に与える影響
- あなたの組織にとってのレガシーの定義
- デプロイ頻度を正しく設定する
- 管理の重要な役割
DevOpsにおけるサイズの重要性
まず、彼らはDevOpsにおいてサイズがいかに重要であるかについて話しました。
“大企業のDevOpsは小さな会社やスタートアップのDevOpsとは非常に異なり、それがDevOpsの状態レポートの大きなテーマのようです。”
“私が2015年に会議で会っていた人々は小さな会社であり、最も大きくて著名な会社はSpotifyでした。彼らはチーム編成やその他の面で非常に大きな先駆者でした。たった4年後、銀行や通信会社が登場しました。彼らはアジャイル開発を行ったと感じていましたが、運用側は本当にアジャイルとして進化していませんでした。
“私にとって最も興味深いことは、[彼らが言ったように]レガシーは一夜にして消えるものではないということです。 [銀行が言ったように]多くのトランザクションは最新技術を含むかもしれませんが、多くのレガシー製品も含まれており、何年も変更されない可能性があります。彼らには新しい作業慣行や新しい技術が必要であり、DevOpsがこのガバナンスと複雑さの中で成長するのを許可するための課題があります。
レガシーは変数の用語
カーステンは、“レガシー”もまた変数の用語であると付け加えます。 “顧客がレガシー環境について話し始めるとき、それは必ずしも同じではありません。実際に彼らが持っている古いものすべてではありません。しばしば、非常にDevOpsの考え方を持って運営されている小さなチームによって非常によく運営されている古いメインフレームシステムがあるのです。
“レガシーはしばしば、90年代や2000年代に自己流で構築された半端なアプリケーションを指します。規律があまりなかったのです。皆がこれを進めながら理解していました。私は、メインフレーム上の多くのものよりも、 monetization がはるかに難しいアプリケーションの世代全体があると思います。そして、レガシーの中にはさまざまな問題のカテゴリがあります。
(アプリケーションとソフトウェアのモダナイゼーションに成功する方法を学ぶ。)
デプロイ頻度を正しく設定する
レポートの分類方法に対処する中で、カーステンは次のように説明しました。「低、中、高の進化的グループのアイデアを導入しました。デプロイ頻度は低レベルで月次から3ヶ月毎、6ヶ月でデプロイが完了するまでに実現され、中間は日次から週次、高いグループはオンデマンドです。」
“デプロイ頻度は、あまりにも重視されると虚栄の指標になり得ますが、月次から数日ごとに移行することはビジネスにとって本当に大きな飛躍です。
"[調査のデータを見てみると]、ほとんどの組織には低から中に移行するための比較的取り組みやすい課題があります。そして、中から高に移行するための比較的具体的なタスクがあります。低いグループは小さくなり、高いグループは大きくなっていますが、まだ中間エリアから脱出できない人々が約80パーセントいます。だからこそ、今年はそこに本当に焦点を当てたかったのです。
“[これらの課題は]技術的な問題ではなく、[大企業における制約は]人々の相互作用やチームの相互作用、コミュニケーション、すべての社会技術システムです。そして、人々の側に変更を加えると、技術に影響を与え、その逆も同様で、これが多くの人々にとって進展を妨げています。
スティーブンス・ホールは、多くの組織が直面している現在の複雑さがその課題を増大させると指摘しています：
“[中途半端な状態から人々を引き出すために]、企業の技術部門は、そのツールチェーンの所有者と連携することを保証できます。[我々は]このサービス管理システムに持ち込むこともでき、サービス組織の人々がDevOpsチームの人々と協力して情報を共有し、知識を創造できるようにすることができます。
管理も関与する必要があります
カーステンは、管理者へのアドバイスもあります。「運用の観点から、管理にいる場合、最も重要なのは、チームに明確な目的とアイデンティティがあることを確認し、彼らの間の相互作用を明確に定義することです」と彼は説明します。
“機能の境界を越えて協力することがすべてです。しかし、実際には、協力は大規模に運営するには非常に時間を要し非効率的な方法です。もしあなたが比較的小さなサービス管理チームや運用チームで、何百人もの開発者と一緒にいる場合、すべての人と協力することはできません。
“進化した組織は、実践を共有し、実践のための空間を作るものです。優れた進展を妨げるのは、中心的な優位性と呼ばれることです。
カーステンは、実行可能なヒントをいくつか推奨しています：
- "それをコミュニティ・オブ・プラクティスのような別の何かと呼ぶこと。少し階層的で自律的で権威的でないもの。
- 人々が聞いたり学んだり、共有することができる空間を作る。人々は本当に賢く、一般的に非常に関与しています。
- そして、解決策を見つけるスペースを提供すれば、彼らはそれを実施します。
次に、DevOps Institute Upskillingレポートを見てみましょう。DevOps Instituteは、DevOps人材が持つべき必要なスキルを調査する研究を、2年連続で実施しました。このレポートでは、世界中の1,260人以上の個人に調査を行い、DevOpsとデジタル変革において重要とされるスキルを特定しました。
主な発見には次のようなものがあります:
- 今日主に使用されているDevOpsトポロジーは大きな課題です。
- DevOps変革の旅は、50％以上の企業にとって依然として非常に困難です。
- アジャイル、DevOps、ITILは、SREから強力な競争を受けています。
- DevOps人材はハイブリッドな職業と役割です。
2021年Accelerate DevOpsの状態レポート
最後に、Google CloudのDevOps Research and Assessmentチーム（DORA）からの2021年のAccelerate DevOpsの状態レポートがあります。この調査は7年間にわたって実施され、世界中から32,000人以上の技術専門家が参加しました。
歴史的に、彼らの研究はDevOpsチームがどれだけ効果的に機能しているかを測るための4つの主要なソフトウェア配信メトリクスを調査しています。しかし、今年の研究では、DevOpsチームが成功を計測するための新たな5つ目のメトリクスが浮かび上がりました:
- デプロイ頻度
- 変更のリードタイム
- サービスの復旧時間
- 変更失敗率
- （新）可用性から信頼性へ
配信メトリクスのほかにも、レポートには多くの新しいDevOpsトレンドが見られ、以下はそのいくつかのハイライトです:
- 健全なチーム文化は、困難な時期の燃え尽き症候群を軽減します（私たちが最近経験したように）。
- 最高のパフォーマーは引き続き基準を引き上げています。
- SREとDevOpsは互いに補完し合います。
- クラウドの採用がパフォーマンスを向上させます。
- ソフトウェアサプライチェーンを確保することは不可欠であり、パフォーマンスを向上させます。
- 良好な内部文書はDevOpsを成功裏に実施するための跳躍台です。
成功するDevOpsの採用に向けたステップ
これらの業界研究からの洞察を踏まえ、DevOpsのための正しい基盤を築くことに目を向けましょう。年々、組織はこれらのステップをDevOpsの採用の基盤として使用しています。
前段階: 基盤を築く
DevOpsの変革が真にDevOpsをサポートできる基盤から始まるのは、運命的です。この前段階の開発では、会社の役員やその他の利害関係者が:
- より良いコミュニケーションとコラボレーションの必要性を認識します。
- ギャップを埋めるためにさまざまな技術を実装するための迅速な承認を開始します。
このプロセスは急速に始まるかもしれませんが、迅速に達成できるものではありません。時間が経つにつれて、企業はアプローチを微調整し、目標を達成するために技術をカスタマイズし始めます。最終的に、組織全体でDevOpsを促進できるプラットフォームが生まれます。この段階に達した組織は、アイデア、技術、知識、メトリクスを共有します。
この段階の指標は？企業は...
- 大規模なソフトウェア購入を行っている
- 新しい慣行を迅速に実施している
ステップ1: テクノロジースタックを正常化
DevOps進化の最初の正式なステップでは、企業はテクノロジースタックを正常化し始めます。チームが自然にアジャイルプラクティスを選択し、新しい手法を検討し始めると、このステップをプロセスで特定できるようになります。
このステップの重要なテクマーカーはバージョン管理です。チームはそれを実装し、継続的インテグレーションの初期段階と見なされる他の慣行を実施します。テクノロジースタックの正常化は、インフラストラクチャの冗長性を減らすことや、アプリケーションのリファクタリングの形で現れることもあります。この冗長性を減らす必要性は、プロセスの次の部分で前面に出てきますが、フェーズ1で始まります。
ステップ2: 標準化
冗長性を排除することが重要視される中で、チームはテクノロジースタックのバリエーションを減少させ、標準化を目指した慣行を実施します。この段階でDevOpsチームは、OSの数を制限することで統合を図ります。
ここでは、独立して統合を進めるチームが協力できる機会があります。全体の目標は、協力や開発の取り組みを促進するために連携して機能する技術の標準ファミリーを持つことです。
このフェーズの結果は、全体的な複雑さの低下をもたらし、チームが複数のアプリケーションで仕事をする機会を増やし、専門知識を最大限に活用できるようになります。このフェーズの利点は次の通りです:
- アプリケーションのデプロイの迅速化
- エラーの削減
- サービス品質の向上
これらの理由から、標準化はDevOpsの状態において重要な要素です。
ステップ3: DevOpsの慣行を試す
前のフェーズでは、標準化が行われている間にチームはプラットフォーム技術の内部動作を探求しています。また、彼らはシステムを本当に理解し始めています。DevOpsの慣行の段階では、チームは単にシステムを探るだけでなく、それを利用するための推奨を行うことができるようになります。
これは痛点を評価する良い時期です。通常、この深掘りアプローチは、組織におけるデプロイメントフェーズでの苦労を認める必要があります。デプロイメントは、DevOpsのベストプラクティスが確立されていない多くの組織にとって難しい場合があります。
一般的な問題は、進化の前のステップで行われた改善により、開発者がデプロイメントのプロセスがサポートできるよりも早くデプロイメントに向かうことです。これにより、運用がボトルネックになります。デプロイメントで追加のDevOps慣行を実施して迅速に対処することが重要です。これには、同じデプロイメントパターンを繰り返し再利用し、この段階に達する前にデプロイメントをテストすることが含まれます。
ステップ4: インフラストラクチャを自動化
重要な結果が特定されると、自動化はチームがさらに成功するのを助けます。
最も重要な項目は、プロビジョニングやシステム構成が含まれます。チームがインフラストラクチャの配信を自動化すると、開発者のスループットがデプロイメントを上回る際に発生する問題を解決します。これがDevOpsの慣行の後の重要な次のステップです。さらに、自動化された構成は、チームがソフトウェアをより迅速にデプロイするのを助けます。
自動化はセルフサービスへの重要な前提条件です。これはDevOpsプロセスの最終段階の触媒です。これはセルフサービスを刺激し、組織全体での効率を高めます。
ステップ5: セルフサービス
セルフサービスの段階では、ITの慣行が組織全体で行われ、1つのコストセンターに限定されない場合があります。これにより、組織内でセルフサービスをスムーズにする進展が可能になります。
この最終段階でのコラボレーションは、前のステップでの利点を増幅します。最も重要な進展は、アプリケーションの自動化が標準化を超えて進化し、クラウド移行やその他の上級プロセスを含むときに実現されます。セキュリティも単にチームの即時のニーズを満たすことから、組織全体のコンプライアンスの基準を作成することに進化します。
DevOpsを理解する
「DevOpsの状態」に関する研究を追跡することは、IT組織が自らのベンチマークを設定し、他者のフィードバックに基づいて改善の機会を探るのに役立ちます。2022年のDevOps（およびSRE）の見通しは明るく、アプリケーション配信とリリースの自動化が成功する組織にとってますます重要になっています。
関連情報
これらの投稿は私自身のものであり、必ずしもBMCの立場、戦略、または意見を表すものではありません。