ロシアにおける DevOps の現状 2020

何かの状態を理解するにはどうすればよいでしょうか?

Web サイト上の出版物や経験など、さまざまな情報源から得られた自分の意見を信頼できます。 同僚や知人に尋ねることもできます。 もう XNUMX つのオプションは、カンファレンスのトピックに注目することです。プログラム委員会は業界の積極的な代表であるため、関連するトピックの選択に関してはプログラム委員会を信頼しています。 調査とレポートは別の領域です。 しかし問題がある。 DevOpsの現状に関する調査は世界中で毎年行われており、レポートは外国企業によって発行されていますが、ロシアのDevOpsに関する情報はほとんどありません。

しかし、そのような研究が行われる日が来たので、今日はその結果についてお話します。 ロシアにおけるDevOpsの現状は企業によって共同研究されました。」エクスプレス 42"そして"オンティコ」。 Express 42 は、テクノロジー企業による DevOps の実践とツールの実装と開発を支援しており、ロシアで DevOps について最初に話題にした企業の 42 つです。 この研究の著者であるイゴール・クロチキン氏とヴィタリー・ハバロフ氏は、Express 8 で分析とコンサルティングに従事する一方、さまざまな企業での運用と経験による技術的な背景を持っています。 XNUMX 年間、同僚たちは、スタートアップから大企業に至るまで、さまざまな問題を抱え、文化やエンジニアリングの成熟度も異なる数十の企業やプロジェクトを検討してきました。

Igor 氏と Vitaly 氏はレポートの中で、研究の過程でどのような問題があり、それらをどのように解決したか、また DevOps 研究が原則的にどのように行われるのか、そして Express 42 が独自の研究を行うことにした理由について述べました。 彼らのレポートを見ることができます ここで.

DevOps の研究

会話はイゴール・クロチキンによって始まりました。

私たちは DevOps カンファレンスの聴衆に定期的に「今年の DevOps 状況レポートを読みましたか?」と尋ねます。 手を挙げる人はほとんどおらず、私たちの調査では、手を挙げる人はわずか XNUMX 分の XNUMX であることがわかりました。 このようなレポートを見たことがない場合は、それらはすべて非常に似ているとすぐに言ってみましょう。 ほとんどの場合、「昨年と比較して...」のようなフレーズがあります。

ここに最初の問題があり、その後にさらに XNUMX つの問題があります。

1. 昨年のデータはありません。 ロシアにおける DevOps の状況には誰の関心もありません。
2. 方法論。 仮説を検証する方法、質問を作成する方法、分析し、結果を比較し、関連性を見つける方法が明確ではありません。
3. 用語。 レポートはすべて英語であり、翻訳が必要です。共通の DevOps フレームワークはまだ発明されておらず、誰もが独自のフレームワークを考案しています。

DevOps の状態分析が世界中でどのように行われているかを見てみましょう。

歴史的情報

DevOps 研究は 2011 年から実施されています。 構成管理システムの開発者である Puppet は、これらを最初に実施しました。 当時、これはコードの形式でインフラストラクチャを記述するための主要なツールの 2013 つでした。 XNUMX 年まで、これらの研究は単に非公開の調査であり、公開レポートはありませんでした。

2013 年に、DevOps に関するすべての主要書籍の出版社である IT Revolution が登場しました。 彼らは Puppet と協力して、最初の State of DevOps 出版物を準備しました。そこでは 4 つの主要な指標が初めて登場しました。 翌年、業界の慣行やツールに関する定期的なテクノロジーレーダーで知られるコンサルティング会社、ThoughtWorks が参加しました。 そして 2015 年には方法論に関するセクションが追加され、分析がどのように行われるかが明らかになりました。

2016 年、この研究の著者らは独自の会社 DORA (DevOps Research and Assessment) を設立し、年次報告書を発表しました。 翌年、DORA と Puppet は最後の共同レポートを発表しました。

そして、興味深いことが始まりました。

