Imported from tadokoro-ryusuke/cc-plugins (dev-core/skills/reliability-sla-design/SKILL.md). Install upstream with npx skills add tadokoro-ryusuke/cc-plugins --skill reliability-sla-design. Copyright stays with the author.

Reliability & SLA Design

鉄則: 計測できないSLOは合意していないのと同じ。守れない約束は書いた瞬間に負債になる。

「システムがどのくらい止まってよいか」を顧客と合意し、それを実現するコストとのバランスを設計する。 要件定義〜基本設計で非機能要件として合意し、保守契約書のSLA条項に落とす。営業段階（提案書）から関与する。 なぜ: 可用性目標を高く約束しすぎれば守れず、低すぎれば案件を失う。この層の設計品質が保守契約の収益性と持続可能性を決める。

設計時に必ず作る成果物

• 非機能要件定義書（IPA非機能要求グレードのシートをベースにカスタマイズ）
• SLO定義書（SLI・目標値・計測方法・エラーバジェットポリシー）
• 可用性設計書（冗長構成図、SPOF=単一障害点の分析）
• バックアップ設計書（対象・方式・世代数・保管先・リストア手順）
• DR計画書（RTO/RPO、DR発動基準、復旧手順書）
• SLA条項ドラフト（保守契約書の別紙）→ 文言化・法的確認は自組織の法務・契約プロセスへ（Step 8）

Step 1: 最初に2つの数字を聞く — RTO / RPO

技術選定より先に、顧客にこの2つを聞く。 なぜ: RTO/RPOが決まるとDR方式とコストがほぼ決まる。ここを飛ばしたDR提案は根拠がない。

• 顧客は即答できないのが普通。停止1時間あたりの業務影響（売上機会・人件費・信用）を一緒に見積もって導く。
• 答えを非機能要件定義書に記録し、以降の全設計の前提として扱う。

Step 2: RTO/RPO を DR 4戦略にマッピングする

• 下へ行くほどコストは桁で増える。Step 1 の数字がどの行に落ちるかで方式を提案する。
• 中小案件の大半は Backup & Restore で十分。要求が上振れしたら Step 4 のコスト説明で顧客に選ばせる。
• なぜ: 過剰なDRは受託側の利益と運用体力を直接削る。「必要な行」を証明できることが提案の説得力になる。

Step 3: SLI / SLO / SLA の3層を分けて設計する

• SLOはSLAより必ず厳しく設定する。 なぜ: SLA違反の前にSLO警報が鳴る構造にし、契約違反を未然に防ぐため。
• エラーバジェット = 100% − SLO。SLO 99.9% なら月43分が「使ってよい不信頼性」。
• バジェット消化中の行動（リリース凍結・改善優先）を事前にポリシー化する。 なぜ: 信頼性と開発速度のトレードオフを、感覚でなく数値で運転できるようになる。

Step 4: 可用性レベルをコストとセットで顧客に選ばせる

稼働率と停止時間の換算表を必ず見せる。「99.9%」という文字列だけでは顧客は判断できない。

可用性は「9が1つ増えるとコストが約10倍」の世界（目安）。説明テンプレ:

現在の構成は稼働率◯%（月あたり最大停止◯時間）を想定しています。 これを◯%（月◯分）に上げるには◯◯（Multi-AZ化 / Warm Standby 等）が必要で、 ランニングコストは概算で約◯倍になります。可用性は9が1つ増えるとコストが約10倍になる世界です。 停止1時間あたりの業務影響額とこの差額を比較して、レベルをお選びください。

• 決めるのは顧客。選択肢と価格差を作るのが受託側の仕事。具体金額の算定は自組織の見積・価格判断プロセスで行う。
• 顧客への説明・合意形成の進め方 → delivery-core:client-alignment 参照。

Step 5: IPA非機能要求グレードで段階的にレベル合意する

• 6大項目（可用性・性能拡張性・運用保守性・移行性・セキュリティ・環境）・238メトリクスで顧客と段階的にレベルを合意する、日本の受託の事実上の標準（2026年時点の最新は2018年版・要確認）。
• 「社会的影響が小さい/大きい/極めて大きい」の3モデル系から出発し、モデルとの差分だけ議論する。 なぜ: ゼロから238項目を聞くと顧客が疲弊する。モデル起点なら合意が速く、抜けも防げる。
• 可用性以外の大項目はそれぞれの正本へ: 移行性 → dev-core:migration-cutover-planning、運用・保守性 → dev-core:ops-design-handover、セキュリティ → dev-core:security-by-design。
• 非機能を含む要件合意プロセス全体 → delivery-core:requirements-definition 参照。

Step 6: 冗長化はマネージドに外注し、SPOFを潰す

• 原則: 可用性はマネージドサービス（マネージドDB の Multi-AZ、サーバーレス実行基盤等）に「外注」する。 なぜ: 自前の冗長構成の面倒を見続けるのは小規模体制では守れない。SLAの裏付けはクラウド事業者のSLAで作り、自分の責任範囲を絞る。
• SPOF分析チェックリスト（可用性設計書に結果を記録する）:
  • DB（レプリカ / Multi-AZ）
  • NAT Gateway・ロードバランサ
  • TLS証明書の自動更新
  • DNS
  • 外部API・決済などの依存サービス
  • バッチ / ジョブ実行基盤
  • 「担当者本人」という SPOF（属人化・不在時の対応手段）
