F5 DevOps および NetOps 調査レポート: 自動化はデジタル格差を埋める鍵
DevOps と NetOps の間の典型的な関係については多くのことが語られています。 私たちは、一方を他方と対立させ、両者を隔てる壁の向こうに申し立てや非難を投げつける「私たち対彼ら」というレトリックの連続に絶えずさらされている。 アプリをより速く、より頻繁に提供しなければならないというプレッシャーが高まるにつれ、この壁はアプリ経済の勝者とそれ以外の人々を隔てるデジタル格差になる可能性があります。
幸いなことに、このデジタル格差は IT の自動化とオーケストレーションのおかげで縮小しています。 私たちは、各グループを個別に調査し、テクノロジの使用状況、互いの認識、提供しているアプリケーションを詳しく調べたところ、NetOps と DevOps の両方がこのデジタルの溝を埋めるために協力したいという願望を持っていることがわかりました。 これは、自動化とオーケストレーションによってのみ効果的に達成できる規模とスピードを必要とするデジタル変革の取り組みに着手している企業にとって、ますます朗報となっています。 これは、すでに手一杯のスタッフからさらに注意を払う必要があるマルチクラウド環境に苦労している組織にとっても朗報です。 自動化によってオンプレミスの負担を軽減すると、クラウド関連のプロジェクトに取り組むためのリソースを解放できます。
2017 年夏に実施されたオンライン調査には、884 人の NetOps および DevOps の専門家が回答しました。 私たちは、アプリケーション全般と NetOps または DevOps におけるそれらの対応物に関する認識関連の質問をいくつか行い、さらに、展開の頻度と成功率の認識に焦点を当てた質問も行いました。
調査結果によると、両者の間には依然として壁が存在しているものの、コミュニティ内の対話や他の業界レポートが主張するほど高くも不透明でもないことがわかった。 生産パイプラインの自動化の重要性と要望に関して、あらゆる規模と業種の組織で多くの共通点が見つかりました。また、両グループが開発および展開に取り組んでいるアプリケーションのセキュリティ、パフォーマンス、信頼性に対する共通の信頼も見つかりました。
自動化は NetOps と DevOps を統合する力となるようです。 少なくとも原則的には、具体的な実装の詳細ではそうではありません。
DevOps と NetOps は、セルフサービスと自動化を通じてどの程度のパイプライン アクセスが可能になるかに関して意見が一致していませんが、大部分では、どちらのグループも相手が正しい方向に進んでいると考えています。 DevOps の 82% と NetOps の 76% は、お互いが「正しいこと」を優先していることに同意しています。 明らかに、組織図に必ずしも共通点があるわけではないとしても、少なくとも目標と焦点においては、デジタル格差を越えて共通点がある。
NetOps 側の反対者の間で、DevOps が十分に優先していないことに対する最も一般的な回答は、セキュリティでした。 信頼性は、NetOps 担当者にとって DevOps に対する不満の原因としても頻繁に取り上げられました。
信頼性とセキュリティは、配信のスピードと同じくらい重要です。 セキュリティは依然として後付けです。 パフォーマンス、セキュリティ、信頼性。
当然のことながら、NetOps による優先順位付けに関して DevOps から最もよく聞かれる意見の 1 つは、自動化に重点が置かれていました。 あるいはむしろ、その欠如。
自動化、自動化、自動化。 クラウド空間において、自動化され、クラウドに依存しないリソース作成を優先してほしいと思います。 自動化、DevOps、クラウド、セキュリティ。
この意見の相違は、おそらく次の重要な調査結果の根底にあると思われます。この調査結果では、開発者と DevOps が自動化とセルフサービスを通じて本番パイプラインにアクセスできないことが、クラウドや IT 以外のソリューションの採用にどのような影響を与えるかが明らかになりました。
自動化がクラウド導入に影響を与える
彼らはあなたの声を聞くことができます。 ビジネスと DevOps の利害関係者の両方によるクラウド導入の推進要因の 1 つは、本番環境のデプロイメント パイプラインへのセルフサービス アクセスが不足しており、その結果、デプロイメント サイクルが長くなることであると長い間考えられてきました。 あまり良いニュースではありませんが、私たちの調査ではこの考えが裏付けられており、DevOps の 27% がクラウドベースのソリューションを選択する決定にこれが「大きく」影響していると回答し、38% が「ある程度」影響していると回答しています。 幸いなことに、NetOps はこの影響に気づいていません。 NetOps の 65% 以上が、本番パイプラインを自動化し、セルフサービス アクセスを提供したいという要望は、DevOps によるクラウド採用の決定によって「ある程度」または「大きく」影響を受けていると述べています。
主な調査結果
- 自動化に対する強力なサポート。 配信および展開パイプラインの自動化の重要性については確固たる合意が得られており、5 段階評価で平均重要度評価は DevOps が 4.0、NetOps が 3.5 となっています。 全体的に、回答者は、生産パイプラインが 50% 以上自動化されている場合、アプリケーションの信頼性、パフォーマンス、セキュリティに対する信頼が高まると報告しました。 両グループとも、相手が「正しいことを優先している」ということに圧倒的多数が同意した。
- 自動化はクラウドの導入に影響を与え、逆もまた同様です。 その合意にもかかわらず、2 つのグループ間の意見の相違は現実であり、結果をもたらします。 その 1 つは、プロダクション パイプライン アクセスに関するさまざまな見解であり、これがマルチクラウドの台頭に寄与していると考えられます。 DevOps 側では、回答者の 65% が、本番パイプラインへのアクセスの欠如が、クラウドや外部ソリューションを求める決定に影響を与えていると回答しました。 逆に、NetOps のほぼ大多数 (44%) は、DevOps のクラウドへの移行の決定がパイプライン アクセスを提供したいという要望に「ある程度」影響していると答え、さらに 21% が「大きな」影響があると認めています。
- パイプラインアクセスをめぐる不協和音。 内部の効率性と外部との関わりを向上させるアプリケーションの提供に重点を置いたデジタル変革の取り組みでは、開発と生産の間の隔たりを越える必要があります。 両者の間には依然として壁があり、開発者と DevOps にどの程度のプロダクション パイプライン アクセスを提供すべきかについてはさまざまな意見があります。 DevOps の回答者の大多数は、生産パイプラインの 75% 以上がセルフサービスと自動化によって利用可能になるべきだと考えています。 NetOps はそれほど寛大ではありませんが、一般的な認識ほど大きな差はありません。
- 現在の展開頻度は問題ありません。 DevOps と NetOps はどちらも、現在のデプロイメントの頻度は「十分」であることに異論なく同意しました。 2つのグループ間の断絶に関する現在の認識を踏まえると、 NetOps では、DevOps に比べて、デプロイメント頻度が「頻繁すぎる」と判断する可能性が 2 倍高くなります。 DevOps 側では、リリースが「頻繁すぎる」ということがあると考えている人はわずか (4%) でした。
自動化の強力なサポート
責任の押し付け合いは終わった。 インシデント発生後に NetOps と DevOps が果てしなく非難合戦を繰り広げるというよくあるストーリーとは対照的に、各グループが互いをはるかに肯定的に見ているという証拠が見つかりました。
パイプラインへのアクセス不足に不満を抱く人々がクラウドに手を伸ばしたことが、マルチクラウドの台頭とそれに伴うセキュリティやパフォーマンスの課題に大きく貢献しており、その結果生じる「不正な IT」に悩む人々がよく指摘しています。 NetOps は、プライベート クラウドまたはクラウドのようなシステムを使用して自動化/セルフサービスによるアクセスを提供する取り組みを継続していますが、オフプレミス クラウド ソリューションへの既存の投資は依然として大きく、無視できないものとなっています。 これにより、組織は複数のクラウド ソリューションと環境を管理、監視、保護する必要があり、デジタル経済における運用の複雑さが増します。
ここでの疑問は、「本番パイプラインへのセルフサービス アクセスを提供するか」ではなく、「どの程度公開するか」です。
パイプラインアクセスをめぐる不協和音
どれくらいあれば十分でしょうか? 自動化/セルフサービス機能を通じて開発者と DevOps に適切な量のパイプライン アクセスを提供することで、意見に顕著な違いが生まれました。 DevOps は、NetOps が提供できる以上の本番パイプラインへのアクセスを間違いなく望んでいます。
NetOps が DevOps にパイプライン アクセスを拡大することに消極的である理由については尋ねませんでしたが、その答えは、それを可能にするスキルの中に見つかるかもしれません。 NetOps の回答者は一般的に、業務を遂行するために必要なスキルと現在持っているトレーニングや知識の間にギャップがあると考えています。
実際、自分自身を「開発者」と認識している NetOps と DevOps の両方が、同様の責任とスキル セットを考えると、5 年後も自分の仕事が重要になると考える傾向が強かったです。 最も自信がなかったのは、壁の両側でネットワーク オペレーターであると自認する人々でした。
NetOps 側での生産パイプライン自動化の現状は、そのスキルギャップの影響を反映しているようです。 DevOps 配信パイプラインに比べて大幅に遅れていることがわかったのは驚くことではありませんでした。 NetOps の 11% が本番パイプラインの自動化を行っていないことを認めている一方で、DevOps ではアプリケーション配信パイプラインについて同じことを述べているのはわずか 5% でした。
パイプライン自動化と成功したデプロイメントの頻度の間には正の相関関係があることが判明したため、パイプライン自動化の状態に注目することが重要です。 パイプライン自動化の割合が高い (75% 以上) NetOps の 86% は、非常に成功した (90% 以上) 展開の頻度も高いと報告しました。
しかし、それが唯一の要因というわけではなく、アプリケーションの変更頻度もデプロイメントの成功頻度に影響を与えるようです。
現在の展開頻度は問題ありません
大丈夫ですよ、ありがとう。 おそらく、最大の文化的隔たりは、依然として配備頻度の領域内に存在する。 DevOps の一部では、猛スピードでアプリを本番環境に配信していますが (12% では 1 日に 1 回以上本番環境に変更を配信しています)、NetOps では、よりゆっくりとした、しかし安定したペースで変更を展開する方がはるかに快適であるようです。
全体的に、回答者の大多数は、月次および週次頻度に関してある程度の合意があるようです。 当然のことながら、DevOps は NetOps よりも頻繁に配信することを好みます。 つまり、より頻繁に配信したいと考えている DevOps の 26% のうち、28% は週に 1 回配信しており、26% はすでに 1 日 1 回以上配信しています。
変更が実施される速度の適切さに関する認識はグループによって異なります。 しかし、両者の大多数 (DevOps の 70%、NetOps の 74%) が変更の頻度を「当社にとって十分」と評価していることは注目に値します。
共通点はそこで終わります。 DevOps 部門では、現在のスケジュールが「頻度が高すぎる」と回答したのはわずか 4% でしたが、NetOps 部門では、配信頻度が「頻度が高すぎる」と回答した人が 2 倍に増加しました。 DevOps の 4 人に 1 人 (26%) 以上がスピードアップを望んでいるのに対し、NetOps の 5 人に 1 人未満 (18%) がペースアップを望んでいます。
しかし、欲求を無視して結果を調べると、速度と成功率のバランスをとるための「理想的な」展開頻度が明らかになります。 90% 以上の確率でデプロイメントが成功している NetOps の 65% と DevOps の 57% のうち、変更は「週に 1 回」本番環境にプッシュされています。
結論
アプリケーションが配信から展開に至るまでに通過しなければならないデジタル ディバイドは依然として存在します。 デプロイメント パイプラインの大部分は依然として手動で実行されており、アプリケーションは引き続きクラウドに移行されます。 代わりに、DevOps がクラウドに移行するという決定により、NetOps は移行をスピードアップするために必要なセルフサービス アクセスをさらに多く提供できるようになります。
自動化は、NetOps と DevOps がよりスマートに、より効率的に機能し、ビジネスのニーズに合わせて運用を拡張できるようにするため、デジタル ディバイドを埋める鍵となります。
方法論
このレポートのデータは、2017 年 7 月に実施された 2 つの個別のオンライン調査からまとめられました。 どちらも、開発から展開までのアプリケーション ライフサイクルにおける自動化の使用と、関係する 2 つの主要グループの認識を調査するために設計されました。 両グループの回答者には参加するようインセンティブが与えられました。
補遺: 調査抜粋
以下には、NetOps と DevOps の両方の回答者から収集された、調査の質問に対する追加の選択された回答が含まれています。 これらは包括的なリストではありませんが、受け取ったフィードバックの種類のサンプルとしてここに示します。 製品名は正確さを保つために編集されていますが、それ以外は、コメントを編集せずに受け取ったまま公開することを目的としています。
ネットオペレーション
「開発チームは適切に優先順位を付けていますか？」の質問に「いいえ」と答えた場合、優先順位をどのように変えてほしいですか？
- 安定性、品質、ビジョン。 多くの場合、人々は期日に向けて全力で走りますが、その際に最も損なわれるのは品質です。 また、現在のタスクを超えて考えないと、大量のやり直しが必要になり、最終的には最適とは言えない解決策になってしまいます (ジャンクが寄せ集められて機能するかもしれませんが、決して最適でも理想的でもありません)。
- 開発チームとシステム管理チーム間の連携をさらに強化する必要があります。 手動管理からの脱却が十分に進んでいません。
- 開発チームが運用の信頼性、アーキテクチャの一貫性、異なる開発チーム間の協力をもっと重視することを望んでいます
- アプリ開発者はネットワークやセキュリティについて考えていません。セキュリティは開発についてわずかにしか認識しておらず、ネットワークは開発が完了すると運用上の変更を認識します。
理想的な世界では、開発チームと運用チーム間のやり取り、コミュニケーション、コラボレーションなどをどのように改善しますか?
- メトリック、監視、可視性を改善し、双方がパフォーマンスを把握できるようにします。 パイプラインを自動化してサービスの提供を高速化します。 長い納期を回避するために十分な容量をプロビジョニングします。
- より賢い人材と交代する
- お互いを障害物とみなすのをやめ、すべてのチームが最も価値を付加できる分野に貢献できるようにします。 自動化は素晴らしいですが、何らかの監視がなければ、機能するかもしれないソリューションが実装されても、より優れた、より最適な方法があった場合がよくあります。
- 開発チームと運用チームの境界線がさらに曖昧になります。 利用可能なインフラストラクチャ上で最小限のオーバーヘッドで拡張およびパフォーマンスが良好な方法でアプリケーションを提供するという共通の目標を持つ「1 つのチーム」と見なす必要があります。
- ネクタイを締めたロックのような精神状態の相手と話しているのであれば、コミュニケーションは重要ではありません。
- 開発サイクルのプロセスの早い段階で F5 チームを関与させる。
- 開発サイクルの早い段階で運用を導入する
- コードの共有とパイプラインの可視性。 コードで管理できるツールが多ければ多いほど良いです (たとえば、F5 BIG-IP をコードで適切に管理することはできません。これが私たちのプロセスの弱点です)。
デブオプス
「運用チームは適切に優先順位を付けていますか？」の質問に「いいえ」と答えた場合、優先順位をどのように変えてほしいですか？
- クラウド空間において、自動化され、クラウドに依存しないリソース作成を優先してほしいと思います。 プッシュボタン インフラストラクチャは、開発者、QA、運用にとって確実に実現可能で便利です。
- 自分たちが触れるものすべてを自動化することに適応し、失業を恐れるのをやめる必要がある
- 手作業が多すぎる、自動化されていない、中核となる技術的問題に対する理解が不足している。 開発者に権限を与えます。
- 彼らはお金を投げつけて問題を解決しようとする傾向がある。 より多くの（高価な）機器。 自動化ではなく、ハンドルを回す人員を増やす。
理想的な世界では、開発チームと運用チーム間のやり取り、コミュニケーション、コラボレーションなどをどのように改善しますか?
- 運用チームには、運用環境の詳細を抽象化するためのツールをさらに提供してほしい
- 私は開発者であり、インフラストラクチャを展開して自動化する必要があります。 運用担当者は自動化といくつかのツールを学ぶ必要があります。
- 運用チームを、インフラストラクチャの管理を自動化するインフラストラクチャ サポートの役割に変更します。 これにより、開発者はアップグレードやサーバー管理などを実行するために運用に頼るのではなく、インフラストラクチャをサービスとして使用できるようになります。 また、アプリケーションの管理を容易にするために、運用チームのメンバーを連絡役として他のグループに組み込みます。
- 運用チームを拡大し、開発とテストに直接関与する必要があります。リクエストの受け皿となる場所ではなく、最前線で統合されたパートナーとなる必要があります。