azure-reliability

Azure Reliability Assessment & Configuration

クイックリファレンス

プロパティ	詳細
最適な用途	信頼性の評価、ゾーン冗長性の有効化、マルチリージョンフェールオーバーのセットアップ
主な機能	信頼性評価テーブル、ゾーン冗長性の構成、マルチリージョン IaC の生成
サポート対象サービス	Azure Functions、App Service（Container Apps は今後のバージョンで対応予定）
MCP ツール	Azure Resource Graph クエリ、Azure CLI コマンド

このスキルを使用する場面

ユーザーが次のことを希望している場合に、このスキルを有効にします。

• 「Function アプリの信頼性を評価して」
• 「Web アプリの信頼性を評価して」
• 「リソースグループの信頼性を確認して」（App Service と Functions リソースのみ）
• 「アプリはゾーン冗長ですか？」（App Service と Functions リソースのみ）
• 「App Service プランはゾーン冗長ですか？」
• 「アプリをゾーン冗長にして」（App Service と Functions リソースのみ）
• 「App Service プランをゾーン冗長にして」
• 「アプリのマルチリージョンフェールオーバーを設定して」（App Service と Functions リソースのみ）
• 「信頼性の状況を確認して」
• 「単一障害点を見つけて」（App Service と Functions リソースのみ）
• 「アプリの高可用性を有効にして」（App Service と Functions リソースのみ）
• 「災害復旧の準備状況を確認して」
• 「アプリの回復性を高めて」（App Service と Functions リソースのみ）

対象範囲に関する注意： このスキルが現在対応しているのは、Azure Functions と Azure App Service のみです。ユーザーから Azure Container Apps の信頼性について尋ねられた場合は、対応が予定されているものの、まだ利用できないことを伝え、対象範囲内の App Service と Functions リソースに該当する部分のみを進めてください。

前提条件

• 認証：ユーザーが az login を使用して Azure にログインしていること
• 権限：対象のサブスクリプション／リソースグループに対する Reader アクセス（評価用）
• 権限：Contributor アクセス（構成変更用）
• Azure Resource Graph 拡張機能：az extension add --name resource-graph

MCP ツール

ツール	目的
mcp_azure_mcp_extension_cli_generate	リソースのクエリと構成に使用する az CLI コマンドを生成します
mcp_azure_mcp_subscription_list	利用可能なサブスクリプションを一覧表示します
mcp_azure_mcp_group_list	リソースグループを一覧表示します

主なクエリ方法：az graph query を使用した Azure Resource Graph（az extension add --name resource-graph が必要です）。

評価のワークフロー

フェーズ 1：リソースを検出する

1. 対象範囲を特定する — リソースグループ、サブスクリプション、またはアプリ名をユーザーに尋ねます
2. Azure Resource Graph にクエリを実行する — 対象範囲内のすべてのリソースを検出します
3. リソースを分類する — サービスの種類（Functions、Storage など）ごとに分類します。Container Apps が見つかった場合は、記録しますが、詳細な調査は行いません。

重要： クエリの対象範囲は、必ずユーザーが指定したリソースグループまたはサブスクリプションに限定してください。すべての Resource Graph クエリに次のフィルターを追加します。

• リソースグループ：| where resourceGroup =~ '<rg-name>'
• サブスクリプション：az graph query に --subscriptions <sub-id> フラグを使用します
• アプリ名：| where name =~ '<app-name>'

フェーズ 2：信頼性を評価する

2 段階で評価します。まずプラットフォームレベルで検出し、次にサービスごとに詳しく確認します。

ステップ 1 — プラットフォームの検出（対象を確認する）。 これらを使用して、対象範囲内のリソースを列挙し、複数のサービスにまたがる信頼性のギャップを検出します。

プラットフォームの確認項目	参照先
ゾーン冗長性 — 検出	references/zone-redundancy-checks.md
ストレージ冗長性（サービス横断）	references/storage-redundancy-checks.md
マルチリージョンとグローバルロードバランサー	references/multi-region-checks.md
Front Door / Traffic Manager / App Insights のプローブ	references/health-probe-checks.md

