ロシア2020年のDevOpsの状態

何かの状態を理解する方法は？



サイトでの出版物や経験など、さまざまな情報源から形成された意見に頼ることができます。あなたは同僚や知人に尋ねることができます。もう1つのオプションは、会議のトピックを確認することです。プログラム委員会は業界の積極的な代表者であるため、関連するトピックを選択する際に彼らを信頼しています。別の分野は研究と報告です。しかし、問題があります。 DevOpsの状態に関する調査は世界で毎年行われており、レポートは外国企業によって発行されており、ロシアのDevOpsに関する情報はほとんどありません。



しかし、そのような研究が行われた日が来たので、今日は得られた結果についてお話します。ロシアのDevOpsチームの状態が共同で調査したエクスプレス42とOntiko"。Express 42は、テクノロジー企業がDevOpsのプラクティスとツールを実装および開発するのに役立ち、ロシアでDevOpsについて最初に話した人の1人でした。調査の著者であるIgorKurochkinとVitalyKhabarovは、Express 42で分析とコンサルティングに従事しており、さまざまな企業での運用と作業の経験から技術的なバックグラウンドを持っています。過去8年間、同僚は、スタートアップから企業まで、さまざまな問題とさまざまな文化的および工学的成熟度を備えた数十の企業やプロジェクトを調査してきました。



IgorとVitalyはレポートの中で、調査プロセスにどのような問題があったか、どのように解決したか、DevOps調査が原則としてどのように行われるか、Express42が独自に実施することを決定した理由について説明しました。彼らのレポートはここで見ることができます。

DevOps Research

IgorKurochkinが会話を始めました。



DevOpsカンファレンスでは、定期的に聴衆に質問をします。「今年のDevOpsステータスレポートを読んだことがありますか？」手を挙げているのはごくわずかであり、私たちの調査では、3分の1だけが彼らを調査していることが示されました。そのようなレポートを見たことがない場合は、それらがすべて非常に類似しているとすぐに言いましょう。ほとんどの場合、次のようなフレーズがあります。「昨年と比較して...」



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

1. 過去1年間のデータはありません。ロシアのDevOpsの状態は、誰にとっても興味深いものではありません。
2. 方法論。仮説をテストする方法、質問を作成する方法、分析を実行する方法、結果を比較する方法、接続を見つける方法は明確ではありません。
3. 用語。すべてのレポートは英語であり、翻訳が必要であり、共通のDevOpsフレームワークはまだ発明されておらず、誰もが独自のフレームワークを考え出します。

世界中のDevOpsの状態の分析が一般的にどのように行われたかを見てみましょう。

歴史的参照

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



2013年に、すべての主要なDevOpsブックの発行元であるITRevolutionが誕生しました。彼らはPuppetと協力して、4つの主要な指標が最初に登場した最初の出版物「StateofDevOps」を作成しました。翌年、業界の慣行とツールに関する定期的なテクノロジーレーダーで知られるコンサルティング会社ThoughtWorksが参加しました。そして2015年には、方法論のセクションが追加され、分析の実行方法が明らかになりました。



2016年に、調査の著者は、自社のDORA（DevOps Research and Assessment）を作成し、年次報告書を発行しました。翌年、DORAとPuppetは最後に共同報告書を発表しました。



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







2018年に、会社は分割され、2つの独立したレポートがリリースされました。1つはPuppetから、もう1つはGoogleと連携したDORAからです。 DORAは、主要な指標、パフォーマンスプロファイル、および主要な指標と全社的なパフォーマンスに影響を与えるエンジニアリング手法を使用して、その方法論を引き続き使用しています。そして、Puppetは、DevOpsのプロセスと進化を説明する独自のアプローチを提供しました。しかし、話はうまくいきませんでした。2019年に、Puppetはこの方法論を放棄し、新しいバージョンのレポートをリリースしました。このレポートには、主要なプラクティスと、それらがDevOpsにどのように影響するかがリストされています。その後、別のことが起こりました。GoogleがDORAを購入し、一緒に別のレポートをリリースしました。あなたは彼を見たことがあるかもしれません。



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



しかし、DORAとGoogleからの発表はまだありません。調査が通常始まった5月、DORAの創設者の1人であるNicoleForsgrenが別の会社に引っ越したという情報が届きました。したがって、今年はDORAからの調査や報告はないと想定しました。

ロシアの状況はどうですか？

DevOpsの調査は行っていません。私たちは会議で話し、他の人々の結論を語り、Raiffeisenbankは2019年の「Stateof DevOps」を翻訳しました（Habréで彼らの発表を見つけることができます）、彼らに感謝します。そしてそれがすべてです。



そのため、DORAの方法論と調査結果を使用して、ロシアで独自の調査を実施しました。Raiffeisenbankの同僚のレポートを、用語と翻訳の同期を含む調査に使用しました。また、業界固有の質問は、DORAレポートと今年のPuppet調査から得られます。

