6-2 運用保守
Operations and Maintenance
1. 運用保守の概要
1.1 運用と保守の違い
運用と保守は混同されがちだが、目的と活動内容が異なる。 運用はシステムの日常的な稼働を維持する活動であり、 保守はシステムを修正・改善する活動である。 両者は密接に連携しながら、システムの安定稼働と継続的な価値提供を実現する。
| 活動 | 目的 | 内容 |
|---|---|---|
| 運用 | システムの安定稼働 | 監視、バックアップ、障害対応、日常作業 |
| 保守 | システムの維持・改善 | バグ修正、機能改善、環境更新 |
1.2 保守の種類（ISO/IEC 14764）
国際規格ISO/IEC 14764では、ソフトウェア保守を4つのカテゴリに分類している。 この分類を理解することで、保守作業の優先順位付けや工数見積もりが 適切に行えるようになる。一般的に、是正保守と適応保守が保守工数の 大部分を占めるが、予防保守への投資が将来的なコスト削減につながる。
| 種類 | 目的 | 例 |
|---|---|---|
| 是正保守 | 欠陥の修正 | バグ修正、障害対応 |
| 適応保守 | 環境変化への対応 | OS更新、法改正対応 |
| 完全化保守 | 機能・性能の改善 | 機能追加、性能改善 |
| 予防保守 | 将来の問題防止 | リファクタリング、脆弱性対応 |
2. 監視
2.1 監視の種類
効果的な監視体制は、障害の早期発見と迅速な対応を可能にする。 監視は複数のレイヤーで実施し、インフラからアプリケーション、 さらにはビジネス指標まで、多角的に状態を把握することが重要である。 単一の視点だけでは、問題の根本原因を特定することが困難になる。
| 監視種類 | 対象 | 監視項目例 |
|---|---|---|
| インフラ監視 | サーバー、ネットワーク | CPU、メモリ、ディスク、死活 |
| アプリケーション監視 | アプリケーション | レスポンスタイム、エラー率 |
| ログ監視 | ログファイル | エラーログ、アクセスログ |
| 外形監視 | ユーザー視点 | サービス応答、画面表示 |
2.2 監視ツール
監視ツールは、収集・可視化・アラートの機能を提供する。 クラウド環境ではマネージドサービスを活用することで、 運用負荷を軽減できる。オンプレミス環境では、 OSSの組み合わせも有効な選択肢となる。
| ツール | 特徴 |
|---|---|
| Prometheus + Grafana | メトリクス収集、可視化（OSS） |
| Datadog | 統合監視SaaS、APM機能 |
| CloudWatch | AWS統合監視 |
| Zabbix | オープンソース、多機能 |
過剰なアラートは運用者の注意力を低下させる。 重要度に応じたアラートレベル設定と、ノイズの削減が重要である。 「オオカミ少年」状態にならないよう、アラートの閾値は 定期的に見直し、実際に対応が必要なものだけを通知する。
3. 障害対応
3.1 障害対応プロセス
障害対応は、検知から復旧、事後対応までの一連のプロセスである。 パニックにならず、手順に従って冷静に対応することが重要である。 特に初動対応では、影響範囲の確認と関係者への連絡を最優先とし、 原因調査は復旧後に詳細に行う。
@startuml !theme plain skinparam backgroundColor #FEFEFE skinparam defaultFontName Noto Sans JP ' タイトル設定 skinparam titleFontSize 14 skinparam titleFontColor #1E3A5F skinparam titleFontStyle bold ' 矢印設定 skinparam ArrowColor #475569 skinparam ArrowThickness 1.5 ' ノート設定 skinparam NoteBackgroundColor #FFFBEB skinparam NoteBorderColor #CA8A04 skinparam NoteFontSize 10 title 障害対応プロセス rectangle "検知" as Detect #DBEAFE rectangle "影響確認" as Impact #DBEAFE rectangle "関係者連絡" as Notify #DBEAFE rectangle "原因調査" as Investigate #D1FAE5 rectangle "暫定対応" as Workaround #D1FAE5 rectangle "復旧確認" as Verify #FEF3C7 rectangle "復旧宣言" as Declare #FEF3C7 rectangle "報告書作成" as Report #FEE2E2 Detect --> Impact Impact --> Notify Notify --> Investigate Investigate --> Workaround Workaround --> Verify Verify --> Declare Declare --> Report note right of Detect 監視アラート ユーザー報告 end note note right of Investigate ログ分析 切り分け end note note right of Report ポストモーテム 再発防止策 end note @enduml
図1: 障害対応プロセス
| フェーズ | 活動 |
|---|---|
| 検知 | 監視アラート、ユーザー報告 |
| 初動対応 | 影響範囲確認、関係者連絡 |
| 原因調査 | ログ分析、切り分け |
| 復旧 | 暫定対応、恒久対応 |
| 事後対応 | 報告書作成、再発防止策 |
3.2 インシデント管理
インシデントは重要度によって分類し、対応優先度を決定する。 すべてのインシデントを同じ緊急度で扱うと、 本当に重要な問題への対応が遅れる危険性がある。 事前に分類基準と対応時間目標を定義しておくことが重要である。
| 重要度 | 影響 | 対応時間目安 |
|---|---|---|
| Critical | サービス全停止 | 即時対応 |
| High | 主要機能停止 | 1時間以内 |
| Medium | 一部機能障害 | 4時間以内 |
| Low | 軽微な問題 | 翌営業日 |
障害後は必ず振り返りを行う。目的は犯人探しではなく、 システムとプロセスの改善である。 「なぜ」を5回繰り返し、根本原因を特定する。 非難のない文化（Blameless Culture）が、 正直な報告と効果的な改善を可能にする。
4. SLA/SLO
4.1 用語の定義
サービスレベルに関する用語は混同されやすい。 SLAは顧客との契約であり、違反時にはペナルティが発生する可能性がある。 SLOは内部目標であり、SLAよりも厳しく設定することで、 SLA違反を未然に防ぐバッファを確保する。
| 用語 | 定義 |
|---|---|
| SLA（Service Level Agreement） | サービス提供者と顧客間の契約 |
| SLO（Service Level Objective） | 内部目標値 |
| SLI（Service Level Indicator） | 測定指標 |
4.2 一般的なSLA指標
可用性は最も一般的なSLA指標である。「99.9%」（スリーナイン）は 年間ダウンタイム約8.76時間を意味する。「99.99%」（フォーナイン）では 約52分となり、達成難易度が大きく上がる。 ビジネス要件とコストのバランスを考慮して、適切なレベルを設定する。
| 指標 | 例 |
|---|---|
| 可用性 | 99.9%（年間ダウンタイム8.76時間） |
| 応答時間 | 95%のリクエストが200ms以内 |
| 障害復旧時間 | MTTR 4時間以内 |
[1] ITIL 4 Foundation.
[2] Google. Site Reliability Engineering.