2018 年に両社は分割され、2019 つの独立したレポートがリリースされました。XNUMX つは Puppet から、もう XNUMX つは DORA と Google からのものです。 DORA は、主要な指標、パフォーマンス プロファイル、および主要な指標と全社的なパフォーマンスに影響を与えるエンジニアリング プラクティスを備えた方法論を活用し続けています。 そして、Puppet は、DevOps のプロセスと進化を説明する独自のアプローチを提供しました。 しかし、この話は根付かず、XNUMX年にPuppetはこの方法論を放棄し、主要な実践方法と、それが彼らの観点からDevOpsにどのような影響を与えるかをリストした新バージョンのレポートをリリースした。 その後、別の出来事が起こりました。Google が DORA を買収し、共同で別のレポートを発表しました。 あなたも彼を見たことがあるかもしれません。

今年は事態が複雑になりました。 パペットは独自の調査を開始したことが知られている。 彼らは私たちよりXNUMX週間早くそれを行いました、そしてそれはすでに終わっています。 私たちはそれに参加し、彼らがどのようなトピックに興味を持っているかを調べました。 現在、Puppet は分析を行っており、レポートの発行を準備しています。

しかし、DORA と Google からはまだ発表がありません。 通常は調査が始まるXNUMX月に、DORA創設者のXNUMX人であるニコール・フォースグレン氏が別の会社に移籍したという情報が入った。 したがって、今年は DORA からの調査と報告は行われないものと想定していました。

ロシアの様子はどうですか？

DevOps の研究は行っていません。 私たちはカンファレンスで講演し、他の人々の発見を再話し、ライファイゼンバンクは 2019 年の「State of DevOps」を翻訳しました (彼らの発表は Habré でご覧いただけます)。彼らに多大な感謝を申し上げます。 そしてそれだけです。

したがって、私たちは DORA の方法論と調査結果を使用してロシアで独自の調査を実施しました。 私たちは、専門用語と翻訳の同期を含め、ライファイゼン銀行の同僚のレポートを調査に使用しました。 また、業界関連の質問は DORA レポートと今年の Puppet アンケートから取られました。

研究プロセス

報告書はまだ最後の部分です。 研究プロセス全体は、次の XNUMX つの主要なステップで構成されます。

準備段階では、業界の専門家にインタビューし、仮説のリストを作成しました。 それらに基づいて質問がまとめられ、6 月全体にわたって調査が開始されました。 次に、レポート自体を分析して作成しました。 DORA の場合、このプロセスには 3 か月かかります。 私たちは XNUMX か月以内に会いましたが、今では時間がほとんど足りなかったことがわかりました。分析を実行することでのみ、何を質問する必要があるかがわかります。

参加者

外国の報道はすべて参加者の肖像画から始まりますが、そのほとんどはロシアからのものではありません。 ロシア人の回答者の割合は年ごとに 5 ～ 1% の間で変動しており、これによって結論は出せません。

Accelerate State of DevOps 2019 レポートの地図:

私たちの調査では、889 人にインタビューすることができました。これはかなりの数です (DORA はレポートで毎年約 XNUMX 人にアンケートを行っています)。ここで目標を達成しました。

確かに、参加者全員が最後まで到達したわけではありません。完了率は半分よりわずかに低いことが判明しました。 しかし、これでも代表的なサンプルを取得して分析を行うには十分でした。 DORA はレポートで充填率を開示していないため、ここでは比較できません。

業界と役職

私たちの回答者は十数の業界を代表しています。 半分は情報技術関連の仕事をしています。 これに金融サービス、貿易、通信などが続きます。 役職には、スペシャリスト (開発者、テスター、オペレーション エンジニア) および管理スタッフ (チーム、グループ、エリア、ディレクター) が含まれます。

9人に40人が中堅企業に勤めています。 XNUMX人にXNUMX人が大企業で働いています。 ほとんどの場合、最大 XNUMX 人のチームで作業します。 別途、主な活動内容を聞いたところ、大半が何らかの形で運営に関係しており、約XNUMX％が開発に携わっています。

