# 運用・保守性（Operability & Maintainability）

## 運用・保守性の基本方針

システムを安定的かつ効率的に運用し、将来にわたって保守性を維持するためのインフラ・ミドルウェア戦略を以下に示す。

### 運用監視方針
- **統合監視体制**: インフラ、ミドルウェアの稼働状況を一元的に監視し、異常を早期に検知
- **自動化されたアラート**: 閾値に基づき自動でアラートを発報し、担当者へ通知
- **ログの一元管理**: 全てのシステムログを中央集約し、迅速な原因究明を可能にする

### バックアップ・リカバリ方針
- **自動バックアップ**: 重要なデータおよび設定のバックアップを自動化し、人為的ミスを排除
- **定期的なリストアテスト**: バックアップデータの有効性を定期的に検証し、確実な復旧を保証
- **世代管理と保存期間**: 法令・要件に基づき、適切な世代管理と保存期間を設定

### 構成管理方針
- **Infrastructure as Code (IaC)**: インフラ構成をコード化し、バージョン管理と自動デプロイを徹底
- **変更管理プロセスの確立**: インフラ・ミドルウェアの変更は、承認プロセスを経て実施し、変更履歴を管理

### メンテナンス方針
- **計画停止の最小化**: 無停止デプロイやローリングアップデートを活用し、計画停止時間を最小化
- **パッチ適用プロセスの標準化**: OSやミドルウェアのセキュリティパッチ適用を定期的に実施し、脆弱性に対応

### 運用環境方針
- **本番環境との類似性**: 開発・試験環境を本番環境に極力近づけ、デプロイ後の不具合発生リスクを低減
- **リモート運用体制**: セキュアなリモートアクセス手段を確立し、効率的な運用を可能にする

---

## 運用・保守性要件の実現方式

### C1. 通常運用 (Normal Operation)

#### C1.1 運用時間 (Operation Time)

##### C1.1.1 運用時間（通常）
- **要件**: 24時間365日稼働
- **実現方式・仕様**:
  - クラウドプロバイダーのマネージドサービス（例: AWS RDS, Azure App Service）を活用し、インフラの可用性を確保
  - サーバー、ネットワーク機器は冗長化構成とし、単一障害点（SPOF）を排除

##### C1.1.2 運用時間（特定日）
- **要件**: 年末年始、決算期など特定の期間は無停止運用を原則とする
- **実現方式・仕様**:
  - 運用カレンダーにメンテナンス禁止期間を設定し、CI/CDパイプラインでデプロイを自動制御
  - OSやミドルウェアの計画メンテナンスは、影響の少ない時期に実施するようスケジュール調整

#### C1.2 バックアップ (Backup)

##### C1.2.2 外部データの利用可否
- **要件**: 外部システム連携データ（例: 決済情報、顧客マスタ）は、システム障害時に整合性を保ちつつ復旧可能であること
- **実現方式・仕様**:
  - 外部システムからの連携データは、受信後速やかにデータベースに格納し、DBバックアップの対象とする
  - 外部システムとの連携履歴ログを別途取得し、必要に応じてデータ再送要求が可能な仕組みを構築

##### C1.2.3 バックアップ利用範囲
- **要件**: データベース、OSイメージ、ミドルウェア設定ファイル、静的コンテンツをバックアップ対象とする
- **実現方式・仕様**:
  - データベースは、マネージドDBサービスの自動バックアップ機能（PITR含む）を利用
  - サーバーOSイメージは、定期的にスナップショットを取得し、AMI（Amazon Machine Image）として保存
  - ミドルウェア設定ファイルは、Git等のバージョン管理システムで管理し、CI/CDパイプラインで自動デプロイ

##### C1.2.4 バックアップ自動化の範囲
- **要件**: データベース、OSイメージのバックアップは完全自動化されていること
- **実現方式・仕様**:
  - クラウドの自動バックアップ機能を活用し、RPO/RTO要件を満たす設定
  - IaC（Infrastructure as Code）ツール（例: Terraform, Ansible）を用いて、バックアップ設定自体もコードとして管理

