zhongwei/gh-windschord-claude-skils-operations-design

Files

Zhongwei Li ebf56024dd Initial commit

2025-11-30 09:06:28 +08:00

42 KiB

Raw Blame History

運用設計書

ドキュメント情報

項目	内容
ドキュメント名	[サービス名] 運用設計書
バージョン	[バージョン番号]
作成日	[YYYY-MM-DD]
最終更新日	[YYYY-MM-DD]
作成者	[作成者名]
承認者	[承認者名]
ステータス	[Draft / Review / Approved]

改訂履歴

バージョン	日付	変更内容	変更者
0.1	YYYY-MM-DD	初版作成	[名前]

1. 概要

1.1 目的

本ドキュメントの目的を記載します。

運用に求められる要件の明確化
システム運用に関わる関係者間の合意形成
運用プロセスの標準化と最適化
運用品質の向上と継続的改善

1.2 対象範囲

本運用設計書が対象とするシステム・サービスの範囲を記載します。

対象システム:

[システム名・サービス名]

対象業務:

[業務名]

対象期間:

[運用開始予定日] ～ [運用終了予定日（該当する場合）]

1.3 前提条件

運用設計における前提条件を記載します。

システム開発が完了していること
運用環境が構築されていること
運用チームの体制が整っていること
[その他の前提条件]

1.4 制約条件

運用における制約事項を記載します。

予算制約: [金額や制約内容]
リソース制約: [人員やインフラリソースの制約]
技術制約: [技術的な制約]
法規制・コンプライアンス: [該当する法規制]

2. サービス概要

2.1 サービスの目的

サービスが提供する価値と目的を記載します。

ビジネス目的:

[ビジネス上の目的]

提供価値:

[ユーザーに提供する価値]

2.2 サービスの機能

主要な機能を記載します。

機能名	概要	重要度
[機能1]	[機能の説明]	High / Medium / Low
[機能2]	[機能の説明]	High / Medium / Low

2.3 システム構成

システムのアーキテクチャと主要コンポーネントを記載します。

アーキテクチャ図:

graph TB
    subgraph "ユーザー層"
        User[エンドユーザー]
    end

    subgraph "アプリケーション層"
        Web[Webサーバー]
        App[アプリケーションサーバー]
    end

    subgraph "データ層"
        DB[(データベース)]
        Cache[(キャッシュ)]
    end

    User --> Web
    Web --> App
    App --> DB
    App --> Cache

主要コンポーネント:

コンポーネント	役割	技術スタック	冗長化
[コンポーネント1]	[役割]	[技術]	Yes / No
[コンポーネント2]	[役割]	[技術]	Yes / No

2.4 外部連携

外部システムとの連携を記載します。

連携先	連携方式	データフロー	重要度
[システム名]	API / Batch / etc	[方向と内容]	High / Medium / Low

3. 運用方針と目標

3.1 運用基本方針

運用における基本的な方針を記載します。

可用性重視: [方針の詳細]
セキュリティ優先: [方針の詳細]
継続的改善: [方針の詳細]
コスト最適化: [方針の詳細]

3.2 サービスレベル目標（SLO）

【重要】ユーザー中心のSLO設計原則:

SLOは「測りやすい指標」ではなく、「ユーザーが快適に使える範囲」を起点として設計します。

設計アプローチ:

ユーザーの期待値を理解する
- ユーザーはどの程度の応答速度を期待しているか
- どの程度のエラーなら許容できるか
- サービス停止はどの程度の影響を与えるか
ユーザー体験に基づいた目標設定
- 「サーバーCPU使用率」ではなく「ユーザーが体感するレスポンスタイム」
- 「データベース接続数」ではなく「ユーザーがエラーに遭遇する頻度」
- 技術指標はユーザー体験指標の裏付けとして使用
システム構成ごとの目標設定
- 同期処理、非同期処理、バッチ処理でユーザー期待値は異なる
- それぞれに適切な目標値を設定

SLO定義:

システム構成/機能	指標名	目標値	ユーザー視点での意味	測定方法	測定頻度
[全体]	可用性	[例: 99.9%]	ユーザーがサービスを利用できる時間の割合	[測定方法]	[頻度]
[Web同期リクエスト]	レスポンスタイム（P95）	[例: 500ms以下]	ユーザーが操作後に結果が表示されるまでの体感速度	[測定方法]	[頻度]
[Web同期リクエスト]	エラーレート	[例: 0.1%以下]	ユーザーがエラーに遭遇する頻度	[測定方法]	[頻度]
[非同期APIリクエスト]	処理完了時間（P95）	[例: 5秒以内]	バックグラウンド処理が完了するまでの時間	[測定方法]	[頻度]
[バッチ処理]	処理完了時刻	[例: 翌朝8時まで]	業務開始時にデータが利用可能になっている状態	[測定方法]	日次
[全体]	MTTR	[例: 30分以内]	障害発生時にユーザーが待つ時間	[測定方法]	[頻度]