そこで、さまざまな業界、企業、チームの代表者の比較と分析のための情報を収集しました。 私の同僚のヴィタリー・ハバロフが分析について話します。

分析と比較

ヴィタリー・ハバロフ: 私たちの調査を完了し、アンケートに記入し、仮説のさらなる分析と検証のためのデータを提供してくれた参加者全員に感謝します。 そしてクライアントや顧客のおかげで、私たちは業界の懸念事項を特定し、調査でテストした仮説を立てるのに役立つ豊富な経験を持っています。

残念ながら、一方では質問のリストを、もう一方ではデータを取得して、何らかの方法でそれらを比較し、「はい、すべてそのように機能します。私たちは正しかったです」と言って解散することはできません。 いいえ、私たちが間違っていないこと、そして私たちの結論が信頼できるものであることを確認するには、方法論と統計的手法が必要です。 その後、これらのデータに基づいてさらなる作業を構築できます。

主要な指標

私たちは DORA 方法論を基礎として採用しました。これについては、書籍『Accelerate State of DevOps』で詳しく説明されています。 私たちは、主要な指標がロシア市場に適しているかどうか、「ロシアの産業は外国の産業にどのように対応しているのか?」という質問に答えるために DORA が使用しているのと同じ方法で使用できるかどうかを確認しました。

主要な指標:

1. 導入頻度。 アプリケーションの新しいバージョンは実稼働環境にデプロイされる頻度 (ホットフィックスとインシデント対応を除く、計画された変更) はどのくらいの頻度で行われますか?
2. 納期。 変更をコミット (コードとして機能を記述する) してから、その変更を実稼働環境にデプロイするまでの平均時間はどれくらいですか?
3. 回復時間。 アプリケーション ユーザーに影響を与えるインシデント、サービスの低下、またはバグの発見後、アプリケーションを運用環境に復元するのに平均でどれくらい時間がかかりますか?
4. 失敗した変更。 実稼働環境でのデプロイメントのうち、アプリケーションの機能低下やインシデントが発生し、修正 (変更のロールバック、ホットフィックスまたはパッチの開発) が必要となるのは何パーセントですか?

DORA はその調査で、これらの指標と組織のパフォーマンスとの間に関連性があることを発見しました。 私たちの研究でもそれをテストしています。

しかし、XNUMX つの主要な指標が何かに影響を与える可能性があることを確認するには、それらが互いに何らかの関連性があるのか​​どうかを理解する必要があります。 DORA は肯定的に答えましたが、XNUMX つの注意点がありました。失敗した変更 (変更失敗率) と他の XNUMX つの指標との関係はわずかに弱いということです。 ほぼ同じ写真が得られました。 配信時間、導入頻度、および復旧時間に相関関係がある場合 (この相関関係はピアソン相関関係とチャドック尺度を通じて確立しました)、失敗した変更にはそれほど強い相関関係はありません。

基本的に、ほとんどの回答者は、本番環境で発生するインシデントの数はかなり少ないと回答する傾向があります。 失敗した変更に関しては、回答者のグループ間にまだ大きな差があることが後でわかりますが、この部門ではこの指標をまだ使用できません。

これは、（一部のお客様との分析とコミュニケーション中に判明したように）何がインシデントとみなされるかについての認識にわずかな違いがあるためであると考えています。 技術的な期間中にサービスのパフォーマンスを復元できた場合、これはインシデントとみなされますか? おそらくそうではありません。すべてを修正したので、私たちは素晴らしいです。 通常の使い慣れたモードでアプリケーションを 10 回再ロールしなければならなかった場合、それを事件とみなしてよいでしょうか? そうではないようです。 したがって、失敗した変更と他の指標との関係の問題は未解決のままです。 さらに磨きをかけます。

ここで重要なのは、配信時間、復旧時間、展開頻度の間に有意な相関関係があることが判明したことです。 したがって、これら XNUMX つの指標を使用して、回答者をパフォーマンス グループにさらに分類しました。

どのくらいグラムでぶら下がっていますか？

