テーブルを作成します。ステートメントを使用してデータが正規化および変換されます。変更、デプロイ、インシデントの正確な定義は、チームのビジネス要件に応じて異なります。このため、柔軟な方法でイベントを追加または除外できることが重要です。定義はチームによって異なりますが、スクリプトでは最初に利用できるデフォルト設定が用意されています。スクリプトの例を示します。データ変換を行うメリットの一つに、データを編集または再分類する際にパイプラインを再実行する必要がないことがあります。データを解析して操作することができます。関数を使用することもできます。指標をシステムレベルの計算に変換する方法を説明します。レベルに分類しました。クリックして拡大ただし、コンピュータに尋ねるよりも、実際の作業者にデプロイの頻度を尋ねる方がはるかに簡単です。マネージャーに対し、デプロイをどの程度の頻度(毎日、毎週、毎月など)で実行していたかを尋ねると、マネージャーは通常、自分の組織がどのカテゴリに分類されるかを直感で把握します。同じ情報をコンピュータから取得する場合は、定義を非常に明確にし、自分で価値判断を下す必要があります。次に、指標の定義と計算における細かな意味を説明します。「組織による正常な本番環境へのリリースの頻度。あるため、最も収集しやすい指標です。頻度に関する分類は、計算が難しい要素の一つです。ボリュームの表示や、週単位のデプロイ平均回数の収集であれば簡単で単純ですが、この指標はデプロイのボリュームではなく頻度です。日以上である場合です。わかりやすく言い換えると、「毎日デプロイする」というカテゴリに分類されるようにするには、ほぼすべての営業日にデプロイを実行する必要があります。Monthly(毎月)に分類されます。次に、本番環境へのデプロイの成功の条件を検討する必要があります。場合はどうでしょうか?最終的には、これはチームの個々のビジネス要件に応じて異なります。スクリプトを編集してこのしきい値を調整できます。つの重要なデータが必要です。すべてのデプロイで、デプロイに含まれるすべての変更のリストを維持する必要があります。マッピングとトリガーを使うと簡単です。テーブルの変更のリストを使用して、変更テーブルに再び結合してタイムスタンプを取得し、リード時間の中央値を計算できます。つの数値に基づいて決まります。合計デプロイ回数を必要とします。テーブルから簡単に取得でき、インシデントにリンクされます。インシデントのラベル、フォームからスプレッドシートへのパイプライン、課題管理システムなどから取得されます。含まれていることです。つのテーブルを結合できます。「組織が本番環境での障害から回復するのにかかる時間」サービス復元時間を測定するには、インシデントが作成された時点とインシデントが解決された時点を確認しておく必要があります。インシデントが作成された時点と、デプロイによりそのインシデントが解決された時点も確認しておく必要があります。変更障害率と同様に、このデータはインシデントを管理するさまざまなシステムから取得されます。ダッシュボードで可視化することができます。コネクタを使用します。テンプレートに接続できます。つの主な指標に関する研究に基づく大まかな分類を示し、最近のパフォーマンスに関する実行ログを表示するように設計されています。チームは早い段階でパフォーマンスの低下を把握でき、この低下を緩和する措置をとることができます。パフォーマンスが低い場合、バケットが更新される前に、チームが低下の兆候を早期に確認できます。プロジェクトをご覧になり、お試しください。スクリプトを実行すると、アーキテクチャがセットアップされプロジェクトと統合されます。フィードバックや投稿をお待ちしております。指標収集に関するフォローアップ投稿も予定しております。controlsヘルプLanguage‪English‬‪Deutsch‬‪Français。