ステップ 2 — サービスごとの詳細確認。 ステップ 1 で検出した各コンピューティングリソースについて、対応するサービスリファレンスを読み込みます。サービスリファレンスは、そのサービスのプラン／SKU のルール、評価クエリ、CLI コマンド、IaC パッチ（Bicep + Terraform + AVM）、レポート作成のヒントについての唯一の信頼できる情報源です。

このスキルのバージョンに含まれるサービス別リファレンスは、Azure Functions と App Service のみです。振り分けロジックが明確になるよう、その他のコンピューティングサービスも以下に明記しています。リソースが未対応の行に該当する場合、リファレンスを読み込んだり、CLI コマンドを捏造したり、IaC パッチを生成したりしないでください。

検出されたサービス	参照先
Azure Functions（microsoft.web/serverfarms で、kind contains 'functionapp' の場合）	references/services/functions/reliability.md
Azure App Service（Functions 以外のサイト：microsoft.web/sites で kind contains 'functionapp' を含まない場合、または microsoft.web/serverfarms で kind contains 'functionapp' を含まない場合）	references/services/app-service/reliability.md
Azure Container Apps（microsoft.app/containerapps、microsoft.app/managedenvironments）	⚪ まだ提供されていません — 今後のバージョンで提供予定です

未対応サービスの扱い： リソースが上記の未対応の行に該当する場合は、検出の概要に記載し、フェーズ 3 の表では ⚪ not assessed (planned) とマークして、サービス別の修正手順をスキップしてください。これらのサービスについて、CLI コマンドや IaC パッチを捏造しようとしないでください。

フェーズ 3：信頼性チェックリストの作成

調査結果は機能を軸にした表で提示してください。信頼性機能ごとに 1 行（コンピューティングのゾーン冗長性、ゾーン冗長ストレージ、ヘルスプローブ、マルチリージョンフェイルオーバー）とし、ステータスを 1 つだけ示して、その機能に関連する具体的なリソースを記載してください。これにより、ほとんどのセルが n/a になるリソースごとの行による煩雑さを避けられます。数値スコアや評価は付けないでください。

🔍 Reliability Assessment — {scope}
─────────────────────────────────────────────────────────────────────────────────────────────
Reliability Feature              Status      Resources
─────────────────────────────────────────────────────────────────────────────────────────────
Zone redundancy — compute        🔴 OFF      • plan-web-ii5trxva2ark4 (P1v3)
                                              • plan-ii5trxva2ark4 (FC1)

Zone-redundant storage           🔴 GRS      • stii5trxva2ark4 (defaulted; no SKU set in IaC)

Health probes                    🔴 OFF      • func-api-ii5trxva2ark4 — needs code change (FC1)
                                              • app-web-ii5trxva2ark4 — no health check path

Multi-region failover            🔴 OFF      • Single region (eastus) only — Front Door not configured
─────────────────────────────────────────────────────────────────────────────────────────────

Want me to fix the 🔴 items? I'll do the quick wins first (App
plan zone redundancy + health checks on supported plans), then ask before
storage migration and multi-region setup. (yes/no)

表のルール：

• 機能ごとに 4 行をこの順序で記載： ゾーン冗長性 — コンピューティング · ゾーン冗長ストレージ · ヘルスプローブ · マルチリージョンフェイルオーバー。対象範囲内に適用できるリソースがない場合に限り、その行を完全に省略します。
• ステータス列は記号 1 つと短い語句 1 つだけにし、それ以外の文字を含めないでください。
  • 🟢 ON — 対象範囲内の関連リソースすべてで機能が完全に有効
  • 🟡 PARTIAL — 有効なリソースと無効なリソースがある（または、liveness のみなど設定が部分的）
  • 🔴 OFF — 関連リソースすべてで機能が無効
  • ストレージの場合、該当するときは OFF を現在の SKU に置き換えてください（🔴 LRS、🔴 GRS、🟢 ZRS、🟢 GZRS）。IaC で SKU が設定されていない場合は 🔴 GRS とラベル付けし、その旨をリソース行に記載してください（ARM/AVM の既定値）。