階層クラスター分析を使用しました。

• 回答者を n 次元空間に分布させます。各回答者の座標が質問に対する回答となります。
• 各回答者は小さなクラスターとして宣言されます。
• 互いに最も近い XNUMX つのクラスターを XNUMX つの大きなクラスターに結合します。
• 次のクラスターのペアを見つけて、それらを結合してより大きなクラスターを作成します。

このようにして、すべての回答者を必要なクラスターの数にグループ化します。 樹状図 (クラスター間の接続のツリー) を利用すると、隣接する XNUMX つのクラスター間の距離がわかります。 私たちに残っているのは、これらのクラスター間に一定の距離制限を設定し、「これら XNUMX つのグループ間の距離が非常に大きいため、これら XNUMX つのグループは互いに完全に区別可能である」と言うだけです。

しかし、ここには隠れた問題があります。クラスターの数に制限はなく、2、3、4、10 個のクラスターを取得できます。 そして最初のアイデアは、DORA のように、すべての回答者を 4 つのグループに分けてみてはどうかというものでした。 しかし、これらのグループ間の違いは重要ではなくなり、回答者が本当に自分のグループに属しており、隣のグループに属しているかどうかを確信することはできないことがわかりました。 ロシア市場をまだ XNUMX つのグループに分けることはできません。 したがって、統計的に有意な差がある XNUMX つのプロファイルに落ち着きました。

次に、クラスターごとのプロファイルを決定しました。各グループの各メトリックの中央値を取得し、パフォーマンス プロファイルの表を作成しました。 実際、各グループの平均的な参加者のパフォーマンス プロファイルを取得しました。 低、中、高の XNUMX つの効率プロファイルを特定しました。

ここで、4 つの主要な指標がパフォーマンス プロファイルを決定するのに適しており、それらは西側市場とロシア市場の両方で機能するという仮説を確認しました。 グループ間には差があり、統計的に有意です。 最初にこのパラメータで回答者を分割し​​なかったにもかかわらず、平均の観点から失敗した変更の指標に関して、パフォーマンス プロファイル間に大きな差があることを強調します。

次に、これをどのように使用するかという疑問が生じます。

使用方法

任意のチーム、4 つの主要な指標をテーブルに適用した場合、85% のケースで完全な一致は得られません。これは単なる平均的な参加者であり、実際の結果ではありません。 私たちは皆（そしてどのチームも）少しずつ異なります。

私たちは調査しました。回答者と DORA のパフォーマンス プロファイルを取得し、どれだけの回答者がこのプロファイルに適合するかを調べました。 いずれかのプロファイルに確実に該当する回答者は 16% だけであることがわかりました。 残りはすべてその間のどこかに分散しています。

これは、効率プロファイルの範囲が限られていることを意味します。 最初の近似のどこにいるかを理解するには、次の表を使用できます。「ああ、中か高に近づいているようです!」 次にどこに行くべきかを理解していれば、これで十分かもしれません。 ただし、目標が継続的かつ継続的な改善であり、どこを開発し、何をすべきかをより正確に知りたい場合は、追加の資金が必要です。 私たちはそれらを計算機と呼びました。

• ドラ電卓
• Calculator Express 42* (開発中)
• 独自の開発 (独自の内部計算機を作成できます)。

それらは何のために必要なのでしょうか? 理解するには:

• 私たちの組織内のチームは私たちの基準を満たしていますか?
• そうでない場合、当社が持つ専門知識の枠組みの中でそれを加速させることができるでしょうか?
• もしそうなら、さらに改善できるでしょうか？

これらを使用して社内の統計を収集することもできます。

• どのようなチームがありますか?
• チームをプロファイルに分割します。
• 参照: ああ、これらのコマンドはパフォーマンスが低下しています (少しも落ちません)。しかし、これらは素晴らしいものです。これらは毎日デプロイされ、エラーもなく、リード タイムは XNUMX 時間未満です。

そして、当社には、まだ水準に達していないチームに必要な専門知識とツールがあることがわかります。