3.3 サービスレベル指標（SLI）

SLOを測定するための具体的な指標を記載します。

SLI名	定義	データソース	計算式
[SLI1]	[定義]	[ソース]	[計算式]
[SLI2]	[定義]	[ソース]	[計算式]

3.4 サービスレベル合意（SLA）

顧客またはユーザーに対して約束するサービス品質の基準を記載します。

SLA策定の重要性:

SLOとSLIに基づいた実現可能な目標設定
顧客期待値の明確化
サービス品質保証の根拠
違約時の対応方針の明確化

SLA定義:

システム構成/機能	SLA項目	保証値	測定方法	測定期間	未達時の対応
[全体]	サービス可用性	[例: 99.9%]	[測定方法]	月次	[対応内容]
[Web同期リクエスト]	レスポンスタイム（P95）	[例: 500ms以下]	[測定方法]	月次	[対応内容]
[非同期APIリクエスト]	処理完了時間（P95）	[例: 5秒以内]	[測定方法]	月次	[対応内容]
[バッチ処理]	処理完了時刻	[例: 翌朝8時まで]	[測定方法]	日次	[対応内容]

システム構成別のSLA設定指針:

同期的なWebリクエスト（ユーザー対話操作）
- ユーザーが快適に操作できる範囲を基準とする
- レスポンスタイム: 一般的に500ms以下（P95）
- エラーレート: 0.1%以下
非同期APIリクエスト（バックグラウンド処理）
- ユーザー体験に直接影響しない範囲で設定
- 処理完了時間: 数秒〜数十秒
- 再試行ポリシーを含む
バッチ処理（夜間処理等）
- 業務開始時刻までの完了を保証
- 処理時間: 数時間単位
- 失敗時の再実行ポリシー

SLA未達時のペナルティまたは対応:

サービスクレジット: [内容]
エスカレーション: [プロセス]
改善計画の提出: [内容]

3.5 エラーバジェット

許容されるエラーの範囲を定義します。

エラーバジェット算出:

可用性目標: 99.9%
許容ダウンタイム（月間）: [計算結果]
エラーバジェット消費の閾値: [閾値]

エラーバジェットポリシー:

エラーバジェット残量 > 50%: [対応方針]
エラーバジェット残量 20-50%: [対応方針]
エラーバジェット残量 < 20%: [対応方針]

4. 運用体制

4.1 運用組織体制

運用組織の体制を記載します。

graph TB
    Manager[運用マネージャー]

    Manager --> Team1[運用チーム1]
    Manager --> Team2[運用チーム2]
    Manager --> Team3[SREチーム]

    Team1 --> Ops1[オペレーター1]
    Team1 --> Ops2[オペレーター2]

    Team2 --> Ops3[オペレーター3]
    Team2 --> Ops4[オペレーター4]

    Team3 --> SRE1[SREエンジニア1]
    Team3 --> SRE2[SREエンジニア2]

4.2 役割と責任（RACI）

主要な運用プロセスにおける役割と責任を記載します。

プロセス/タスク	運用マネージャー	運用チーム	SREチーム	開発チーム	備考
監視・アラート対応	A	R	C	I	[備考]
インシデント対応	A	R	C	C	[備考]
変更管理	A	I	C	R	[備考]
リリース管理	A	C	R	R	[備考]

※ R=Responsible（実行責任）, A=Accountable（説明責任）, C=Consulted（相談）, I=Informed（報告）

4.3 運用時間帯

運用体制の時間帯を記載します。

時間帯	運用体制	対応内容
平日 9:00-18:00	通常体制	[対応内容]
平日 18:00-9:00	オンコール体制	[対応内容]
休日・祝日	オンコール体制	[対応内容]

オンコール体制:

1次対応: [担当者・連絡先]
2次対応: [担当者・連絡先]
エスカレーション先: [担当者・連絡先]

4.4 コミュニケーション

運用におけるコミュニケーション方法を記載します。

定例会議:

会議名	頻度	参加者	目的
日次運用会議	毎日	[参加者]	[目的]
週次運用レビュー	毎週	[参加者]	[目的]
月次運用報告	毎月	[参加者]	[目的]