##### C1.2.5 バックアップ取得間隔
- **要件**:
  - データベース: トランザクションログはリアルタイム、増分バックアップは日次、フルバックアップは週次
  - OSイメージ/ミドルウェア設定: 週次
- **実現方式・仕様**:
  - データベースは、マネージドDBサービスのPITR（Point-in-Time Recovery）機能を有効化し、トランザクションログを継続的に取得
  - OSイメージのスナップショットは、週に1回、システム負荷の低い時間帯に自動取得するよう設定

##### C1.2.6 バックアップ保存期間
- **要件**:
  - データベース: 7世代（約1ヶ月分）
  - OSイメージ/ミドルウェア設定: 4世代（約1ヶ月分）
- **実現方式・仕様**:
  - クラウドのバックアップ保存ポリシーを設定し、指定された世代数を超過したバックアップは自動的に削除
  - 長期保存が必要なデータは、S3 Glacierなどの低コストストレージにアーカイブするライフサイクルポリシーを設定

#### C1.3 運用監視 (Operation Monitoring)

##### C1.3.1 監視情報
- **要件**:
  - サーバーリソース（CPU使用率、メモリ使用率、ディスクI/O、ネットワークI/O）
  - ミドルウェア稼働状況（Webサーバープロセス、DBプロセス、メッセージキュー稼働状況）
  - ログ（エラーログ、警告ログ）
- **実現方式・仕様**:
  - 統合監視ツール（例: Zabbix, Prometheus, Datadog）を導入し、インフラ・ミドルウェアの各メトリクスを収集
  - ログ管理基盤（例: ELK Stack, Splunk）を構築し、各サーバーからログを中央集約

##### C1.3.2 監視間隔
- **要件**:
  - サーバーリソース: 1分間隔
  - ミドルウェア稼働状況: 5分間隔
  - ログ: リアルタイム
- **実現方式・仕様**:
  - 監視ツールのエージェント設定により、各監視項目の収集間隔を上記要件に準拠させる
  - ログ収集エージェント（例: Fluentd, Logstash）は、ログファイルをリアルタイムで監視基盤に転送する設定

### C2. 保守運用 (Maintenance Operation)

#### C2.1 計画停止 (Planned Downtime)

##### C2.1.1 計画停止の有無
- **要件**: 原則として計画停止なし。やむを得ない場合は月1回、2時間以内。
- **実現方式・仕様**:
  - 無停止デプロイ方式（Blue-Green Deployment / Rolling Update）を採用し、アプリケーションの更新をサービス無停止で実施
  - OSパッチ適用やミドルウェアのバージョンアップは、ローリングアップデートや冗長構成を活用し、サービス影響を最小化

#### C2.2 運用負荷削減 (Reduction of Operational Load)

##### C2.2.1 保守作業自動化の範囲
- **要件**: OSパッチ適用、ミドルウェアの設定変更、リソースの増減は自動化されていること
- **実現方式・仕様**:
  - IaCツール（例: Ansible, Chef）を用いてOSパッチ適用やミドルウェア設定を自動化
  - クラウドのオートスケーリング機能により、負荷に応じたサーバーリソースの自動増減を実現
  - CI/CDパイプラインにインフラ・ミドルウェアのデプロイ・設定変更を組み込み、自動化を推進

### C4. 運用環境 (Operational Environment)

#### C4.1 開発用環境の設置 (Development Environment Setup)

##### C4.1.1 開発用環境の設置有無
- **要件**: 開発者向けに、本番環境と類似した開発環境が個別に提供されていること
- **実現方式・仕様**:
  - DockerやKubernetesを活用し、開発者ローカル環境で本番に近いミドルウェアスタックを再現
  - IaCテンプレートを用いて、クラウド上に開発者ごとのサンドボックス環境を自動構築

#### C4.2 試験用環境の設置 (Test Environment Setup)