あるいは、社内で自分が素晴らしいと感じていること、自分が他の人よりも優れていることを理解すれば、もう少し広い視野で見ることができます。 これはまさにロシア産業です。私たちは、自分自身を加速させるために、ロシア産業で必要な専門知識を得ることができるでしょうか? Express 42 計算機がここで役に立ちます (開発中です)。 ロシア市場を超えて成長している場合は、次のことを見てください。 ドラ電卓 そして世界市場へ。

大丈夫。 DORA 電卓の Elite グループに属している場合は、どうすればよいでしょうか? ここには良い解決策はありません。 あなたは業界の最前線にいる可能性が高く、社内の研究開発とより多くのリソースの投入により、さらなる加速と信頼性が可能になります。

最も魅力的な比較に移りましょう。

比較

私たちは当初、ロシアの産業を西側の産業と比較したいと考えていました。 直接比較すると、プロファイルの数が少なく、相互に少し混合されており、境界が少しぼやけていることがわかります。

私たちのエリート パフォーマーはハイ パフォーマーの中に隠れていますが、彼らはそこにいます - これらはかなりの高みに到達したエリート、ユニコーンです。 ロシアでは、エリートプロフィールとハイプロフィールの違いはまだ十分に顕著ではありません。 将来的には、エンジニアリング文化、エンジニアリング実践の実装の質、企業内での専門知識の増加により、この分離が起こると考えています。

ロシア業界内での直接比較に移ると、知名度の高いチームがあらゆる点で優れていることがわかります。 また、これらの指標と組織のパフォーマンスの間には関係があるという仮説も確認しました。つまり、知名度の高いチームは、目標を達成するだけでなく、それを上回る可能性がはるかに高いということです。
そこで終わりではなく、注目度の高いチームになりましょう。

しかし、今年は特別であり、パンデミックの中で企業がどのような状況にあるのかを確認することにしました。注目を集めているチームは、業界平均よりもはるかに優れた業績を上げており、気分も良好です。

• 新製品をリリースする可能性が 1,5 ～ 2 倍高く、
• アプリケーション インフラストラクチャの信頼性やパフォーマンスが向上する可能性が 2 倍高くなります。

つまり、彼らがすでに持っていたコンピテンシーは、より迅速な開発、新製品の発売、既存製品の修正に役立ち、それによって新しい市場や新しいユーザーを獲得することができました。

他に私たちのチームに役立ったものは何でしょうか?

エンジニアリングの実践

私たちがテストした各実践における重要な発見についてお話します。 おそらく他の何かがチームを助けたかもしれませんが、私たちは DevOps について話しています。 そして、DevOps 内では、異なるプロファイルのチーム間で違いが見られます。

サービスとしてのプラットフォーム

プラットフォームの年齢とチームのプロフィールの間に有意な関係は見つかりませんでした。プラットフォームは、下位チームと上位チームの両方でほぼ同時に登場しました。 しかし、後者の場合、プラットフォームは平均して、プログラム コードを通じて制御するためのより多くのサービスとより多くのプログラミング インターフェイスを提供します。 そして、プラットフォーム チームは、開発者やチームのプラットフォームの使用を支援し、問題やプラットフォーム関連のインシデントをより頻繁に解決し、他のチームを教育する可能性が高くなります。

コードとしてのインフラストラクチャ

ここではすべてが非常に標準的です。 私たちは、インフラストラクチャ コードの作業の自動化と、インフラストラクチャ リポジトリ内に保存される情報の量との間に関係があることを発見しました。 ハイプロファイルコマンドは、インフラストラクチャ設定、CI/CD パイプライン、環境設定、ビルドパラメータなどの詳細情報をリポジトリに保存します。 この情報をより頻繁に保存し、インフラストラクチャ コードをより適切に操作し、インフラストラクチャ コードを操作するためのより多くのプロセスとタスクを自動化します。