コミュニケーションツール:

チャット: [ツール名・チャンネル]
チケット管理: [ツール名]
ドキュメント共有: [ツール名]
インシデント管理: [ツール名]

5. 運用スケジュール

5.1 定期運用スケジュール

定期的に実施する運用作業のスケジュールを記載します。

作業項目	頻度	実施日時	担当	所要時間
[作業1]	日次	[時刻]	[担当]	[時間]
[作業2]	週次	[曜日・時刻]	[担当]	[時間]
[作業3]	月次	[日・時刻]	[担当]	[時間]

5.2 メンテナンスウィンドウ

計画メンテナンスの実施可能時間帯を記載します。

定期メンテナンス:

頻度: [週次/月次/四半期等]
実施日時: [曜日・時刻]
所要時間: [時間]
影響範囲: [影響内容]

緊急メンテナンス:

実施判断基準: [基準]
承認プロセス: [プロセス]
通知方法: [通知手段]

5.3 年間運用カレンダー

年間の主要イベントとメンテナンススケジュールを記載します。

月	イベント/作業	詳細
1月	[イベント]	[詳細]
2月	[イベント]	[詳細]
...	...	...

6. 定常運用作業

6.1 日次運用作業

毎日実施する運用作業を記載します。

7.1.1 [作業名1]

目的: [作業の目的]

実施タイミング: [時刻]

手順:

[手順1]
[手順2]
[手順3]

確認項目:

[確認項目1]
[確認項目2]

成果物: [成果物があれば記載]

エスカレーション基準: [異常時の対応]

7.1.2 [作業名2]

[同様の形式で記載]

6.2 週次運用作業

週単位で実施する運用作業を記載します。

7.2.1 [作業名]

[日次作業と同様の形式で記載]

6.3 月次運用作業

月単位で実施する運用作業を記載します。

7.3.1 [作業名]

[日次作業と同様の形式で記載]

7. 監視・通知

7.1 監視方針

【重要】ユーザー中心の監視設計原則:

監視は「測りやすい技術指標」ではなく、「ユーザーが快適に使える状態」を維持するために実施します。

監視設計アプローチ:

ユーザー体験起点の監視
- まず「ユーザーが体感する品質」を監視
- 技術指標はユーザー体験指標が悪化した時の原因特定に使用
- 例: レスポンスタイムの悪化を検知 → CPU使用率を確認して原因を特定
外形監視を最優先
- ユーザーと同じ視点でサービスを監視
- エンドツーエンドの動作確認
- 実際のユーザートランザクションをシミュレート
システム構成ごとの監視基準
- 同期処理、非同期処理、バッチ処理で監視基準を分ける
- それぞれのユーザー期待値に基づいた閾値設定

監視の目的:

第一目的: ユーザーが快適に利用できる状態の維持
サービスの可用性確保
パフォーマンス劣化の早期検知（ユーザー体感品質の観点から）
セキュリティインシデントの検知
キャパシティ不足の予兆検知

監視レベル:

レベル1（Critical）: ユーザーに直接影響がある状態 [具体的な定義と対応]
レベル2（Warning）: ユーザーへ影響が及ぶ可能性のある状態 [具体的な定義と対応]
レベル3（Info）: ユーザーに影響はないが注視すべき状態 [具体的な定義と対応]

7.2 監視項目

【重要】監視項目の優先順位:

優先度1: ユーザー体験監視（SLI直結）

ユーザーが直接体感する品質指標
これらが正常であればサービスは正常

優先度2: アプリケーション監視

ユーザー体験指標の裏付け
問題発生時の原因特定用

優先度3: インフラ監視

アプリケーション指標の裏付け
キャパシティ管理用

監視項目定義:

優先度	監視対象	監視項目	閾値	監視間隔	アラートレベル	ユーザー視点での意味
1	外形監視（Web同期）	レスポンスタイム（P95）	500ms超	1分	Warning	ユーザーが遅いと感じる
1	外形監視（Web同期）	レスポンスタイム（P95）	1000ms超	1分	Critical	ユーザーがストレスを感じる
1	外形監視（Web同期）	エラーレート	0.1%超	1分	Warning	ユーザーがエラーに遭遇し始める
1	外形監視（Web同期）	エラーレート	1%超	1分	Critical	多数のユーザーがエラーに遭遇
1	外形監視（非同期API）	処理完了時間（P95）	5秒超	5分	Warning	バックグラウンド処理の遅延
1	外形監視（バッチ）	処理完了時刻	7:00以降	1時間	Warning	業務開始に間に合わない可能性
1	外形監視（バッチ）	処理完了時刻	8:00以降	1時間	Critical	業務開始に間に合わない
2	アプリケーション	エラーレート	[閾値]	1分	[レベル]	アプリケーションレベルのエラー発生状況
2	アプリケーション	レスポンスタイム	[閾値]	1分	[レベル]	アプリケーション処理時間
3	Webサーバー	CPU使用率	80%超	1分	Info	リソース逼迫の予兆
3	Webサーバー	CPU使用率	90%超	1分	Warning	リソース逼迫
3	Webサーバー	メモリ使用率	[閾値]	[間隔]	[レベル]	メモリリソース状況
3	データベース	接続数	[閾値]	[間隔]	[レベル]	DB接続リソース状況

システム構成別の監視設計:

同期的なWebリクエスト
- ユーザーは即座に結果を期待
- レスポンスタイム: P95で500ms以下を目標
- 監視間隔: 1分（迅速な検知が必要）
非同期APIリクエスト
- ユーザーは数秒の待機は許容
- 処理完了時間: P95で5秒以内を目標
- 監視間隔: 5分（ある程度の猶予あり）
バッチ処理
- ユーザーは完了時刻を期待
- 処理完了時刻: 業務開始時刻まで
- 監視間隔: 1時間（処理時間が長いため）

7.3 ログ管理

ログの収集・保管・分析方針を記載します。

ログ種類:

ログ種類	出力先	保管期間	用途
アクセスログ	[保存先]	[期間]	[用途]
アプリケーションログ	[保存先]	[期間]	[用途]
エラーログ	[保存先]	[期間]	[用途]
セキュリティログ	[保存先]	[期間]	[用途]

ログ分析:

ツール: [ツール名]
分析頻度: [頻度]
分析内容: [内容]

7.4 アラート通知

アラート通知のルールと方法を記載します。

通知ルート:

graph LR
    Alert[アラート発生] --> Level{レベル判定}

    Level -->|Critical| Notify1[即時通知<br/>電話+メール+チャット]
    Level -->|Warning| Notify2[メール+チャット]
    Level -->|Info| Notify3[チャットのみ]

    Notify1 --> Oncall[オンコール担当]
    Notify2 --> Team[運用チーム]
    Notify3 --> Log[ログ記録]

通知先:

アラートレベル	通知方法	通知先	対応時間
Critical	電話+メール+チャット	[通知先]	即時
Warning	メール+チャット	[通知先]	30分以内
Info	チャット	[通知先]	営業時間内

8. インシデント管理

8.1 インシデント定義

インシデントの定義と分類を記載します。

インシデント定義: サービスの計画外の中断、またはサービス品質の低下

インシデント分類:

優先度	定義	対応目標時間	例
P1（Critical）	サービス全停止	15分以内に対応開始	[例]
P2（High）	主要機能停止	30分以内に対応開始	[例]
P3（Medium）	一部機能停止	2時間以内に対応開始	[例]
P4（Low）	軽微な問題	営業時間内対応	[例]

8.2 インシデント対応フロー

インシデント対応の標準フローを記載します。

graph TD
    Start[インシデント検知] --> Triage[トリアージ]
    Triage --> Priority{優先度判定}

    Priority -->|P1/P2| Urgent[緊急対応]
    Priority -->|P3/P4| Normal[通常対応]

    Urgent --> Investigate1[原因調査]
    Normal --> Investigate2[原因調査]

    Investigate1 --> Fix1[復旧作業]
    Investigate2 --> Fix2[修正作業]

    Fix1 --> Verify1[動作確認]
    Fix2 --> Verify2[動作確認]

    Verify1 --> Close1[インシデントクローズ]
    Verify2 --> Close2[インシデントクローズ]

    Close1 --> Postmortem[ポストモーテム]
    Close2 --> Review[レビュー]

8.3 インシデント対応手順

インシデント対応の詳細手順を記載します。

9.3.1 検知・報告

検知方法:

監視アラート
ユーザー報告
運用チーム発見

報告フロー:

インシデント管理ツールにチケット作成
運用チームに通知
優先度に応じてエスカレーション

9.3.2 トリアージ

トリアージ基準:

影響範囲（全ユーザー / 一部ユーザー / 特定機能）
ビジネスインパクト（売上損失 / 信用失墜 / 軽微）
緊急度（即時対応必要 / 計画的対応可能）