研究プロセス

レポートは最後の部分にすぎません。調査プロセス全体は、4つの大きなステップで構成されています。







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

参加者

すべての外国の報告は参加者の肖像画で始まり、それらのほとんどはロシアからのものではありません。ロシアの回答者の割合は年々5から1％に変動しており、これは結論を引き出すことを可能にしません。



Accelerate State of DevOps 2019レポートからのマップ：







私たちの調査では、なんとか889人にインタビューしました-これはかなりの数であり（DORAは毎年レポートで約1,000人をポーリングしています）、ここで目標を達成しました：







本当、すべての参加者が終わりに達したわけではありません：パーセンテージ充填量は半分弱であることが判明しました。しかし、これでも代表的なサンプルを入手して分析を行うには十分でした。DORAは、レポートへの記入の割合を開示していないため、ここで比較することはできません。

業界とポジション

回答者は12の業界を代表しています。それらの半分は情報技術で働いています。これに続いて、金融サービス、貿易、電気通信などがあります。役職には、スペシャリスト（開発者、テスター、運用エンジニア）と管理チーム（チームリーダー、チーム、ディレクション、ディレクター）が







含まれます。毎秒中規模の企業で働いています。3人に1人は大企業で働いています。ほとんどは最大9人のチームで作業します。これとは別に、主な活動についてお伺いしましたが、そのほとんどが何らかの形で運営に関連しており、約40％が開発に携わっています。







これにより、さまざまな業界、企業、チームの代表者を比較分析するための情報を収集しました。同僚のVitalyKhabarovが分析について説明します。

分析と比較

Vitaly Khabarov：調査を完了し、質問に回答し、仮説をさらに分析およびテストするためのデータを提供してくれたすべての参加者に感謝します。また、クライアントと顧客のおかげで、業界が懸念する問題を特定し、調査でテストした仮説を立てるのに役立つ豊富な経験があります。



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

主な指標

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



主な指標：

1. 展開頻度。アプリケーションの新しいバージョンが実稼働環境にデプロイされる頻度はどれくらいですか（ホットフィックスとインシデント対応を除く計画された変更）？
2. 納期。変更をコミットして（機能をコードとして記述して）、変更を製品環境にデプロイするまでの平均時間はどれくらいですか？
3. . , , ?
4. . ( , )?

DORAは、調査の結果、これらの指標と組織のパフォーマンスとの間に関係があることを発見しました。調査でも確認しています。



しかし、4つの主要な指標が何かに影響を与える可能性があることを確認するには、理解する必要があります-それらは何らかの形で相互に関連していますか？ DORAは、1つの警告を付けて肯定的に回答しました。変更失敗率と、他の3つのメトリックとの関係はわずかに弱いです。ほぼ同じ写真が得られました。配信時間、展開頻度、および回復時間が相互に相関している場合（ピアソン相関とチャドックスケールを通じてこの相関が見つかりました）、変更の失敗との強い相関はありません。



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



これは、（一部のお客様との分析およびコミュニケーション中に判明したように）インシデントと見なされるものの認識にわずかな違いがあるという事実と関連付けられています。テクニカルウィンドウの間にサービスの操作性を回復できた場合、これはインシデントと見なすことができますか？おそらくそうではありません。すべてを修正したので、私たちは素晴らしいです。通常のモードでアプリケーションを10回再ロールアウトする必要がある場合、インシデントと見なすことができますか？そうではないようです。したがって、失敗した変更と他のメトリックとの関係の問題は未解決のままです。さらに改良していきます。



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

グラムでいくら計量しますか？

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

• 回答者をn次元空間に分散します。ここで、各回答者の座標は質問への回答です。
• 各回答者を小さなクラスターとして宣言します。
• 互いに最も近い2つのクラスターを1つの大きなクラスターに結合します。
• 次のクラスターのペアを見つけて、それらを組み合わせてより大きなクラスターにします。

これが、すべての回答者を必要な数のクラスターにグループ化する方法です。樹状図（クラスター間の接続のツリー）の助けを借りて、2つの隣接するクラスター間の距離を確認します。私たちに残っているのは、これらのクラスター間に特定の距離制限を設定し、「これら2つのグループは、それらの間の距離が大きいため、互いに非常に区別できる」と言うことだけです。



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







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







ここでは、4つの主要な指標がパフォーマンスプロファイルの決定に適しており、西部市場とロシア市場の両方で機能するという仮説を確認しました。グループ間には違いがあり、統計的に有意です。最初は回答者をこのパラメーターで除算しなかったにもかかわらず、失敗した変更のメトリックに応じて、パフォーマンスプロファイル間の平均に有意差があることを強調したいと思います。



次に、疑問が生じます：これをどのように使用するのですか？

