Managed Service Column ＜システム運用コラム＞第３回：運用設計の考え方―運用管理対象をどういう視点で管理するのか？運用要件から落とし込むときのポイント

システムのクラウド移行が加速する中、「クラウドサービスを活用しているが、クラウド毎に個別に監視・運用をしているため、運用が煩雑化している。どうすればよいか？」「オンプレミスとクラウドを併用することになり、運用管理体制を見直したい」といったお声をいただくことも多くなりました。

システムは構築して終わりではなく、安定稼働するための運用が重要です。そして、システム運用の品質を担保しながら効率を上げていくためには、運用設計が必要となります。

この連載では、運用設計の考え方やの取り組みについて、事例も交えて紹介します（全12回）。

はじめに

前回のコラムでは、システムの目的（あるべき姿）を維持するために監視・管理する、システム構成要素（運用管理対象）の洗い出し方を説明しました。

今回は、運用管理対象をどういう視点で管理すればよいのか、「運用要件」から管理項目に落としこんでいくときの考え方を紹介します。

運用要件とは

運用要件とは、システムを安定稼働させるために必要な要件をいいます。

繰り返しになりますが、システムは構築して終わりではなく、そのシステムの目的を達成し続けるために運用する必要があります。 そのシステムが安定的にサービス提供するためには、ユーザーから求められる要件（いつでも使いたいときに使いたい）や、ビジネスから求められる要件（業界標準以上のセキュリティを実現する、災害時の事業継続性を担保する、急なビジネス拡大にもシステムが追随できる）、開発チームから求められる要件（機能追加時にも継続的にサービス提供できるようにする）など様々な要求に応える必要があります。このシステムリリース後の運用フェーズにおける要求をまとめたものが、「運用要件」となります。

システム（アプリケーション）で実現したい機能に対する要求が「機能要件」であるのに対し、ステークホルダーが「システムが当然満たすべき」と考える運用要件は、「非機能要件」とも言えるでしょう。

IPAによる定義では、非機能要件とはシステム基盤に対する要求を指し、「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の６つの大項目に整理できる、とあります。
( 出典：非機能要求グレード2018 利用ガイド [解説編] 表1.3.2.1 (p.7) より)

非機能要件を実現するために、システム基盤を設計し、システム構成要素を適切に管理します。後者が「システム運用管理」であり、システム運用管理を円滑に進めるためのルール・体制づくりが「運用設計」となります。

運用管理項目とは

運用管理項目とは、「運用要件」を満たすために「運用管理対象の状態」をどういう視点で監視・管理するのか、をまとめたものです。

３つの運用要件から、運用管理項目を洗い出す

ここでは、当社が20年以上にわたりシステム運用サービスをご提供してきた中でとくに重要と考える「３つの運用要件」と、運用管理項目の洗い出し方を説明します。IPA定義の括りとは少し違いますが、押さえるべきポイントは同じです。
（ここでは、システム稼働後の運用のしかたにフォーカスするため、「移行性」、「システム環境・エコロジー」については説明を割愛します。また、非機能要件のうち、システム基盤設計で実現すべき要求項目についても、ここでは省きます）

当社では、システムに求められる運用要件のうち、以下の３つを特に重要だと考えています。

• 可用性：情報を使いたいときに使える状態にしておくこと
  （システムの性能や拡張性に対する要求（性能要件）についても、「使いたいときに使える状態にしておくこと」ととらえ、可用性要件に含めます）
• 完全性：持っている情報を正確かつ完全で許可されていない修正から保護されていること、および、最新の状態で管理すること
• 機密性：情報が漏れないように管理すること

この３つの要件を満たす状態に維持するために、運用管理対象（システム構成要素）をどういう視点で評価・管理すべきか考えていきます。

（関連コラム：「第２回：運用設計の考え方―何を管理するのか？運用管理対象の洗い出し方」）

可用性要件から、何をすべきか考える

可用性は、情報を使いたいときに使える状態にしておくことです。 そのために何をすべきでしょうか。
例えば、24時間のサービスを提供しているシステムでは、サービス停止が直接売上に影響する、または停止による信用失墜が生じるので、そうならないためにシステムを冗長化し耐障害性を高めること、保全しているデータが消滅しないことなどを行うことでシステムの可用性を高めていきます。

システム運用を行う立場から見た、可用性を維持するための押さえるべき項目は以下になります。