優先度判定: [優先度判定のマトリクスやルール]

9.3.3 対応・復旧

対応原則:

まず復旧、原因究明は後
影響範囲の最小化を優先
コミュニケーションを密に

復旧手順:

[手順1]
[手順2]
[手順3]

9.3.4 ポストモーテム

実施タイミング:

P1/P2インシデント: 必須
P3インシデント: 必要に応じて
P4インシデント: 任意

ポストモーテム内容:

インシデントサマリー
影響範囲と期間
根本原因分析（なぜなぜ分析）
再発防止策
アクションアイテム

8.4 エスカレーション

エスカレーションルールを記載します。

エスカレーション基準:

対応開始から[X]分経過しても復旧しない
影響範囲が拡大している
技術的な判断が必要
ビジネス判断が必要

エスカレーションパス:

graph TB
    L1[L1: 運用担当者] -->|15分| L2[L2: 運用リーダー]
    L2 -->|30分| L3[L3: 運用マネージャー]
    L3 -->|60分| L4[L4: 開発チーム]
    L3 -->|重大影響| L5[L5: 経営層]

9. 変更管理

9.1 変更管理方針

変更管理の基本方針を記載します。

変更管理の目的:

変更に伴うリスクの最小化
変更の影響評価と承認プロセスの明確化
変更履歴の記録と追跡可能性の確保

変更の定義: 本番環境への以下の変更を対象とします

システム構成の変更
アプリケーションのデプロイ
インフラ設定の変更
セキュリティ設定の変更

9.2 変更分類

変更の種類と承認プロセスを記載します。

変更分類	定義	承認者	リードタイム
標準変更	手順化済みの低リスク変更	運用リーダー	即時
通常変更	一般的な変更	運用マネージャー	3営業日
緊急変更	緊急対応が必要な変更	運用マネージャー	即時
重要変更	高リスクまたは大規模な変更	変更諮問委員会	1週間

9.3 変更管理フロー

変更管理のプロセスを記載します。

graph TD
    Request[変更要求] --> Classification{変更分類}

    Classification -->|標準| Approve1[自動承認]
    Classification -->|通常| Review1[レビュー]
    Classification -->|緊急| Review2[緊急レビュー]
    Classification -->|重要| CAB[CAB審査]

    Review1 --> Approve2[承認]
    Review2 --> Approve3[承認]
    CAB --> Approve4[承認]

    Approve1 --> Plan[実施計画]
    Approve2 --> Plan
    Approve3 --> Plan
    Approve4 --> Plan

    Plan --> Implement[変更実施]
    Implement --> Verify[検証]
    Verify --> Close[クローズ]

    Verify -->|失敗| Rollback[ロールバック]
    Rollback --> Review3[原因分析]

9.4 変更実施手順

変更を実施する際の標準手順を記載します。

事前準備:

変更チケットの作成
変更内容の詳細記載
影響評価の実施
ロールバック計画の作成
承認取得

実施時:

事前バックアップの取得
変更作業の実施
作業ログの記録
動作確認の実施

事後:

変更結果の報告
ドキュメントの更新
チケットのクローズ

9.5 ロールバック計画

ロールバックの基準と手順を記載します。

ロールバック判断基準:

変更後の動作確認でエラーが検出された
SLOを下回る性能劣化が発生した
予期しない副作用が発生した
[その他の基準]

ロールバック手順:

[手順1]
[手順2]
[手順3]

10. リリース管理

10.1 リリース方針

リリースの基本方針を記載します。

リリース原則:

定期リリースと緊急リリースの明確な区別
本番環境へのリリース前の十分なテスト
段階的なロールアウト（カナリアリリース等）
自動化されたデプロイメントプロセス

10.2 リリーススケジュール

定期リリースのスケジュールを記載します。

リリース種別	頻度	実施日時	対象
メジャーリリース	四半期毎	[日時]	大規模機能追加
マイナーリリース	月次	[日時]	機能改善
パッチリリース	週次	[日時]	バグフィックス
ホットフィックス	随時	随時	緊急対応

10.3 リリースフロー

リリースプロセスを記載します。

graph LR
    Dev[開発環境] --> Test[テスト環境]
    Test --> Staging[ステージング環境]
    Staging --> Canary[カナリア環境]
    Canary --> Prod[本番環境]

    Test -.->|NG| Dev
    Staging -.->|NG| Dev
    Canary -.->|NG| Rollback[ロールバック]

各環境の役割:

