Microsoft AZ-400: モニタリング、可観測性、フィードバック — 学習ガイド

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

こちらの一部です： Microsoft DevOps Engineer Expert AZ-400 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

現代の DevOps チームは、監視、可観測性、フィードバックを、エンジニアリング、運用、および製品に関する意思決定に情報を提供する継続的なループとして扱います。Azure では、テレメトリはアプリケーションとインフラストラクチャから Azure Monitor と Log Analytics に流れ込み、そこでクエリ、関連付け、視覚化が行われます。分散トレーシングはサービスをエンドツーエンドのトランザクションに結びつけ、アラートとオンコール連携が迅速な修復を促進します。Azure DevOps のダッシュボード、作業項目分析、および実験は、インサイトを計画とデリバリーにフィードバックすることでループを完結させます。このセクションでは、あらゆる段階で実用的なフィードバックを提供する統合された可観測性スタックを設計するために必要な詳細を解説します。

テレメトリ、トレーシング、および Azure Monitor

Application Insights は、Azure Monitor のアプリケーションパフォーマンス監視 (APM) コンポーネントです。インストルメンテーションは、次の方法で追加されます。

• SDK と自動インストルメンテーション: .NET/.NET Core、Java、JavaScript、Node.js、Python、および .NET と Java 用の Application Insights Agent。接続文字列を使用し、cloud_RoleName を設定してコンポーネントを区別します。
• テレメトリ初期化子とプロセッサ: プロパティ (例: tenantId) を追加または変更し、送信前に PII をフィルター処理します。
• カスタムテレメトリ: ビジネスアクションには TrackEvent、数値 KPI には TrackMetric、エラーコンテキストには TrackException、明示的にモデル化する必要がある外部呼び出しには TrackDependency を使用します。

テレメトリの種類には、リクエスト、依存関係 (HTTP、SQL、Azure SDK)、トレース、例外、ページビュー、ページ読み込みパフォーマンス、可用性テスト結果、カスタムイベント/メトリック、ライブメトリックが含まれます。サンプリングは、シグナルを維持しながらボリュームとコストを制御します。SDK のアダプティブサンプリングは、ターゲットスループットと相関関係を維持するためにタイプごとのレートを自動的に調整します。固定レートサンプリングは、コンプライアンスのために決定論的なサンプリングを提供します。ダウンストリームシステムがドロップされたアイテムを処理しないように、SDK 側のサンプリングを優先します。エンドツーエンドのトレースの整合性を保つために、スティッキーサンプリングを維持します。

分散トレーシングは、エンドツーエンドのトランザクションの可視性を提供します。Application Insights は W3C Trace-Context 標準 (traceparent/tracestate) を実装し、HTTP を介して関連付け ID を自動的に伝播させます。トレースが途切れるのを避けるため、非同期の境界やカスタムプロトコルを越えてコンテキストを伝播させます。依存関係の追跡は、一般的なアウトバウンドコールを自動収集します。コールグラフを完成させるために、メッセージキューのホップや非標準の RPC に対してカスタム依存関係を出力します。App Map と Transaction Search は、サービス間のフロー、レイテンシー、および障害のホットスポットを視覚化します。フロントエンドとバックエンドの相関付けには、JavaScript SDK を有効にし、サーバー側で相関ヘッダーが受け入れられるようにして、真のページ読み込み時間とユーザージャーニーを測定します。

Azure Monitor は、プラットフォームとアプリケーションのテレメトリを統合します。