##### C4.2.1 試験用環境の設置有無
- **要件**: テストチーム向けに、本番環境とデータ量・リソース構成が類似した試験環境が提供されていること
- **実現方式・仕様**:
  - 本番環境と同等のIaCテンプレートを用いて、ステージング環境を構築
  - 本番データのサブセットを匿名化・マスキング処理したテストデータを定期的に試験環境に同期

#### C4.3 マニュアル準備レベル (Manual Preparation Level)

##### C4.3.1 マニュアル準備レベル
- **要件**: 運用手順書、障害対応手順書、構成管理台帳、監視項目一覧が整備され、常に最新の状態に保たれていること
- **実現方式・仕様**:
  - ドキュメント管理システム（例: Confluence, Wiki）で運用マニュアルを一元管理
  - IaCで管理されている構成情報は、自動的に構成管理台帳に反映される仕組みを構築
  - 定期的なレビューと更新サイクルを確立

#### C4.4 リモートオペレーション (Remote Operation)

##### C4.4.1 リモート監視地点
- **要件**: データセンター外、またはクラウド環境から安全にシステムを監視できること
- **実現方式・仕様**:
  - VPN接続を介して、運用拠点から監視システムにアクセス
  - クラウドのマネージド監視サービス（例: CloudWatch, Azure Monitor）を利用し、Webコンソールから監視情報を確認

##### C4.4.2 リモート操作の範囲
- **要件**: サーバーへのSSH接続、ミドルウェアの管理コンソール操作、クラウドプロバイダーの管理画面操作が可能であること
- **実現方式・仕様**:
  - 踏み台サーバー（Bastion Host）を経由したSSH接続を必須とし、アクセス元IPアドレスを制限
  - クラウドのIAMロールや多要素認証（MFA）を必須とし、最小権限の原則に基づいたアクセス制御

#### C4.5 外部システム接続 (External System Connection)

##### C4.5.1 外部システムとの接続有無
- **要件**: 外部決済システム、SaaS連携、ログ転送サービスなど、外部システムとの接続があること
- **実現方式・仕様**:
  - 外部システムとの接続は、VPN、専用線、またはAPI Gatewayを介してセキュアに行う
  - 接続先のIPアドレスやポート番号は、ファイアウォールで厳密に制御

### C5. サポート体制 (Support System)

#### C5.1 保守契約（ハードウェア） (Hardware Maintenance Contract)

##### C5.1.1 保守契約（ハードウェア）の範囲
- **要件**: 全ての物理サーバー、ネットワーク機器、ストレージについて保守契約が締結されていること
- **実現方式・仕様**:
  - データセンター提供の物理インフラについては、データセンター事業者との保守契約を確認
  - クラウド環境の場合、クラウドプロバイダーのSLA（Service Level Agreement）に基づき、ハードウェア障害対応はクラウド事業者が実施

#### C5.2 保守契約（ソフトウェア） (Software Maintenance Contract)

##### C5.2.1 保守契約（ソフトウェア）の範囲
- **要件**: OS、ミドルウェア（データベース、Web/APサーバー、メッセージキューなど）、監視ツールについて保守契約が締結されていること
- **実現方式・仕様**:
  - 各ベンダー提供のOS・ミドルウェアについては、サポート契約を締結
  - クラウドのマネージドサービスを利用している場合は、クラウドプロバイダーのSLAに基づき、ミドルウェアのサポートはクラウド事業者が実施

#### C5.3 ライフサイクル期間 (Lifecycle Period)

##### C5.3.1 ライフサイクル期間
- **要件**: システム稼働期間は5年間とし、期間終了後にはリプレースまたはサービス終了を検討する
- **実現方式・仕様**:
  - インフラ・ミドルウェアのEOL（End-of-Life）情報を定期的に収集し、計画的なバージョンアップやリプレース計画を策定
  - 5年間の運用を見越したキャパシティプランニングとコスト予測を実施

### C6. その他の運用管理方針 (Other Operational Management Policies)