• リソース列には、その機能に関連する項目のみをリソースごとに 1 つの箇条書きで記載します。
  • 修正が必要なリソースには、簡潔な理由をインラインで含めてください（(FC1)、(defaulted; no SKU set)、liveness only、needs code change (FC1)）。
  • その機能がすでに有効なリソースは、同じ行に — already ON と記載し、適切な設定ができていることをユーザーに示してください。
• n/a、—、空のセルは含めないでください。対象範囲内に該当するリソースがない機能は、その行を削除してください。
• 数値スコア、評価、ポイントの合計は記載しないでください。
• 段階的な修正フローを開始するため、評価の最後に「はい／いいえ」で答えられる質問を1 つだけ記載してください。リソースごとの修正一覧はここでは列挙しないでください。「はい」と回答した後に、ユーザーに提示します（Configuration Workflow Step 1）。

UX に関する注意： 評価の結果、アプリに中核的な信頼性機能（ゾーン冗長性、ZRS/GZRS ストレージ、ヘルスプローブ）がすべてすでに備わっている場合は、修正を促す質問を省略し、Configuration Workflow Step 3（マルチリージョンに関するフォローアップ）に進んでください。明示的な同意なしに、マルチリージョンの作業を開始してはいけません。

Configuration Workflow

評価結果を修正したいとユーザーが希望した場合：

⛔ 変更を実行する前に、必ずユーザーに確認してください。 変更内容、費用への影響、破壊的な操作（環境の再作成など）があれば提示してください。

Step 1: 修正計画の提示 + パスの選択

評価後、ユーザーが「修正して」／「信頼性を向上させて」／「ゾーン冗長性を有効にして」と言った場合：

1. 修正可能な各調査結果と具体的な対応を列挙する
2. 費用への影響や互換性を損なう変更があれば明記する
3. 希望するパスをユーザーに尋ねる：

I'll start with the quick wins (no downtime, fast):

1. ✏️  Enable zone redundancy on plan-ii5trxva2ark4 (Flex Consumption — no cost change)
2. ✏️  Set health check path to /api/health on func-api-ii5trxva2ark4

Then, separately, I'll ask if you want to upgrade storage:

3. 🕒  Upgrade stii5trxva2ark4 from LRS → ZRS (small cost increase, migration takes hours)
   — Required for full zone redundancy, but I'll confirm with you before starting.

How would you like to apply these changes?

  A) Fix now — Run az CLI commands against your live resources (immediate, one-time)
  B) Patch my IaC — Update your Bicep/Terraform files so changes persist across deploys