使い方

チーム、4つの主要な指標を取得してテーブルに適用すると、85％の場合、完全に一致することはありません。これは単なる平均的な参加者であり、実際の参加者ではありません。私たちは皆（そして各チーム）少し異なっています。



確認しました。回答者とDORAのパフォーマンスプロファイルを取得し、特定のプロファイルに適合する回答者の数を調べました。回答者の16％だけがプロファイルの1つに正確にヒットしていることがわかりました。他のすべてはその間のどこかに散らばっています：







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

• DORA計算機
• Calculator Express 42 *（開発中）
• 独自の開発（独自の内部計算機を作成できます）。

彼らは何のために必要ですか？理解するには：

• 組織内のチームは基準を満たしていますか？
• そうでない場合、私たちは彼女を助けることができます-私たちの会社が持っている専門知識の枠組みの中で彼女を加速させますか？
• もしそうなら、私たちはそれをさらに良くすることができますか？

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

• どのチームがありますか。
• チームをプロファイルに分割します。
• 参照：ああ、これらのチームはパフォーマンスが低く（少し引っ張らない）、クールです。エラーなしで毎日展開され、リードタイムは1時間未満です。

そして、私たちの会社の中には、まだ頑張っていないチームに必要な専門知識とツールがあることがわかります。



または、社内で自分が素晴らしいと感じていること、他の人よりも優れていることを理解している場合は、より広い視野を持って見ることができます。これはまさにロシアの産業です。私たちは自分自身を加速するためにロシアの産業で必要な専門知識を得ることができますか？ Calculator Express 42がここで役立ちます（開発中です）。ロシア市場を超えた場合は、DORA計算機と世界市場を見てください。



はい。また、DORA計算機のElitグループに所属している場合は、どうすればよいですか？ここには良い解決策はありません。あなたは業界の最前線にいる可能性が高く、社内のR＆Dとより多くのリソースを費やすことで、さらなる加速と信頼性の向上が可能です。



最も甘い比較に移りましょう。

比較

私たちは当初、ロシアの産業と西洋の産業を比較したかったのです。直接比較すると、プロファイルが少なく、プロファイルが少し混ざり合っており、境界が少しぼやけていることがわかります。







エリートパフォーマーはハイパフォーマーの中に隠されていますが、存在しています。彼らは、かなりの高さに達したエリートのユニコーンです。ロシアでは、エリートプロファイルとハイプロファイルの違いはまだ十分に重要ではありません。将来的には、この分離は、エンジニアリング文化の向上、エンジニアリング慣行の実施の質、および企業内の専門知識に関連して行われると考えています。



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

注目を集めるチームになりましょう。それだけではありません。







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

• 新製品は1.5〜2倍の頻度でリリースされました
• アプリケーションインフラストラクチャの信頼性やパフォーマンスを向上させる可能性が2倍高くなります。

つまり、彼らがすでに開発を迅速化し、新製品を導入し、既存の製品を変更し、それによって新しい市場と新しいユーザーを征服するのに役立った能力：







他に何が私たちのチームを助けましたか？

エンジニアリングプラクティス

私たちがチェックした各プラクティスからの重要な発見についてお話します。おそらく他の何かがチームを助けましたが、私たちはDevOpsについて話しているのです。また、DevOps内では、さまざまなプロファイルのチーム間で違いが見られます。

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

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

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

ここではすべてがかなり標準的です。インフラストラクチャコードの自動化と、インフラストラクチャリポジトリ内に保存されている情報の量との間に関係があることがわかりました。ハイプロファイルコマンドは、リポジトリに詳細情報を格納します。これは、インフラストラクチャ構成、CI / CDパイプライン、環境設定、およびビルドパラメータです。彼らはこの情報をより頻繁に保存し、インフラストラクチャコードでより適切に機能し、インフラストラクチャコードで作業するためのより多くのプロセスとタスクを自動化しました。



興味深いことに、インフラストラクチャのテストに大きな違いは見られませんでした。私はこれを、ハイプロファイルコマンドが一般により多くのテスト自動化を持っているという事実と関連付けます。インフラストラクチャテストによって個別に気を散らされるべきではないかもしれませんが、アプリケーションをチェックするために使用するテストで十分であり、それらのおかげで、どこで何が壊れたかをすでに確認できます。

統合と配信

最も退屈なセクションは、自動化が進むほど、コードの操作が向上するほど、最良のメトリックを取得できる可能性が高くなることを確認したためです。

建築

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



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

どうやってこれらすべてを見つけたのですか？

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







ました。各プロファイルのチーム間のエンジニアリングプラクティスの分布を調べたところ、ハイプロファイルのチームは平均してエンジニアリングプラクティスをより頻繁に使用していることがわかりました。あなたは私たちのレポートでこれらすべてについてもっと読むことができます。



