定常運用

Home

📕Arrow icon of a page linkサンエムシステム 上流工程標準(Preview版)

⚖️Arrow icon of a page linkサンエムシステム上流工程 標準規格

📘Arrow icon of a page link要件定義 実践ガイド

📘Arrow icon of a page link基本設計 実践ガイド

📄Arrow icon of a page linkテンプレート集

Get Started

📄Arrow icon of a page link基本設計工程のルール

📄Arrow icon of a page link基本設計書の構成を決める

🚧Arrow icon of a page link基本設計のプロセスモデル

実践ガイド

文書情報
システム方式設計
外部仕様設計
運用設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
レビュー・承認

定常運用

システムの安定稼働を維持し、定常的な運用業務を標準化・効率化することで、サービスレベルを確保し、運用品質の向上を実現します。

🎯 概要


  • 目的: システムの安定稼働を維持し、定常的な運用業務を標準化・効率化することで、サービスレベルを確保し、運用品質の向上を実現する
  • スコープ: 日常運用作業(日次・週次・月次)、バッチジョブ管理、定期メンテナンス、リリース後作業などの定常的な運用オペレーションをカバーする。障害対応や緊急対応は対象外
  • 推奨する実施タイミング: システムリリース前の運用設計フェーズで実施し、本番稼働後は継続的に運用手順を改善する
  • 関連するステークホルダー: 運用チーム、運用リーダー、開発チーム、インフラチーム、サービスオーナー

📥 重要な前提知識・インプット


  • 前提知識: システムアーキテクチャ、バッチ処理の仕組み、監視・ログ管理の基礎知識、運用プロセスの理解、SLA/KPIの概念
  • インプット: システム構成図、非機能要件書(可用性・性能目標)、バッチジョブ一覧、監視項目定義、SLA定義書、運用体制図

📄 成果物の定義


  • ドキュメントテンプレート: 📄Arrow icon of a page link[テンプレ]定常運用
  • 必須要素: 運用カレンダー(日次・週次・月次作業一覧)、ジョブスケジュール定義書、メンテナンス手順書、リリース後チェックリスト、運用フロー図、役割分担表
✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
作業の網羅性 すべての定常作業(日次・週次・月次)が漏れなく定義されているか
手順の明確性 各作業の実施手順が具体的で、誰でも実施できるレベルで記載されているか
ジョブ依存関係 バッチジョブ間の依存関係と実行順序が明確に定義されているか
異常時の対応 エラー発生時の対応手順、エスカレーション基準が明確か
実行可能性 想定作業時間が現実的で、運用チームのリソースで実施可能か

👁️‍🗨️ レビュー観点:

  • 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時間 |
| SLAKPI集計 | 月末 | 運用リーダー | 可用性・性能指標の集計と評価 | 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 | データクレンジング | 毎月12: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| 半期SLAKPIレビュー | |
| 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式ジェネレーター、運用カレンダーテンプレート


テンプレートサイト: 📄Arrow icon of a page linkテンプレート集