azure-reliability
Azure Functions と App Service の単一障害点を洗い出して、ゾーン冗長化まで段階的に直させる
npx skills add microsoft/azure-skills/azure-reliability入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 305,578
- 実用度
- 98
- GitHub star
- 1,623
- 最終更新
- 2026/11/7
頼み方の例
そのままコピーして使えますazure-reliabilityスキルを使って、リソースグループ rg-prod の App Service と Functions の可用性を点検してください。まず現状のチェックリストだけ出して、直す作業はまだ実行しないでください。ゾーン冗長化にすると何が止まるのかも書いてください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- シェルコマンドを実行する記述があります
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
いつ使うか
Azure Functions と App Service が、一緒に落ちる構成になっていないかを調べるときです。
見るのは 4 つ
- ゾーン冗長（Zone Redundancy）1 つのゾーンの障害で全部止まる
- ZRS ストレージストレージが単一ゾーンだと同じ
- 正常性プローブ（health probe）落ちたインスタンスに振り続ける
- 複数リージョンのフェイルオーバーリージョン障害で復旧手段が無い
現状を表で出してから、段階的に直す
このスキルは現状を表で出してから、段階的に直す流れを持っています。
- 走査するAzure Resource Graph でデプロイ済みのリソースを走査する
- 表で出す機能ごとのチェックリストを出す
- 直す確認を取りながら CLI か IaC で直す
表は 4 つの機能を 1 行ずつ並べ、状態は 🟢 ON・🟡 PARTIAL・🔴 OFF の記号と短い語だけです。点数や評価の段階は付けないと決められています。
直す順序も決まっています。すぐ済むもの（計算資源のゾーン冗長、正常性プローブ）を先にし、時間のかかるストレージの移行は改めて聞き、複数リージョンは最後に別に聞きます。
組で入れないと止まるもの
この公開元には組で入れないと止まるものがあります。全体の役割分担は microsoft/azure-skills の地図にまとめています。
使わないほうがいいとき
Container Apps を使っているとき
SKILL.md に「将来の版で対応予定」と書かれています。いまの対象は Functions と App Service だけです。
設計を一から相談したいとき
これはすでに動いているものの点検で、新規構成の設計には向きません。設計なら azure-prepare です。
落ちている原因を調べたいとき
それは azure-diagnostics です。このスキルは「落ちたらどうなるか」を先に見る道具です。
注意点
解析で見つかった記述
SKILL.md の解析では、外部への通信とシェルコマンドの実行の記述が見つかっています。Azure Resource Graph へのクエリと az コマンドを動かす前提です。
点検だけで止めたいなら、依頼文でそう書く
このスキルは「評価 → 段階的な修正」を 1 つの流れとして持っています。点検の表の最後は「🔴 を直しますか（yes/no）」という 1 つの質問で終わり、yes と答えると CLI のコマンドや azd up などのデプロイをスキル自身が実行します。確認を取る作りになっていますが、構成を変える方向に進むのが既定だと考えて依頼してください。
ストレージの移行は長く、本番のまま進む
計算資源のゾーン冗長は、プランの設定をその場で変える速い作業だと書かれています。ただし App Service は Premium v2 以上などのプランで、2 台以上にしてからでないと有効にできません。Basic と Standard は対応していないので、プランの格上げが要ります。
CLI だけで直すと、あとで azd up や terraform apply を流したときに IaC の定義で上書きされうる、という警告もあります。IaC も合わせて直すよう勧めています。
Functions の従量課金系は、コードに手を入れる
Flex Consumption（FC1）と Consumption のプランでは正常性チェックの経路の設定が使えません。代わりに /api/health の関数をアプリのコードに足すことになり、ソースに触れる前に必ず利用者の同意を取ると書かれています。
課金に影響する
ゾーン冗長も複数リージョンも、インスタンス数と構成が増えるぶん費用が上がります。本文は直す前の計画で費用の影響を示すよう求めていて、目安も書かれています（2026-10-09 確認）。
- ストレージを ZRS にすると 1 GB あたり月 0.01 ドルほど増える
- 複数リージョンは計算資源がおよそ 2 倍（待機系を持つ形）、Front Door が月 35 ドルほどから
複数リージョンは自動では始めず、単一リージョンの項目がすべて 🟢 になってから聞いて、返事を待つ決まりです。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
よくある質問
読み取り権限だけで動きますか
点検の部分は読み取りで動きます。修正の段階に進むと書き込み権限が必要です。読み取り専用の資格情報で動かせば、点検で止まります。それが一番安全な使い方です。
出てきたチェックリストは信用できますか
Azure Resource Graph の実データを見た結果なので、いまの構成がどうなっているかは事実として読めます。一方で「どう直すべきか」は Microsoft の推奨に沿った一般論です。自分の要件（許容できる停止時間、予算）と突き合わせてください。