変更のために、複雑な統計から単純な統計に切り替えましょう。

他に何を見つけましたか？

ツール

ほとんどのチームがLinuxオペレーティングシステムを使用していることがわかります。しかし、Windowsはまだトレンドにあります。回答者の少なくとも4分の1が、Windowsのいずれかのバージョンの使用に言及しています。市場にはこのニーズがあるようです。したがって、これらの能力を開発し、会議でプレゼンテーションを行うことができます。



Kubernetesはオーケストレーターのリーダーです（52％）。次のオーケストレーターはDockerSwarm（約12％）です。最も人気のあるCIシステムはJenkinsとGitLabです。最も人気のある構成管理システムはAnsibleであり、次に私たちの最愛のShellが続きます。



アマゾンは依然としてクラウドホスティングサービスのリーダーです。ロシアの雲のシェアは徐々に増加しています。来年、市場シェアが拡大した場合、ロシアのクラウドプロバイダーがどのように感じるかを見るのは興味深いでしょう。それらは、あなたがそれらを使うことができる、そしてそれは良いことです：







私はいくつかのより多くの統計を与えるであろうイゴールに床を与えます。

実践の普及

Igor Kurochkin：別途、回答者に、検討されているエンジニアリング手法が社内でどのように普及しているかを示すように依頼しました。ほとんどの企業は、異なるパターンのセットを使用した混合アプローチを採用しており、パイロットプロジェクトは非常に人気があります。また、プロファイル間にわずかな違いが見られました。ハイプロファイルの代表者は、スペシャリストの小さなチームが作業プロセスやツールを変更し、成功した開発を他のチームと共有するときに、「下からイニシアチブ」パターンを使用することがよくあります。Mediumでは、これはトップからのイニシアチブであり、コミュニティと卓越したセンターを作成することで会社全体に影響を与えます。

アジャイルとDevOps

AgileとDevOpsの関係は、業界でホットなトピックです。この問題は2019/2020年のStateof Agile Reportでも提起されているため、AgileとDevOpsの活動が企業でどのように関連しているかを比較することにしました。非アジャイルDevOpsはまれであることがわかりました。回答者の半数では、アジャイルの普及ははるかに早く始まり、約20％が同時開始を観察しました。目立たない兆候のひとつは、アジャイルとDevOpsの実践がないことです。

コマンドトポロジ

昨年末には、チームのトポロジーを説明するためのフレームワークを提案した「チームのトポロジー」という本が出版されました。ロシアの企業にも当てはまるのではないかと思いました。そして、私たちは質問をしました：「あなたはどんなパターンを見つけますか？」



インフラストラクチャチームは、回答者の半数と、個別の開発、テスト、および運用チームによって監視されています。個々のDevOpsチームは45％が注目し、その中で高代表がより一般的です。これに続いて、Highではより一般的なクロスファンクショナルチームが続きます。個別のSREコマンドが高、中プロファイルに表示され、低プロファイルに表示されることはめったにありません。

DevQaOps比率

SkyengプラットフォームチームリーダーからのFaceBookでこの質問を見ました。彼は、企業の開発者、テスター、管理者の比率に興味を持っていました。私たちはそれを尋ね、プロファイルに基づいて回答を調べました。ハイプロファイルの代表者は、開発者あたりのテストおよび運用エンジニアが少なくなっています。

2021年の計画

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







ここでは、DevOps Live2020会議との交差点を見ることができます。プログラムを注意深く検討しました。

• 製品としてのインフラストラクチャ
• DevOps変換
• DevOpsプラクティスの普及
• DevSecOps
• ケースクラブとディスカッション

しかし、私たちのスピーチはすべてのトピックを検討するのに十分な時間ではありません。舞台裏に残された：

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

私たちのレポートは50ページに及ぶ膨大な量であることが判明し、より詳細に見ることができます。

まとめ

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



ロシアのDevOpsの状態に関する最初の調査の結果：

• 主要な指標。開発、テスト、および運用の有効性を分析するには、主要なメトリック（リード時間、展開頻度、回復時間、および失敗した変更）が適切であることがわかりました。
• High, Medium, Low. High, Medium, Low , , . High , Low. .
• , 2021 . , . High , , .
• DevOpsの実践、ツール、およびそれらの開発。来年の企業の主な計画には、DevOpsプラクティスとツールの開発、DevSecOpsプラクティスの導入、および組織構造の変更が含まれます。また、DevOpsプラクティスの効果的な実装と開発は、パイロットプロジェクト、コミュニティと能力の中心の形成、会社の上位レベルと下位レベルでのイニシアチブの助けを借りて実行されます。

私たちはあなたのフィードバック、ストーリー、フィードバックを聞いてうれしいです。調査にご参加いただいた皆様、ありがとうございました。来年もよろしくお願いいたします。