# 運用の基本方針・体制

## 本章の目的

本章では、システムの安定運用を実現するために必要な運用体制、役割分担、責務範囲を定義する。

## 運用要件の要約

本システムの運用要件は、要件定義書に記載された以下の項目に基づく。

- **可用性要件**: 稼働率 99.9% 以上、計画停止は月次メンテナンス時のみ
- **運用時間帯**: 24時間365日のサービス提供
- **保守対応**: 平日9:00-18:00は即時対応、夜間・休日はオンコール体制
- **バックアップ**: 日次フルバックアップ、保持期間30日

詳細は要件定義書を参照。

---

## 運用体制

### 運用体制図

```mermaid
graph TB
    Owner[サービスオーナー<br/>経営層]
    Manager[運用責任者<br/>システム部長]
    
    L1[一次対応<br/>運用チーム]
    L2[二次対応<br/>保守開発チーム]
    L3[三次対応<br/>ベンダー・専門家]
    
    Monitor[監視担当<br/>24h365d]
    Ops[運用オペレーター<br/>平日日中]
    
    Owner --> Manager
    Manager --> L1
    Manager --> Monitor
    L1 --> Ops
    L1 -.エスカレーション.-> L2
    L2 -.エスカレーション.-> L3
    Monitor -.障害検知.-> L1
```

### 運用組織の役割定義

| 役割 | 責務 | 担当者/チーム | 稼働時間 |
|------|------|--------------|---------|
| サービスオーナー | 最終意思決定、予算承認、重大障害時の判断 | 経営層 | - |
| 運用責任者 | 運用全体の統括、SLA管理、改善施策の立案 | システム部長 | 平日 9:00-18:00 |
| 一次対応 | 障害の初動対応、ログ収集、切り分け | 運用チーム | 24時間365日（オンコール） |
| 二次対応 | 詳細調査、暫定対応、恒久対応の実施 | 保守開発チーム | 平日 9:00-18:00 + オンコール |
| 三次対応 | 高度な技術支援、製品バグ対応 | ベンダー・専門家 | 契約による |
| 監視担当 | システム監視、アラート対応、初期トリアージ | 監視チーム | 24時間365日 |
| 運用オペレーター | 定型作業、バッチ実行、データ投入 | 運用チーム | 平日 9:00-18:00 |

---

## 運用部門と保守・開発部門の責務分界

### 責務分界の基本原則

- **運用部門**: システムの安定稼働維持、定型作業、監視、一次対応
- **保守・開発部門**: 障害の根本原因調査、恒久対応、機能改善、リリース作業

### 詳細責務分界表

| 作業分類 | 作業内容 | 運用部門 | 保守開発部門 | 備考 |
|---------|---------|---------|-------------|------|
| **日常運用** | システム監視 | ● | - | 24h365d |
| | バッチ実行・確認 | ● | - | |
| | データ投入・修正 | ● | △ | 複雑なケースは開発部門 |
| | ユーザー問い合わせ対応 | ● | △ | 技術的内容は開発部門 |
| **障害対応** | 障害検知・初動対応 | ● | - | |
| | 切り分け・ログ収集 | ● | - | |
| | 詳細調査・根本原因分析 | △ | ● | |
| | 暫定対応実施 | ● | ● | 状況に応じて協働 |
| | 恒久対応（修正リリース） | - | ● | |
| **メンテナンス** | 定期メンテナンス計画 | ● | △ | |
| | メンテナンス作業実施 | ● | △ | 技術的作業は開発部門 |
| | パラメータ変更 | ● | △ | 影響大の場合は開発部門 |
| **リリース** | リリース計画策定 | △ | ● | |
| | リリース作業実施 | ● | ● | 協働実施 |
| | リリース後動作確認 | ● | ● | |
| **改善・最適化** | 性能チューニング | △ | ● | |
| | 運用改善提案 | ● | - | |
| | システム改善開発 | - | ● | |

凡例: ● = 主担当、△ = 支援・協力、- = 対象外

---

## 権限ロール定義

### アクセス権限マトリクス

| ロール | 本番DB<br/>参照 | 本番DB<br/>更新 | サーバー<br/>ログイン | システム<br/>設定変更 | デプロイ<br/>実行 | 監視画面<br/>閲覧 |
|--------|---------------|---------------|-------------------|-------------------|----------------|----------------|
| 監視オペレーター | - | - | - | - | - | ● |
| 運用オペレーター | ● | △ | - | - | - | ● |
| 運用管理者 | ● | ● | ● | △ | △ | ● |
| 開発者 | ● | - | ● | - | - | ● |
| 保守担当者 | ● | ● | ● | ● | ● | ● |
| システム管理者 | ● | ● | ● | ● | ● | ● |

凡例: ● = 権限あり、△ = 承認後に実施可能、- = 権限なし

### 権限管理ルール

- **最小権限の原則**: 業務遂行に必要最小限の権限のみを付与
- **職務分離**: リリース実行者と承認者を分離
- **定期レビュー**: 四半期ごとに権限設定を見直し
- **一時権限**: 緊急対応時の権限昇格は事後申請・承認必須
- **操作ログ**: すべての特権操作はログに記録し、監査対象とする

### アカウント管理