#### C6.1 内部統制対応 (Internal Control Compliance)

##### C6.1.1 内部統制対応の実施有無
- **要件**: システム運用プロセスが、IT統制に関する内部統制要件に準拠していること
- **実現方式・仕様**:
  - 運用担当者のアクセス権限は最小限に制限し、定期的にレビューを実施
  - 重要な設定変更やデプロイは、承認プロセスを経て実施し、変更履歴を監査ログとして記録
  - 運用監査ログを定期的に確認し、不正アクセスや不適切な操作がないかチェック

#### C6.2 サービスデスク (Service Desk)

##### C6.2.1 サービスデスクの設置有無
- **要件**: 運用チームへの問い合わせ窓口として、サービスデスク機能が設置されていること
- **実現方式・仕様**:
  - チケット管理システム（例: Jira Service Management, Zendesk）を導入し、問い合わせ、インシデント、変更要求を一元管理
  - 運用チームのオンコール体制を確立し、緊急時の連絡フローを明確化

---

## テスト計画（運用・保守性関連）

### バックアップ・リストアテスト
- **実施時期**: 四半期ごと、および大規模な構成変更後
- **テスト項目**:
  - データベースのフルバックアップからのリストア、およびPITR（Point-in-Time Recovery）の検証
  - OSイメージからのサーバー復旧、およびミドルウェア設定のリストア
  - バックアップデータの整合性チェック
- **合格基準**: RTO/RPO要件を満たし、データが正常に復旧できること

### 監視・アラートテスト
- **実施時期**: 月次、および監視設定変更後
- **テスト項目**:
  - 各監視項目の閾値超過時に、設定された通知先にアラートが発報されること
  - 監視ツールからのログ収集が正常に行われていること
  - 障害検知から通知までの時間
- **合格基準**: 監視アラートが設定通りに発報され、通知が遅延なく届くこと

### パッチ適用テスト
- **実施時期**: OS/ミドルウェアのパッチリリース後、本番適用前
- **テスト項目**:
  - 開発・試験環境でのパッチ適用手順の検証
  - パッチ適用後のシステム動作、性能、セキュリティへの影響確認
  - ローリングアップデート時のサービス継続性
- **合格基準**: パッチ適用によりシステムに異常が発生せず、サービス継続性が維持されること

### 構成変更テスト
- **実施時期**: インフラ・ミドルウェアの構成変更前
- **テスト項目**:
  - IaCツールによる構成変更の適用検証
  - 変更後のシステム動作、性能への影響確認
  - ロールバック手順の検証
- **合格基準**: 構成変更が正常に適用され、システムが安定稼働すること

---

## リスクと対策

| No | リスク | 影響 | 発生確率 | 対策 |
|----|--------|------|---------|------|
| 1 | 監視設定の漏れや不備 | 障害検知の遅延、システム停止 | 中 | 監視項目定義書の定期的な見直し、監視設定のIaC化とレビュー |
| 2 | バックアップの失敗やデータ破損 | データ損失、システム復旧不能 | 低 | 定期的なリストアテストの実施、バックアップの多重化保存、バックアップログの監視 |
| 3 | パッチ適用によるシステム障害 | サービス停止、セキュリティ脆弱性の露呈 | 中 | 開発・試験環境での事前検証、ロールバック計画の策定、無停止適用方式の採用 |
| 4 | 運用手順の不備や属人化 | 障害対応の遅延、誤操作によるシステム停止 | 中 | 運用手順書の整備と定期更新、複数人でのレビュー、運用担当者の多能工化 |
| 5 | リモートアクセス経路の脆弱性 | 不正アクセスによる情報漏洩、システム改ざん | 低 | VPN/踏み台サーバーの導入、多要素認証の必須化、アクセスログの厳重な監視 |
| 6 | 外部システム連携障害による運用負荷増大 | 運用担当者の対応負荷増大、サービス品質低下 | 中 | 外部システムとのSLA確認、連携インターフェースの監視強化、自動リトライ機構の導入 |

---