システムを安定稼働させる運用設計 – 検討する３つの分類と検討項目

【目次】
・はじめに
・運用設計の目的と効果
・３つの運用設計
　- 業務運用
　- 基盤運用
　- 運用管理

はじめに

システム構築では、どうしてもシステムを作ることにフォーカスされるのですが、忘れていけないのが「運用設計」です。
ユーザは稼働するシステムを求めているのではなく、サービスが正しく利用できることに関心があります。
システムを安定稼働させるためには、監視やメンテナンスといった運用保守を正しく行うことが大切です。

この運用保守ですが、ただエンジニアを保守要員としてアサインするだけでは安定稼働につながりません。

今回は、システムの運用設計を行うための方法について説明します。

運用設計の目的と効果

そもそも、なぜ運用設計しなければいけないのでしょうか。
それはシステムは機能を提供する手段であり、その機能を利用できる状態を維持するためです。
システム開発はシステムを作ることだけでなく、その先の運用を見据えて行います。
ここで見るべき運用は、システムが安定稼働するための仕組み作り、メンテナンス手順といったシステマティックな内容から、保守体制、運用フローなどの管理方法など幅広いです。

運用設計を正しく行うメリットは、安定稼働につながるだけでなく運用コストを適正化する効果もあります。
どうしてもシステム運用にはコストが発生します。
そのコストが、求められる品質レベルと比べて適正なのか検討する必要もあります。

３つの運用設計

運用設計には、大きく「業務運用」「基盤運用」「運用管理」の３つの分類に分けることができます。

業務運用
ユーザが適切にシステムを活用するための支援を行います。
サービスデスクや利用者申請などの手続きが該当します。

基盤運用
システムを安定稼働させるためにアプリケーションやインフラを管理、メンテナンスします。
バックアップやログ、監視業務などが該当します。

運用管理
システムを運用するためのルールを策定して実行します。
基本的にシステムは単独で動くのではなく、他のシステムと連携していることが多いです。
そのため、システム構築するシステムだけでなく他システム含めて広い視野でルールに問題ないか検討します。

業務運用

システムに関連する業務内容を整理して、運用するための必要事項を検討します。

業務フロー図

システム利用の業務フロー図を作成します。
要件定義で業務フロー図を作成していたら、そちらをブラッシュアップすると良いでしょう。

ちなみに業務フロー図はIPAのサンプルを参考にしてください。

要件定義で作成する業務フロー図は、アプリケーションの操作に特化している場合が多いです。
例えば「新規ユーザを登録する場合は、システム管理者に利用申請を提出する」という運用が必要になる場合があります。
この業務フロー図に人間系の運用について補記したり、発生する業務を確認します。

運用スケジュール

システムの稼働時間、バッチ処理やバックアップ、データ更新の定周期処理など、スケジュールで管理すべき事項があります。
日次、月次、年次の業務やメンテナンスなどのイベントがある場合、それらの実施カレンダーについても管理します。

運用スケジュールを管理することで、システム管理者がいつ、何をするのか把握することができます。
今後のシステム改良において、現行システムの全体を把握するためにも活用されます。

メンテナンス業務

システムを適切に稼働するためのメンテナンス作業を整理します。

ユーザ管理
システムを利用するユーザの管理方法を検討します。
利用できるユーザを把握するだけでなく、ユーザ登録やパスワード再発行などの申請といった手順や書類についても検討します。

データメンテナンス
システムで登録されているマスタデータの変更、組織変更や人事異動などの反映といったデータ更新に関連する運用について検討します。

インフラ関連
サーバなどインフラ機器の点検や不要データの削除などの機器に関する運用を検討します。
システムを利用するためのPCを手配している場合、手配やリース管理なども行います。

リリース
アプリケーションなどのリリース作業を行う場合の手順について整理します。
作業の時間や体制、作業手順、問題発生時の切り戻し方法など、リリース作業が安全に行えるための準備をします。

サポートデスク

ユーザからシステム利用に関する問い合わせ窓口について検討します。
サポートデスクでは、ユーザへの利用説明からトラブル連絡の受付など、様々な対応を受け付けます。
利用者数が少なければシステムを管理する部署で対処することもありますが、問い合わせが頻繁に発生するのであればサポートデスクが必要です。

ちなみにサポートデスクはシステムごとに設置するのではなく、社内の複数システムでまとめて対応すると良いです。
コスト的な問題もありますが、サポートデスクが乱立するとトラブル発生時にシステム間で情報が統制できなくなります。
ユーザも、どこに問い合わせすればよいかわからず混乱する可能性もあります。

システムの重要度や24時間体制など特殊な事情がなければ１つにまとめます。

インシデント管理

システムでトラブルが発生したとき、ビジネスへの影響を最小限に抑えるためのプロセスを検討します。
インシデントに備えて何を準備するのか、またインシデント発生時の対応手順をあらかじめ準備します。

