成功のためのDevOpsチームのセットアップ

概要

パフォーマンスの高いエンジニアリングチームとパフォーマンスの低いエンジニアリングチームの間のギャップは、どの角度から見ても劇的です。 彼らの技術スタックとアーキテクチャの選択、パフォーマンスメトリック、または文化的要素とチーム要素を分析するかどうかにかかわらず、デルタは非常に印象的である傾向があります。 さまざまなアプローチにもかかわらず、いくつかの指標は、十分に油を塗ったセットアップの典型的な特性を明確に示しています。

ズームインすると根本的な原因に到達しています 文化的側面。 チームはどのように管理しますか DevOps？ 所有権はどのように分配され、考えられますか？ これは、データが最も明確であり、変化を推進したいチームが実際に始めることができる場所です。 パフォーマンスの高いチームの100人の開発者のうち100人が、真のチームを実行していると報告しています 「あなたはそれを構築し、あなたはそれを実行します" 設定。 非常に合理化および最適化されたセットアップであるため、過度に複雑な設計や制限的な抽象化を邪魔することはありません。 比較すると、パフォーマンスの低いチームの3.1％だけがこれを報告しています。 52％のケースでは、パフォーマンスの低い人は依然として「フェンスを越えて投げる」操作のモデルにとらわれています。 ケースの44.9％で、開発者は放置され、「シャドウオペレーション」モデルを開発します。このモデルでは、上級開発者がオペレーションの役割を引き継ぎ、経験の浅い開発者を支援し、あらゆる種類の非効率性を生み出します。

Tech Stack＆Architecture：

アプリケーションのアーキテクチャ

• トップパフォーマーは、アプリの95％ですべての緩く結合されたアーキテクチャを実行しています。 
• パフォーマンスの低いユーザーは、モノリスであるアプリケーションのほぼXNUMX倍の数を実行します。

ITを

• トップパフォーマーが選んだ パブリッククラウド 支配的なアプローチとして
• パフォーマンスの低いユーザーは、オンプレミスをより多く表示します 

コンテナ化

• すべてのチームで、82％がすでに 完全にコンテナに、現在移行中、または現在移行を開始しています。
• 18％は、移行を開始する予定はありません。 XNUMX倍以上のパフォーマンスの低いユーザーが、移行することはないと報告しています。エコシステムの老朽化とサーバーの削減が残りの選択肢です。
• Kubernetesは、すべてのチームの62％以上が選択する、新しいレガシーおよびソリューションです。

コードとしての構成

コードとして構成を使用しないパフォーマンスの低い40％は、ロールバック、適切なガバナンスの実行、監査要件の達成などを試みる作業量が急増します。 

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

パフォーマンスメトリクス

展開頻度：環境管理が動的でない場合、モノリスを使用している場合、またはチームの構成とプロセスフローにバグがある場合、ソフトウェアの迅速な展開と出荷は非常に困難になります。

• ハイパフォーマーにより、開発者は50％以上のケースで本番環境にデプロイできます。 トップパフォーマーの80％以上が、少なくともXNUMX日に数回展開しています。 
• パフォーマンスの低い人の22％は、「年に数回」しか展開しないと答えています 

リードタイム：コードの実装、テスト、および配信にかかる時間。

• パフォーマンスの低いユーザーの20％以上が、すべての段階でコードを配信するのにXNUMXか月以上かかります
• トップパフォーマーの50％以上が数分かかり、XNUMX週間以上かかるものはほとんどありません。 つまり、特定の展開で適用される個々のコードの変更は大幅に小さくなる可能性が高く、同僚のレビューが容易になり、変更の失敗率が低下します。

平均修復時間（MTTR）：製品またはシステムに障害が発生した後、すべてが完全に機能するようになるまでにかかる時間

• IaCまたはConfigasCodeで実行されていないパフォーマンスの低いユーザーの場合、横向きになると修正に時間がかかります。

故障率の変更： 特定のデプロイメントで「障害のある」コードが本番環境にどの程度到達するかを示します