興味深いことに、インフラストラクチャ テストでは大きな違いは見られませんでした。 これは、知名度の高いチームが一般にテストの自動化が進んでいるという事実によるものだと私は考えています。 おそらく、彼らはインフラストラクチャ テストだけに気を取られるのではなく、むしろアプリケーションをチェックするためのテストに気をとられるべきです。そのおかげで、何がどこで壊れているのかがすでにわかります。

統合と配信

最も退屈なセクションです。自動化が多ければ多いほど、コードをより適切に操作でき、より良い結果が得られる可能性が高まることが確認されているためです。

アーキテクチャ

私たちは、マイクロサービスがパフォーマンスにどのような影響を与えるかを確認したかったのです。 実際のところ、マイクロサービスの使用はパフォーマンス指標の向上とは関連していないため、そうではありません。 マイクロサービスは、ハイ プロファイル コマンドとロー プロファイル コマンドの両方に使用されます。

しかし重要なのは、ハイチームにとって、マイクロサービス アーキテクチャへの移行により、独自にサービスを開発して展開できるようになるということです。 アーキテクチャにより、開発者がチーム外部の誰かを待たずに自律的に行​​動できる場合、これは速度を向上させるための重要な能力となります。 この場合、マイクロサービスが役に立ちます。 そして、その実装だけでは大きな役割を果たしません。

これらすべてをどのようにして発見したのでしょうか?

私たちは DORA 手法を完全に再現するという野心的な計画を立てていましたが、リソースが不足していました。 DORA が多額のスポンサーシップを使用し、調査に半年かかる場合、私たちは短期間で調査を完了しました。 私たちは DORA のような DevOps モデルを構築したいと考えており、将来的にはそうする予定です。 これまでのところ、ヒート マップに限定してきました。

各プロファイルのチーム間でのエンジニアリング プラクティスの分布を調べたところ、平均して、注目度の高いチームがエンジニアリング プラクティスを使用する可能性が高いことがわかりました。 これらすべてについて詳しくは、こちらの記事をご覧ください。 レポート.

気分を変えて、複雑な統計情報から単純な統計情報に切り替えてみましょう。

他に何を発見しましたか?

ツール

ほとんどのコマンドが Linux ファミリの OS で使用されていることがわかります。 しかし、Windows は依然としてトレンドにあります。回答者の少なくとも XNUMX 分の XNUMX が、Windows のいずれかのバージョンを使用していると回答しました。 市場にはそうしたニーズがあるようだ。 したがって、これらの能力を開発し、会議でプレゼンテーションを行うことができます。

オーケストレーターの中で、Kubernetes がトップ (52%) であることは誰にとっても秘密ではありません。 次に有力なオーケストレーターは Docker Swarm (約 12%) です。 最も人気のある CI システムは、Jenkins と GitLab です。 最も人気のある構成管理システムは Ansible で、次に人気の Shell が続きます。

Amazon は現在、主要なクラウド ホスティング プロバイダーです。 ロシアの雲のシェアは徐々に増加しています。 来年、ロシアのクラウドプロバイダーがどのように感じるか、市場シェアが増加するかどうかを見るのは興味深いことになるだろう。 それらは実際に使用でき、それは良いことです。

私はイゴールに発言権を渡し、イゴールはさらに統計を教えてくれるでしょう。

実践の普及

Igor Kurachkin: これとは別に、検討中のエンジニアリング実践が社内でどのように分散されているかを回答者に尋ねました。 ほとんどの企業では、さまざまなパターンのセットで構成される混合アプローチがあり、パイロット プロジェクトは非常に人気があります。 プロファイル間にはわずかな違いも見られました。 知名度の高い代表者は、専門家からなる小規模なチームが作業プロセスやツールを変更し、成功事例を他のチームと共有する「下からの取り組み」パターンをより頻繁に使用します。 Medium では、これはコミュニティと卓越したセンターの創設を通じて会社全体に影響を与えるトップダウンの取り組みです。

アジャイルとDevOps