開発環境: 機能開発とユニットテスト
テスト環境: 結合テストと品質保証
ステージング環境: 本番環境と同等構成での最終確認
カナリア環境: 一部ユーザーでの先行リリース
本番環境: 全ユーザー向けリリース

10.4 デプロイメント戦略

デプロイメント方式を記載します。

採用戦略: [選択した戦略]

デプロイメント方式の比較:

方式	メリット	デメリット	採用判断
Blue-Green	ダウンタイムゼロ	リソース2倍必要	[○/×]
Rolling	リソース効率的	段階的な切り替え	[○/×]
Canary	リスク最小化	複雑な制御必要	[○/×]

自動化ツール:

CI/CDツール: [ツール名]
デプロイツール: [ツール名]
インフラ管理: [ツール名]

11. バックアップ・リカバリ

11.1 バックアップ方針

バックアップの基本方針を記載します。

バックアップ目的:

データ損失時の復旧
ランサムウェア等のセキュリティインシデント対応
監査・コンプライアンス要件への対応

バックアップ原則:

3-2-1ルール: 3つのコピー、2つの異なるメディア、1つはオフサイト
暗号化されたバックアップの保管
定期的なリストアテストの実施

11.2 バックアップ設計

バックアップ対象と方式を記載します。

バックアップ対象	バックアップ方式	頻度	世代管理	保管場所
データベース	フル+差分	日次フル+6時間毎差分	30世代	[場所]
ファイルストレージ	フル	日次	7世代	[場所]
システム設定	フル	変更時	10世代	[場所]
ログファイル	増分	1時間毎	90日	[場所]

バックアップスケジュール:

gantt
    title バックアップスケジュール（1日）
    dateFormat HH:mm
    axisFormat %H:%M

    section データベース
    フルバックアップ    :00:00, 2h
    差分バックアップ1   :06:00, 30m
    差分バックアップ2   :12:00, 30m
    差分バックアップ3   :18:00, 30m

    section ファイル
    フルバックアップ    :02:00, 1h

11.3 リカバリ設計

リカバリの目標値と手順を記載します。

リカバリ目標:

対象	RPO（目標復旧時点）	RTO（目標復旧時間）
データベース	6時間以内	4時間以内
ファイルストレージ	24時間以内	2時間以内
システム全体	24時間以内	8時間以内

リカバリ手順:

データベースリカバリ

[手順1]
[手順2]
[手順3]

リカバリテスト:

頻度: 四半期毎
対象: [テスト対象]
成功基準: [基準]

11.4 災害対策（DR）

災害復旧計画を記載します。

DR方針:

DR サイト: [有/無]
DR 構成: [Hot Standby / Warm Standby / Cold Standby]

DR切り替えシナリオ:

シナリオ	発生条件	切り替え判断	切り替え時間目標
データセンター障害	[条件]	[判断基準]	[時間]
リージョン障害	[条件]	[判断基準]	[時間]

12. セキュリティ運用

12.1 セキュリティ運用方針

セキュリティ運用の基本方針を記載します。

セキュリティ原則:

多層防御（Defense in Depth）
最小権限の原則
ゼロトラストアーキテクチャ
継続的なセキュリティ監視

12.2 アクセス管理

アクセス権限の管理方針を記載します。

権限管理:

ロール	権限範囲	承認者	レビュー頻度
システム管理者	全権限	[承認者]	月次
運用担当者	運用操作のみ	[承認者]	月次
開発者	開発環境のみ	[承認者]	月次
閲覧者	読み取りのみ	[承認者]	四半期

アクセスレビュー:

頻度: [頻度]
実施者: [担当者]
レビュー内容: [内容]

12.3 脆弱性管理

脆弱性の検出と対応プロセスを記載します。

脆弱性スキャン:

ツール: [ツール名]
頻度: [頻度]
対象: [対象システム]

パッチ適用:

脆弱性レベル	対応期限	承認プロセス
Critical	24時間以内	緊急変更
High	7日以内	通常変更
Medium	30日以内	通常変更
Low	90日以内	計画変更

12.4 セキュリティインシデント対応

セキュリティインシデントの対応手順を記載します。

セキュリティインシデント分類:

レベル	定義	例	対応時間
L1	重大な侵害	データ漏洩、ランサムウェア	即時
L2	侵害の疑い	不正アクセス試行	1時間以内
L3	セキュリティ違反	ポリシー違反	24時間以内

対応フロー:

graph TD
    Detect[検知] --> Contain[封じ込め]
    Contain --> Eradicate[根絶]
    Eradicate --> Recover[復旧]
    Recover --> PostIncident[事後対応]
    PostIncident --> Improve[改善]