インシデントへの備えについては、別記事「システム障害に備える５つのドキュメント」「システム障害発生時に対応する５つの手順」を参考にしてください。

トレーニング・マニュアル

システムを新規稼働させるとき、ユーザが正しくシステム利用できるように研修などのトレーニングを実施するのか検討します。

またシステム利用のマニュアルの作成についても検討が必要です。
どこまでの手順を作成するのか、どのような資料構成とするのか整理する必要があります。
マニュアル類は、システム構築の見積もりで忘れずにクライアントと相談するべきです。

何の説明もマニュアルもなく、いきなり新しいシステムを使うように言われてもユーザは困ります。
構築したシステムが正しく利用されるためにも、マニュアルや運用手順は用意すべきです。

基盤運用

システムのインフラに関連する運用を検討します。
アプリケーションを安定稼働させるためには、その土台であるインフラがしっかりしていることが重要です。
アプリケーションはプログラムに不具合がなければ想定通りの動作をしますが、インフラは定期的にメンテナンスしないと故障することもあります。

ジョブ管理

バッチやスクリプトを手動で操作するのは大変なので、管理者の作業負荷を軽減するためにスケジュール設定など自動化することで負荷軽減します。
ジョブは管理ソフトを導入したり、タスクスケジューラやcronによるスケジュール実行など様々ですが、運用担当者がジョブの内容や実行方法など把握できるように整理します。

ジョブ管理ですが、考えられる処理を全て自動化すればよいわけではありません。
ジョブではなくアプリケーションとして機能開発したり、あえて人間に操作させる場合もあります。
要件定義でシステム全体を俯瞰しながら自動化の方針を定義したうえで対象を検討します。

バックアップ／リストア

最近のサーバは昔に比べて故障しないのですが、それでも突如としてOSや機器が破損する場合があります。
またメンテナンス作業のミスやアプリケーション不具合によりデータ破損することもあります。

どのようなトラブルが発生しても業務継続できるように、バックアップとリストアの方針を検討して対処します。
ポイントとなるのはリストア時のRPO（目標復旧時点）とRTO（目標復旧時間）により方針が変わります。
障害発生時の直前までデータ復旧したり、復旧までの時間を短くすると、それだけコストがかかります。
システム要件とコストとのバランスで検討します。

詳細については、別記事「バックアップ／リストア」を参照してください。

ログ

ログを使用する目的として、「調査用」「監査用」のために採取します。

調査用は障害発生時に障害ポイントを特定するために使用したり、機能の利用状況といった情報を採取するために使用します。

監査用とういのは、「誰が、いつアクセスしたか」などのセキュリティ監査で使用することがあります。
また法令や社内規定により証跡を残すことが義務付けられている場合もあります。

これらのログ出力を検討するのはアプリケーション側の設計ですが、このログの保管方法、保管期間、保管場所を検討するのは運用設計です。

監視

システムにはアプリからインフラまで様々なコンポーネントが組み合わさって稼働します。
それらの稼働状況を正しく把握し、問題あれば即時対応するためにシステム監視を行います。
監視を設計する場合、異常検知するアーキテクチャだけでなく監視者のオペレーションも含めて検討します。
監視者のオペレーションでは、次のような項目を検討します。

役割（誰が、何を監視するのか）
対応時間
連絡方法
エスカレーションルール
監視記録

特にエスカレーションルールについては、トラブル内容によってルールが変わります。
障害ランクの設定、障害発生時の発報メッセージなど、システムの開発側と連携して検討する必要があります。

システム監視については別記事「システム監視のデザインパターン」を参考にしてください。

パッチ適用

OSやミドルウェアのパッチ適用についての運用を検討します。
このパッチ適用は軽く見られがちですが、やり方によってコストがかかるためクライアントと揉めるケースが多いです。

パッチ適用はセキュリティ対策として非常に重要なので、最新が出たらすぐに適用することが求められます。
しかしパッチ適用することで互換性の問題からシステムが動かなくなる場合があります。
その対策として考えられるのは次の２つです。

①検証環境でパッチ適用後の動作確認を行う
②パッチ内容を分析して、適用して問題ないか検証する

①の場合、本番環境とは別に検証環境を用意する必要があります。
この環境は本番環境と同じサーバ構成が望ましいですが、コスト的に難しい場合はＰＣに疑似環境を作って確認することもあります。
本番環境が冗長構成の場合、片方の本番環境に入れて確認することもありますが、本番環境で問題発生したときの影響を考えるとリスクが高いです。

②の方法もありますが、調査だけでも相当のコストが発生します。
厳密にチェックしてから導入することが求められるプロジェクトやクライアントもありますが、そのコストに見合った内容なのか、クライアントと協議のうえ方針を決めます。

ちなみに①で検証した結果、パッチに含まれる特定のコンポーネントが誤動作を起こすときは、該当コンポーネントをパッチから除外して適用します。
その場合パッチ適用の都度、上記のコンポーネントを除外することになり、非常に手間がかかります。