• ❌ よくある失敗: DBだけ冗長化して、NAT Gateway や証明書更新が SPOF のまま残る。
• インフラ構成・ネットワークの実装詳細 → dev-core:cloud-infra-network-design 参照。
• アプリ側の回復性（リトライ・タイムアウト・サーキットブレーカ）→ dev-core:resilience-design 参照。

Step 7: バックアップは 3-2-1 + イミュータブル、完了条件は「リストア成功の証跡」

• 3-2-1ルール: 3コピー・2種類の媒体・1つはオフサイト（別リージョン / 別アカウント）。
• ランサムウェア対策としてイミュータブル（削除不能）バックアップを標準にする（2024年以降の実務標準。目安・要確認）。
• バックアップ設計の完了条件は「取れていること」ではなく「リストアに成功した証跡」。 なぜ: 復元できないバックアップは存在しないのと同じ。実務で最頻出の失敗がこれ。
• リストア訓練を最低年1回実施する。カオスエンジニアリングのフル実装は通常案件では不要だが、この最小版だけは必須。

チェックリスト:

• 対象・方式・世代数・保管先がバックアップ設計書に明記されている
• 1コピーが別リージョン / 別アカウントにある
• イミュータブル設定（Object Lock 等）を検討し、採否を記録した
• リストア手順書があり、実際に実行した証跡（実施日・所要時間・結果）がある
• リストアの実測所要時間が RTO に収まっている なぜ: リストアに6時間かかるなら RTO 2時間の SLA は物理的に守れない。証跡が SLA の裏付けになる。
• 証拠ベース完了判定の一般原則 → dev-core:verify 参照。

Step 8: SLA条項は「守れる約束」だけを書く

稼働率の数字だけの SLA を書かない。必ず4点セットで設計する:

• 対応時間帯: 「平日9-18時、重大障害（Sev1）のみ時間外ベストエフォート」など、実際の稼働体制で守れる範囲から始める

• 免責事項: クラウド事業者起因の障害・事前通知した計画停止・顧客起因・不可抗力を明記する

• 上限: 返金・賠償は月額の一定割合までなど、上限を必ず設ける

• 計測方法: どの SLI でどう稼働率を算定するか（Step 9）を条項に紐付ける

• 24時間365日対応を小規模体制で SLA に書くのは自殺行為。必要とする顧客には、マネージドサービス+自動復旧+一次対応の自動化（AIエージェント / 外部一次受け）の組み合わせを提案する。 なぜ: 「守れない高SLA」より「守れる範囲を明示したSLA」の方が信頼も収益性も高い。

• AI一次対応に人間の承認・引き継ぎを挟む設計 → ai-engineering:human-in-the-loop-design 参照。

• 条項の文言化・法的リスクの最終確認は、自組織の法務・契約プロセス（必要に応じて弁護士）へ送る。本スキルの守備範囲は「技術的に守れる条件の設計」まで。

Step 9: SLI計測（外形監視）を必ずセットで実装する

• 外形監視（synthetic monitoring）を最低1本入れ、稼働率を自動計測する。SLA を合意した案件では必須の実装物として扱う。 なぜ: SLA 99.9% を謳いながら計測の仕組みがなければ、違反したかどうか誰にも分からない。計測できないSLOは合意していないのと同じ。
• SLO定義書に SLI・計測ツール・算定式・レポート先を明記する。
• 計測結果は月次報告に載せ、保守の価値を可視化する。監視設計・アラート運用・月次報告の型 → dev-core:ops-design-handover 参照。

AIがやること / 人間にしか決められないこと

なぜ分担線がここか: SLA は事業リスクの引き受けであり、守れるかどうかは受託側の稼働体制の問題。生成と一次分析はAIに任せられるが、約束の水準と発動判断はAIには決められない。

アンチパターン（見つけたら即座に指摘する）

• ❌ バックアップは取っているがリストア訓練ゼロ → Step 7
• ❌ DBだけ冗長化、NAT Gateway・証明書更新が SPOF → Step 6
• ❌ SLA 99.9% を謳うが SLI 計測の仕組みなし → Step 9
• ❌ SLO と SLA が同値（警報の余白ゼロ） → Step 3
• ❌ 対応時間帯・免責・上限のない稼働率だけの SLA → Step 8
• ❌ RTO/RPO を聞かずに DR 構成を提案 → Step 1

境界（このスキルが扱わないこと）

• 非機能を含む要件合意の進め方 → delivery-core:requirements-definition
• 顧客への説明・合意形成の技術 → delivery-core:client-alignment
• インフラ構成・ネットワーク設計 → dev-core:cloud-infra-network-design
• アプリケーションレベルの回復性パターン → dev-core:resilience-design
• 監視運用・インシデント管理・保守契約への引き継ぎ → dev-core:ops-design-handover
• 移行・カットオーバー計画 → dev-core:migration-cutover-planning
• 検証フローと証拠ベース完了判定 → dev-core:verify
• 金額・見積の算定 → 自組織の見積・価格判断プロセスへ（本スキルは倍率・桁感の説明構造まで）
• 契約文言・法的判断 → 自組織の法務・契約プロセス（弁護士確認）へ