チームのセットアップと文化

• チームの21.2％だけが、すべてのDevOpsタスクを自分で実行できると報告しています。
• ケースの44.6％はそうなるはずですが、セットアップは非常に複雑であるため、実際には経験豊富な開発者だけがDevOpsタスクに取り組み、チームのボトルネックになることができます。 
• ケースの34.2％、現実は20年前のように分割された「柵を越えて」です
• トップパフォーマーの96.6％は、開発者エクスペリエンスを改善するために多額の投資を行い、それを最優先事項と考えていると報告しています。 に投資する セルフサービス機能. 

Salesforceの内部開発者プラットフォームを構築したAaronErickson氏は、次のように述べています。「理論的にはサービスの所有権は良い考えですが、実際には人々は混乱します。 開発者がサービスのためにすべての操作を実行する必要がある場合、規模の経済はありません。 Kubernetesの周りで1,000の異なるサービスを実行するために、1,000のKubernetesエキスパートを必要としないはずです。」

認知的負荷の最適化

• 認知的負荷：ワーキングメモリリソースの使用量を示します（開発者向け）
• 彼らはIaCウィザードになりつつありますが、専門分野に頼っています。
• 過剰通信は、開発チームにセルフサービス機能を提供することと、開発ベースの役割から抽象化することのバランスを見つけるための唯一のソリューションです。

黄金の檻の上の黄金の道

ゴールデンパス–抽象化せずに抽象化することについて

ゴールデンパススタイルのセルフサービスセットアップで最も一般的に使用される説明は、内部開発者プラットフォームです。 内部開発者プラットフォーム（IDP）は、開発者が組織の配信設定と独立して対話できるようにするセルフサービスレイヤーであり、環境、展開、データベース、ログなど、アプリケーションの実行に必要なすべてのものをセルフサービスできます。

必ず 開発者をユーザーとして扱い、 あなたは彼らと繰り返す必要があります、あなたはなぜ黄金の道が理にかなっているのか、そしてなぜ彼らが皆のためにそれを使うべきなのかを説明しなければなりません。 （（「開発者の心をつかむ」)

プラットフォームチームによるセルフサービスセットアップビルドでDevOpsを獲得

使命： 開発者が高速、品質、パフォーマンスを備えたスケーラブルなアプリケーションを出荷できるようにするツールを構築する

プラットフォームチームは、SREまたはOpsチームのある種の拡張としてではなく、組織内の顧客（アプリ開発者）にサービスを提供する独自の製品チームとして見なされます。 プラットフォームエンジニアになる

内部バランス

成功した内部プラットフォームチームは、開発チームに強力なガードレールと標準を導入することができます。 彼らの自律性をあまり奪うことなく。

最高のパフォーマンスを発揮する内部プラットフォームチームが重点的に取り組んでいる主な分野は次のとおりです。

• プラットフォームを製品として扱います。プラットフォームは、 製品の考え方。 フィードバックに基づいて、社内の顧客であるアプリ開発者に真の価値を提供するものに焦点を当てる必要があります
• 反復速度の最適化：開発者は、物事が壊れないことを確信しながら、より多くの機能と製品を一貫して顧客に出荷できるようになります。
• 一般的な問題を解決する：開発の速度低下の原因となる開発者の問題点と摩擦領域を理解することから始めます。
• 私の友人、接着剤である：プラットフォームチームは、開発者のための黄金の道を定義する必要があります。それは、仕事を成し遂げ、サービスの構築、展開、運用を可能にする、正気で実績のあるツールの選択肢の削減です。 内部プラットフォームチームとして作成する主な価値は、すべてのツールをまとめてエンジニアにスムーズな開発と展開のエクスペリエンスを保証する粘着性の接着剤になることです。
• チームを教育し、権限を与える：定期的なアーキテクチャ設計レビューを促進します。 知識や経験を共有し、ベストプラクティスをまとめて定義します。 エンジニアが一般的な落とし穴を検証およびチェックするための適切なツールを備えていることを確認します。 ハッカソンを開催します。