アジャイルと DevOps の関係の問題は、業界でよく議論されます。 この問題は、2019/2020 年の State of Agile レポートでも取り上げられているため、企業内でアジャイル活動と DevOps 活動がどのように関連しているかを比較することにしました。 アジャイルのない DevOps は珍しいことがわかりました。 回答者の半数では、アジャイルの普及ははるかに早く始まり、約 20% が同時開始を観察しました。注目度が低い兆候の XNUMX つは、アジャイルと DevOps の実践が欠如していることです。

コマンドトポロジ

昨年末に出版された本『チームトポロジ」では、コマンド トポロジを記述するためのフレームワークが提案されています。 それがロシア企業にも適用できるかどうかは私たちにとって興味深いものでした。 そして、「どのようなパターンが見つかりますか?」という質問をしました。

回答者の半数にはインフラストラクチャ チームが存在し、開発、テスト、運用には別のチームが存在していることが観察されました。 別の DevOps チームは 45% を記録しており、その中で高の代表者がより一般的です。 次に機能横断的なチームが続きますが、これも高等部でより一般的です。 個別の SRE コマンドは高、中プロファイルに表示されますが、低プロファイルではほとんど表示されません。

DevQaOps 比率

Skyeng プラットフォーム チームのチーム リーダーからのこの質問を Facebook で見ました。彼は企業内の開発者、テスター、管理者の比率に興味を持っていました。 私たちはそれを尋ね、プロフィールに基づいて回答を調べました。知名度の高い代表者には、開発者ごとに少ないテスト エンジニアと運用エンジニアがいます。

2021年計画

来年の計画について、回答者は次の活動に言及しました。

ここでは、DevOps Live 2020 カンファレンスとの交差点がわかります。私たちはプログラムを注意深く検討しました。

• 製品としてのインフラ
• DevOps の変革
• DevOps プラクティスの配布
• DevSecOps
• ケースクラブとディスカッション

しかし、プレゼンテーションの時間ではすべてのトピックをカバーするのに十分ではありません。 舞台裏に残されたもの:

• サービスおよび製品としてのプラットフォーム。
• コードとしてのインフラストラクチャ、環境、クラウド。
• 継続的な統合とデリバリー。
• 建築;
• DevSecOps パターン。
• プラットフォームおよび部門横断的なチーム。

レポート 50ページにわたるボリュームのある内容で、より詳細にご覧いただけます。

要約

私たちの調査とレポートが、開発、テスト、運用に対する新しいアプローチを試すきっかけとなるとともに、調査の他の参加者と比較し、独自のアプローチを改善できる領域を特定するのに役立つことを願っています。

ロシアにおけるDevOpsの現状に関する最初の調査結果:

• 主要な指標。 主要な指標 (配信時間、展開頻度、回復時間、変更失敗) が、開発、テスト、運用プロセスの有効性を分析するのに適していることがわかりました。
• プロファイルは高、中、低です。 収集されたデータに基づいて、指標、実践、プロセス、ツールの点で独特の特徴を持つ高、中、低の統計的に異なるグループを区別できます。 高プロファイルの代表者は、低プロファイルよりも優れた結果を示します。 彼らは目標を達成し、それを超える可能性が高くなります。
• 2021 年の指標、パンデミック、計画。 今年の特別な指標は、企業がパンデミックにどのように対処したかです。 高位の代表者はより良い成績を収め、ユーザー エンゲージメントの増加を経験しました。成功の主な理由は、効率的な開発プロセスと強力なエンジニアリング文化でした。
• DevOps の実践、ツール、およびその開発。 企業の来年の主な計画には、DevOps 実践とツールの開発、DevSecOps 実践の導入、組織構造の変更が含まれます。 そして、DevOps プラクティスの効果的な実装と開発は、パイロット プロジェクト、コミュニティと卓越したセンターの形成、会社の上層部と下層部の取り組みの助けを借りて実行されます。

皆様のフィードバック、ストーリー、フィードバックをお待ちしております。 研究にご参加いただいた皆様に感謝するとともに、来年も皆様のご参加をお待ちしております。

出所： habr.com