(If you use azd or Terraform, option B is recommended so `azd up` won't overwrite changes.)

パス A：今すぐ修正（CLI）

az CLI コマンドを使って、稼働中のリソースに修正を適用します。まずはすぐにできる修正を行い、その後、時間のかかるストレージ移行について確認します。

サービスごとの正確な CLI コマンドは、サービス別のリファレンスに記載されています。フェーズ 2 で検出されたリソースに該当するものを選んでください。

修正	リファレンス
ゾーン冗長性の有効化／正常性プローブの構成（Functions）	references/services/functions/reliability.md
ゾーン冗長性の有効化／正常性プローブの構成（App Service）	references/services/app-service/reliability.md
ストレージのレプリケーションのアップグレード（複数サービスに適用）	references/configure-storage.md
マルチリージョンの設定（複数サービスに適用）	references/configure-multi-region.md
プラットフォームの概要／検証	references/configure-zone-redundancy.md、references/configure-health-probes.md

実行順序 — 必ず、まずはすぐにできる修正を行ってください。

1. コンピューティングのゾーン冗長性（迅速に実施できます。App のプランに対するインプレースのプロパティ更新です）。

2. 正常性プローブ（Premium／Dedicated のみ — インプレースで更新できます。FC1／Consumption の場合は、configure-health-probes.md の同意確認手順に従ってください）。

3. 検証 — ほかの作業に進む前に、コンピューティングの変更が成功したことを確認します。

4. ⛔ 停止 — ストレージのアップグレードについて確認します。 コンピューティングはゾーン冗長になりましたが、ストレージは LRS または GRS のままの可能性があります。ユーザーに明示的に確認してください。

   ✅ Compute is now zone-redundant.
   
   To be **fully zone-redundant**, your storage account also needs to be upgraded:
     • stii5trxva2ark4: currently `Standard_LRS` → needs `Standard_ZRS`
   
   ⚠️  This is a live storage redundancy conversion:
      • Takes hours to days depending on data volume
      • Small ongoing cost increase (~$0.01/GB/month more)
      • Only supported for Standard general-purpose v2 accounts
   
   Do you want me to start the storage migration now? (yes / no / later)
   

   • はい → az storage account update --sku Standard_ZRS を実行します（必要に応じて migration start を実行）。az storage account show --query sku.name をポーリングし、Standard_ZRS と表示されるまで確認します。
   • いいえ／後で → ストレージはそのままにします。再評価時に、ZR ストレージが未対応項目として残っていることを記載します。

5. マルチリージョン — 自動実行しないでください。再評価後の明示的なフォローアップとして、以下のステップ 3 で対応します。

⚠️ 警告： 後でユーザーが azd up または terraform apply を実行すると、CLI だけで行った変更が IaC 定義によって上書きされる可能性があります。CLI で修正した後、IaC も修正することを推奨してください。

パス B：IaC を修正

信頼性設定が維持されるよう、ユーザーの Bicep または Terraform ファイルを更新します。

ステップ 1：IaC の種類を検出

1. プロジェクトのルートに infra/ フォルダーがあるか確認します
2. 見つからない場合は、プロジェクトのルートに *.bicep または *.tf ファイルがあるか確認します
3. それでも見つからない場合は、ユーザーに「IaC ファイルはどこにありますか？」と尋ねます
4. *.bicep ファイルを確認 → Bicep の修正を使用します
5. *.tf ファイルを確認 → Terraform の修正を使用します
6. 両方ある場合は、どちらを修正するかユーザーに尋ねます
7. IaC が存在しない場合は、パス A（CLI）に切り替え、その旨をユーザーに伝えます

ステップ 2：修正ごとにリスクレベルを分類

修正	リスクレベル	内容
ゾーン冗長性（App プラン）	🟢 安全な修正	次回のデプロイ時にインプレースでプロパティを更新します
ストレージの LRS → ZRS	🟡 事前移行が必要	IaC の SKU 変更をデプロイする前に、稼働中のストレージ移行を完了する必要があります。安全な修正と決してまとめないでください — ステップ 3～5 の 2 回のデプロイ手順を使用します。
正常性チェックのパス（Basic／Standard／Premium／Dedicated）	🟢 安全な修正	インプレースで更新しますが、アプリの再起動が発生します
正常性チェックのパス（FC1／Consumption）	⚪ コードのみ — 事前に確認	healthCheckPath はサポートされていません。正常性エンドポイントを追加するには、アプリのコードに HTTP トリガーの /api/health 関数を追加する必要があります。ソースコードに手を加える前に、必ずユーザーの明示的な同意を得てください。IaC は修正しないでください。

ステップ 3：2 回のデプロイで修正を適用（まずはすぐにできる修正を実施）

IaC 修正フレームワーク（検出、AVM モジュールのガイダンス、デプロイ順序のルール、ストレージ SKU の修正）は、以下に記載されています。

IaC の種類	フレームワークのリファレンス
Bicep	references/iac-patching-bicep.md
Terraform	references/iac-patching-terraform.md
実際のサービスごとのコンピューティングパッチ（Function App プラン ZR、App Service プラン ZR など）は、サービスごとのリファレンスにあります。正確な Bicep／Terraform／AVM スニペットを確認するには、Phase 2 から該当するサービスファイルを読み込んでください。このスキルのバージョンでサービスごとのリファレンスがあるのは Azure Functions と App Service のみです。Container Apps は対象外です。

デプロイ 1 — すぐに適用できる項目のみ。 🟢 Safe 項目（App Service／Function App プランのゾーン冗長性、Basic／Standard／Premium／Dedicated のヘルスプローブ）にパッチを適用してください。このデプロイには、ストレージ SKU のパッチを含めないでください。

パッチ適用後、スキルがデプロイ自体を実行します（ユーザーに実行を促して処理を止めないでください）。デプロイツールを検出し、実行前に一度だけ確認してください。

📦 Patches applied to your IaC. Ready to deploy:
   Tool detected: azd (found azure.yaml)
   Command:       azd up

Proceed with deployment? (yes / no)

はいの場合、適切なコマンドを実行し、出力をユーザーに逐次表示して、成功したら次のステップに進んでください。

• AZD プロジェクト（azure.yaml がある場合）：azd up
• Bicep のみの場合：az deployment group create --resource-group <rg> --template-file infra/main.bicep --parameters @infra/main.parameters.json
• Terraform の場合：terraform plan -out tfplan →（プランの概要を表示）→ terraform apply tfplan

いいえの場合、停止してパッチを適用したファイルを報告してください。Step 4／再評価には進まないでください。

デプロイに失敗した場合は、エラーを提示して停止してください。ストレージのステップには進まないでください。

⛔ 停止 — デプロイ 2 の前にストレージのアップグレードについて確認してください。 デプロイ 1 が成功した後、ユーザーに明示的に尋ねてください。

✅ Quick-win patches deployed. Compute is now zone-redundant.

To be **fully zone-redundant**, your storage account also needs to be upgraded:
  • stii5trxva2ark4: currently `Standard_LRS` → needs `Standard_ZRS`

⚠️  This is a two-part change:
   1. Live storage migration (`az storage account migration start`) — takes hours to days
   2. A second deploy to update your IaC's storage SKU to match

Do you want me to start the storage migration now? (yes / no / later)

• はい → スキルが移行コマンド自体を実行し、完了するまでポーリングしてから、IaC のストレージ SKU にパッチを適用し、デプロイ 2 を実行します（この時点では変更のないことを確認するだけです）。ユーザーが手動で実行する必要はありません。
• いいえ／後で → ストレージ SKU のパッチは適用せずに残します。再評価では ZR ストレージが引き続き未対応であることを記載し、後で再検討するよう提案してください。

Step 4：ストレージの移行（Step 3 でユーザーが「はい」と答えた場合のみ）

スキルが以下のコマンドを自体で実行します。ユーザーに実行を依頼しないでください。進捗を随時表示してください。

🔄 Starting storage migration (this can take up to 72 hours)...

   az storage account migration start --name stii5trxva2ark4 \
     --resource-group rg-example --sku Standard_ZRS --no-wait

   Polling: az storage account show --name stii5trxva2ark4 --query sku.name
   ...
   ✅ Migration complete: sku.name = Standard_ZRS

非常に時間のかかる移行では、会話全体をブロックする代わりに、ユーザーに進捗状況を伝えて後で確認してもらうよう案内してもかまいません（「引き続き実行中です。後ほどご確認ください」）。

Step 5：デプロイ 2 — ストレージ SKU のパッチ

移行が完了したら、スキルが IaC のストレージ SKU にパッチを適用し、Step 3 と同じデプロイコマンド（例：azd up）を実行します。このデプロイは、IaC が現在の状態と一致していることを確認するだけのものです。実行前にユーザーに一度だけ確認してから、スキルが直接実行してください。

Step 2（両方のパス）：再評価

変更が適用された後（CLI）、またはデプロイされた後（IaC）、評価を自動的に再実行し、Phase 3 と同じ機能別の表を表示してください。各機能の行のステータスは、新しい状態を反映したものに更新します。前回の実行から変わった点を簡潔に説明してください。

🔄 Reliability Re-Assessment — rg-eventhubs-python-jan13 (eastus)
───────────────────────────────────────────────────────────────────────────────────────
Reliability Feature              Status      Resources
───────────────────────────────────────────────────────────────────────────────────────
Zone redundancy — compute        🟢 ON       • plan-ii5trxva2ark4 (FC1)              — now ON
                                             • plan-web-ii5trxva2ark4 (P1v3)         — now ON

Zone-redundant storage           🟢 ZRS      • stii5trxva2ark4                       — GRS → ZRS

Health probes                    🟡 PARTIAL  • func-api-ii5trxva2ark4                — still off (FC1, code change declined)
                                             • app-web-ii5trxva2ark4                 — now ON

Multi-region failover            🔴 OFF      • Single region (eastus) only
───────────────────────────────────────────────────────────────────────────────────────

What changed: Function App and App Service plan zone redundancy, storage replication and health probes on App Service.
(Multi-region offered next — see Step 3.)

ステップ 3（どちらのパスでも）：マルチリージョンへのフォローアップ — 確認して待つ

マルチリージョン化は、コストと複雑さが大きく増すステップです。自動的に開始しないでください。 再評価の後、単一リージョンの信頼性を確保するためのすべての主要機能が 🟢 ON の場合（ゾーン冗長コンピューティング、ZRS/GZRS ストレージ、ヘルスプローブ）に限り、ユーザーに明示的に確認し、何も実行せずに返答を待ってください。

🟢 Your app is now fully zone-redundant in {region}.

The next step (optional) is multi-region failover with Azure Front Door:
   • Deploys compute + storage in a second region (paired region recommended)
   • Adds Azure Front Door for global load balancing with health-probe-driven failover
   • Protects against full region outages
   • Estimated additional cost: ~2x compute (active-passive); Front Door ~$35/month base

Do you want me to set up multi-region failover now? (yes / no / later)

• yes → references/configure-multi-region.md に従って進めます。セカンダリリージョンの選択をユーザーに確認してから、次の手順を実行します。
  1. マルチリージョンの IaC（セカンダリリージョン用の Bicep / Terraform の追加分、および Front Door）を生成します。
  2. ユーザーに一度確認します。📦 Multi-region IaC generated. Ready to deploy with \azd up`. Proceed? (yes / no)`
  3. yes の場合、スキルが自らデプロイを実行し（azd up / az deployment group create / terraform apply）、出力をストリーミングします。そこで停止して、ユーザーに実行するよう伝えてはいけません。
  4. デプロイが成功した後、最終的な再評価を実行し、マルチリージョンのフェイルオーバーが 🟢 ON になることをユーザーが確認できるようにします。
• no / later → デプロイの状態は変更しません。単一リージョンでゾーン冗長化されていれば信頼性の高い状態であり、マルチリージョン化はいつでも再検討できることを伝えます。

⛔ 待機を省略してはいけません。 ユーザーが明示的に yes と回答するまで、マルチリージョンの IaC を生成したり、Front Door をデプロイしたり、ファイルを変更したりしてはいけません。主要な信頼性機能がすべて 🟢 でない場合は、マルチリージョンについて確認せず、まず主要な不足を解消してください。

優先度の分類

優先度	条件	対応
Critical	ゾーン冗長性がなく、本番環境のワークロードである	直ちに修正
High	ゾーン冗長コンピューティングで LRS ストレージを使用している	数日以内に修正
Medium	マルチリージョンではない（単一リージョンだがゾーン冗長化されている）	次のスプリントで計画
Low	ヘルスプローブの不足、または監視の不足がある	追跡して修正

エラー処理

エラー	メッセージ	対処方法
認証が必要	"Please login"	az login を実行して再試行
アクセス拒否	"Forbidden"	Reader/Contributor ロールの割り当てを確認
プランが ZR に対応していない	"Upgrade required"	プランのアップグレード方法と追加コストをユーザーに伝える
リージョンが AZ に対応していない	"Region limitation"	対応リージョンを提案

ベストプラクティス

• インフラストラクチャに重要な変更を加えるたびに、信頼性を評価します
• 定期的にフェイルオーバーのシナリオをテストします（少なくとも四半期ごと）

スキルの適用範囲

アクション	このスキルの対応	引き継ぎ先
信頼性の状態を評価する	✅ 対応します	—
改善を推奨する	✅ 対応します	—
ゾーン冗長性を有効にする（CLI コマンド）	✅ 対応します	—
信頼性のために Bicep/Terraform にパッチを適用する	✅ 対応します	—
マルチリージョンの IaC を生成する	✅ 対応します（セカンダリリージョン用の追加分と Front Door）	新しいアプリの IaC 全体をスキャフォールディングする場合は azure-prepare
信頼性向上の変更に伴う IaC をデプロイする	✅ 対応します（ユーザーの確認後、自ら azd up / terraform apply / az deployment を実行します）	一般的なデプロイや信頼性向上を目的としないデプロイは azure-deploy
デプロイ前に検証する	信頼性チェックのみ	検証全体は azure-validate