• システムが提供するサービス（機能）の正常性 と 異常性 が全て認識出来ているか
• 利用者が享受するサービスの正常性を監視出来ているか
• 利用者が享受するサービスの性能目標（応答時間や同時アクセス数など）を評価するための監視が出来ているか
• サービス提供に必要な設備、ハードウェア、ソフトウェア、アプリケーション、サービスの状態を監視出来ているか
• 冗長化構成された機構のハードウェアやソフトウェアの状態をモニタリング出来ているか、冗長化されたシステム間でのデータ同期が正しく機能しているかを監視出来ているか

• システムに障害が発生した際の切替動作を定期的に検証できているか
• 冗長化されたシステム間でのデータ同期に障害が発生した際のリカバリ方法を検証できているか
• 保管したデータからの復元が正しく行えることを定期的に検証できているか

完全性要件から、何をすべきか考える

完全性とは、持っている情報を完全かつ正確で、許可されていない修正から保護されていること、最新の状態で管理することです。
「持っている情報」とは漠然とした書き方ですが、一例としては、サーバーやネットワーク機器の設定情報やアカウント情報、システムの設計書、操作マニュアル、障害対応手順書などがあります。これらの情報は、機能追加や構成変更時に更新する必要があります。

システム運用を行う立場から見た、完全性を維持するための押さえるべき項目は以下になります。

• システムや機能を変更する際の操作マニュアルの更新手順や検証・承認フローは機能しているか
• システム構成が変更された場合の設計書類の更新手順や検証・承認フローは機能しているか
• システムや機能が変更された際の障害対応マニュアルの更新手順や検証・承認フローは機能しているか
• 設定情報、仕様書、マニュアル類の世代管理は行われているか
• 適切なアカウント管理やアクセス制御は行われているか

機密性要件から、何をすべきか考える

機密性とは、情報が漏れないように管理することです。
機密性要件を実現するには、決められた人だけが対象のデータにアクセスできるようにする、脆弱性に対応したセキュリティパッチを速やかに適用する、守るべき箇所に応じたセキュリティ製品を導入することで、悪意を持った人間が行う侵入・改ざん・搾取の防止とヒューマンエラーによる情報漏えいリスクを回避します。

システム運用を行う立場から見た、機密性を維持するための押さえるべき項目は以下になります。

• アカウント追加・変更・削除の手順や承認フローは機能しているか
• システムを構成している各種リソースへのアクセス権が、目的通り維持出来ているか
• 機器、ファームウェア、オペレーティングシステム、ミドルウェア、アプリケーションに対する脆弱性情報は把握出来ているか、脆弱性が発見された場合の修正の適用手順や承認フローは機能しているか
• 認証ログをはじめとしたセキュリティログは収集されているか

• 重要なデータは安全に保管出来ているのか
• ログイン管理を行い、不当に設定情報等が変更されない仕組みか
• 収集されているログからは、不自然な通信（業務利用外のURLへの定期的な通信、業務時間外の通信）や、通常の認証要求とは異なる特殊な操作要求が行われたことを検知できているか

このように運用管理項目を特定したら、必要な監視仕様や運用手順を作成していくことができるようになります。

まとめ

今回は、運用管理対象をどういう視点で管理するのか（運用管理項目）を、「可用性」「完全性」「機密性」といった運用要件から落としこんでいく考え方を説明しました。

管理項目を特定出来たら、監視仕様や運用手順書の作成に入れますが、その前に、次回は「システム運用方針のまとめ方と、運用体制を構築する際に考えるべきこと」を説明します。

運用設計のポイントを手っ取り早く把握したい方へ

クラウド運用課題を解決する「運用設計の考え方」「運用設計のフレームワーク」のポイントを手っ取り早く把握したい！という方は、以下のホワイトペーパー「運用設計が丸わかり！クラウド運用課題解決への４ステップ（運用設計ガイド）」もあわせてご参照ください。

「クラウド運用の課題と対応策」や「自社で運用設計する際の課題」、「運用設計と継続的な運用改善を継続させるポイント」も記載していますので、参考になさってください。

Tag： 運用設計

• 

  第２回：運用設計の考え方―何を管理するのか？運用管理対象の洗い出し方

• 

  第４回：システム運用方針のまとめ方と、運用体制構築に必要なこと