はじめに
システム開発では、要件定義や設計の段階で機能や性能に注目が集まりがちです。
実際、お客様との打ち合わせでも、
- どのような機能を実装するか
- どのくらいの性能が必要か
- どれだけ止まらないシステムにするか
といった話題が中心になることが少なくありません。
しかし、システムは構築して終わりではありません。
本番稼働後は数年から十年以上にわたり運用され続けます。そのため、日々の監視やバックアップ、障害対応、パッチ適用などの運用・保守作業が適切に実施できることが非常に重要です。
実務でも、
「バックアップを取得していると思っていた」
「パッチ適用のルールが決まっていなかった」
「障害発生時の連絡先が不明だった」
といった問題が発生することがあります。
このようなトラブルを防ぐために、IPAの非機能要求グレードでは「運用・保守性」という観点が定義されています。
非機能要求グレードがそもそも何か？については以下の記事にまとめています。
インフラ要件定義で役立つ「非機能要求グレード」とは？実務で感じたメリットと注意点
今回は、運用・保守性の考え方や、要件定義で確認しておくべきポイントについて解説します。
運用・保守性とは何か
運用・保守性とは、システムを継続的かつ安定的に利用するために必要な運用方法や保守方法に関する要求です。
可用性や性能がシステムそのものの品質を定義するのに対し、運用・保守性はシステムを維持するための仕組みや体制を定義するものと言えます。
例えば、
- バックアップをどのように取得するか
- 障害をどのように検知するか
- パッチをどのような頻度で適用するか
- 障害発生時に誰が対応するか
といった内容が該当します。
これらを要件定義で整理しておかないと、本番稼働後に運用が属人化したり、障害発生時に適切な対応ができなくなったりする可能性があります。
IPAの非機能要求グレードでは、運用・保守性を以下の6つの観点に分類しています。
- 通常運用
- 保守運用
- 障害時運用
- 運用環境
- サポート体制
- その他の運用管理方針
実務でも、この分類に沿って整理すると抜け漏れを防ぎやすくなります。
通常運用｜日々の運用ルールを明確にする
通常運用では、システムを問題なく利用するための日常的な運用について整理します。
代表的な項目として、
- 運用時間
- バックアップ
- 運用監視
- 時刻同期
があります。
特に重要なのが運用時間です。
例えば、
- 平日9時～18時のみ利用
- 24時間365日利用
- 月末のみ夜間利用
など、業務によって利用形態は大きく異なります。
また、特定日だけ異なる運用を行うケースもあります。
例えば、
- 毎週日曜日は計画停止
- 毎月第一土曜日にバックアップ作業
- 年末年始は特別運用
などです。
実務では通常運用だけを確認し、特定日の運用を見落とすことがあります。
しかし、本番稼働後に
「その日は止められない」
「バックアップ時間が確保できない」
という問題が発生することも少なくありません。
そのため、通常運用だけでなく例外的な運用スケジュールも整理しておくことが重要です。
保守運用｜システム品質を維持するための仕組み
システムは構築した瞬間から劣化が始まります。
OSやミドルウェアには脆弱性が発見されますし、ハードウェアも経年劣化します。
そのため、継続的なメンテナンスが必要になります。
保守運用では主に、
- 計画停止
- パッチ適用
- 活性保守
- バージョンアップ
などを整理します。
特にパッチ適用ポリシーは重要です。
例えば、
- セキュリティパッチは即時適用
- 定例メンテナンス時に適用
- 年数回まとめて適用
など、運用方針によって必要な構成や体制が変わります。
また、可用性要件とも密接に関係します。
システムを停止できない場合は、
- 冗長構成
- ローリングアップデート
- クラスタ構成
などが必要になる場合があります。
実務では、
「止められないシステムだから」
という理由だけで高可用構成を採用するケースがありますが、その背景にある保守運用方針も合わせて確認することが重要です。
障害時運用｜障害発生時の対応を事前に決める
システムは必ず障害が発生します。
そのため重要なのは、障害をゼロにすることではなく、障害発生時に適切な対応ができることです。
障害時運用では、
- 障害検知方法
- エスカレーションルール
- 復旧作業手順
- 交換部材の確保
などを整理します。
実務で特に重要なのが一次対応の定義です。
例えば、
- お客様が一次対応するのか
- 運用ベンダが対応するのか
- SIerが対応するのか
が曖昧なまま運用開始されるケースがあります。
その結果、
「誰も対応していなかった」
という最悪の事態につながることもあります。
また、オンプレミス環境では保守部材の確保も重要です。
障害発生時に交換部品がなければ、復旧時間が大幅に長引く可能性があります。
クラウド環境でも、
- 障害発生時の切り戻し方法
- バックアップからの復元手順
などを整理しておく必要があります。
運用環境は後回しにすると失敗しやすい
実務で見落とされやすいのが運用環境です。
運用環境には、
- 開発環境
- 検証環境
- 保守環境
- リモート接続環境
- マニュアル類
などが含まれます。
例えば、
「本番環境しか用意していない」
という構成では、パッチ適用前の検証ができません。
また、
「リモート接続環境がない」
場合、障害発生時に現地対応が必要になります。
特に最近はテレワークが一般化しているため、リモートオペレーションの重要性は以前より高まっています。
運用開始後に追加しようとすると大きなコストが発生するため、要件定義段階から整理しておくことが重要です。
サポート体制と役割分担を明確にする
技術的な設計以上に重要なのが、人の体制です。
どれだけ優れたシステムでも、運用体制が整っていなければ安定稼働は実現できません。
サポート体制では、
- ハードウェア保守契約
- ソフトウェア保守契約
- 問い合わせ窓口
- 役割分担
- 教育・訓練
などを整理します。
実務では、
「障害時はベンダが対応すると思っていた」
「運用監視はお客様側が実施すると思っていた」
といった認識齟齬が発生することがあります。
そのため、
- 誰が監視するのか
- 誰が障害対応するのか
- 誰がパッチ適用するのか
を明確にしておく必要があります。
また、運用担当者向けの教育や訓練も重要です。
障害は発生頻度が低いため、実際に発生した際に対応方法が分からないケースもあります。
定期的な訓練や報告会を実施することで、運用品質を向上させることができます。
ITILやインシデント管理も重要な要素
近年のシステム運用では、ITILをベースとした運用管理を採用するケースも増えています。
例えば、
- サービスデスク
- インシデント管理
- 問題管理
- 変更管理
- 構成管理
などです。
小規模システムでは不要な場合もありますが、大規模システムになるほど重要性が高まります。
例えば、変更管理を実施していない場合、
「誰がいつ設定変更したのか分からない」
という事態が発生します。
また、インシデント管理が整備されていない場合、同じ障害が何度も繰り返されることがあります。
これらは直接システム性能に影響するものではありませんが、長期的な運用品質を維持するためには重要な要素です。
まとめ
運用・保守性は、システムを安定して利用し続けるために欠かせない非機能要件です。
特に重要なのは、
- 日々の運用方法を決めること
- 保守作業のルールを決めること
- 障害時の対応を整理すること
- 運用環境を準備すること
- 役割分担を明確にすること
- 運用管理プロセスを整備すること
です。
実務では機能要件や性能要件が優先され、運用・保守性の検討が後回しになることがあります。
しかし、本番稼働後の長い運用期間を考えると、むしろ運用・保守性こそシステム品質を左右する重要な要素と言えるでしょう。
IPAの非機能要求グレードは、運用・保守性を体系的に整理するための優れたフレームワークです。
要件定義の段階からしっかり検討し、運用しやすく保守しやすいシステムを目指しましょう。
コメント