Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
定常運用
システムの安定稼働を維持し、定常的な運用業務を標準化・効率化することで、サービスレベルを確保し、運用品質の向上を実現します。
🎯 概要
- 目的: システムの安定稼働を維持し、定常的な運用業務を標準化・効率化することで、サービスレベルを確保し、運用品質の向上を実現する
- スコープ: 日常運用作業(日次・週次・月次)、バッチジョブ管理、定期メンテナンス、リリース後作業などの定常的な運用オペレーションをカバーする。障害対応や緊急対応は対象外
- 推奨する実施タイミング: システムリリース前の運用設計フェーズで実施し、本番稼働後は継続的に運用手順を改善する
- 関連するステークホルダー: 運用チーム、運用リーダー、開発チーム、インフラチーム、サービスオーナー
📥 重要な前提知識・インプット
- 前提知識: システムアーキテクチャ、バッチ処理の仕組み、監視・ログ管理の基礎知識、運用プロセスの理解、SLA/KPIの概念
- インプット: システム構成図、非機能要件書(可用性・性能目標)、バッチジョブ一覧、監視項目定義、SLA定義書、運用体制図
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]定常運用
- 必須要素: 運用カレンダー(日次・週次・月次作業一覧)、ジョブスケジュール定義書、メンテナンス手順書、リリース後チェックリスト、運用フロー図、役割分担表
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 作業の網羅性 | すべての定常作業(日次・週次・月次)が漏れなく定義されているか |
| 手順の明確性 | 各作業の実施手順が具体的で、誰でも実施できるレベルで記載されているか |
| ジョブ依存関係 | バッチジョブ間の依存関係と実行順序が明確に定義されているか |
| 異常時の対応 | エラー発生時の対応手順、エスカレーション基準が明確か |
| 実行可能性 | 想定作業時間が現実的で、運用チームのリソースで実施可能か |
👁️🗨️ レビュー観点:
- SLA達成可能性: 定義された運用手順でSLA要件を満たせるか
- 運用負荷の妥当性: 運用チームの人員・スキルで実施可能な作業量か
- 自動化の検討: 手作業が多すぎないか、自動化可能な作業はないか
- 属人性の排除: 特定の担当者に依存せず、標準化された手順になっているか
- 継続的改善: 運用実績をもとに手順を改善するプロセスが組み込まれているか
🧪成果物のサンプル
# 定常運用
## 運用フロー概要
本章では、システムの日常的な運用オペレーションについて定義する。
### 運用体制の前提
- 運用担当者: システムの日常運用・監視を担当
- 運用リーダー: 運用チームの統括、エスカレーション対応
- 開発チーム: 障害対応時の技術支援、機能改修
### 運用の分類
```mermaid
graph TD
A[定常運用] --> B[日常運用]
A --> C[イベント運用]
B --> B1[日次作業]
B --> B2[週次作業]
B --> B3[月次作業]
C --> C1[メンテナンス]
C --> C2[リリース後作業]
C --> C3[臨時作業]
```
---
## 日常運用
### 日次作業
| 作業項目 | 実施時刻 | 担当 | 作業内容 | 所要時間 |
|---------|---------|------|---------|---------|
| バッチ実行結果確認 | 9:00 | 運用担当者 | 夜間バッチの成功/失敗を確認 | 15分 |
| システム稼働状況確認 | 9:30 | 運用担当者 | CPU・メモリ・ディスク使用率の確認 | 10分 |
| エラーログ確認 | 10:00 | 運用担当者 | アプリケーションログのエラー確認 | 20分 |
| アラート対応 | 随時 | 運用担当者 | 監視システムからのアラート対応 | 都度 |
| 日報作成 | 17:00 | 運用担当者 | 当日の作業内容・インシデントを記録 | 15分 |
**日次作業フロー**
```mermaid
graph LR
A[作業開始] --> B[バッチ結果確認]
B --> C{異常あり?}
C -->|Yes| D[バッチ再実行 or<br/>エスカレーション]
C -->|No| E[システム状態確認]
E --> F{リソース逼迫?}
F -->|Yes| G[原因調査・対応]
F -->|No| H[エラーログ確認]
H --> I{エラーあり?}
I -->|Yes| J[影響範囲確認・対応]
I -->|No| K[日報作成]
D --> K
G --> K
J --> K
K --> L[作業完了]
```
### 週次作業
| 作業項目 | 実施曜日 | 担当 | 作業内容 | 所要時間 |
|---------|---------|------|---------|---------|
| ディスク使用状況確認 | 月曜 | 運用担当者 | 全サーバーのディスク使用率を確認 | 30分 |
| バックアップ検証 | 火曜 | 運用担当者 | バックアップファイルの整合性確認 | 1時間 |
| セキュリティログ確認 | 水曜 | 運用担当者 | 不正アクセス・異常ログイン確認 | 30分 |
| 性能レポート作成 | 金曜 | 運用リーダー | 週次の性能指標をまとめて報告 | 1時間 |
### 月次作業
| 作業項目 | 実施日 | 担当 | 作業内容 | 所要時間 |
|---------|-------|------|---------|---------|
| 月次定期点検 | 第1営業日 | 運用担当者 | システム全体の健全性確認 | 2時間 |
| ログアーカイブ | 第1営業日 | 運用担当者 | 前月のログをアーカイブ保存 | 1時間 |
| パッチ適用確認 | 第2週 | 運用リーダー | OS・ミドルウェアのパッチ適用状況確認 | 1時間 |
| 運用報告書作成 | 月末 | 運用リーダー | 月次運用実績レポートを作成 | 2時間 |
| SLA・KPI集計 | 月末 | 運用リーダー | 可用性・性能指標の集計と評価 | 1時間 |
---
## イベント運用
### メンテナンス作業フロー
```mermaid
graph TD
A[メンテナンス計画] --> B[事前通知<br/>利用者へ1週間前]
B --> C[メンテナンス準備]
C --> C1[作業手順書作成]
C --> C2[ロールバック手順確認]
C --> C3[バックアップ取得]
C3 --> D[メンテナンスモード開始]
D --> E[作業実施]
E --> F{作業成功?}
F -->|Yes| G[動作確認]
F -->|No| H[ロールバック]
G --> I{確認OK?}
I -->|Yes| J[メンテナンスモード解除]
I -->|No| H
H --> K[原因調査]
K --> L[再計画]
J --> M[利用者へ完了通知]
M --> N[作業報告書作成]
```
**メンテナンス区分**
| 区分 | 実施タイミング | 事前通知 | 承認プロセス |
|------|--------------|---------|------------|
| 定期メンテナンス | 月次(第3土曜 2:00-5:00) | 1週間前 | 運用リーダー承認 |
| 臨時メンテナンス | 必要時 | 3営業日前 | サービスオーナー承認 |
| 緊急メンテナンス | 障害対応時 | 可能な限り事前通知 | 運用責任者判断 |
### リリース後の定型作業フロー
```mermaid
graph LR
A[リリース完了] --> B[稼働確認<br/>30分間]
B --> C{異常検知?}
C -->|Yes| D[即時ロールバック]
C -->|No| E[ログ確認]
E --> F{エラーあり?}
F -->|Yes| G[影響範囲確認]
F -->|No| H[性能確認]
G --> I{致命的?}
I -->|Yes| D
I -->|No| H
H --> J{性能劣化?}
J -->|Yes| K[原因調査・対応]
J -->|No| L[リリース報告書作成]
D --> M[障害報告書作成]
K --> L
L --> N[作業完了]
M --> N
```
**リリース後チェックリスト**
- [ ] 主要機能の動作確認(画面表示、API応答)
- [ ] エラーログの確認(アプリケーション、ミドルウェア)
- [ ] 応答時間の確認(リリース前と比較)
- [ ] CPU・メモリ使用率の確認
- [ ] データ整合性の確認(必要に応じて)
- [ ] 外部連携システムとの疎通確認
- [ ] 監視アラートの確認
---
## ジョブ管理
### ジョブ一覧
| ジョブID | ジョブ名 | 実行タイミング | 処理内容 | 想定実行時間 | 優先度 |
|---------|---------|--------------|---------|------------|-------|
| JOB001 | 日次売上集計 | 毎日 3:00 | 前日の売上データを集計 | 30分 | High |
| JOB002 | ユーザーデータ同期 | 毎日 4:00 | 外部システムからユーザー情報取得 | 15分 | High |
| JOB003 | ログアーカイブ | 毎日 5:00 | 古いログをアーカイブストレージへ移動 | 20分 | Medium |
| JOB004 | レポート生成 | 毎週月曜 6:00 | 週次レポートをPDF生成 | 1時間 | Medium |
| JOB005 | データクレンジング | 毎月1日 2:00 | 不要データの削除・整理 | 2時間 | Low |
### ジョブ依存関係(DAG)
```mermaid
graph TD
A[JOB001: 売上集計] --> B[JOB004: レポート生成]
C[JOB002: ユーザーデータ同期] --> A
A --> D[JOB003: ログアーカイブ]
E[JOB005: データクレンジング] --> C
style A fill:#ff9999
style C fill:#ff9999
style B fill:#ffcc99
style D fill:#ffcc99
style E fill:#cccccc
```
**凡例**
- 赤色: 優先度 High(失敗時は即時対応必須)
- オレンジ色: 優先度 Medium(営業時間内に対応)
- 灰色: 優先度 Low(翌営業日対応可)
### ジョブスケジュール詳細
**JOB001: 日次売上集計**
- **Cron式**: `0 3 * * *`
- **実行サーバー**: バッチサーバー01
- **前提条件**: JOB002が正常終了していること
- **タイムアウト**: 60分
- **リトライ**: 3回(10分間隔)
**JOB002: ユーザーデータ同期**
- **Cron式**: `0 4 * * *`
- **実行サーバー**: バッチサーバー01
- **前提条件**: 外部システムAPIが稼働していること
- **タイムアウト**: 30分
- **リトライ**: 5回(5分間隔)
### ジョブ異常時の対応
**異常パターンと対応**
| 異常パターン | 対応手順 | スキップ可否 | エスカレーション |
|------------|---------|------------|---------------|
| タイムアウト | 手動でジョブを停止後、再実行 | 不可 | 運用リーダーへ報告 |
| データ不整合 | ロールバック後、原因調査・修正して再実行 | 不可 | 開発チームへ連携 |
| 外部システム接続エラー | リトライ後も失敗なら翌日に延期 | 可(優先度Low) | 運用リーダーへ報告 |
| リソース不足 | 不要プロセス停止、ディスク空き容量確保後に再実行 | 不可 | 運用リーダーへ報告 |
**リトライ・再実行手順**
```mermaid
graph TD
A[ジョブ失敗検知] --> B{自動リトライ<br/>設定あり?}
B -->|Yes| C[自動リトライ実行]
B -->|No| D[運用担当者へ通知]
C --> E{リトライ成功?}
E -->|Yes| F[正常終了]
E -->|No| D
D --> G[ログ確認・原因特定]
G --> H{スキップ可能?}
H -->|Yes| I[スキップ実施<br/>翌日再実行]
H -->|No| J[原因除去]
J --> K[手動再実行]
K --> L{成功?}
L -->|Yes| F
L -->|No| M[エスカレーション]
```
**手動再実行コマンド例**
```bash
# ジョブ再実行
./batch/run_job.sh JOB001 --date 2025-12-08
# 特定ステップから再実行
./batch/run_job.sh JOB001 --from-step 3
# ドライラン(実行せずに確認のみ)
./batch/run_job.sh JOB001 --dry-run
```
---
## 操作手順書
各定常運用における詳細な操作手順は、以下の外部ドキュメントを参照すること。
| 手順書名 | 参照先 | 更新日 |
|---------|-------|-------|
| 日次運用手順書 | [Confluence: 日次運用マニュアル](#) | 2025-12-01 |
| バッチ運用手順書 | [Confluence: バッチ管理ガイド](#) | 2025-11-15 |
| メンテナンス手順書 | [Confluence: メンテナンス作業手順](#) | 2025-10-20 |
| リリース手順書 | [Confluence: リリースオペレーション](#) | 2025-12-05 |
---
## 運用カレンダー
### 年間運用スケジュール
| 月 | 定期作業 | 備考 |
|----|---------|------|
| 1月 | 年次システム棚卸、DR訓練 | 年始休暇に注意 |
| 2月 | セキュリティ診断 | |
| 3月 | 年度末データアーカイブ | 繁忙期・リソース注意 |
| 4月 | 年次インフラ更改計画策定 | |
| 5月 | - | GW休暇に注意 |
| 6月 | 半期SLA・KPIレビュー | |
| 7月 | DR訓練 | |
| 8月 | ミドルウェアバージョンアップ | 夏季休暇に注意 |
| 9月 | セキュリティ診断 | |
| 10月 | - | |
| 11月 | 負荷試験(年次) | |
| 12月 | 年次運用レビュー、年末年始対応確認 | 年末休暇に注意 |
### 週次運用カレンダー(例)
| 曜日 | 作業内容 |
|------|---------|
| 月曜 | ディスク使用状況確認、週次定例会 |
| 火曜 | バックアップ検証 |
| 水曜 | セキュリティログ確認 |
| 木曜 | - |
| 金曜 | 性能レポート作成、週次報告 |
| 土曜 | 定期メンテナンス(第3土曜) |
| 日曜 | - |
---
## 運用担当者の役割分担
| 役割 | 担当者 | 主な責務 |
|------|-------|---------|
| 運用リーダー | [氏名] | 運用チーム統括、エスカレーション対応、月次報告 |
| 運用担当者A | [氏名] | 日次運用、監視対応、バッチ管理 |
| 運用担当者B | [氏名] | 週次作業、セキュリティ確認、ドキュメント更新 |
| バックアップ担当 | [氏名] | 主担当者不在時の代行 |
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: 運用作業の洗い出しと分類
設計対象:
システム稼働に必要な定常的な運用作業を網羅的に洗い出し、実施頻度(日次・週次・月次)と作業区分(日常運用・イベント運用)に分類する。
具体例:
- バッチジョブの実行結果確認、システム稼働状況確認、ログ確認などの日次作業
- バックアップ検証、ディスク使用状況確認、性能レポート作成などの週次作業
- 月次定期点検、パッチ適用確認、SLA/KPI集計などの月次作業
- 定期メンテナンス、リリース後作業、臨時メンテナンスなどのイベント運用
設計原則:
- 網羅性の確保: システム構成、非機能要件、SLA定義から必要な運用作業を漏れなく抽出する
- 適切な頻度設定: 作業の重要度とリスクに応じて、過不足のない実施頻度を設定する
- 実行可能性の確認: 運用チームのリソース(人員・時間)で実施可能な作業量か検証する
- 優先度の明確化: 各作業の重要度と緊急度を定義し、リソースが不足した場合の優先順位を明確にする
文書化の推奨表現:
- 運用カレンダーの作成: 日次・週次・月次・年次の作業スケジュールを一覧表とカレンダー形式で可視化する
- 作業一覧表の整備: 各作業の実施時刻、担当、作業内容、所要時間を表形式で整理する
- 作業分類の明示: 日常運用とイベント運用を明確に区別し、それぞれの作業フローを定義する
🏗️ プロセス2: バッチジョブスケジュールの設計
設計対象:
定期的に実行するバッチジョブの一覧、実行タイミング、依存関係、異常時の対応方法を定義する。
具体例:
- 日次売上集計、ユーザーデータ同期、ログアーカイブなどのジョブ定義
- 各ジョブの実行時刻、想定実行時間、タイムアウト設定
- ジョブ間の依存関係(DAG: Directed Acyclic Graph)の定義
- ジョブ失敗時のリトライ回数、エスカレーション基準、スキップ可否
設計原則:
- 依存関係の明確化: ジョブ間の前提条件と依存関係を可視化し、実行順序を明確にする
- タイムウィンドウの確保: 各ジョブに十分な実行時間を確保し、処理遅延時の影響を最小化する
- リトライ戦略の定義: 一時的なエラーに対する自動リトライと、エスカレーションの判断基準を明確にする
- 優先度の設定: ビジネスへの影響度に応じてジョブの優先度を定義し、リソース割り当てを最適化する
文書化の推奨表現:
- ジョブ一覧表の作成: ジョブID、ジョブ名、実行タイミング、処理内容、想定実行時間、優先度を表形式で整理する
- 依存関係図の作成: Mermaidなどでジョブ間の依存関係をDAGで可視化する
- ジョブスケジュール詳細: Cron式、実行サーバー、前提条件、タイムアウト、リトライ設定を明記する
- 異常時対応手順: 異常パターン別の対応手順、リトライ・再実行フロー、手動実行コマンド例を記載する
🏗️ プロセス3: メンテナンス・イベント運用手順の策定
設計対象:
定期メンテナンス、リリース後作業、臨時メンテナンスなどのイベント運用における作業フローと手順を定義する。
具体例:
- 定期メンテナンスの実施タイミング、事前通知、作業手順、確認項目
- リリース後の稼働確認、ログ確認、性能確認、チェックリスト
- メンテナンス区分(定期・臨時・緊急)ごとの承認プロセス
- ロールバック判断基準と手順
設計原則:
- 事前通知の徹底: 利用者への影響を最小化するため、適切なリードタイムで事前通知を行う
- 作業手順の標準化: 作業手順書を整備し、誰が実施しても同じ品質を確保できるようにする
- 確認項目の明確化: メンテナンス後の動作確認、性能確認の具体的なチェックリストを定義する
- リスク管理: ロールバック手順を事前に準備し、問題発生時の迅速な復旧を可能にする
文書化の推奨表現:
- 作業フロー図の作成: メンテナンス作業、リリース後作業のフローをMermaidで可視化する
- メンテナンス区分表: 区分、実施タイミング、事前通知、承認プロセスを表形式で整理する
- チェックリストの整備: リリース後の確認項目をチェックボックス形式で列挙する
- 操作手順書へのリンク: 詳細な操作手順は外部ドキュメントとして管理し、参照先を明記する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『ITサービスマネジメント(ITIL)』、『Site Reliability Engineering(SRE)』、『運用設計の実践ガイド』
- 関連する他のガイド: 監視設計ガイド、障害対応ガイド、バックアップ・リカバリ設計ガイド、SLA定義ガイド
- ツール・テンプレート: Mermaid(フロー図・DAG作成)、Cron式ジェネレーター、運用カレンダーテンプレート
テンプレートサイト: 📄テンプレート集