Relicプラットフォームに移動この機械翻訳は参考用に提供されます。英語版と翻訳版に矛盾がある場合は、英語版が優先されます。Relicを使用して、コードデプロイメントの品質とリズムを改善および最適化する方法について説明します。これは、可観測性の成熟度に関するシリーズの一部です。開発チームは、最終的にリリースの頻度と成功によって評価されます。リリースが遅すぎるチームは、ビジネスの需要やイノベーションに追いつくことができません。システム全体の安定性に悪影響を及ぼします。(DORA)チームは、ソフトウェア開発組織のパフォーマンスを示す4つの主要な指標を特定しました。当社のイノベーションと成長のバリュードライバーは、これらの指標を使用して、より効率的で応答性の高い開発チームと、より信頼性が高くパフォーマンスの高いアプリケーションを推進する全体的なプログラムを作成します。このリリース品質(RelQual)ガイドは、展開頻度、アプリケーションパフォーマンス、およびアプリケーションの信頼性を促進することにより、そのプログラムに貢献します。望ましい結果このリリース品質ガイドのプロセスを使用して、展開の頻度を増やしながら、サイズと範囲を縮小します。これにより、アイデアを本番コードに実装する時間が短縮されると同時に、ソフトウェアの欠陥による影響(またはブラスト半径)が減少します。RelQualプロセスにより、パフォーマンスのボトルネックやエラーの原因を特定し、開発プロセスにフィードバックして解決できるようにする予定です。これにより、信頼性と顧客満足度を向上させるとともに、インフラコストを低減させることができます。RelQualの全体的な目標は、パフォーマンス向上の継続的なサイクルを作成し、より少ない変更でより多くのリリースのパターンを推進することです。これにより、ビジネスの評判と収益に対するリスクを軽減し、アプリケーションのパフォーマンスと信頼性を向上させることができます。重要な概念Kepの概念は次のとおりです。Relicの可観測性成熟度プラクティスの中心的なテーマの1つは、「コミュニケーション、修復、革新」です。RelQualは、特定のKPIを使用して、開発プラクティスとアプリケーションの現在の状態を利害関係者に伝達できるようにすることで、そのテーマをサポートします。次に、これらのKPIを使用して、開発プラクティスを調整し、低速で信頼性の低いアプリケーションコンポーネントを特定して、後続の開発スプリントで修正できるようにします。最後に、これらのKPIを使用して開発慣行を加速し、革新のための時間を追加します。Assessment(DORA)組織によって、より迅速な配信とより高い組織パフォーマンスを推進する主要な機能として特定されたプラクティスです。これはCI/CDに必須のプラクティスです。トランクベースの開発では、開発作業が小さなバッチに分割され、単一のトランクのブランチに対して実行されます。作業のバッチが完了するとすぐに、ブランチはトランクにマージされます。各ブランチの有効期間は短いと予想されるため、トランクへのマージが簡単になり、すべての開発者がコードベースの最新リリースから作業できるようになります。RelQualは、このDevOpsのベストプラクティスの採用を推進し、その遵守を保証します。することで、本番環境へのコード投入を加速させることができます。ITサービスバウンダリーRelQualのユースケースは、ITサービス境界のレベルで機能します。境界でサービスを測定することにより、その上流で何が起こっているかを把握できます。ご覧のとおり、可観測性成熟度シリーズのサービスレベル管理ガイドでは、サービス境界の概念を使用して、サービスとその依存関係の応答時間とエラー率を測定しています。プロセスを使用して、次のKPIを収集および測定します。詳細情報は以下の通りです。リリース率KPIリリース率は、時間の経過に伴うリリースの回数を測定します。リリース・イベントには、以下の属性を含める必要があります。ベストプラクティスです。継続的な改善プロセスを用いて、より高いリリースレートを推進する。リリースの失敗の影響を減らすために、各リリースでの変更回数を最小限に抑える。このKPIをビジネスインパクトにマッピングし、ステークホルダーに報告する。KPIリリースサイズ/スコープは、追加または削除されたコードの行数を測定します。別の方法として、変更されたコードベースの割合を測定することもできます。このKPIは、リリース率KPIで定義されるリリースイベントの属性として含まれる必要があります。各リリースのサイズ/スコープを縮小する。ベストプラクティスです。リリースの失敗の影響を減らすために、各リリースでの変更回数を最小限に抑える。このKPIをビジネスインパクトにマッピングし、ステークホルダーに報告する。アプリのトランザクションの応答性とエラーのKPIアプリの応答性とエラーKPIは、リリースの95パーセンタイル応答時間とエラーの量を測定します。アプリケーションのサービス境界でトランザクションごとにこのKPIを収集するために、観測可能なインスツルメンテーションを使用する必要があります。属性は、最低限、以下のものを含むべきである。レスポンスタイムを改善し、エラーを減らす。ベストプラクティスです。サービスレベルの管理手法を使用して、ユーザーが直面するエラーが少なく、応答性の高いアプリケーションを作成します。このKPIは、エンジニアリングのパフォーマンス向上のための取り組みの優先順位付けに使用します。観測可能なソリューションを使用して、ボトルネックや問題のあるコンポーネントに関する情報を開発チームにフィードバックし、修正できるようにします。生産影響KPI本番環境への影響は、失敗したリリースの数を測定します(ロールバックされたリリースやデプロイに失敗したリリースなど)。このKPIは、リリース率KPIで定義されるリリースイベントの属性として含まれる必要があります。目標:失敗したリリースの数を減らします。ベストプラクティスです。本番環境に移行する前に、非本番環境において現実的なテストを行うようにしてください。失敗したデプロイメントを詳細に振り返ることで、テストとデプロイメントのプロセスにおけるギャップを発見し、修正することができます。観測可能範囲KPIこのKPIは、観測可能なインスツルメンテーションを持つアプリケーションの割合を測定します。100%のカバレッジベストプラクティスです。アプリケーションの主要コンポーネントに診断用インスツルメンテーションを追加する。達成度の失敗を診断プロセスに利用し、観測可能なギャップを特定し、埋める。インシデントレトロスペクティブを使用して、観測可能性のギャップを特定し、埋める。サポートチケット量KPI(オプション)サポートチケットのボリュームは、このリリースに対して開かれたサポートチケットの数を測定します。このKPIは、以下の属性を持つ時間単位または日単位の指標として収集する必要があります。目標:チケットの数を減らします。ベストプラクティスです。サポートチケットを特定のリリースに関連付けることができるようにする。サポートチケットを分析し、発生した問題の種類を理解し、その情報を継続的な改善のために利用する。アプリケーションのホスティングコストを測定します。オプションのKPIです。目標:予測可能で安定したコストモデルを作成します。ベストプラクティスです。各アプリケーションのホスティングインフラのコストを測定する。アプリケーションのパフォーマンスとコストの指標を定期的に見直し、アプリケーションがその機能とビジネスの重要性に見合ったリソースを有していることを確認する。修了しておく必要があります。以下の基本的な理解も必要です。計装入門NewRelicダッシュボードとNRQLKPIの現状を把握する他の継続的改善プロセスと同様に、RelQualの最初のステップは、KPIの現在の状態を確立することです。そのためには、次のタスクを実行します。継続的改善プロセスの開始これらについては、以下で詳しく説明します。最初のステップは、RelQualプロセスの最初の反復の対象であるアプリケーションを特定することです。RelQualプロセスに含めるべきアプリケーションは、以下のようなものです。重要なオペレーションサービスである開発サイクルが遅いデプロイメントに失敗した実績がある必要なKPIを収集するリリース品質ユースケースの成功は、その主要なパフォーマンス指標に大きく依存します。CI/CDプラットフォーム、ソース・リポジトリ、観測可能なソリューションなどの明確なソースから定義されたKPIを確実に収集することから始める必要があります。プラットフォームにインポートするための方法を特定する必要があります。セクションにリストされています。通常、開発ツールチェーンのAPIを使用してKPIとその属性を抽出し、カスタムイベントAPIを使用してそれらをNewRelicに送信します。カスタム統合作業を開始する前に、目標を満たすすぐに使用できる統合が存在するかどうかを判断する必要があります。品質改善プロセスの主要な原動力です。傾向が表示されるので、改善の取り組みを特定して優先順位を付けることができます。サンプルのRelQualダッシュボードは、GitHubの可観測性成熟度リソースセンターにあります。ダッシュボードで提示する情報の一部は、開発ツールチェーンに依存するため、ダッシュボードはサンプルからの変更が必要な場合があります。ベースラインを設定するRelQualプロセスでは、ベースラインが必要です。実行することができます。ベースラインには、リリース活動の代表的なサンプルを含める必要があります。ベースラインには、少なくとも1つの完全なリリースサイクルを含める必要がありますが、有効なベースラインを得るためには、より多くのサイクルが必要な場合もあります。ベースラインの収集と評価のサイクルは、アジャイル・スプリントと一致させ、RelQualイベント・データが期待通りに蓄積されていることを定期的に確認する必要があります。イニシャルイネーブルメントの実施この段階では、開発チームとその他の利害関係者に、ベースラインのRelQualデータと、実行する継続的な改善プロセスを紹介します。このプロセスは4つのアクティビティで構成されています。トランクベースの開発の概念を紹介します。あなたと利害関係者は、トラックベースの開発のコアコンセプトを確認し、現在の慣行がどこで異なるかを特定し、それを実装するための戦略を作成します。リリースのKPIと傾向を確認します。リリースレートとリリースサイズ/スコープKPIを確認して、トランクベースの開発の実装に向けて進歩していることを確認します。あなたの目標は、新しいリリースのサイズ/範囲を縮小しながら、リリース率を上げることです。アプリケーションのKPIと傾向を確認します。ここでは、アプリケーションのパフォーマンスとエラーKPIを確認して、アプリケーションの信頼性とパフォーマンスの向上に向けた取り組みを特定し、優先順位を付けます。ここでは、あなたと関連するステークホルダーが、リリースワークフローや観測可能性戦略の変更など、技術的な推奨事項を特定し、検討します。プロセスのこの部分を整理することができます。改善プロセスこれは、継続的改善プロセスの進行中のフェーズです。このフェーズでは、最初の有効化手順を繰り返して、ベースラインに対する進捗状況を確認し、戦略と戦術を調整して、必要な前向きなビジネス成果を実現します。改善プロセスの各サイクルは、リリースプロセスのいくつかの反復の後に発生する必要があります。別の方法として、各アジャイル・スプリントの中間点と終了時に評価を予定することもできます。この段階では、あなたはKPIを上層部に報告することで、ステークホルダーチームが適切に作業の優先順位をつけていることを確認し、約束されたビジネス成果への進捗を示すことができます。数ヶ月から数年にわたり、毎週のKPIを記録・保存し、基準値を設定し、改善率を表示します。これは継続的な改善プロセスであることに注意してください。RelQualの目標を確実に達成するために、長期にわたってKPIの収集と評価を継続します。価値の実現RelQualプロセスの実装が成熟すると、アプリケーションの展開に関連するビジネスリスクと技術リスクが減少し、アプリケーションのパフォーマンスが向上します。これにより、顧客満足度が向上し、間接費が削減され、収益の可能性が向上します。開発品質ガイドを確認して使用することもお勧めします。