• メトリック: 多次元で、ほぼリアルタイム (1 分以下の粒度)。静的または動的なしきい値を持つメトリックアラートを使用して、高速で低レイテンシーの検出を行います。
• ログ: Log Analytics ワークスペース内の半構造化テレメトリ。詳細な分析や異常検出のために KQL でクエリを実行します。
• アラート: メトリック、ログ、およびアクティビティログのルールは、アクション グループにルーティングされます。一貫した処理のために、動的しきい値、複数リソースのターゲティング、および共通アラートスキーマを使用します。
• アクション グループ: メール/SMS/音声、プッシュ通知、Webhook (PagerDuty/OpsGenie を含む)、ITSM コネクタ、Logic Apps、Azure Functions、および修復のための Automation Runbook。
• 診断設定: 各 Azure リソースを構成して、プラットフォームのメトリック/ログを Log Analytics、Azure Storage (アーカイブ用)、および Event Hubs (SIEM 取り込み用) にストリーミングします。ポリシー主導のデプロイメントで一貫性を確保します。

Log Analytics (KQL) を使用したクエリと分析

Log Analytics ワークスペースは、ログのクエリとガバナンスの境界です。環境とデータ主権に基づいて計画します。本番環境と非本番環境でワークスペースを分けると、RBAC とリテンションポリシーを簡素化できます。一元化すると、サービス間の相関付けが容易になります。データソースには、Azure Diagnostics (プラットフォームのログ/メトリック)、VM エージェント (Syslog/Windows イベント、パフォーマンスカウンター)、Container Insights/AKS、Application Insights コンポーネントのログ (Azure Monitor Logs の下で統合)、Azure AD サインイン、インジェスト API を介したカスタムログ、および正確なストリームルーティングと変換のためのデータ収集ルールが含まれます。

Kusto クエリ言語 (KQL) は、時系列およびテレメトリ分析に最適化されています。

• 主要な演算子: where (フィルター)、project (選択)、extend (派生)、summarize by (集計)、join/union (相関)、parse/parse_json (抽出)、mv-expand (配列)、時間バケット化のための make-series と bin、グラフ作成のための render。
• パターン: エラーバジェットの消費 (時間加重の失敗率)、p50/p95 レイテンシー分布、依存関係の外れ値検出、トラフィックに対するリクエスト成功率、および季節性を考慮したアラートのための series_decompose_anomalies を使用した異常検出。
• ガバナンス: 保存されたクエリと関数は再利用を促進します。RBAC とテーブルレベルのアクセスは、機密データセットを制限します。
• クロスリソースおよびクロスワークスペース: workspace("workspaceNameOrId").Table と workspaces() 関数を使用して、環境やサブスクリプションをまたいでデータセットを結合します。クロスリソース結合には resource() を使用します。大規模な結合のパフォーマンスを制御するために、let バインディングと materialize() を適用します。

Azure DevOpsにおける可視化とアジャイルフィードバック

Azure DevOpsのダッシュボードは、運用の健全性とプロセスの健全性の両方を伝えます。チームレベルのダッシュボードは、チームのバックログ、イテレーション、WIPに焦点を当てます。プロジェクトレベルのダッシュボードは、チーム横断およびポートフォリオのビューを表示します。ウィジェットには、Sprint Burndown、Burnup、Velocity、Cumulative Flow Diagram (CFD)、Cycle Time、Lead Time、Work Item Chart/Query Results、Build/Releaseサマリー、そしてランブックやSLOステータス用のMarkdownなどがあります。ダッシュボードの権限でウィジェットを保護し、クエリのスコープをチーム/エリアに厳密に設定して、チーム間の情報漏洩を防ぎます。

Boardsクエリ（クエリビルダーまたはWIQL経由）は、多くのウィジェットの動力源となります。再利用のために、チームのエリアパス/イテレーションでクエリをパラメータ化します。正確性とパフォーマンスのために、利用可能であればAnalyticsベースのウィジェットを優先します。主要なフローメトリクス：