インシデント対応チーム（CSIRT）:

リーダー: [担当者]
メンバー: [担当者リスト]
外部連絡先: [セキュリティベンダー、警察等]

12.5 コンプライアンス

法規制・コンプライアンス要件への対応を記載します。

適用法規制:

監査対応:

内部監査: [頻度・実施者]
外部監査: [頻度・監査法人]
証跡管理: [保管方法・期間]

13. キャパシティ管理

13.1 キャパシティ管理方針

キャパシティ管理の基本方針を記載します。

キャパシティ管理の目的:

サービス品質の維持
コストの最適化
将来の需要予測と計画

13.2 キャパシティ監視

監視対象リソースと閾値を記載します。

リソース	現在の使用率	警告閾値	限界閾値	対応アクション
CPU	[%]	70%	85%	[アクション]
メモリ	[%]	75%	90%	[アクション]
ディスク	[%]	80%	90%	[アクション]
ネットワーク帯域	[%]	70%	85%	[アクション]

13.3 キャパシティ計画

将来の需要予測と増強計画を記載します。

需要予測:

期間	予想ユーザー数	予想トラフィック	必要リソース
3ヶ月後	[数値]	[数値]	[内容]
6ヶ月後	[数値]	[数値]	[内容]
1年後	[数値]	[数値]	[内容]

増強計画:

実施時期: [時期]
増強内容: [内容]
見積もりコスト: [金額]

13.4 スケーリング戦略

スケーリングの方針と実装を記載します。

スケーリング方式:

垂直スケーリング（スケールアップ）: [適用箇所]
水平スケーリング（スケールアウト）: [適用箇所]

オートスケーリング設定:

対象	スケールアウト条件	スケールイン条件	最小/最大インスタンス数
[対象1]	[条件]	[条件]	[最小数]/[最大数]
[対象2]	[条件]	[条件]	[最小数]/[最大数]

14. コスト管理

14.1 コスト管理方針

コスト管理の基本方針を記載します。

コスト管理の目的:

予算内での運用実現
コスト効率の最適化
コスト可視化と予測

14.2 コスト構造

運用コストの内訳を記載します。

コスト項目	月額コスト	年額コスト	備考
インフラコスト	[金額]	[金額]	[内訳]
ライセンスコスト	[金額]	[金額]	[内訳]
人件費	[金額]	[金額]	[内訳]
外部委託費	[金額]	[金額]	[内訳]
その他	[金額]	[金額]	[内訳]
合計	[金額]	[金額]

14.3 コスト最適化施策

コスト削減・最適化の取り組みを記載します。

実施中の施策:

計画中の施策:

14.4 コスト監視

コストの監視とアラート設定を記載します。

コスト監視:

ツール: [ツール名]
監視頻度: [頻度]
レポート: [頻度・宛先]

コストアラート:

月次予算超過アラート: [閾値]
異常なコスト増加アラート: [条件]

15. 問題管理

15.1 問題管理方針

問題管理の基本方針を記載します。

問題の定義: 1つ以上のインシデントの根本原因、または潜在的なインシデントの原因

問題管理の目的:

インシデントの根本原因の特定と除去
既知のエラーの記録と回避策の提供
再発防止策の実装

15.2 問題管理プロセス

問題管理のフローを記載します。

graph TD
    Incident[インシデント発生] --> Analysis[傾向分析]
    Analysis --> Problem{問題として<br/>管理すべきか？}

    Problem -->|Yes| Register[問題登録]
    Problem -->|No| End1[終了]

    Register --> Investigate[根本原因分析]
    Investigate --> Known[既知のエラー登録]

    Known --> Workaround[回避策の提供]
    Known --> Solution[恒久対策の検討]

    Solution --> Implement[対策実装]
    Implement --> Verify[効果検証]
    Verify --> Close[クローズ]

15.3 既知のエラー管理

既知のエラーと回避策を記録します。

エラーID	問題概要	影響	回避策	恒久対策の状況
KE-001	[概要]	[影響]	[回避策]	[状況]
KE-002	[概要]	[影響]	[回避策]	[状況]

16. ナレッジ管理

16.1 ナレッジ管理方針

ナレッジの蓄積と共有の方針を記載します。

ナレッジ管理の目的:

運用ノウハウの蓄積と継承
問題解決の効率化
属人化の排除

16.2 ドキュメント体系

管理するドキュメントの種類と保管場所を記載します。

ドキュメント種別	保管場所	更新頻度	管理者
運用設計書	[場所]	[頻度]	[担当]
運用手順書	[場所]	[頻度]	[担当]
障害対応手順書	[場所]	[頻度]	[担当]
FAQ	[場所]	[頻度]	[担当]
ポストモーテム	[場所]	都度	[担当]

16.3 ドキュメント管理ルール

ドキュメントの作成・更新・レビューのルールを記載します。

作成ルール:

テンプレートの使用
命名規則の遵守
バージョン管理の実施

更新ルール:

変更履歴の記録
レビュープロセスの実施
関連ドキュメントの同期更新

レビュープロセス:

レビュー頻度: [頻度]
レビュー担当: [担当者]
レビュー基準: [基準]

17. 継続的改善

17.1 改善活動方針

継続的改善の基本方針を記載します。

改善の原則:

データドリブンな意思決定
小さな改善の積み重ね
チーム全体での取り組み
定期的な振り返りと学び

17.2 改善プロセス

改善活動のサイクルを記載します。

graph LR
    Plan[計画<br/>Plan] --> Do[実行<br/>Do]
    Do --> Check[評価<br/>Check]
    Check --> Act[改善<br/>Act]
    Act --> Plan

改善活動の実施:

週次: チーム振り返り
月次: メトリクスレビュー
四半期: 運用プロセスレビュー
年次: 運用戦略レビュー

17.3 運用メトリクス

運用品質を測定する指標を記載します。

メトリクス	目標値	測定方法	レポート頻度
可用性	99.9%以上	[方法]	月次
MTBF（平均故障間隔）	[目標]	[方法]	月次
MTTR（平均復旧時間）	30分以内	[方法]	月次
変更成功率	95%以上	[方法]	月次
インシデント件数	[目標]	[方法]	月次
デプロイ頻度	[目標]	[方法]	月次

17.4 改善施策管理

改善施策の管理方法を記載します。

改善施策リスト:

施策ID	施策名	目的	担当	期限	ステータス
IMP-001	[施策名]	[目的]	[担当]	[期限]	[ステータス]
IMP-002	[施策名]	[目的]	[担当]	[期限]	[ステータス]

18. 運用ツール

18.1 運用ツール一覧

使用する運用ツールを記載します。

カテゴリ	ツール名	用途	ライセンス	管理者
監視	[ツール名]	[用途]	[ライセンス]	[担当]
ログ管理	[ツール名]	[用途]	[ライセンス]	[担当]
インシデント管理	[ツール名]	[用途]	[ライセンス]	[担当]
変更管理	[ツール名]	[用途]	[ライセンス]	[担当]
CI/CD	[ツール名]	[用途]	[ライセンス]	[担当]
コミュニケーション	[ツール名]	[用途]	[ライセンス]	[担当]

18.2 ツール統合

ツール間の連携を記載します。

統合フロー:

graph LR
    Monitor[監視ツール] -->|アラート| Incident[インシデント管理]
    Incident -->|通知| Chat[チャットツール]
    Chat -->|トリガー| CICD[CI/CDツール]
    CICD -->|ログ| LogTool[ログ管理ツール]
    LogTool -->|メトリクス| Monitor

19. 付録

19.1 用語集

本ドキュメントで使用する用語の定義を記載します。

用語	定義
SLO	Service Level Objective: サービスレベル目標
SLI	Service Level Indicator: サービスレベル指標
SLA	Service Level Agreement: サービスレベル合意
MTTR	Mean Time To Repair: 平均復旧時間
MTBF	Mean Time Between Failures: 平均故障間隔
RPO	Recovery Point Objective: 目標復旧時点
RTO	Recovery Time Objective: 目標復旧時間
RACI	Responsible, Accountable, Consulted, Informed

19.2 参照ドキュメント

関連ドキュメントへのリンクを記載します。

ドキュメント名	場所/URL	備考
システム設計書	[リンク]	[備考]
セキュリティポリシー	[リンク]	[備考]
運用手順書	[リンク]	[備考]

19.3 連絡先

運用に関わる主要な連絡先を記載します。

役割	担当者	連絡先	対応時間
運用マネージャー	[名前]	[連絡先]	[時間]
オンコール担当	[名前]	[連絡先]	24/365
セキュリティ担当	[名前]	[連絡先]	[時間]

19.4 承認

本ドキュメントの承認記録を記載します。

役割	氏名	承認日
作成者	[名前]	[日付]
レビュアー	[名前]	[日付]
承認者	[名前]	[日付]