- **個人アカウント**: 運用作業は個人アカウントで実施（共有アカウント禁止）
- **システムアカウント**: バッチ・自動処理用の専用アカウント
- **緊急用アカウント**: break-glass アカウントは物理的に隔離された場所に保管
- **パスワードポリシー**: 12文字以上、90日ごとに変更、多要素認証必須

---

## コミュニケーション・報告体制

### 定例報告

| 報告種別 | 頻度 | 参加者 | 内容 |
|---------|------|-------|------|
| 日次報告 | 毎日 | 運用チーム、運用責任者 | 前日の障害・インシデント、バッチ実行結果 |
| 週次報告 | 毎週月曜 | 運用責任者、保守開発リーダー | 週間稼働状況、課題事項、対応計画 |
| 月次報告 | 毎月第1営業日 | 全関係者、サービスオーナー | SLA達成状況、月間統計、改善提案 |

### 障害時の連絡フロー

```mermaid
graph LR
    A[障害検知] --> B{重大度判定}
    B -->|Critical| C[即時エスカレーション<br/>運用責任者+開発リーダー]
    B -->|High| D[1時間以内に<br/>運用責任者へ報告]
    B -->|Medium| E[4時間以内に<br/>定例報告で共有]
    B -->|Low| F[翌営業日<br/>定例報告で共有]
    
    C --> G[サービスオーナーへ報告<br/>影響大の場合]
```

### 連絡手段

- **即時連絡**: Slack（#alert-critical チャンネル）、電話、SMS
- **通常連絡**: Slack（#ops-general チャンネル）、メール
- **記録**: チケットシステム（JIRA Service Management）に全件記録

---

## SLA・KPI管理

### SLA（Service Level Agreement）

| 指標 | 目標値 | 測定方法 |
|------|--------|---------|
| 稼働率 | 99.9% 以上 | 月間総時間 - 障害停止時間 / 月間総時間 |
| 障害対応時間（Critical） | 15分以内に初動対応開始 | 検知時刻 - 対応開始時刻 |
| 障害復旧時間（Critical） | 4時間以内 | 検知時刻 - 復旧完了時刻 |
| バッチ実行成功率 | 99.5% 以上 | 成功ジョブ数 / 総ジョブ数 |

### KPI（Key Performance Indicator）

| 指標 | 目標値 | 確認頻度 |
|------|--------|---------|
| MTBF（平均故障間隔） | 720時間以上 | 月次 |
| MTTR（平均復旧時間） | 2時間以内 | 月次 |
| インシデント件数 | 月10件以下 | 月次 |
| 変更失敗率 | 5%以下 | 月次 |
| 計画外停止時間 | 月2時間以内 | 月次 |

### 測定・報告

- 月次でSLA・KPIを集計し、運用責任者が経営層へ報告
- 目標未達の場合は原因分析と改善計画を策定
- 四半期ごとにSLA・KPIの妥当性を見直し

---

## 運用ドキュメント管理

### ドキュメント体系

```mermaid
graph TD
    A[運用ドキュメント] --> B[設計書]
    A --> C[手順書]
    A --> D[記録]
    
    B --> B1[基本設計書]
    B --> B2[詳細設計書]
    B --> B3[運用設計書]
    
    C --> C1[運用手順書]
    C --> C2[障害対応手順書]
    C --> C3[リリース手順書]
    C --> C4[バックアップ・リストア手順書]
    
    D --> D1[運用日誌]
    D --> D2[障害報告書]
    D --> D3[変更管理記録]
    D --> D4[定期点検記録]
```

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

- **保管場所**: Confluence、SharePoint などの文書管理システム
- **バージョン管理**: すべてのドキュメントはバージョン番号と更新日を明記
- **レビュー**: 年1回または重大変更時にドキュメントの妥当性を確認
- **アクセス権**: 役割に応じたアクセス権を設定（読取専用 / 編集可能）

---

## 教育・訓練計画

### 教育プログラム

| 対象 | 内容 | 頻度 | 実施方法 |
|------|------|------|---------|
| 新規運用担当者 | システム概要、運用手順、ツール操作 | 着任時 | OJT + e-learning |
| 全運用担当者 | 障害対応シミュレーション | 半期に1回 | 演習 |
| 全運用担当者 | セキュリティ教育 | 年1回 | e-learning |
| 運用責任者 | インシデント管理、エスカレーション | 年1回 | 研修 |

### 訓練計画

- **障害対応訓練**: 年2回、想定シナリオに基づく障害対応演習を実施
- **リリース訓練**: リリース前に本番環境を模した環境でリハーサル実施
- **DR訓練**: 年1回、災害復旧シナリオに基づく訓練を実施

---

## 継続的改善

### 改善活動の流れ

```mermaid
graph LR
    A[運用実績の収集] --> B[問題点の抽出]
    B --> C[改善施策の立案]
    C --> D[承認・実施]
    D --> E[効果測定]
    E --> A
```

### 改善提案の受付

- 運用担当者は日常業務で気づいた改善点を随時提案
- 月次運用会議で改善提案を審議し、優先度を決定
- 承認された改善施策は四半期計画に組み込む

### 振り返り（ポストモーテム）

- 重大インシデント発生時は事後レビューを実施
- 原因分析、対応の評価、再発防止策を文書化
- 得られた知見は運用手順書・FAQ に反映

---