• Cycle time: Active（進行中）からDoneまでの経過時間。Cycle Timeウィジェットを使用して実行効率を追跡します。
• Lead time: 作成/コミットメントからDoneまでの経過時間。顧客が認識するシステム全体の遅延を示します。
• Throughput: 時間間隔あたりに完了したアイテム数。WIPポリシーと比較してボトルネックを検出します。
• Cumulative Flow Diagram: 時間の経過に伴う状態ごとのキューサイズを可視化します。帯が広がっている部分は、制約やコンテキストスイッチングを明らかにします。 スプリントの追跡には、Burndown（残作業がゼロに向かうトレンド）とBurnup（総スコープと完了作業の対比、スコープ変更に強い）を使用します。Velocityはスプリントあたりの平均完了作業量を報告し、キャパシティプランニングに情報を提供します。チーム間で集計する際は、同じ見積もり単位のみを対象とします。

プロダクト分析が必要な場合は、Azure DevOps AnalyticsをPower BIに接続し、デリバリーメトリクスと運用テレメトリ（例：lead timeと欠陥流出率の対比）を組み合わせて、改善の優先順位を決定します。

信頼性、アラート、継続的フィードバック

SLI/SLO/SLAは、信頼性を第一級の機能として確立します:

• SLI: ユーザーエクスペリエンスの定量的尺度。例: リクエスト成功率、p95レイテンシー、重要なエンドポイントの可用性、UIでのタスク完了率。
• SLO: 特定期間における目標。例: 月間可用性99.9%、p95 < 300ms。SLOはインフラではなく、ユーザージャーニーに結びつけます。
• エラーバジェット: 1 − SLO。リリースリスク、ロールバック基準、インシデント対応を管理します。高速および低速な違反の両方に対応するため、KQLまたはメトリックアラートを使用して、バーンレートアラート（例: 2倍および14倍のバジェット消費）を実装します。
• SLA: 顧客への外部コミットメント。通常はSLOよりも緩やかで、ペナルティが含まれます。エンジニアリングのガードレールを決定づけるものではなく、推進するものです。

アラートとオンコール:

• レイテンシーに敏感な状態にはメトリックアラートを使用し、複雑な述語（例: 複数シグナルの相関や異常スコア）にはログアラートを使用します。
• 重複排除（アラート処理ルール）、動的しきい値、重要度のチューニング、計画メンテナンス中の自動抑制により、アラート疲れを軽減します。
• 共通アラートスキーマを使用して、アクショングループのWebhook経由でPagerDuty/OpsGenieと統合します。インシデントの重複排除のためにアラートの相関キーをマッピングし、サービスごとにエスカレーションポリシーを定義します。
• Azure AutomationのRunbook、Functions、またはLogic Appsを使用して修復を自動化します（例: キューの深さに応じたスケールアウト、障害が発生したインスタンスのリサイクル、機能フラグの切り替え）。監査可能性のため、すべての自動アクションをApplication Insightsにカスタムイベントとして記録します。

継続的なフィードバックと実験:

• A/Bテストと段階的ロールアウト: エッジでのトラフィックスプリットにはAzure Front DoorまたはTraffic Managerを使用するか、Azure App Configuration Feature Managerで機能フラグを実装して、ユーザーごとまたはコホートベースのロールアウトを行います。コードパスをフラグで保護し、バリアントごとにイベントテレメトリを収集します。
• ユーザーテレメトリ: 機能フラグの状態、ユーザープロパティ（非PII）、シナリオ識別子を含むTrackEventを発行します。Application Insightsでファネル、ユーザーフロー、リテンション、コホートパフォーマンスを分析し、仮説を検証します。
• 機能利用分析: DAU/WAU/MAU、機能の採用率、コンバージョンメトリクスを追跡するダッシュボードを構築します。結果をバックログの優先順位付けに反映させます。ステージングのSLIベースラインが失敗した場合や、実験のKPIにリグレッションが検出された場合に本番環境へのデプロイをブロックするために、Azure Pipelinesのゲートを使用します。

実践的な問題シナリオ

Spotifyは、Azure Kubernetes Service (AKS) と Azure App Service APIにデプロイされたポッドキャストの取り込みおよび再生サービスのエンドツーエンドの可視性とフィードバックを改善する必要があります。インシデントの検出が遅れ、プロダクトチームは新しい再生機能の信頼できる採用メトリクスを欠いています。

1. アプリケーションテレメトリの計測と相関付け

• .NETおよびNode.jsサービスにApplication Insights SDKを追加し、WebクライアントでApplication Insights JavaScript SDKを有効にします。cloud_RoleNameと接続文字列を構成し、マイクロサービスとメッセージキュー間でのW3Cトレースコンテキストの伝播を有効にします。 理由: ブラウザからサービス、依存関係までの完全なトランザクション可視性のために、一貫した相関IDと分散トレーシングを保証します。

2. プラットフォーム診断をLog Analyticsにストリーミングする

• Azure Policyを介してすべてのAKSクラスター、App Serviceプラン、Application Gateway、Cosmos DB、およびストレージアカウントに診断設定を適用し、中央のprodワークスペースにルーティングします。保持期間は90日とし、ストレージにアーカイブします。 理由: KQLによる相関分析とコスト効率の良い長期保存のために、プラットフォームのログ/メトリクスの一様なカバレッジを保証します。

3. SLI、SLO、エラーバジェットの定義

• SLI: p95 APIレイテンシー、リクエスト成功率、取り込みパイプラインのスループット、プレイヤー開始成功率。
• SLO: 月間成功率99.95%、p95再生開始 < 300ms、取り込み遅延 < 2分。
• KQLベースのエラーバジェットバーンレートアラート（高速/低速）と、動的しきい値を持つレイテンシー用のメトリックアラートを作成します。 理由: ビジネスの成果を、タイムリーなアラートを備えた測定可能で実行可能な信頼性目標に変換します。

4. 実用的なアラートとオンコール連携の構築

• スマートグルーピングを使用してAzure Monitorのアラートルールを作成し、共通アラートスキーマを使用してWebhook経由でPagerDutyをトリガーするアクショングループにルーティングします。キューの深さに応じた自動スケールや、不健康なポッドの再起動を行うAzure Automation Runbookをアタッチします。 理由: 信頼性の高いページングと、安全で監査可能な自動修復を通じてMTTA/MTTRを削減します。

5. エンジニアリングとプロダクト向けのダッシュボードの確立

• Azure DevOpsチームレベルのダッシュボード: サイクルタイム（アクティブ→完了）、リードタイム（作成→完了）、CFD、ベロシティ、およびスクワッド向けのスプリントバーンダウン。プロジェクトレベルのダッシュボード: リリースごとのバーンアップ、チーム横断のスループット、およびMarkdown/AnalyticsウィジェットによるSLOステータス。 理由: スクワッドに実行に関する洞察を与えつつ、リーダーシップにはポートフォリオと信頼性の健全性を提供します。

6. 実験と利用状況分析の実装

• Azure App Configurationの機能フラグを使用して、新しい「無音部分のスマートスキップ」機能を段階的にロールアウトします。必要に応じてエッジでA/Bテストを行うために、Front Doorのルールでコホートを分割します。featureFlagState、ユーザーコホート、および成果メトリクスを含むTrackEventを発行します。 理由: 証拠に基づいた意思決定のために忠実度の高いユーザーテレメトリをキャプチャしながら、影響を安全に検証します。

7. ゲートによるリリース品質の強制

• Azure Pipelinesで、ステージング環境のKPI（p95レイテンシー、失敗率、実験バリアントのパフォーマンス）をApplication Insights/Log Analyticsに問い合わせるゲートを追加します。ベースラインまたはSLOに沿ったしきい値を満たさない場合、ゲートを失敗させます。 理由: リグレッションが本番環境に到達するのを防ぎ、デプロイの決定を信頼性とプロダクトのKPIに整合させます。

← テスト戦略と品質エンジニアリング · すべてのドメイン · パッケージ管理とアーティファクト管理 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →